Bug#365427: Autotests for apt-build utility

2021-04-16 Thread Brian Thompson
On Thu, 15 Nov 2018 23:40:07 +0300 =?UTF-8?B?0JrQvtC70Y8g0JPRg9GA0YzQtdCy?=  wrote:> I intend to do some refactoring of apt-build, but first I'd like to> write autopkgtests for the package. I have two versions of a simple test> case for install command, and I still can't decide what language use for> tests. In attachment you'll find two identical scripts in Bash and Perl.> Comments are welcome!> > It'd be good to write full tests before new year and buster freeze.> > To be clear: I'm not going to adopt the package yet, because I'm unsure> that I have enough time for this work.>  @Axel Beckert This is the message I was referring to from “2016”. I would like to adopt this package if no one else has. Best regards, Brian Thompson 


Bug#987061: Further information

2021-04-16 Thread Kurt Fitzner
Further digging shows this error to be caused by phpMyAdmin's default
connection collation being set to "utfmb4_unicode_ci".  Every new user
that logs in to phpMyAdmin will have its connection collation set to
"utfmb4_unicode_ci" by default.  Unfortunately, that collation is
incompatible with Debian's MariaDB server default collation of
"utfmb4_general_ci".  You cannot mix unicode and general collations in
queries and views. 

To correct this problem this package's default connection collation
needs to be set to "utfmb4_general_ci", or the Debian's Maria DB server
package's default server collation needs to be changed to the more
appropriate "utfmb4_unicode_ci".

Bug#986993: release-notes: Mention OpenJDK 17 status in bullseye

2021-04-16 Thread Justin B Rye
Paul Gevers wrote:
> Attached patch ready to push.

> +  
> +OpenJDK 17
> +
> +  Debian bullseye comes with an early access version of
> +  OpenJDK 17 (the next expected
> +  OpenJDK LTS version after OpenJDK
> +  11), to avoid the rather tedious bootstrap
> +  process. OpenJDK 17 will be updated in
> +  bullseye to the final upstream release announced for October
> +  2021. Security updates for OpenJDK 17 are
> +  planned on a best effort basis, but don't expect to see updates
> +  for every quarterly upstream security update.
> +
> +  

That looks good as it is; or here's a relatively futureproofed variant
that might work better in November:

 process. The plan is for OpenJDK 17 to
 receive an update in bullseye to the final upstream release
 announced for October 2021, followed by security updates on
 a best effort basis, but users should not expect to see
 updates for every quarterly upstream security update.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)

2021-04-16 Thread Justin B Rye
Paul Gevers wrote:
> How about (dropping the package specific section, and just merge it into
> upgrade items):
> 5.1. Upgrade specific items for bullseye
> 5.2. Items not limited to the upgrade process
>  * Limitations in security support
>  * Gnome accessibility issue
>  * password-less rescue mode
> 5.3. Obsolescence and deprecation
>  * Noteworthy obsolete packages
>  * Deprecated components for bullseye

That's just about what I was thinking, if I'd taken the trouble to
look up the section numbers.
 
> Now I'm going over it, the Python2 is probably also not in the right
> section. I think it warrants to be mentioned under "Noteworthy obsolete
> packages" (section of 5.1) as the Python2 deprecation has resulted in *a
> lot* of Python2 packages to have been removed.

If we move it then it probably also needs... maybe just an extra line:

Python 2 is already beyond its End Of Life, and will receive no
security updates. It is not supported for running applications,
  + and packages relying on it have either been switched to Python 3 or removed.
However, Debian bullseye does still include a version of Python 2.7,

> Paul
> PS: on the one hand it feels more natural to have deprecate before
> obsolete, but on the other hand I guess it's more important to learn
> about obsolete packages, so that goes first?

I like having "obsolete" first; maybe that's because I'm hoping to
get a py2less system this summer but I'm still treating the
deprecation of unmerged /usr as just a cloud on the horizon.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



Bug#987063: gwenview: looses image metadata on jpg rotation

2021-04-16 Thread Norbert Preining
On Fri, 16 Apr 2021, Nicholas D Steeves wrote:
> Justification: loss of exif metadata.  A photographer would say "grave 
> severity"!

Uploaded a fixed version.

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13



Bug#365427: [O: apt-build] Is this package worth adopting or has it been replaced?

2021-04-16 Thread Axel Beckert
Hi,

No Body wrote:
> Is this package worth adopting or has it been replaced by something
> else?

There's nothing like it so far AFAIK. apt-src is close, but has a
different focus (modification instead of compile-time optimization).

> I read the entire bug message history and saw that in 2016 there was some
> development going on to replace the package.

I don't see which message you mean. In 2016, there were only control
messages and spam in this bug report.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#987063: gwenview: looses image metadata on jpg rotation

2021-04-16 Thread Norbert Preining
severity -1 serious
thanks

Meta data is data, and losing exif data is extremely bad.

I will upload a new package later today, that needs urgent fixing.

Thanks for the pointer to the PR.

Norbert
-- 
PREINING Norbert  https://www.preining.info
Fujitsu   + IFMGA ProGuide + TU Wien + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Apr 17, 2021 12:18:29 Nicholas D Steeves :

> Control: tag -1 + patch
> Control: severity -1 important
> Justification: loss of exif metadata.  A photographer would say "grave 
> severity"!
> 
> Hi Karsten,
> 
> Karsten Hilbert  writes:
> 
>> Package: gwenview
>> Version: 4:20.12.3-1
>> Severity: normal
>> Tags: upstream
>> 
>> This release started to drop metadata from JPEG files after rotating
>> them. I do believe the following upstream commit is the culprit:
>> 
>>   
>> https://invent.kde.org/graphics/gwenview/commit/a401e66621bcffbdc75048d9eaded1a5f5a67137
>> 
>> because it "unconditionally" saves JPEGs thereby overwriting them w/o
>> carrying over metadata :(
>> 
> 
> Thank you very for filing this bug.  I agree, this is a nasty issue that
> will compromise Debian's reputation for reliability and a reassuring
> policy of no data-loss bugs in stable releases.  IMHO this bug is RC,
> but strictly speaking metadata isn't data, which is why I chose
> "important"...nevertheless, no one should be punished for viewing a
> photo in Gwenview rather than Darktable!
> 
> The emergency quick fix is here:
> https://invent.kde.org/graphics/gwenview/-/commit/7e59f65fb1f14c36fcf12683c6eacb5f658dc3fc
> 
> from the PR:
> https://invent.kde.org/graphics/gwenview/-/merge_requests/57
> 
> Cheers,
> Nicholas



Bug#987063: gwenview: looses image metadata on jpg rotation

2021-04-16 Thread Nicholas D Steeves
Control: tag -1 + patch
Control: severity -1 important
Justification: loss of exif metadata.  A photographer would say "grave 
severity"!

Hi Karsten,

Karsten Hilbert  writes:

> Package: gwenview
> Version: 4:20.12.3-1
> Severity: normal
> Tags: upstream
>
> This release started to drop metadata from JPEG files after rotating
> them. I do believe the following upstream commit is the culprit:
>
>   
> https://invent.kde.org/graphics/gwenview/commit/a401e66621bcffbdc75048d9eaded1a5f5a67137
>
> because it "unconditionally" saves JPEGs thereby overwriting them w/o
> carrying over metadata :(
>

Thank you very for filing this bug.  I agree, this is a nasty issue that
will compromise Debian's reputation for reliability and a reassuring
policy of no data-loss bugs in stable releases.  IMHO this bug is RC,
but strictly speaking metadata isn't data, which is why I chose
"important"...nevertheless, no one should be punished for viewing a
photo in Gwenview rather than Darktable!

The emergency quick fix is here:
https://invent.kde.org/graphics/gwenview/-/commit/7e59f65fb1f14c36fcf12683c6eacb5f658dc3fc

from the PR:
https://invent.kde.org/graphics/gwenview/-/merge_requests/57

Cheers,
Nicholas


signature.asc
Description: PGP signature


Bug#365427: Is this package worth adopting or has it been replaced?

2021-04-16 Thread No Body
Is this package worth adopting or has it been replaced by something else?
I read the entire bug message history and saw that in 2016 there was some
development going on to replace the package.  Has that already been done?
If so, then I presume there is no point in adopting this package.


Bug#985424: vorta: "Backup successful" notification even if return code is 1

2021-04-16 Thread Nicholas D Steeves
clone 985424 -1
retitle -1 vorta: "Backup successful" notification even if return code is 1
notforwarded -1
thanks

Gah, forgot the "-1".  Now fixed.


signature.asc
Description: PGP signature


Bug#978105: vorta: SIGSEGV on exit

2021-04-16 Thread Nicholas D Steeves
clone 978105 -1
reopen -1
retitle -1 vorta: another SIGSEGV on exit (after creating a new profile)
thanks


signature.asc
Description: PGP signature


Bug#985424: vorta: "Backup successful" notification even if return code is 1

2021-04-16 Thread Nicholas D Steeves
retitle 985424 vorta: emits "Backup successful" even when source paths are 
inaccessible (thus not backed up)
clone 985424
thanks


signature.asc
Description: PGP signature


Bug#985424: vorta: "Backup successful" notification even if return code is 1

2021-04-16 Thread Nicholas D Steeves
Control: forwarded -1 https://github.com/borgbase/vorta/issues/916
Control: severity -1 important

Hi Sandro!

Sorry for my delay replying, and thank you *very much* for reporting
this bug.

Sandro Tosi  writes:

> Package: vorta
> Version: 0.7.5-1
> Severity: normal
>
> Hello,
> i have a few unaccessible files, so vorta during the backup records that, and
> the backup itself finished with a return code of 1.
>
> but the notification says "backup successful" -- that's rather confusing
>
> - does the return code of the backup not indicate the success or not of the
>   backup?
> - will the backup end up not being succesful only if a specific list of return
>   codes are returned?
>

I've bumped the severity of this bug, because it sounds like it's not
clear that Vorta assumes that a backup consists solely of $USER
accessible paths, and this may result in the following case:

1. User adds / as a source
2. "backup successful"
3. Catastrophic system failure
4. Restoring from backup results in a broken Debian installation
5. User feels betrayed, Debian reputation for reliability suffers, trust
in Vorta suffers.

IMHO backup software reliability is like a file system reliability or
anything email-related--unexpected behaviour or bugs that result in an
incomplete dataset will prejudice the user against the software
forever.

To be fair, upstream is open about this limitation, but it sounds like
it's not visible enough, and permission checks are--after all--a
cornerstone of correct design ;-)

Regards,
Nicholas


signature.asc
Description: PGP signature


Bug#987066: xfce4-panel: Crashes when removing a launcher

2021-04-16 Thread James Valleroy
Package: xfce4-panel
Version: 4.16.2-1
Severity: important
X-Debbugs-Cc: jvalle...@mailbox.org

Dear Maintainer,

   * What led up to the situation?

I removed a launcher. I tried this 3 times, with 3 different
launchers, and had the same result.
   
   * What exactly did you do (or not do) that was effective (or ineffective)?

I right-clicked on a launcher in a panel, and clicked remove.

   * What was the outcome of this action?

All the panels disappear. After logging out and logging in again, I
can see that the launcher has been removed.

   * What outcome did you expect instead?

The launcher should be removed without all the panels disappearing.

I took a log with PANEL_DEBUG=1, so I will attach that to this report.

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

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

Versions of packages xfce4-panel depends on:
ii  exo-utils4.16.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-11
ii  libcairo21.16.0-5
ii  libdbusmenu-gtk3-4   18.10.20180917~bzr492+repack1-2
ii  libexo-2-0   4.16.0-1
ii  libgarcon-1-04.16.1-1
ii  libgarcon-gtk3-1-0   4.16.1-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libwnck-3-0  3.36.0-1
ii  libx11-6 2:1.7.0-2
ii  libxext6 2:1.3.3-1.1
ii  libxfce4panel-2.0-4  4.16.2-1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1
ii  libxfconf-0-34.16.0-2

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information
james@desk:~$ xfce4-panel -q
james@desk:~$ PANEL_DEBUG=1 xfce4-panel
xfce4-panel(main): version 4.16.2 on gtk+ 3.24.24 (3.24.24), glib 2.66.8 
(2.66.7)
xfce4-panel(module-factory): reading /usr/share/xfce4/panel/plugins
xfce4-panel(application): found window manager after 1 tries
xfce4-panel(base-window): 0x5591ecbabde0: rgba visual=0x5591ecb77ca0, 
compositing=true
xfce4-panel(base-window): 0x5591ecbabde0: rgba visual=0x5591ecb77ca0, 
compositing=true
xfce4-panel(display-layout): 0x5591ecbabde0: display=:0.0{comp=true}, 
screen-0[0x5591ecb5e020]=[3840,1080] (HDMI-A-0=[0,0;1920,1080], 
HDMI-A-1=[1920,0;1920,1080])
xfce4-panel(positioning): 0x5591ecbabde0: screen=0x5591ecb5e020, monitors=2, 
output-name=Primary, span-monitors=false, base=0,0
xfce4-panel(positioning): 0x5591ecbabde0: working-area: screen=0x5591ecb5e020, 
x=0, y=0, w=1920, h=1080
xfce4-panel(struts): 0x5591ecbabde0: top=62, start_x=0, end_x=3838
xfce4-panel(module): new item (type=object-type, name=applicationsmenu, id=1)
xfce4-panel(module): new item (type=object-type, name=tasklist, id=3)
xfce4-panel(module): new item (type=object-type, name=separator, id=15)
xfce4-panel(external): register dbus path /org/xfce/Panel/Wrapper/6
xfce4-panel(module): new item (type=external-wrapper, name=systray, id=6)
xfce4-panel(external): systray-6: child spawned; pid=28405, argc=7
xfce4-panel(external): register dbus path /org/xfce/Panel/Wrapper/16
xfce4-panel(module): new item (type=external-wrapper, name=pulseaudio, id=16)
xfce4-panel(external): pulseaudio-16: child spawned; pid=28406, argc=7
xfce4-panel(module): new item (type=object-type, name=pager, id=4)
xfce4-panel(module): new item (type=object-type, name=clock, id=5)
xfce4-panel(base-window): 0x5591ece72880: rgba visual=0x5591ecb77ca0, 
compositing=true
xfce4-panel(base-window): 0x5591ece72880: rgba visual=0x5591ecb77ca0, 
compositing=true
xfce4-panel(base-window): 0x5591eceb6280: rgba visual=0x5591ecb77ca0, 
compositing=true
xfce4-panel(display-layout): 0x5591ece72880: display=:0.0{comp=true}, 
screen-0[0x5591ecb5e020]=[3840,1080] (HDMI-A-0=[0,0;1920,1080], 
HDMI-A-1=[1920,0;1920,1080])
xfce4-panel(positioning): 0x5591ece72880: screen=0x5591ecb5e020, monitors=2, 
output-name=Primary, span-monitors=false, base=0,0
xfce4-panel(positioning): 0x5591ece72880: unset struts edge; between monitors
xfce4-panel(positioning): 0x5591ece72880: working-area: screen=0x5591ecb5e020, 
x=0, y=0, w=1920, h=1080
xfce4-panel(external): register dbus path /org/xfce/Panel/Wrapper/14
xfce4-panel(module): new item (type=external-wrapper, name=whiskermenu, id=14)
xfce4-panel(external): whiskermenu-14: child spawned; pid=28410, argc=7
xfce4-panel(module): new item (type=object-type, name=separator, id=13)
xfce4-panel(module): new item (type=object-type, name=launcher, id=12)

(xfce4-panel:28401): garcon-CRITICAL **: 17:08:45.428: 

Bug#987071: unblock: netbase/6.3

2021-04-16 Thread Marco d'Itri
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package netbase

One port added.

unblock netbase/6.3

-- 
ciao,
Marco
diff -Nru netbase-6.2/debian/changelog netbase-6.3/debian/changelog
--- netbase-6.2/debian/changelog	2020-10-04 18:06:02.0 +0200
+++ netbase-6.3/debian/changelog	2021-03-27 23:33:28.0 +0100
@@ -1,3 +1,12 @@
+netbase (6.3) unstable; urgency=medium
+
+  * services: added ntske (4460/tcp). (Closes: #983592)
+  * services: removed the disclaimer about non-used transports.
+It is not relevant anymore because all such entries for ports assigned to
+non-used transports should have been removed starting from release 5.4.
+
+ -- Marco d'Itri   Sat, 27 Mar 2021 23:33:28 +0100
+
 netbase (6.2) unstable; urgency=medium
 
   * services: added https (443/udp) which was removed in 5.4 but now is
diff -Nru netbase-6.2/etc/services netbase-6.3/etc/services
--- netbase-6.2/etc/services	2020-10-04 16:27:46.0 +0200
+++ netbase-6.3/etc/services	2021-03-27 23:32:57.0 +0100
@@ -1,9 +1,5 @@
 # Network services, Internet style
 #
-# Note that it is presently the policy of IANA to assign a single well-known
-# port number for both TCP and UDP; hence, officially ports have two entries
-# even if the protocol doesn't support UDP operations.
-#
 # Updated from https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml .
 #
 # New ports will be added on request if they have been officially assigned
@@ -217,6 +213,7 @@
 epmd		4369/tcp			# Erlang Port Mapper Daemon
 remctl		4373/tcp		# Remote Authenticated Command Service
 f5-iquery	4353/tcp			# F5 iQuery
+ntske		4460/tcp	# Network Time Security Key Establishment
 ipsec-nat-t	4500/udp			# IPsec NAT-Traversal [RFC3947]
 iax		4569/udp			# Inter-Asterisk eXchange
 mtn		4691/tcp			# monotone Netsync Protocol


signature.asc
Description: PGP signature


Bug#987072: unblock: whois/5.5.9

2021-04-16 Thread Marco d'Itri
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package whois

[ Reason ]
Updated the internal databases.

[ Impact ]
Will not work correctly for some domains.

[ Tests ]
No, anybody who cares feel free to contribute some.

[ Risks ]
Only data changes.

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

[ Other info ]
Yes, VERSION is obviously wrong but it is in the package in testing as 
well.

unblock whois/5.5.9

-- 
ciao,
Marco
diff -Nru whois-5.5.8/debian/changelog whois-5.5.9/debian/changelog
--- whois-5.5.8/debian/changelog	2021-02-16 01:53:57.0 +0100
+++ whois-5.5.9/debian/changelog	2021-03-28 00:38:20.0 +0100
@@ -1,3 +1,11 @@
+whois (5.5.9) unstable; urgency=medium
+
+  * Updated the .ga TLD server.
+  * Removed the .cd and cf TLD servers.
+  * Removed 72 new gTLDs which are no longer active.
+
+ -- Marco d'Itri   Sun, 28 Mar 2021 00:38:20 +0100
+
 whois (5.5.8) unstable; urgency=medium
 
   * Added the .xn--4dbrk0ce (.ישראל, Israel) TLD server.
diff -Nru whois-5.5.8/new_gtlds_list whois-5.5.9/new_gtlds_list
--- whois-5.5.8/new_gtlds_list	2020-10-27 18:29:26.0 +0100
+++ whois-5.5.9/new_gtlds_list	2021-02-28 12:58:38.0 +0100
@@ -19,7 +19,6 @@
 accountant
 accountants
 aco
-active
 actor
 adac
 ads
@@ -32,7 +31,6 @@
 agakhan
 agency
 aig
-aigo
 airbus
 airforce
 airtel
@@ -121,14 +119,12 @@
 bio
 black
 blackfriday
-blanco
 blockbuster
 blog
 bloomberg
 blue
 bms
 bmw
-bnl
 bnpparibas
 boats
 boehringer
@@ -138,7 +134,6 @@
 boo
 book
 booking
-boots
 bosch
 bostik
 boston
@@ -179,10 +174,8 @@
 career
 careers
 cars
-cartier
 casa
 case
-caseih
 cash
 casino
 catering
@@ -191,7 +184,6 @@
 cbn
 cbre
 cbs
-ceb
 center
 ceo
 cern
@@ -204,10 +196,8 @@
 chat
 cheap
 chintai
-chloe
 christmas
 chrome
-chrysler
 church
 cipriani
 circle
@@ -301,11 +291,8 @@
 dnp
 docs
 doctor
-dodge
 dog
-doha
 domains
-doosan
 dot
 download
 drive
@@ -313,7 +300,6 @@
 dubai
 duck
 dunlop
-duns
 dupont
 durban
 dvag
@@ -329,19 +315,16 @@
 engineer
 engineering
 enterprises
-epost
 epson
 equipment
 ericsson
 erni
 esq
 estate
-esurance
 etisalat
 eurovision
 eus
 events
-everbank
 exchange
 expert
 exposed
@@ -381,7 +364,6 @@
 flir
 florist
 flowers
-flsmidth
 fly
 foo
 food
@@ -441,7 +423,6 @@
 goldpoint
 golf
 goo
-goodhands
 goodyear
 goog
 google
@@ -487,7 +468,6 @@
 homes
 homesense
 honda
-honeywell
 horse
 hospital
 host
@@ -499,7 +479,6 @@
 house
 how
 hsbc
-htc
 hughes
 hyatt
 hyundai
@@ -509,7 +488,6 @@
 icu
 ieee
 ifm
-iinet
 ikano
 imamat
 imdb
@@ -523,29 +501,24 @@
 institute
 insurance
 insure
-intel
 international
 intuit
 investments
 ipiranga
 irish
-iselect
 ismaili
 ist
 istanbul
 itau
 itv
 iveco
-iwc
 jaguar
 java
 jcb
-jcp
 jeep
 jetzt
 jewelry
 jio
-jlc
 jll
 jmp
 jnj
@@ -578,12 +551,10 @@
 kuokgroup
 kyoto
 lacaixa
-ladbrokes
 lamborghini
 lamer
 lancaster
 lancia
-lancome
 land
 landrover
 lanxess
@@ -601,7 +572,6 @@
 lego
 lexus
 lgbt
-liaison
 lidl
 life
 lifeinsurance
@@ -635,7 +605,6 @@
 ltd
 ltda
 lundbeck
-lupin
 luxe
 luxury
 macys
@@ -655,8 +624,6 @@
 maserati
 mattel
 mba
-mcd
-mcdonalds
 mckinsey
 med
 media
@@ -666,9 +633,7 @@
 memorial
 men
 menu
-meo
 merckmsd
-metlife
 miami
 microsoft
 mini
@@ -679,7 +644,6 @@
 mls
 mma
 mobile
-mobily
 moda
 moe
 moi
@@ -687,8 +651,6 @@
 monash
 money
 monster
-montblanc
-mopar
 mormon
 mortgage
 moscow
@@ -696,15 +658,11 @@
 motorcycles
 mov
 movie
-movistar
 msd
 mtn
-mtpc
 mtr
 mutual
-mutuelle
 nab
-nadex
 nagoya
 nationwide
 natura
@@ -716,7 +674,6 @@
 network
 neustar
 new
-newholland
 news
 next
 nextdirect
@@ -760,16 +717,13 @@
 oracle
 orange
 organic
-orientexpress
 origins
 osaka
 otsuka
 ott
 ovh
 page
-pamperedchef
 panasonic
-panerai
 paris
 pars
 partners
@@ -788,7 +742,6 @@
 photography
 photos
 physio
-piaget
 pics
 pictet
 pictures
@@ -858,7 +811,6 @@
 rich
 richardli
 ricoh
-rightathome
 ril
 rio
 rip
@@ -886,7 +838,6 @@
 sandvikcoromant
 sanofi
 sap
-sapo
 sarl
 sas
 save
@@ -903,7 +854,6 @@
 schwarz
 science
 scjohnson
-scor
 scot
 search
 seat
@@ -931,7 +881,6 @@
 shouji
 show
 showtime
-shriram
 silk
 sina
 singles
@@ -956,19 +905,15 @@
 soy
 spa
 space
-spiegel
 sport
 spot
 spreadbetting
 srl
-srt
 stada
 staples
 star
-starhub
 statebank
 statefarm
-statoil
 stc
 stcgroup
 stockholm
@@ -989,7 +934,6 @@
 swiftcover
 swiss
 sydney
-symantec
 systems
 tab
 taipei
@@ -1006,8 +950,6 @@
 team
 tech
 technology
-telecity
-telefonica
 temasek
 tennis
 teva
@@ -1051,7 +993,6 @@
 tvs
 ubank
 ubs
-uconnect
 unicom
 university
 uno
@@ -1075,8 +1016,6 @@
 virgin
 visa
 vision
-vista
-vistaprint
 viva
 vivo
 vlaanderen
@@ -1093,7 +1032,6 @@
 walter
 wang
 wanggou
-warman
 watch
 watches
 weather
@@ -1146,8 +1084,6 @@
 xn--6qq986b3xl
 xn--80adxhks
 xn--80aqecdr1a
-xn--80asehdb
-xn--80aswg
 xn--8y0a063a
 xn--9dbq2a
 

Bug#875958: sa-compile: The package fails to run sa-compile

2021-04-16 Thread rob

I had the same issue :

Running sa-compile (may take a long time)
This account is currently not available.
dpkg: error processing package sa-compile (--configure):
 installed sa-compile package post-installation script subprocess 
returned error exit status 1

Errors were encountered while processing:
 sa-compile


to fix in /etc/passwd

old:

debian-spamd:x:111:118::/var/lib/spamassassin:/usr/sbin/nologin

new:

debian-spamd:x:111:118::/var/lib/spamassassin:/bin/bash


I had tried moving /etc/profile.d out of the way , that did not fix the 
error here.



we are using debian stable

# apt show sa-compile
Package: sa-compile
Version: 3.4.2-1+deb10u3



Bug#987070: reportbug: Support GNU BTS at debbugs.gnu.org

2021-04-16 Thread Kevin Locke
Package: reportbug
Version: 7.10.3
Severity: wishlist

Dear Maintainers,

It would be great if reportbug could be used to query and report bugs to
the debbugs-based GNU BTS at https://debbugs.gnu.org, presumably via
`-B gnu` or similar.

Thanks for considering,
Kevin

P.S. I started working on a patch to add support until I realized that
python3-debianbts only supports bugs.debian.org (Bug #949867), which may
make adding support difficult.



Bug#985481: debootstrap: Detection of docker container is broken with cgroup v2

2021-04-16 Thread Nicholas D Steeves
Control: affects -1 release-notes

Hi Arnaud!

Adding src:docker.io maintainers and Shengjing Zhu (recent uploader) to
CC list.

Arnaud Rebillout  writes:

> Hello Nicholas! Thanks for your feedback here, see replies below.
>

You're welcome :-)

> On Sun, 11 Apr 2021 11:51:20 -0400 Nicholas D Steeves 
>  wrote:
>
>  > I'm not sure that systemd-detect-virt and your patch are
>  > forward-compatible in light of
[snip]
>  > This makes it sounds like ".dockerenv" may be deprecated and later
>  > removed.
>
> That's a good point, but it's also a 5 years old comment, and the 
> .dockerenv file is still present these days.
>
> I would think that if Docker plans to remove it, they will issue a more 
> formal deprecation warning that will give us enough time to fix things 
> on our side. Also the fact that systemd checks for this file gives me 
> more confidence that it's not just me doing something fancy here: it 
> seems that this is the "de facto" solution to detect docker containers.
>
> FWIW, it's also the most common solution on Q sites like 
> stackoverflow. Other people do that, because there is no better solution 
> provided apparently. Unless I missed it.
>

Yes, I agree; It appears to be the defacto solution, and might very well
be the only solution for Bullseye in the sense that "perfect is the
enemy of the good", ie: that it's better to solve this issue in a
non-future compatible way to solve a bonafide issue in Bullseye; Later,
a future alternative to /.dockerenv can be documented in Debian.NEWS
and/or release-notes for Bookworm.

>  > Cgroup v2 is also mounted at /sys/fs/cgroup, so I wonder if the original
>  > check should be rewritten to check for something under this path instead
>  > of mountinfo?  Also, using this /sys/fs/cgroup method, I'm not sure if
>  > it's better debootstrap style to express the OR logical operator in the
>  > regex or a shell "||" (ie: seems to be needed because the tree under
>  > /sys/fs/cgroup is different between v1 and v2).
>
> I just had a quick look in /sys/fs/cgroup from within a container. 
> Nothing obvious stands out, there's no file named docker, and nothing in 
> the content of those files mentions docker. I'll attach the output below.
>
> I will CC Tianon, as he was the author of the comment mentioned above, 
> and he might know better, 5 years after :)
>
> In short, Tianon, if you're reading those lines, our question is: what 
> would be the right way to detect that we're running from within a docker 
> container, apart from checking for the existence of the file 
> `/.dockerenv` ???
>

Thank you for this investigation!  I was also unable to find an
alternative is_running_in_docker cgroupv2 check using /sys/fs/cgroup.
Hopefully one of the src:docker.io maintainers knows!  I've also added
"affects release-notes" (and filed separate release-notes bugs) to
defend against a worst-case scenario where this bug isn't resolved in
time.


Regards,
Nicholas


signature.asc
Description: PGP signature


Bug#986861: pragha: No way of sorting album by track number

2021-04-16 Thread Gabriel F. T. Gomes
Hello again, Pelle,

I just tested it under sway and the column selection pop up showed up
normally. Perhaps I'm using Sway the wrong way?

I simply installed it with apt install sway; logged in from lightdm,
learned how to open a terminal, and launched pragha from it. Then, when
I right click on the headers row, the column list pops up and the
following message is written to the controlling terminal:

  Gdk-Message: 19:35:07.947: Window 0x55e815cb2070 is a temporary window 
without parent, application will not be able to position it on screen.

  (pragha:210292): Gdk-CRITICAL **: 19:35:07.949: 
gdk_wayland_window_handle_configure_popup: assertion 'impl->transient_for' 
failed


Do you get any similar messages?
Perhaps your messages are different and might help us deciding whether
the bug is in pragha or in sway.

Cheers,
Gabriel



Bug#987069: document which file systems support cgroupv2 I/O controller

2021-04-16 Thread Nicholas D Steeves
Package: release-notes
Severity: normal

Hi,

Last I checked, only btrfs supports the cgroupv2 I/O controller; this
should probably be documented.  Alternatively, if more than btrfs (ie:
XFS and ext4) supports it, but not other file systems (ie: f2fs,
reiser4, jfs, etc) than this should be documented.

As far as I can tell, the significance of this is as follows: Buster
switched to mq-deadline, which does not support the idle I/O priority,
and to get functional ionice the user/sysadmin had to switch to the
non-mq CFQ, or bfq.  The situation in a default Bullseye install is
better, but only for file systems that support the cgroupv2 I/O
controller.

Regards,
Nicholas



Bug#987061: phpmyadmin: Error "Illegal mix of collations" when clicking on Priviliges tab after default installation

2021-04-16 Thread Kurt Fitzner
Package: phpmyadmin
Version: 4:5.0.4+dfsg2-2
Severity: important
Tags: l10n

Dear Maintainer,

A rather important component of phpmyadmin is the ability to change and set 
privileges on tables and columns.
This feature if brokon on a current default install of phpmyadmin when used 
with a default install of MariaDB
on Debian 11/Testing.

Clicking on the "privileges" tab reders the following error:
#1267 - Illegal mix of collations (utf8mb4_general_ci,COERCIBLE) and 
(utf8mb4_unicode_ci,COERCIBLE) for operation '<>'

The database installation is completely default.  No changes have been made to 
default collations after the installation
of mariadb-server.

Reproduction involves installing, logging in, and clicking.  Namely from a 
vanilla Debian 11 (testing) environment...
 - Install and configure your web server of choice with tls (lighttpd in my 
case) 
 - Install mariadb-server and phpmyadmin with all required dependencies
 - Work around the current phpmyadmin bugs with respect to php-cgi-cfm if using 
lighttpd
   (Bugs #979380 and #979421)
 - Add a mariadb login user to use with phpmyadmin
 - Log in to phpmyadmin, click on any database and then the "privileges" tab.



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

Kernel: Linux 5.10.0-5-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 phpmyadmin depends on:
ii  dbconfig-common   2.0.19
ii  dbconfig-mysql2.0.19
ii  debconf [debconf-2.0] 1.5.75
ii  libjs-bootstrap4  4.5.2+dfsg1-6
ii  libjs-codemirror  5.59.2+~cs0.23.109-1
ii  libjs-jquery  3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-mousewheel   1:3.1.13-2
ii  libjs-jquery-timepicker   1.6.3-1
ii  libjs-jquery-ui   1.12.1+dfsg-8
ii  libjs-openlayers  2.13.1+ds2-8
ii  libjs-sphinxdoc   3.4.3-2
ii  php-cli   2:7.4+76
ii  php-common2:76
ii  php-google-recaptcha  1.2.4-3
ii  php-mariadb-mysql-kbs 1.2.12-1
ii  php-mbstring  2:7.4+76
ii  php-mysql 2:7.4+76
ii  php-phpmyadmin-motranslator   5.2.0-1
ii  php-phpmyadmin-shapefile  2.1-5
ii  php-phpmyadmin-sql-parser 5.4.1-1
ii  php-phpseclib 2.0.30-1
ii  php-symfony-config4.4.19+dfsg-1
ii  php-symfony-dependency-injection  4.4.19+dfsg-1
ii  php-symfony-expression-language   4.4.19+dfsg-1
ii  php-symfony-yaml  4.4.19+dfsg-1
ii  php-twig  2.14.3-1
ii  php-twig-i18n-extension   3.0.0-2
ii  php-xml   2:7.4+76
ii  php7.4-cli [php-cli]  7.4.15-5+deb11u1
ii  php7.4-json [php-json]7.4.15-5+deb11u1
ii  php7.4-mbstring [php-mbstring]7.4.15-5+deb11u1
ii  php7.4-xml [php-xml]  7.4.15-5+deb11u1
ii  sensible-utils0.0.14
ii  ucf   3.0043

Versions of packages phpmyadmin recommends:
ii  lighttpd [httpd]1.4.59-1
ii  php-bz2 2:7.4+76
ii  php-curl2:7.4+76
ii  php-gd  2:7.4+76
ii  php-tcpdf   6.3.5+dfsg1-1
ii  php-zip 2:7.4+76
ii  php7.4-bz2 [php-bz2]7.4.15-5+deb11u1
ii  php7.4-curl [php-curl]  7.4.15-5+deb11u1
ii  php7.4-gd [php-gd]  7.4.15-5+deb11u1
ii  php7.4-zip [php-zip]7.4.15-5+deb11u1

Versions of packages phpmyadmin suggests:
ii  mariadb-server-10.5 [virtual-mysql-server]  1:10.5.9-1
pn  php-gd2 
pn  php-pragmarx-google2fa-qrcode   
pn  php-recode  
pn  php-samyoul-u2f-php-server  
ii  php7.4-opcache [php-opcache]7.4.15-5+deb11u1
pn  www-browser 

-- Configuration Files:
/etc/phpmyadmin/lighttpd.conf changed:
alias.url += (
"/phpmyadmin" => "/usr/share/phpmyadmin",
)
$HTTP["url"] =~ "^/phpmyadmin/" {
$HTTP["remoteip"] !~ "^(127.0.0.1)$" {
url.redirect-code=404
url.redirect = ( ".*" => "http://va1der.ca; )
#url.access-deny = ( "" )
}
}


-- debconf information:
  phpmyadmin/remote/host: localhost
* phpmyadmin/reconfigure-webserver: lighttpd
  phpmyadmin/db/dbname: phpmyadmin
* phpmyadmin/dbconfig-install: true
  phpmyadmin/internal/reconfiguring: false
  phpmyadmin/remove-error: abort
  phpmyadmin/upgrade-backup: true
  phpmyadmin/install-error: abort
  phpmyadmin/upgrade-error: abort
  phpmyadmin/missing-db-package-error: abort
  phpmyadmin/remote/newhost:
  phpmyadmin/dbconfig-upgrade: true
* 

Bug#987065: wordpress: CVE-2021-29450: Authenticated disclosure of password-protected posts and pages

2021-04-16 Thread Craig Small
Should CVE-2021-29447 [1] be also listed against this bug? I'll be putting
it in the changelog.

How good is it when WordPress raise their own CVEs! One glorious day they
will put them in their announcements too.

1:
https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-rv47-pc52-qrhh


Bug#911329: add .libretro metadata for better integration with gnome-games

2021-04-16 Thread Jeremy Bicha
Please go ahead.

Thank you,
Jeremy Bicha

On Fri, Apr 16, 2021, 17:14 Sébastien Villemot  wrote:

> Control: found -1 0.5.0+git20160522+dfsg1-2
> Control: severity -1 important
>
> On Sun, 03 Mar 2019 00:35:00 + Jeremy Bicha 
> wrote:
>
> >   libretro-gambatte (0.5.0+git20160522+dfsg1-2) unstable;
> urgency=medium
> >   .
> > * Team upload
> > * Import packaging to https://salsa.debian.org
> > * Add minimal debian/gbp.conf
> > * Use dh-exec instead of manual .sh script for install file
> > * Add .libretro file & AppStream metadata for integration with
> GNOME Games
> >   (Closes: #911329)
>
> Reopening this bug. The .libretro file and the AppStream metadata were
> included in the source package, but not in the binary package.
>
> Also raising the severity, because it makes the package unusable with
> gnome-games-app.
>
> Jeremy: I think this should be fixed for bullseye. Are you going to
> take care of it, or do you want me to NMU?
>
> --
> ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
> ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
> ⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
> ⠈⠳⣄  https://www.debian.org
>
>


Bug#987068: assert "preliminary cgroupv2 support" or fix outstanding bugs (eg: debootstrap+Docker)

2021-04-16 Thread Nicholas D Steeves
Package: release-notes
Severity: normal

Hi,

It looks like Debian's Docker package has broken cgroup2 support
(#985481), so either that bug should be fixed, or issues.dbk (around
L66) should document that cgroup2 support may be broken in Docker
containers on Bullseye.



Cheers,
Nicholas



Bug#987067: mirror submission for mirrors.pardisco.co

2021-04-16 Thread Amir Fouladvand
Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.pardisco.co
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Amir Fouladvand 
Country: IR Iran, Islamic Republic of
Location: Tehran
Sponsor: Pardis Co. https://www.pardisco.co




Trace Url: http://mirrors.pardisco.co/debian/project/trace/
Trace Url: http://mirrors.pardisco.co/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.pardisco.co/debian/project/trace/mirrors.pardisco.co



Bug#911329: add .libretro metadata for better integration with gnome-games

2021-04-16 Thread Sébastien Villemot
Control: found -1 0.5.0+git20160522+dfsg1-2
Control: severity -1 important

On Sun, 03 Mar 2019 00:35:00 + Jeremy Bicha 
wrote:

>   libretro-gambatte (0.5.0+git20160522+dfsg1-2) unstable;
urgency=medium
>   .
>     * Team upload
>     * Import packaging to https://salsa.debian.org
>     * Add minimal debian/gbp.conf
>     * Use dh-exec instead of manual .sh script for install file
>     * Add .libretro file & AppStream metadata for integration with
GNOME Games
>   (Closes: #911329)

Reopening this bug. The .libretro file and the AppStream metadata were
included in the source package, but not in the binary package.

Also raising the severity, because it makes the package unusable with
gnome-games-app.

Jeremy: I think this should be fixed for bullseye. Are you going to
take care of it, or do you want me to NMU?

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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


Bug#987065: wordpress: CVE-2021-29450: Authenticated disclosure of password-protected posts and pages

2021-04-16 Thread Salvatore Bonaccorso
Source: wordpress
Version: 5.7+dfsg1-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 5.0.11+dfsg1-0+deb10u1

Hi,

The following vulnerability was published for wordpress.

CVE-2021-29450[0]:
| Wordpress is an open source CMS. One of the blocks in the WordPress
| editor can be exploited in a way that exposes password-protected posts
| and pages. This requires at least contributor privileges. This has
| been patched in WordPress 5.7.1, along with the older affected
| versions via minor releases. It's strongly recommended that you keep
| auto-updates enabled to receive the fix.


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-29450
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29450
[1] 
https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-pmmh-2f36-wvhq

Regards,
Salvatore



Bug#964654: kcov: fixing the FTBFS

2021-04-16 Thread Philip Hands
Package: kcov
Version: 38+dfsg-1
Followup-For: Bug #964654

Dear Maintainer,

Just in case merge notifications don't get to you from salsa, I thought I'd add
a note here too (I hope that's OK -- I missed a couple of such notifications
myself, hence the concern).

I just created this:

  https://salsa.debian.org/debian/kcov/-/merge_requests/1

it's pretty trivial, as it just reorders the libdl library, but it seems to do
the trick.

Note, I'm not really familiar with Cmake, so there may be better ways of doing
this.

Also, ss mentioned in the MR, I'm a little suspicious about the dbgsyms package
that gets produced, but that also needs to be looked at by someone that knows
what they should expect.

HTH

Cheers, Phil.



Bug#987013: Release goal proposal: Remove Berkeley DB

2021-04-16 Thread Marco d'Itri
On Apr 16, Bastian Blank  wrote:

> postfix is easy.  Would inn2 be license compliant with a AGPL licensed
> BDB, aka able to provide the source to it's users, or what is the plan
> anyway?
The plan is to continue using 5.3, not upgrading.

>  slapd defaults to LMDB since several years and you need to
> explicitely specify the bdb or hdb backend.
Sure, but the point was how to convert existing systems.

-- 
ciao,
Marco


signature.asc
Description: PGP signature


Bug#948698: [Python-modules-team] Bug#948698: Help needed?

2021-04-16 Thread Sandro Tosi
>> > Is there any chance we can get this one year old bug solved before the
>> > Bullseye release so it ships with a current instead of a 6 years old
>> > version of the library?
>>
>> due to freeze policies, no new releases are accepted for Bullseye so
>> the answer is going to be no.
>
> Can i still help to update it so the next release will be more up to date? ( 
> an an eventual transition to newer versions before the next release less 
> painful)

i just noticed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892679
which means there's no physical person currently maintaining this
package: maybe this is a good opportunity for you, Henning, to start
maintaining it within the DPT?

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



Bug#986993: release-notes: Mention OpenJDK 17 status in bullseye

2021-04-16 Thread Paul Gevers
Hi

On 15-04-2021 10:22, Matthias Klose wrote:
> Please document the OpenJDK 17 status in bullseye:
> 
> Debian bullseye comes with an early access version of OpenJDK 17 (the next
> expected OpenJDK LTS version after OpenJDK 11), to avoid the rather tedious
> bootstrap process.  OpenJDK 17 will be updated in bullseye to the final 
upstream
> release announced for October 2021.  Security updates for OpenJDK 17 are 
> planned
> on a best effort basis, but don't expect to see updates for every quarterly
> upstream security update.

Attached patch ready to push.

Paul
From 646cb07d7c3f57a27ad3e83f872dd6c09d81d6e1 Mon Sep 17 00:00:00 2001
From: Matthias Klose 
Date: Fri, 16 Apr 2021 22:17:47 +0200
Subject: [PATCH] issues.dbk: openjdk-17 and security

Closes: #986993
---
 en/issues.dbk | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index ded0769e..de30e4e9 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -425,6 +425,21 @@ information mentioned in .
   The same strategy will be applied for Thunderbird.
 
   
+
+  
+OpenJDK 17
+
+  Debian bullseye comes with an early access version of
+  OpenJDK 17 (the next expected
+  OpenJDK LTS version after OpenJDK
+  11), to avoid the rather tedious bootstrap
+  process. OpenJDK 17 will be updated in
+  bullseye to the final upstream release announced for October
+  2021. Security updates for OpenJDK 17 are
+  planned on a best effort basis, but don't expect to see updates
+  for every quarterly upstream security update.
+
+  
 
 
 
-- 
2.30.2



OpenPGP_signature
Description: OpenPGP digital signature


Bug#948698: [Python-modules-team] Bug#948698: Help needed?

2021-04-16 Thread Henning Sprang
On Fri 16. Apr 2021 at 21:55, Sandro Tosi  wrote:

> > Is there any chance we can get this one year old bug solved before the
> > Bullseye release so it ships with a current instead of a 6 years old
> > version of the library?
>
> due to freeze policies, no new releases are accepted for Bullseye so
> the answer is going to be no.


Can i still help to update it so the next release will be more up to date?
( an an eventual transition to newer versions before the next release less
painful)



> --
Henning Sprang
http://www.sprang.de


Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)

2021-04-16 Thread Paul Gevers
Hi Justin,

On 13-04-2021 11:14, Justin B Rye wrote:
> [...] "package-specific-issues" at
> present, mislabelled as a case where the package might not upgrade
> smoothly; we don't really have any known cases of that to list, so
> maybe we ought to reorganise the subsections a bit.  I would have
> hoped we could arrange things so that the bookworm deprecations
> subsection is at the very end, and whether we do that or not we might
> want the "limited-security-support" bit to be alongside the a11y and
> rescue.service bits in a "chronic-problems" section (but don't call it
> that).

How about (dropping the package specific section, and just merge it into
upgrade items):
5.1. Upgrade specific items for bullseye
5.2. Items not limited to the upgrade process
 * Limitations in security support
 * Gnome accessibility issue
 * password-less rescue mode
5.3. Obsolescence and deprecation
 * Noteworthy obsolete packages
 * Deprecated components for bullseye

Now I'm going over it, the Python2 is probably also not in the right
section. I think it warrants to be mentioned under "Noteworthy obsolete
packages" (section of 5.1) as the Python2 deprecation has resulted in *a
lot* of Python2 packages to have been removed.

Paul
PS: on the one hand it feels more natural to have deprecate before
obsolete, but on the other hand I guess it's more important to learn
about obsolete packages, so that goes first?



OpenPGP_signature
Description: OpenPGP digital signature


Bug#948698: [Python-modules-team] Bug#948698: Help needed?

2021-04-16 Thread Sandro Tosi
> Is there any chance we can get this one year old bug solved before the
> Bullseye release so it ships with a current instead of a 6 years old
> version of the library?

due to freeze policies, no new releases are accepted for Bullseye so
the answer is going to be no.

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



Bug#987064: Core update email sent from WordPress install

2021-04-16 Thread Sam Bull
Package: wordpress
Version: 5.0.11+dfsg1-0+deb10u1

A client I am hosting received an automatic email recently containing:

   Please update your site at [domain] to WordPress 5.0.12.
   We tried but were unable to update your site automatically.

Obviously, this won't work, and the email should never have been sent.
While WP_CORE_UPDATE is false, this doesn't seem to have stopped the email.

Seems like the best way to disable this is with:

   function disable_core_update_emails($notify, $item) {
   return false;
   }
   add_filter('send_core_update_notification_email', 
'disable_core_update_emails');

However, that can't go in wp-config.php, as the add_filter() function is not
defined at that point. I'm not sure if there's another location that Debian
patches that could have this defined.


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


Bug#948698: Help needed?

2021-04-16 Thread Henning Sprang
Hello,

Is there any help needed to solve this issue?

Is there any chance we can get this one year old bug solved before the
Bullseye release so it ships with a current instead of a 6 years old
version of the library?

Please let me know what I can do to help.

Thanks,
Henning

-- 
Henning Sprang
http://www.sprang.de



Bug#987055: ksnip: Requires libkColorPicker.so.0.1.4

2021-04-16 Thread Manu Hernandez
Package: ksnip
Version: 1.7.3-3~bpo10+1
Severity: important

Dear Maintainer,

ksnip doesn't start because the libkcolorpicker0 has been updated.

When I try to start ksnip from the shell, it outputs the following
error:

ksnip: error while loading shared libraries: libkColorPicker.so.0.1.4:
cannot open shared object file: No such file or directory

As a workaround, I created the following symbolic link:

$ sudo ln -s /lib/x86_64-linux-gnu/libkColorPicker.so.0.1.5
/lib/x86_64-linux-gnu/libkColorPicker.so.0.1.4

I know it's an ugly hack, but it allows ksnip to start and I can use the
application again.

As you can see in the "System Information" section, I'm running Debian
Buster with ksnip installed from buster-backports.

Thank you in advance.

Best regards,

Manu


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

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

Versions of packages ksnip depends on:
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libkcolorpicker0 0.1.5~git20201226-1~bpo10+1
ii  libkimageannotator0  0.3.2-2~bpo10+1
ii  libqt5core5a 5.11.3+dfsg1-1+deb10u4
ii  libqt5dbus5  5.11.3+dfsg1-1+deb10u4
ii  libqt5gui5   5.11.3+dfsg1-1+deb10u4
ii  libqt5network5   5.11.3+dfsg1-1+deb10u4
ii  libqt5printsupport5  5.11.3+dfsg1-1+deb10u4
ii  libqt5svg5   5.11.3-2
ii  libqt5widgets5   5.11.3+dfsg1-1+deb10u4
ii  libqt5x11extras5 5.11.3-2
ii  libqt5xml5   5.11.3+dfsg1-1+deb10u4
ii  libstdc++6   8.3.0-6
ii  libx11-6 2:1.6.7-1+deb10u1
ii  libxcb-render0   1.13.1-2
ii  libxcb-shape01.13.1-2
ii  libxcb-xfixes0   1.13.1-2
ii  libxcb1  1.13.1-2

ksnip recommends no packages.

ksnip suggests no packages.

-- no debconf information



Bug#987063: gwenview: looses image metadata on jpg rotation

2021-04-16 Thread Karsten Hilbert
Package: gwenview
Version: 4:20.12.3-1
Severity: normal
Tags: upstream

This release started to drop metadata from JPEG files after rotating
them. I do believe the following upstream commit is the culprit:


https://invent.kde.org/graphics/gwenview/commit/a401e66621bcffbdc75048d9eaded1a5f5a67137

because it "unconditionally" saves JPEGs thereby overwriting them w/o
carrying over metadata :(

Thanks,
Karsten

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

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

Versions of packages gwenview depends on:
ii  kinit  5.78.0-2
ii  kio5.78.0-4
ii  libc6  2.31-11
ii  libcfitsio93.490-3
ii  libexiv2-270.27.3-3
ii  libgcc-s1  10.2.1-6
ii  libjpeg62-turbo1:2.0.6-4
ii  libkf5activities5  5.78.0-2
ii  libkf5baloo5   5.78.0-3
ii  libkf5completion5  5.78.0-3
ii  libkf5configcore5  5.78.0-4
ii  libkf5configgui5   5.78.0-4
ii  libkf5configwidgets5   5.78.0-2
ii  libkf5coreaddons5  5.78.0-4
ii  libkf5filemetadata35.78.0-2
ii  libkf5i18n55.78.0-2
ii  libkf5iconthemes5  5.78.0-2
ii  libkf5itemmodels5  5.78.0-2
ii  libkf5itemviews5   5.78.0-2
ii  libkf5jobwidgets5  5.78.0-2
ii  libkf5kdcraw5  20.12.0-1
ii  libkf5kiocore5 5.78.0-4
ii  libkf5kiofilewidgets5  5.78.0-4
ii  libkf5kiowidgets5  5.78.0-4
ii  libkf5kipi32.0.0   4:20.12.1-1
ii  libkf5notifications5   5.78.0-2
ii  libkf5parts5   5.78.0-3
ii  libkf5purpose-bin  5.78.0-2
ii  libkf5purpose5 5.78.0-2
ii  libkf5service-bin  5.78.0-2
ii  libkf5service5 5.78.0-2
ii  libkf5solid5   5.78.0-2
ii  libkf5widgetsaddons5   5.78.0-2
ii  libkf5xmlgui5  5.78.0-2
ii  liblcms2-2 2.12~rc1-2
ii  libphonon4qt5-44:4.11.1-3
ii  libpng16-161.6.37-3
ii  libqt5core5a   5.15.2+dfsg-5
ii  libqt5dbus55.15.2+dfsg-5
ii  libqt5gui5 5.15.2+dfsg-5
ii  libqt5printsupport55.15.2+dfsg-5
ii  libqt5svg5 5.15.2-2
ii  libqt5widgets5 5.15.2+dfsg-5
ii  libqt5x11extras5   5.15.2-2
ii  libstdc++6 10.2.1-6
ii  libtiff5   4.2.0-1
ii  libx11-6   2:1.7.0-2
ii  perl   5.32.1-3
ii  phonon4qt5 4:4.11.1-3

Versions of packages gwenview recommends:
pn  kamera 
ii  kio-extras 4:20.12.2-1
ii  qt5-image-formats-plugins  5.15.2-2

gwenview suggests no packages.

-- no debconf information



Bug#987015: [pre-approval] unblock: python-apt/2.2.0

2021-04-16 Thread Julian Andres Klode
Control: tag -1 - moreinfo

On Thu, Apr 15, 2021 at 06:54:32PM +0200, Julian Andres Klode wrote:
> On Thu, Apr 15, 2021 at 06:28:49PM +0200, Julian Andres Klode wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: j...@debian.org
> > 
> > Please unblock package python-apt
> > 
> > [ Reason ]
> > 
> > Want to bump version number to stable series versioning, mostly,
> > update the mirror list, and remove invalid PIE disablement which
> > triggers build failures in downstreams (it fails with LTO; I think
> > it's a no-op without LTO either way, or at least supposed to be,
> > given that we link with -fPIC).
> > 
> > Don't really care much about the build dependency !nocheck
> > annotations, but they were already queued. Could revert
> > them if needed.
> > 
> > [ Impact ]
> > 
> > Mirror selection in tools will be from December 2020.
> > 
> > [ Tests ]
> > 
> > We have unit tests run at build time, but there are no
> > code changes, just metadata and build flags.
> > 
> > [ Risks ]
> > 
> > I'm not sure the PIE change does much really, the code is linked with
> > -fPIC, the annotations could trigger bootstrapping issues, but it's
> > not working right now anyway so meh.
> > 
> > [ Checklist ]
> >   [x] all changes are documented in the d/changelog
> >   [x] I reviewed all changes and I approve them
> >   [x] attach debdiff against the package in testing
> 
> Oops.

Resending patch compressed, didn't make it through to debian-release...

Also should be

https://salsa.debian.org/jak/python-apt/-/compare/2.1.7...main

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


python-apt_2.2.0.diff.gz
Description: application/gzip


signature.asc
Description: PGP signature


Bug#986517: piglit: FTBFS: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:11: undefined reference to `pthread_create'

2021-04-16 Thread Adrian Bunk
Control: reassign -1 libwaffle-dev 1.6.3-1
Control: retitle -1 libwaffle-dev: Missing dependency on libudev-dev
Control: affects -1 src:piglit

...
-- Checking for module 'waffle-1'
--   Package 'libudev', required by 'waffle-1', not found
CMake Error at /usr/share/cmake-3.18/Modules/FindPkgConfig.cmake:545 (message):
...


cu
Adrian



Bug#985956: Merge request submittted to initramfs-tools

2021-04-16 Thread Pete Batard
I can try to submit a pull request for linux if needed, but I may need 
some guidance.


I'm going to drop trying to submit a pull request for the linux package 
for the time being, as I can't quite seem to manage to get the required 
process to insert CONFIG_MDIO_BCM_UNIMAC=m where it should appear.


Besides, I am not sure this is needed in the first place, since BMCGENET 
Kconfig should have MDIO_BCM_UNIMAC set by default 
(https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/broadcom/Kconfig#L78)


Thus, I'm going to leave people who are more familiar with Debian linux 
configuration with the action of ensuring that mdio-bcm-unimac.ko does 
get included in the install image.


Apologies for not being to being able to help further on this...

/Pete



Bug#987013: Release goal proposal: Remove Berkeley DB

2021-04-16 Thread Bastian Blank
Hi Marco

On Fri, Apr 16, 2021 at 05:04:03PM +0200, Marco d'Itri wrote:
> On Apr 15, Bastian Blank  wrote:
> > After this time we really should try to get rid of this package, which
> > even is NMU maintained since three years.
> I am not persuaded. I maintain libberkeleydb-perl and it works fine, it 
> is mature software.

Mature and unmaintained are not opposites.  It works, but this does not
mean it's advised to be used, especially if it works on untrusted data.
(I the time I installed by current notebook, Linux 4.0 was the current
version.  It would still work, but would you really still use it on the
internet?)

> And then all the packages currently depending on libdb5.3 will need to 
> implement, or at least document, a transition strategy.

My first goal would be to drop it from base packages, so not every
system out there needs to have it installed.

> Let me just mention postfix (easy), inn2 (possible but very resources 
> intensive) and slapd (I am not sure, but it is critical and scary).

postfix is easy.  Would inn2 be license compliant with a AGPL licensed
BDB, aka able to provide the source to it's users, or what is the plan
anyway?  slapd defaults to LMDB since several years and you need to
explicitely specify the bdb or hdb backend.

Regards,
Bastian

-- 
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
   stardate 4842.6



Bug#987013: Release goal proposal: Remove Berkeley DB

2021-04-16 Thread Bastian Blank
Hi Gerardo

On Fri, Apr 16, 2021 at 10:30:08AM +0200, Gerardo Ballabio wrote:
> Bastian Blank wrote:
> > Berkeley DB was relicensed to AGPLv3 almost eight years ago.
> Sorry but I don't understand, why is that a problem?
> I believe the AGPL (you mean the GNU Affero General Public License,
> right?) is a free license. Is it not?

Yes, the AGPLv3 is a free license.

However the freeness is not the problem here.  The problem is the AGPL,
it's extended source provisions, the incompatibility with the license of
existing software and also a bit "Oracle".

The AGPL was created for network services.  It requires to provide the
source to anyone accessing it via network.  So this is tailored for the
services themselves, not arbitrary libraries deep within the dependency
chain.  There where a lot of discussions about this problems at the
time.[1]

So even if we would switch to a current version of Berkeley DB, we would
need to do the same work to make sure every software that uses it is in
compliance with the AGPL.  AFAIK every distribution either stayed with
BDB 5.3 and often just removed it's use as much as possible or just
killed it alltogether.

Regards,
Bastian

[1]: https://lwn.net/Articles/557820/
-- 
If a man had a child who'd gone anti-social, killed perhaps, he'd still
tend to protect that child.
-- McCoy, "The Ultimate Computer", stardate 4731.3



Bug#986510: lintian-brush: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit code 13

2021-04-16 Thread Jelmer Vernooij
On Fri, Apr 16, 2021 at 09:24:38AM +0200, Andreas Tille wrote:
> I've got a testing-removal warning for routine-update due this bug.  I
> know you are usually very prompt in replying to issues thus I'm simply
> wondering whether you might have missed this bug report.  I personally
> have never dived into lintian-brush but if you give some signal that you
> are not managing to work on this in the next couple of days I could at
> lest seek for help.

Looks like I actually forgot to tag the bug appropriately - it's
alreday fixed. Thanks for the ping, I had indeed missed this.

Jelmer


signature.asc
Description: PGP signature


Bug#987060: vim: highlight: make: Incorrect highlighting in $(shell ...) expression

2021-04-16 Thread Alejandro Colomar
Package: vim
Version: 2:8.2.2434-3
Severity: minor
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear Maintainer,

I have the following in a Makefile:

base_branch = $(shell echo 'origin/develop origin/release/* origin/master' \
| xargs git branch -a -l \
| while read b; do \
d1="$$(git rev-list --first-parent ^$$b HEAD | 
wc -l)"; \
d2="$$(git rev-list --first-parent ^HEAD $$b | 
wc -l)"; \
echo "$$b $$d1 $$d2"; \
done \
| sort -n -k2 -k3 \
| head -n1 \
| awk '{print $$1}' \
| sed -e 's,remotes/,,' -e 's,origin/,,';)

bb:
echo $(base_branch);

It is correct make syntax, AFAIK, and it works as expected, printing the
closest parent branch with a specified pattern, but the highlighting considers
the first closing parenthesis (at the end of the line starting with 'd1')
as the end of the $(shell ...) expression, so the rest of the expression
is wrongly colored.

Could you please fix it?  Or tell me how to fix it? :)

Thanks,

Alex

-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.basic
/usr/bin/vim is /usr/bin/vim.basic

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

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

Versions of packages vim depends on:
ii  libacl1  2.2.53-10
ii  libc62.31-11
ii  libgpm2  1.20.7-8
ii  libselinux1  3.1-3
ii  libtinfo66.2+20201114-2
ii  vim-common   2:8.2.2434-3
ii  vim-runtime  2:8.2.2434-3

vim recommends no packages.

Versions of packages vim suggests:
pn  ctags
pn  vim-doc  
pn  vim-scripts  

-- no debconf information



Bug#987059: gscan2pdf: POD and manpage improvements

2021-04-16 Thread Peter Marschall
Package: gscan2pdf
Version: 2.11.0-1
Severity: minor
Tags: upstream patch

Hi,

please find attached a patch for the POD part & manual page of gscan2pdf,
which brings it more in line with other manual pages

The patch is against upstream version 2.11.2.

Please consider including it in one of the future versions of gscan2pdf
Peter


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

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

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.9.11.60+dfsg-1
ii  imagemagick-6.q16 [imagemagick]8:6.9.11.60+dfsg-1
ii  libconfig-general-perl 2.63-1
ii  libdate-calc-perl  6.4-1.1
ii  libfilesys-df-perl 0.92-6+b6
ii  libgoocanvas2-perl 0.06-2
ii  libgtk3-imageview-perl 6-1
ii  libgtk3-perl   0.038-1
ii  libgtk3-simplelist-perl0.21-1
ii  libhtml-parser-perl3.75-1+b1
ii  libimage-magick-perl   8:6.9.11.60+dfsg-1
ii  libimage-sane-perl 5-1+b1
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-codes-perl   3.66-1
ii  liblocale-gettext-perl 1.07-4+b1
ii  liblog-log4perl-perl   1.54-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b9
ii  libpdf-builder-perl3.021-2
ii  libproc-processtable-perl  0.59-2+b1
ii  libreadonly-perl   2.050-3
ii  librsvg2-common2.50.3+dfsg-1
ii  libset-intspan-perl1.19-1.1
ii  libtiff-tools  4.2.0-1
ii  libtry-tiny-perl   0.30-1
hi  sane-utils 1.0.31-4pm1

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin   3.5.28-1
ii  gocr0.52-3
ii  pdftk-java [pdftk]  3.2.2-1
ii  tesseract-ocr   4.1.1-2.1
ii  unpaper 6.1-2+b2
ii  xdg-utils   1.1.3-4

gscan2pdf suggests no packages.

-- no debconf information
From 951566125ec98859f80b510fcec254aa85d3ffc6 Mon Sep 17 00:00:00 2001
From: Peter Marschall 
Date: Sun, 10 Mar 2019 09:52:43 +0100
Subject: [PATCH] gscan2pdf: man pages updates
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* use ´=over 4' as specified by perlpod to get correct indentation
* add empty lines after '=item' entries for correct separation
  and display of the itemized lists in POD and manual pages
* mark command line options in bold, and file arguments as files
  to visually separate them from surrounding text
* '=item'ize %-variables
  to display them nicely as lists
* indent verbatim text
  to display it as code

Signed-off-by: Peter Marschall 
---
 bin/gscan2pdf | 123 +++---
 1 file changed, 86 insertions(+), 37 deletions(-)

diff --git a/bin/gscan2pdf b/bin/gscan2pdf
index 42d82c7c..f0b630a8 100755
--- a/bin/gscan2pdf
+++ b/bin/gscan2pdf
@@ -7473,7 +7473,7 @@ gscan2pdf - A GUI to produce PDFs or DjVus from scanned 
documents
 
 =head1 USAGE
 
-=over
+=over 4
 
 =item 1. Scan one or several pages in with File/Scan
 
@@ -7489,29 +7489,36 @@ None
 
 gscan2pdf has the following command-line options:
 
-=over
+=over 4
+
+=item B<--device>=F
 
-=item --device=
 Specifies the device to use, instead of getting the list of devices from via 
the SANE API.
 This can be useful if the scanner is on a remote computer which is not 
broadcasting its existence.
 
-=item --help
+=item B<--help>
+
 Displays this help page and exits.
 
-=item --log=
+=item B<--log>=F
+
 Specifies a file to store logging messages.
 
-=item --(debug|info|warn|error|fatal)
-Defines the log level. If a log file is specified, this defaults to 'debug', 
otherwise 'warn'.
+=item B<--debug>, B<--info>, B<--warn>, B<--error>, B<--fatal>
+
+Defines the log level.
+If a log file is specified, this defaults to B<--debug>, otherwise B<--error>.
+
+=item B<--import>=F
 
-=item --import=
 Imports the specified file(s). If the document has more than one page, a 
window is
 displayed to select the required pages.
 
-=item --import-all=
+=item B<--import-all>=F
 Imports all pages of the specified file(s).
 
-=item --version
+=item B<--version>
+
 Displays the program version and exits.
 
 =back
@@ -7527,7 +7534,7 @@ To diagnose a possible error, start gscan2pdf from the 
command line with logging
 
 C
 
-and check file.log.
+and check F.
 
 =head1 EXIT STATUS
 
@@ -7535,7 +7542,7 @@ None
 
 =head1 CONFIGURATION
 
-gscan2pdf creates a text resource 

Bug#987058: gscan2pdf: fix displaying rotated text

2021-04-16 Thread Peter Marschall
Package: gscan2pdf
Version: 2.11.0-1
Severity: wishlist
Tags: upstream patch

Hi,

the attached patches fix the display of rotated text
(which seems to have got lost in some of the recent refactoring ;-)

The patches are agains upstream's 2.11.2

Please consider including them into a future version of gscan2pdf
Peter


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

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

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.9.11.60+dfsg-1
ii  imagemagick-6.q16 [imagemagick]8:6.9.11.60+dfsg-1
ii  libconfig-general-perl 2.63-1
ii  libdate-calc-perl  6.4-1.1
ii  libfilesys-df-perl 0.92-6+b6
ii  libgoocanvas2-perl 0.06-2
ii  libgtk3-imageview-perl 6-1
ii  libgtk3-perl   0.038-1
ii  libgtk3-simplelist-perl0.21-1
ii  libhtml-parser-perl3.75-1+b1
ii  libimage-magick-perl   8:6.9.11.60+dfsg-1
ii  libimage-sane-perl 5-1+b1
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-codes-perl   3.66-1
ii  liblocale-gettext-perl 1.07-4+b1
ii  liblog-log4perl-perl   1.54-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b9
ii  libpdf-builder-perl3.021-2
ii  libproc-processtable-perl  0.59-2+b1
ii  libreadonly-perl   2.050-3
ii  librsvg2-common2.50.3+dfsg-1
ii  libset-intspan-perl1.19-1.1
ii  libtiff-tools  4.2.0-1
ii  libtry-tiny-perl   0.30-1
hi  sane-utils 1.0.31-4pm1

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin   3.5.28-1
ii  gocr0.52-3
ii  pdftk-java [pdftk]  3.2.2-1
ii  tesseract-ocr   4.1.1-2.1
ii  unpaper 6.1-2+b2
ii  xdg-utils   1.1.3-4

gscan2pdf suggests no packages.

-- no debconf information
>From d65fef2ac5821e0f1e449bd0667de17614e8112b Mon Sep 17 00:00:00 2001
From: Peter Marschall 
Date: Wed, 14 Apr 2021 20:08:29 +0200
Subject: [PATCH 1/2] Canvas: make sure rotated text is displayed correctly

Inherit textangle from superior object.

Teseract seems to add the 'textangle' attribute only to line-like elements
(like 'ocrx_line', 'ocrx_header', 'ocrx_footer') but not to the individual
words (i.e. 'ocr_word').

If the words have a 'textangle' attribute themselves, its value gets added to
the the inherited one.

Signed-off-by: Peter Marschall 
---
 lib/Gscan2pdf/Canvas.pm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/Gscan2pdf/Canvas.pm b/lib/Gscan2pdf/Canvas.pm
index 962ecffc..ba7a6d4a 100644
--- a/lib/Gscan2pdf/Canvas.pm
+++ b/lib/Gscan2pdf/Canvas.pm
@@ -483,7 +483,8 @@ sub add_box {
 my @transformation = ( 0, 0, 0 );
 if ( $parent->isa('Gscan2pdf::Canvas::Bbox') ) {
 my $parent_box = $parent->get('bbox');
-@transformation = ( 0, $parent_box->{x}, $parent_box->{y} );
+my $parent_textangle = $parent->get('textangle');
+@transformation = ( $parent_textangle, $parent_box->{x}, 
$parent_box->{y} );
 }
 my %options2 = (
 parent => $parent,
-- 
2.30.2

>From 8cecfcd009575de090ef05218a171fed893d1cc9 Mon Sep 17 00:00:00 2001
From: Peter Marschall 
Date: Wed, 14 Apr 2021 21:11:09 +0200
Subject: [PATCH 2/2] Bbox: show updated rotated text correctly

Scale & rotate the updated text same way it is done when creating the box.

Skip scaling & rotating if the updated text has no width to avoid dividing by 
zero.

Signed-off-by: Peter Marschall 
---
 lib/Gscan2pdf/Canvas/Bbox.pm | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/lib/Gscan2pdf/Canvas/Bbox.pm b/lib/Gscan2pdf/Canvas/Bbox.pm
index 6175639a..778b5adb 100644
--- a/lib/Gscan2pdf/Canvas/Bbox.pm
+++ b/lib/Gscan2pdf/Canvas/Bbox.pm
@@ -480,12 +480,18 @@ sub update_box {
 $self->set( bbox => $selection );
 $text_w->set_simple_transform( 0, 0, 1, 0 );
 my $bounds= $text_w->get_bounds;
+my @transformation = @{ $self->get('transformation') };
+my $rotation = (@transformation) ? $transformation[0] : 0;
 my $textangle = $self->get('textangle');
-my $scale =
-  ( $textangle ? $selection->{height} : $selection->{width} ) /
-  ( $bounds->x2 - $bounds->x1 );
-
-$self->transform_text( $scale, $textangle );
+my 

Bug#987057: gscan2pdf: fixes to hOCR

2021-04-16 Thread Peter Marschall
Package: gscan2pdf
Version: 2.11.0-1
Severity: wishlist
Tags: patch upstream

Hi,

please find attached 3 patches improving hOCR support.
- recognize more tags when reading hOCR
  In addition this also helps for rotated texts (in a separate report)
- preserve more properties when writing hOCR
- fix-indentation of intermediate non-leaf elements

The patches are against upstream's version 2.11.2

Please consider incorporating them into gscan2pdf's next version

Thanks in advance
Peter

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

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

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.9.11.60+dfsg-1
ii  imagemagick-6.q16 [imagemagick]8:6.9.11.60+dfsg-1
ii  libconfig-general-perl 2.63-1
ii  libdate-calc-perl  6.4-1.1
ii  libfilesys-df-perl 0.92-6+b6
ii  libgoocanvas2-perl 0.06-2
ii  libgtk3-imageview-perl 6-1
ii  libgtk3-perl   0.038-1
ii  libgtk3-simplelist-perl0.21-1
ii  libhtml-parser-perl3.75-1+b1
ii  libimage-magick-perl   8:6.9.11.60+dfsg-1
ii  libimage-sane-perl 5-1+b1
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-codes-perl   3.66-1
ii  liblocale-gettext-perl 1.07-4+b1
ii  liblog-log4perl-perl   1.54-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b9
ii  libpdf-builder-perl3.021-2
ii  libproc-processtable-perl  0.59-2+b1
ii  libreadonly-perl   2.050-3
ii  librsvg2-common2.50.3+dfsg-1
ii  libset-intspan-perl1.19-1.1
ii  libtiff-tools  4.2.0-1
ii  libtry-tiny-perl   0.30-1
hi  sane-utils 1.0.31-4pm1

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin   3.5.28-1
ii  gocr0.52-3
ii  pdftk-java [pdftk]  3.2.2-1
ii  tesseract-ocr   4.1.1-2.1
ii  unpaper 6.1-2+b2
ii  xdg-utils   1.1.3-4

gscan2pdf suggests no packages.

-- no debconf information
>From f9d32fbeb11619637ea6263881b6333afc4ebeaf Mon Sep 17 00:00:00 2001
From: Peter Marschall 
Date: Wed, 14 Apr 2021 17:41:56 +0200
Subject: [PATCH 1/3] Bboxtree: preserve more information in to_hocr()

Keep 'textangle' and 'baseline' properties in to_hocr() method.

Signed-off-by: Peter Marschall 
---
 lib/Gscan2pdf/Bboxtree.pm | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/Gscan2pdf/Bboxtree.pm b/lib/Gscan2pdf/Bboxtree.pm
index 59edaf61..2ee47834 100644
--- a/lib/Gscan2pdf/Bboxtree.pm
+++ b/lib/Gscan2pdf/Bboxtree.pm
@@ -514,6 +514,12 @@ EOS
 $string .= $SPACE x ( 2 + $bbox->{depth} ) . "<$tag class='$type'";
 if ( defined $bbox->{id} ) { $string .= " id='$bbox->{id}'" }
 $string .= " title='bbox $x1 $y1 $x2 $y2";
+if ( defined $bbox->{baseline} ) {
+$string .= '; baseline ' . join( $SPACE, @{ $bbox->{baseline} } );
+}
+if ( defined $bbox->{textangle} ) {
+$string .= "; textangle $bbox->{textangle}";
+}
 if ( defined $bbox->{confidence} ) {
 $string .= "; x_wconf $bbox->{confidence}";
 }
-- 
2.30.2

>From 11ed93483c800082525cd6a3afcfb08f0e15be9c Mon Sep 17 00:00:00 2001
From: Peter Marschall 
Date: Wed, 14 Apr 2021 18:02:16 +0200
Subject: [PATCH 2/3] Bboxtree: recognize more hOCR elements in _hocr2boxes()

Recognize additional elements 'ocr_header', 'ocr_footer', 'ocr_caption'
as well as their 'ocrx_...' counterparts when parsing hOCR into a Bboxtree

Recent versions of tesseract seem to generate some of these elements
instead of 'ocrx_line'.

As the line-like elements contain impoartant information, gscan2pdf needs
to recognize them, in order to
* properly diplay the OCR'ed text
* preserve as much information as possible when storing hOCR files

Signed-off-by: Peter Marschall 
---
 lib/Gscan2pdf/Bboxtree.pm | 9 +
 1 file changed, 9 insertions(+)

diff --git a/lib/Gscan2pdf/Bboxtree.pm b/lib/Gscan2pdf/Bboxtree.pm
index 2ee47834..e8fa83d3 100644
--- a/lib/Gscan2pdf/Bboxtree.pm
+++ b/lib/Gscan2pdf/Bboxtree.pm
@@ -138,6 +138,15 @@ sub _hocr2boxes {
 when (/_par$/xsm) {
 $data->{type} = 'para';
 }
+when (/_header$/xsm) {
+$data->{type} = 'header';
+}
+

Bug#985956: Merge request submittted to initramfs-tools

2021-04-16 Thread Pete Batard

On 2021.04.16 14:04, Ben Hutchings wrote:

On Thu, 2021-04-15 at 17:28 +0200, Samuel Thibault wrote:

Hello,

Pete Batard, le jeu. 15 avril 2021 16:11:02 +0100, a ecrit:

Quite a few people are negatively affected by this bug, and one can expect a
lot more to be if Debian 11 goes to release without the inclusion of
mdio-bcm-unimac.ko in the netinst ARM64 ISOs.

I have created an initramfs-tools merge request to attempt to fix the
problem, which can be found at:
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/46


AIUI initramfs-tools rules are not used to build the nic-modules
udeb, it'd rather be happening in the linux package, in
debian/installer/modules/nic-modules, which indeed doesn't include
drivers/net/mdio/.

Linux maintainers, do you know more on this issue?


Yes that's correct.  This should be fixed in both initramfs-tools (for
normal system boot) and linux (for installation).


I can try to submit a pull request for linux if needed, but I may need 
some guidance.


My take is that we want to add and explicit:

  CONFIG_MDIO_BCM_UNIMAC=m

to debian/config/arm64/config and add a:

  drivers/net/mdio/*

line to debian/installer/modules/nic-modules.

In other words, something like this patch:
https://salsa.debian.org/pbatard/linux/-/commit/855c728e4757bdcb4ceba054fc2b5b1da214b8ab

Does this approach look correct? Or do we need something different?

Regards,

/Pete



Bug#986929: unblock/tpu: nheko/0.7.2-3+deb11u1

2021-04-16 Thread Paul Gevers
Hi,

On 16-04-2021 00:07, Hubert Chathi wrote:
> Again, this needs to go through tpu since sid has a newer version

Please read our FAQ [1]. We prefer you revert the newer version and
prepare a targeted fix in unstable. The tpu route is only available if a
package is stuck behind something else that won't migrate (e.g. a build
time generated dependency on a newer version of a library.)

Paul

[1] https://release.debian.org/bullseye/FAQ.html section "How to proceed
if a new upstream version is unreviewable or has not-important changes?"



OpenPGP_signature
Description: OpenPGP digital signature


Bug#987056: unblock: golang-gopkg-yaml.v3/3.0.0~git20200121.a6ecf24-3

2021-04-16 Thread Shengjing Zhu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package golang-gopkg-yaml.v3

[ Reason ]
Fix FTBFS on 32 bit arch

[ Impact ]
The package FTBFS on 32 bit arch.
And packages that build-dep on it _may_ have wrong behaviour on 32 bit arch.
But I think the underlying issue _may_ be minor.

[ Tests ]
Upstream unit tests, and autopkgtest on 32 bit arch.

[ Risks ]
Change is trivial. Key package.

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

[ Other info ]
None

unblock golang-gopkg-yaml.v3/3.0.0~git20200121.a6ecf24-3
diff -Nru golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/changelog 
golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/changelog
--- golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/changelog 
2020-06-02 02:10:00.0 +0800
+++ golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/changelog 
2021-04-16 00:25:23.0 +0800
@@ -1,3 +1,15 @@
+golang-gopkg-yaml.v3 (3.0.0~git20200121.a6ecf24-3) unstable; urgency=medium
+
+  * Team upload.
+  * Add patch to fix failed test on 32 bit arch (Closes: #987005)
+  * Update Section to golang
+  * Update Standards-Version to 4.5.1 (no changes)
+  * Remove test dependency from -dev package
+  * Remove redundant line in d/rules
+  * Fix uscan watch file
+
+ -- Shengjing Zhu   Fri, 16 Apr 2021 00:25:23 +0800
+
 golang-gopkg-yaml.v3 (3.0.0~git20200121.a6ecf24-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/control 
golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/control
--- golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/control   
2020-06-02 02:10:00.0 +0800
+++ golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/control   
2021-04-16 00:25:23.0 +0800
@@ -1,14 +1,14 @@
 Source: golang-gopkg-yaml.v3
 Maintainer: Debian Go Packaging Team 
-Uploaders: Daniel Swarbrick 
-Section: devel
+Uploaders: Daniel Swarbrick ,
+Section: golang
 Testsuite: autopkgtest-pkg-go
 Priority: optional
 Build-Depends: debhelper-compat (= 12),
-   dh-golang,
+   dh-golang (>= 1.39),
golang-any,
golang-gopkg-check.v1-dev,
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
 Rules-Requires-Root: no
 Vcs-Browser: https://salsa.debian.org/go-team/packages/golang-gopkg-yaml.v3
 Vcs-Git: https://salsa.debian.org/go-team/packages/golang-gopkg-yaml.v3.git
@@ -17,8 +17,7 @@
 
 Package: golang-gopkg-yaml.v3-dev
 Architecture: all
-Depends: golang-gopkg-check.v1-dev,
- ${misc:Depends},
+Depends: ${misc:Depends},
  ${shlibs:Depends},
 Description: YAML support for the Go language
  The yaml package enables Go programs to very comfortably encode and decode
diff -Nru 
golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/patches/0001-Fix-0b-on-32-bit-systems.patch
 
golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/patches/0001-Fix-0b-on-32-bit-systems.patch
--- 
golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/patches/0001-Fix-0b-on-32-bit-systems.patch
   1970-01-01 08:00:00.0 +0800
+++ 
golang-gopkg-yaml.v3-3.0.0~git20200121.a6ecf24/debian/patches/0001-Fix-0b-on-32-bit-systems.patch
   2021-04-16 00:25:23.0 +0800
@@ -0,0 +1,48 @@
+From: Shengjing Zhu 
+Date: Fri, 16 Apr 2021 00:40:09 +0800
+Subject: Fix -0b on 32-bit systems
+
+Origin: backport, https://github.com/go-yaml/yaml/pull/442
+---
+ decode_test.go | 7 ---
+ resolve.go | 2 +-
+ 2 files changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/decode_test.go b/decode_test.go
+index 51f5070..9cac74c 100644
+--- a/decode_test.go
 b/decode_test.go
+@@ -175,9 +175,6 @@ var unmarshalTests = []struct {
+   }, {
+   "bin: -0b101010",
+   map[string]interface{}{"bin": -42},
+-  }, {
+-  "bin: 
-0b1000",
+-  map[string]interface{}{"bin": -9223372036854775808},
+   }, {
+   "decimal: +685_230",
+   map[string]int{"decimal": 685230},
+@@ -357,6 +354,10 @@ var unmarshalTests = []struct {
+   "int64_min: -9223372036854775808",
+   map[string]int64{"int64_min": math.MinInt64},
+   },
++  {
++  "int64_min_base2: 
-0b1000",
++  map[string]int64{"int64_min_base2": math.MinInt64},
++  },
+   {
+   "int64_neg_base2: 
-0b111",
+   map[string]int64{"int64_neg_base2": -math.MaxInt64},
+diff --git a/resolve.go b/resolve.go
+index 64ae888..1b7d8c3 100644
+--- a/resolve.go
 b/resolve.go
+@@ -223,7 +223,7 @@ func resolve(tag string, in string) (rtag string, 

Bug#986863: linux: Serial terminal for RPi 4 and p400 corrupted during bootup

2021-04-16 Thread Gunnar Wolf
Control: Severity -1 normal

Ben Hutchings dijo [Fri, Apr 16, 2021 at 03:07:48PM +0200]:
> > During the boot process of the Raspberry Pi models 4 (4 and 8GB) and
> > p400, the console starts working correctly, but as the vc4 video gets
> > initialized, the console gets corrupted.
> [...]
> 
> This is a known problem with the RPi 3/4 hardware:
> 
> "In order to use the mini UART, you need to configure the Raspberry Pi
> to use a fixed VPU core clock frequency. This is because the mini UART
> clock is linked to the VPU core clock, so that when the core clock
> frequency changes, the UART baud rate will also change."
> 
> (from
> ).

Ugh, great... FSVO.

I can confirm both force_turbo=1 and core_freq=250 worked for keeping
the serial port functioning after vc4 is loaded, but am still unsure
which should be enabled by default for our RPi4 users (I'd set it in
the raspi-firmware package).

In any case, I'm downgrading this bug to Normal, as it has a known
workaround, but if you don't disagree, I'd still regard to it as an
existing, open bug.

Thanks!


signature.asc
Description: PGP signature


Bug#944920: Revise terminology used to specify requirements

2021-04-16 Thread Sam Hartman
> "Russ" == Russ Allbery  writes:

Russ> Russ Allbery  writes:
>> In attempting to revise recent GRs to use the same terminology as
>> Policy, I got frustrated again by the lack of precision of our
>> current language.  This is an attempt to make a minor
>> improvement.  It doesn't go all the way to using all-caps terms
>> the way that RFC 2119 does; I think that might be an improvement,
>> but it was a larger change than I wanted to tackle.

Russ> It's been over a year since the last activity on this bug so
Russ> although there were enough seconds for a revised form of this
Russ> patch, I'm reposting it to remind people where the discussion
Russ> was and as a quick double-check that I didn't mess up the
Russ> rebase.

Hi.
I reconfirm my second after reviewing the patch.


signature.asc
Description: PGP signature


Bug#987013: Release goal proposal: Remove Berkeley DB

2021-04-16 Thread Marco d'Itri
On Apr 15, Bastian Blank  wrote:

> After this time we really should try to get rid of this package, which
> even is NMU maintained since three years.
I am not persuaded. I maintain libberkeleydb-perl and it works fine, it 
is mature software.

But even if we agree that all the libdb5.3 reverse dependencies must 
migrate to a different database then probably we will need to keep 
around db5.3-util (and its dependency libdb5.3) to allow dumping and 
restoring the databases.
Not all software uses libdb as a cache which can just be regenerated 
and/or supports multiple databases and has internal dump/restore tools.

And then all the packages currently depending on libdb5.3 will need to 
implement, or at least document, a transition strategy.
Let me just mention postfix (easy), inn2 (possible but very resources 
intensive) and slapd (I am not sure, but it is critical and scary).

-- 
ciao,
Marco


signature.asc
Description: PGP signature


Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."

2021-04-16 Thread Bastian Germann

Am 16.04.21 um 14:25 schrieb Bastian Germann:

The issue is fixed in 2021.04 (experimental) which has the same default 
environment as 2021.01.


The upstream commit that fixed this is
https://github.com/u-boot/u-boot/commit/82d01f04facef1276cede067efd02d2a731ffe83

It applies cleanly on 2021.01+dfsg-4. Please include it or change the config for the affected boards 
not to try EFI bootmanager.




Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."

2021-04-16 Thread Vagrant Cascadian
On 2021-04-16, Bastian Germann wrote:
> On Wed, 10 Feb 2021 09:37:01 +0100 Ivo De Decker  wrote:
>> > With a locally built version of 2020.10+dfsg-2, I can no longer
>> > reproduce this issue at all.
>> > 
>> > Could you try with the new version?
>> 
>> Testing/unstable now has version 2021.01+dfsg-2. Benedikt, could you try this
>> version to see if the issue is still there?
>
> On a Lamobo R1, I can verify 2021.01 versions not to boot with a default 
> environment. However, 
> 2020.10+dfsg-2 boots. Even though the original issue has the same outcome, I 
> guess it is caused by 
> something else. I figured out my problem is caused by 
> https://github.com/u-boot/u-boot/commit/f3866909e35074ea6f50226d40487a180de1132f.
>  The 
> boot_efi_bootmgr will run and read a bad dtb, which makes a boot.scr boot 
> fail.
>
> The issue is fixed in 2021.04 (experimental) which has the same default 
> environment as 2021.01.

I can confirm this on the Lamobo R1, when rootfs is on scsi0 and it
first attempts to boot from microSD (failing to find boot_efi on
mmc0).

If I force it to boot from scsi0 first by interrupting the boot to get
to a u-boot shell, and typing "setenv boot_targets scsi0", it worked
fine with 2021.01 (e.g. it didn't hit the bootefi codepath) as well.

Booting the debian-installer image from
https://d-i.debian.org/daily-images/armhf/20210416-00:15/netboot/SD-card-images/
worked for me (which currently uses 2021.01).

That said, I'm not sure if this is the same issue as in the original
report, as the symptom stuck at "Starting kernel ..." can be caused by a
wide variety of issues...


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#987054: xserver-xorg-core: modesetting driver fails with etnaviv when GPU is Vivante GC2000

2021-04-16 Thread Josua Mayer
Package: xserver-xorg-core
Version: 2:1.20.10-3
Severity: normal
Tags: patch
X-Debbugs-Cc: josua.maye...@gmail.com

Dear Maintainer,

The Vivante GC2000 supported by etnaviv will report support for Desktop OpenGL 
1.3,
which in turn makes the modesetting driver fail because it requires 2.1 or 
later.

There is already a patch [1] in the master branch of xorg addressing this issue,
please consider backporting it to Debian for a chance of inclusion in Bullseye.

Yours sincerely
Josua Mayer

[1] 
https://gitlab.freedesktop.org/xorg/xserver/-/commit/26004df63c25061586a967f3586795a75280acc2

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 205 Apr 16 13:04 etnaviv.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.10.0-6-armmp (debian-ker...@lists.debian.org) 
(arm-linux-gnueabihf-gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU 
Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.28-1 (2021-04-09)

Xorg X server log files on system:
--
-rw-r--r-- 1 debian debian 17199 Apr 15 22:03 
/home/debian/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 root   root   16334 Apr 16 14:22 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[ 17477.754] 
X.Org X Server 1.20.10
X Protocol Version 11, Revision 0
[ 17477.754] Build Operating System: linux Debian
[ 17477.754] Current Operating System: Linux sr-imx6 5.10.0-6-armmp #1 SMP 
Debian 5.10.28-1 (2021-04-09) armv7l
[ 17477.754] Kernel command line:   console=ttymxc0,115200 log_level=7 
net.ifnames=0 console=tty cma=256M
[ 17477.755] Build Date: 17 February 2021  09:17:43AM
[ 17477.755] xorg-server 2:1.20.10-3 (https://www.debian.org/support) 
[ 17477.755] Current version of pixman: 0.40.0
[ 17477.755]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 17477.755] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 17477.755] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Apr 16 14:22:18 
2021
[ 17477.760] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 17477.760] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 17477.762] (==) No Layout section.  Using the first Screen section.
[ 17477.762] (==) No screen section available. Using defaults.
[ 17477.762] (**) |-->Screen "Default Screen Section" (0)
[ 17477.762] (**) |   |-->Monitor ""
[ 17477.769] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[ 17477.769] (**) |   |-->Device "etnaviv"
[ 17477.769] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 17477.769] (**) Option "AutoAddGPU" "false"
[ 17477.769] (==) Automatically adding devices
[ 17477.769] (==) Automatically enabling devices
[ 17477.769] (**) Not automatically adding GPU devices
[ 17477.769] (==) Max clients allowed: 256, resource mask: 0x1f
[ 17477.769] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 17477.769]Entry deleted from font path.
[ 17477.769] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[ 17477.769]Entry deleted from font path.
[ 17477.770] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[ 17477.770]Entry deleted from font path.
[ 17477.770] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist.
[ 17477.770]Entry deleted from font path.
[ 17477.770] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[ 17477.770]Entry deleted from font path.
[ 17477.770] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[ 17477.770]Entry deleted from font path.
[ 17477.770] (==) FontPath set to:
/usr/share/fonts/X11/misc,
built-ins
[ 17477.770] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 17477.770] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[ 17477.770] (II) Loader magic: 0x655f58
[ 17477.770] (II) Module ABI versions:
[ 17477.770]X.Org ANSI C Emulation: 0.4
[ 17477.770]X.Org Video Driver: 24.1
[ 17477.770]X.Org XInput driver : 24.1
[ 17477.770]X.Org Server Extension : 10.0
[ 17477.781] (++) using VT number 1

[ 17477.842] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/_34
[ 17477.846] (II) xfree86: Adding drm device (/dev/dri/card0)

Bug#962290: smuxi-frontend-gnome: freezes when I click on the channel with a recent notification

2021-04-16 Thread Raphael Hertzog
On Fri, 26 Feb 2021 10:10:19 +0100 Raphael Hertzog  wrote:
> On Thu, 11 Feb 2021, Mirco Bauer wrote:
> > Can you please open a terminal and run Smuxi in debug mode like this:
> > smuxi-frontend-gnome -d
> 
> I did that for multiple days but it looks like the issue is gone or its
> frequency decreased really dramatically. Feel free to close the bug.

I had the issue again today but I was not running in debug mode. I have
started to run again in debug mode but it seems really hard to
reproduce...

Cheers,
-- 
Raphaël Hertzog



Bug#984862: iptables-netflow-dkms: module wants to build with gcc instead of kernel's compiler

2021-04-16 Thread Andreas Beckmann
Followup-For: Bug #984862
Control: tag -1 patch
Control: severity -1 serious

Please bump the dkms dependency for bullseye, this issue can trigger on
upgrades from buster to bullseye where iptables-netflow-dkms is upgraded
before dkms. (e.g. apt-get upgrade && apt-get dist-upgrade)
iptables-netflow-dkms worked fine in buster with only gcc-8 (via
linux-compiler-gcc-8-x86) but no gcc installed.

Andreas
diff -Nru iptables-netflow-2.5.1/debian/changelog 
iptables-netflow-2.5.1/debian/changelog
--- iptables-netflow-2.5.1/debian/changelog 2020-10-18 11:22:35.0 
+0200
+++ iptables-netflow-2.5.1/debian/changelog 2021-04-16 15:37:38.0 
+0200
@@ -1,3 +1,10 @@
+iptables-netflow (2.5.1-2) UNRELEASED; urgency=medium
+
+  * iptables-netflow-dkms: Bump dkms dependency to ensure CC/CXX are set to
+the kernel's compiler.  (Closes: #984862)
+
+ -- Andreas Beckmann   Fri, 16 Apr 2021 15:37:38 +0200
+
 iptables-netflow (2.5.1-1) unstable; urgency=medium
 
   * New upstream bugfix release 2.5.1.
diff -Nru iptables-netflow-2.5.1/debian/control 
iptables-netflow-2.5.1/debian/control
--- iptables-netflow-2.5.1/debian/control   2020-04-27 08:39:15.0 
+0200
+++ iptables-netflow-2.5.1/debian/control   2021-04-16 15:37:30.0 
+0200
@@ -15,7 +15,7 @@
 
 Package: iptables-netflow-dkms
 Architecture: linux-any
-Depends: dkms,
+Depends: dkms (>= 2.8.4-3~),
  libc6-dev,
  libxtables-dev,
  pkg-config,


Bug#987053: chromium: Update to version 90.0.4430.72 (security-fixes)

2021-04-16 Thread Sedat Dilek
Package: chromium
Version: 89.0.4389.114-1
Severity: normal
X-Debbugs-Cc: sedat.di...@gmail.com

Dear Maintainer,

Google released chrome web-browser version 90.0.4430.72 with several CVE - some 
of them with "high" risk.
For details please see [1].

Debian's security tracker lists the following Open issues:

Bug stretch buster  bullseyesid 
Description
CVE-2021-21221  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21220  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21219  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21218  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21217  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21216  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21215  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21214  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21213  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21212  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21211  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21210  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21209  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21208  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21207  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21206  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21205  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21204  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21203  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21202  vulnerable  vulnerable  vulnerable  vulnerable  
CVE-2021-21201  vulnerable  vulnerable  vulnerable  vulnerable

Please update chromium to the same version as Google chrome.

Thanks.

Regards,
- Sedat -


[1] 
https://chromereleases.googleblog.com/2021/04/stable-channel-update-for-desktop_14.html
[2] https://security-tracker.debian.org/tracker/source-package/chromium
[3] 
https://www.heise.de/news/Sicherheitsupdates-Mehrere-gefaehrliche-Luecken-in-Chrome-gestopft-6017779.html
 (German)

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

Kernel: Linux 5.12.0-rc7-3-amd64-clang12-lto (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common  89.0.4389.114-1
ii  libasound2   1.2.4-1.1
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libatomic1   10.2.1-6
ii  libatspi2.0-02.38.0-2
ii  libavcodec58 7:4.3.2-0+deb11u1
ii  libavformat587:4.3.2-0+deb11u1
ii  libavutil56  7:4.3.2-0+deb11u1
ii  libc62.31-11
ii  libcairo21.16.0-5
ii  libcups2 2.3.3op2-3
ii  libdbus-1-3  1.12.20-2
ii  libdrm2  2.4.104-1
ii  libevent-2.1-7   2.1.12-stable-1
ii  libexpat12.2.10-2
ii  libflac8 1.3.3-2
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgbm1  20.3.5-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-3
ii  libharfbuzz0b2.7.4-1
ii  libicu67 67.1-6
ii  libjpeg62-turbo  1:2.0.6-4
ii  libjsoncpp24 1.9.4-4
ii  liblcms2-2   2.12~rc1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.63-1
ii  libopenjp2-7 2.4.0-3
ii  libopus0 1.3.1-0.1
ii  libpango-1.0-0   1.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpulse014.2-2
ii  libre2-9 20210201+dfsg-1
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.7.0-2
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libxrandr2   2:1.5.1-1
ii  libxshmfence11.3-1
ii  libxslt1.1   1.1.34-4
ii  

Bug#986592: closed by Debian FTP Masters (reply to u...@debian.org (Aaron M. Ucko)) (Bug#986592: fixed in kaptive 0.7.3-2)

2021-04-16 Thread Aaron M. Ucko
Andreas Tille  writes:

> Do you have any idea why your means to fix this issue were not
> successfully?

Ah, yeah, a closer look indicates that the code I patched takes effect
only for *silent* crashes, whereas these were fatal exceptions
accompanied by error messages.  I'll look into broadening this
workaround accordingly.

Meanwhile, thanks for pinging me -- I'd optimistically skipped
subscribing to this bug (but will do so now).

-- 
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#986863: linux: Serial terminal for RPi 4 and p400 corrupted during bootup

2021-04-16 Thread Ben Hutchings
On Mon, 2021-04-12 at 17:39 -0500, Gunnar Wolf wrote:
> Source: linux
> Version: 5.10.0-5
> Severity: important
> 
> During the boot process of the Raspberry Pi models 4 (4 and 8GB) and
> p400, the console starts working correctly, but as the vc4 video gets
> initialized, the console gets corrupted.
[...]

This is a known problem with the RPi 3/4 hardware:

"In order to use the mini UART, you need to configure the Raspberry Pi
to use a fixed VPU core clock frequency. This is because the mini UART
clock is linked to the VPU core clock, so that when the core clock
frequency changes, the UART baud rate will also change."

(from
).

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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


Bug#985956: Merge request submittted to initramfs-tools

2021-04-16 Thread Ben Hutchings
On Thu, 2021-04-15 at 17:28 +0200, Samuel Thibault wrote:
> Hello,
> 
> Pete Batard, le jeu. 15 avril 2021 16:11:02 +0100, a ecrit:
> > Quite a few people are negatively affected by this bug, and one can expect a
> > lot more to be if Debian 11 goes to release without the inclusion of
> > mdio-bcm-unimac.ko in the netinst ARM64 ISOs.
> > 
> > I have created an initramfs-tools merge request to attempt to fix the
> > problem, which can be found at:
> > https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/46
> 
> AIUI initramfs-tools rules are not used to build the nic-modules
> udeb, it'd rather be happening in the linux package, in
> debian/installer/modules/nic-modules, which indeed doesn't include
> drivers/net/mdio/.
> 
> Linux maintainers, do you know more on this issue?

Yes that's correct.  This should be fixed in both initramfs-tools (for
normal system boot) and linux (for installation).

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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


Bug#987052: timidity: Piano sounds from the right side instead of the center.

2021-04-16 Thread ooyoo...@gmail.com
Package: timidity
Version: 2.14.0-8
Severity: normal

Dear Maintainer,
Piano sounds from the right side instead of the center when I play
some midi files, such as
"https://www.mfiles.co.uk/downloads/beethoven-minuet-in-G.mid;.

I suspect the root cause is 0005-fix-drum-panning.patch, because
reverting the patch or commenting-out "pan=0" from bank 0 & prog 0 in
"/etc/timidity/fluidr3_gm.cfg" makes piano center.

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 timidity depends on:
ii  libao41.2.2+20180113-1.1
ii  libasound21.2.4-1.1
ii  libc6 2.31-11
ii  libflac8  1.3.3-2
ii  libice6   2:1.0.10-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.17~dfsg-1
ii  libncurses6   6.2+20201114-2
ii  libogg0   1.3.4-0.1
ii  libpng16-16   1.6.37-3
ii  libsm62:1.2.3-1
ii  libspeex1 1.2~rc1.2-1.1
ii  libtinfo6 6.2+20201114-2
ii  libvorbis0a   1.3.7-1
ii  libvorbisenc2 1.3.7-1
ii  libx11-6  2:1.7.0-2
ii  libxaw7   2:1.0.13-1.1
ii  libxext6  2:1.3.3-1.1
ii  libxmu6   2:1.1.2-2+b3
ii  libxt61:1.2.0-1
ii  lsb-base  11.1.0
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages timidity recommends:
ii  fluid-soundfont-gm  3.1-5.2

Versions of packages timidity suggests:
pn  fluid-soundfont-gs  
ii  freepats20060219-3
pn  pmidi   
ii  timidity-daemon 2.14.0-8

-- no debconf information



Bug#987051: less: file regarded as empty when new lines are appended

2021-04-16 Thread Vincent Lefevre
Package: less
Version: 487-0.1+b1
Severity: normal

I was looking at /var/log/mail.log and doing a sequence of Page Up
and Page Down, and suddenly, the file was regarded as empty, where
Page Up and Page Down no longer had any effect. I could see after
restarting "less" that a few new lines had been appended at about
the same time. So this is the probable cause of the issue.

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

Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core)
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages less depends on:
ii  debianutils  4.8.6.1
ii  libc62.28-10
ii  libtinfo66.1+20181013-2+deb10u2

less recommends no packages.

less suggests no packages.

-- no debconf information

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



Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."

2021-04-16 Thread Bastian Germann

On Wed, 10 Feb 2021 09:37:01 +0100 Ivo De Decker  wrote:

On Mon, Jan 04, 2021 at 08:27:51PM -0800, Vagrant Cascadian wrote:
> >> I'll test on a few of my systems to see if I can reproduce the issue.
> >
> > I can confirm similar behavior on a pinebook, although the kernel does
> > boot and actually load, and eventually displays on the LCD display (if I
> > "setenv console" from u-boot commandline). It even responds
> > appropriately to ctrl-alt-delete, so it is not a completely hung
> > kernel...
> 
> With a locally built version of 2020.10+dfsg-2, I can no longer

> reproduce this issue at all.
> 
> Could you try with the new version?


Testing/unstable now has version 2021.01+dfsg-2. Benedikt, could you try this
version to see if the issue is still there?


On a Lamobo R1, I can verify 2021.01 versions not to boot with a default environment. However, 
2020.10+dfsg-2 boots. Even though the original issue has the same outcome, I guess it is caused by 
something else. I figured out my problem is caused by 
https://github.com/u-boot/u-boot/commit/f3866909e35074ea6f50226d40487a180de1132f. The 
boot_efi_bootmgr will run and read a bad dtb, which makes a boot.scr boot fail.


The issue is fixed in 2021.04 (experimental) which has the same default 
environment as 2021.01.



Bug#987015: [pre-approval] unblock: python-apt/2.2.0

2021-04-16 Thread Julian Andres Klode
Please look at the second email in the bug, it's attached there.

(Sorry for layout, writing this on phone)

Sebastian Ramacher  schrieb am Fr., 16. Apr. 2021,
14:16:

> Control: tags -1 moreinfo
>
> On 2021-04-15 18:28:49 +0200, Julian Andres Klode wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: j...@debian.org
> >
> > Please unblock package python-apt
> >
> > [ Reason ]
> >
> > Want to bump version number to stable series versioning, mostly,
> > update the mirror list, and remove invalid PIE disablement which
> > triggers build failures in downstreams (it fails with LTO; I think
> > it's a no-op without LTO either way, or at least supposed to be,
> > given that we link with -fPIC).
> >
> > Don't really care much about the build dependency !nocheck
> > annotations, but they were already queued. Could revert
> > them if needed.
> >
> > [ Impact ]
> >
> > Mirror selection in tools will be from December 2020.
> >
> > [ Tests ]
> >
> > We have unit tests run at build time, but there are no
> > code changes, just metadata and build flags.
> >
> > [ Risks ]
> >
> > I'm not sure the PIE change does much really, the code is linked with
> > -fPIC, the annotations could trigger bootstrapping issues, but it's
> > not working right now anyway so meh.
> >
> > [ Checklist ]
> >   [x] all changes are documented in the d/changelog
> >   [x] I reviewed all changes and I approve them
> >   [x] attach debdiff against the package in testing
>
> Looks like the attachment is missing.
>
> Cheers
>
> >
> > [ Other info ]
> > (Anything else the release team should know.)
> >
> > unblock python-apt/2.2.0
> >
> > --
> > debian developer - deb.li/jak | jak-linux.org - free software dev
> > ubuntu core developer  i speak de, en
> >
>
> --
> Sebastian Ramacher
>


Bug#986915: unblock: pexpect/4.8.0-2

2021-04-16 Thread Sebastian Ramacher
Control: tags -1 confirmed moreinfo

On 2021-04-14 08:08:35 +, Gordon Ball wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package pexpect
> 
> (not yet uploaded to unstable)

ACK, please remove the moreinfo tag once the new version is available in
unstable.

Cheers

> 
> [ Reason ]
> #986727: flaky autopkgtests
> 
> [ Impact ]
> Failing autopkgtests in stable causing problems for stable updates,
> unnecessary noise, etc
> 
> [ Tests ]
> Built and ran the autopkgtest 15 times in a loop without failures after
> these changes.
> 
> [ Risks ]
> Affects autopkgtest only, should have no regression potential.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> [ Other info ]
> https://salsa.debian.org/python-team/packages/pexpect/-/compare/debian%2F4.8.0-1...master
> 
> unblock pexpect/4.8.0-2

> diff -Nru pexpect-4.8.0/debian/changelog pexpect-4.8.0/debian/changelog
> --- pexpect-4.8.0/debian/changelog2021-01-04 19:51:00.0 +
> +++ pexpect-4.8.0/debian/changelog2021-04-13 08:20:51.0 +
> @@ -1,3 +1,10 @@
> +pexpect (4.8.0-2) UNRELEASED; urgency=medium
> +
> +  * Skip several flaky tests, both for build and autopkgtest (Closes: 
> #986727)
> +  * Fix broken URL in d/watch
> +
> + -- Gordon Ball   Tue, 13 Apr 2021 08:20:51 +
> +
>  pexpect (4.8.0-1) unstable; urgency=medium
>  
>[ Ondřej Nový ]
> diff -Nru pexpect-4.8.0/debian/rules pexpect-4.8.0/debian/rules
> --- pexpect-4.8.0/debian/rules2021-01-04 19:51:00.0 +
> +++ pexpect-4.8.0/debian/rules2021-04-13 08:20:51.0 +
> @@ -5,7 +5,13 @@
>  # replwrap has issues when wrapping a readline-enabled command when
>  # bracketed-paste mode is enabled, which results in extra escape sequences
>  # pexpect isn't... expecting
> -export PYBUILD_TEST_ARGS = -k 'not (pxssh or replwrap)'
> +# test_beforeacross_chunks seems to contain a race condition as to whether
> +# the captured output contains a newline or not, which it then asserts
> +# test_spawn_uses_env appears to rarely fail with no exit code (also a race?)
> +export PYBUILD_TEST_ARGS = -k 'not (pxssh or replwrap or 
> test_before_across_chunks or test_spawn_uses_env)'
> +
> +# this skips two further tests upstream knows to be flaky in their CI
> +export TRAVIS = 1
>  
>  %:
>   dh $@ --with python3,sphinxdoc --buildsystem=pybuild
> diff -Nru pexpect-4.8.0/debian/tests/control 
> pexpect-4.8.0/debian/tests/control
> --- pexpect-4.8.0/debian/tests/control2021-01-04 19:51:00.0 
> +
> +++ pexpect-4.8.0/debian/tests/control2021-04-13 08:20:51.0 
> +
> @@ -1,2 +1,2 @@
> -Test-Command: python3 -m pytest -k 'not (pxssh or replwrap)' tests
> +Tests: pytest
>  Depends: @, python3-pytest, openssl
> diff -Nru pexpect-4.8.0/debian/tests/pytest pexpect-4.8.0/debian/tests/pytest
> --- pexpect-4.8.0/debian/tests/pytest 1970-01-01 00:00:00.0 +
> +++ pexpect-4.8.0/debian/tests/pytest 2021-04-13 08:20:51.0 +
> @@ -0,0 +1,11 @@
> +#!/bin/sh -e
> +
> +# used upstream to flag some tests as flaky in CI
> +export TRAVIS=1
> +
> +# copy the tests out of the source tree to use the installed lib
> +cp -r tests $AUTOPKGTEST_TMP
> +cd $AUTOPKGTEST_TMP
> +
> +# see d/rules for comments on why these tests are skipped
> +python3 -m pytest -k 'not (pxssh or replwrap or test_before_across_chunks or 
> test_spawn_uses_env)' tests
> diff -Nru pexpect-4.8.0/debian/watch pexpect-4.8.0/debian/watch
> --- pexpect-4.8.0/debian/watch2021-01-04 19:51:00.0 +
> +++ pexpect-4.8.0/debian/watch2021-04-13 08:20:51.0 +
> @@ -1,3 +1,3 @@
>  version=4
>  opts=uversionmangle=s/(rc|a|b|c)/~$1/ \
> -https://github.com/pexpect/pexpect/tags .*/archive/@ANY_VERSION@@ARCHIVE_EXT@
> +https://github.com/pexpect/pexpect/tags .*/@ANY_VERSION@@ARCHIVE_EXT@


-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#987015: [pre-approval] unblock: python-apt/2.2.0

2021-04-16 Thread Sebastian Ramacher
Control: tags -1 moreinfo

On 2021-04-15 18:28:49 +0200, Julian Andres Klode wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: j...@debian.org
> 
> Please unblock package python-apt
> 
> [ Reason ]
> 
> Want to bump version number to stable series versioning, mostly,
> update the mirror list, and remove invalid PIE disablement which
> triggers build failures in downstreams (it fails with LTO; I think
> it's a no-op without LTO either way, or at least supposed to be,
> given that we link with -fPIC).
> 
> Don't really care much about the build dependency !nocheck
> annotations, but they were already queued. Could revert
> them if needed.
> 
> [ Impact ]
> 
> Mirror selection in tools will be from December 2020.
> 
> [ Tests ]
> 
> We have unit tests run at build time, but there are no
> code changes, just metadata and build flags.
> 
> [ Risks ]
> 
> I'm not sure the PIE change does much really, the code is linked with
> -fPIC, the annotations could trigger bootstrapping issues, but it's
> not working right now anyway so meh.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing

Looks like the attachment is missing.

Cheers

> 
> [ Other info ]
> (Anything else the release team should know.)
> 
> unblock python-apt/2.2.0
> 
> -- 
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#986742: unblock: ruby2.7/2.7.3-1

2021-04-16 Thread Sebastian Ramacher
Control: tags -1 + moreinfo

On 2021-04-15 20:13:34 -0300, Antonio Terceiro wrote:
> On Sun, 11 Apr 2021 03:04:42 +0530 Utkarsh Gupta  wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: debian-r...@lists.debian.org
> > 
> > Hello,
> > 
> > Upstream has recently released a bug-fix only release after a
> > vulnerability, CVE-2021-28965, was discovered.
> > 
> > Upstream release note:
> > https://www.ruby-lang.org/en/news/2021/04/05/ruby-2-7-3-released/
> > Upstream git logs b/w 2.7.2 and 2.7.3:
> > https://github.com/ruby/ruby/compare/v2_7_2...v2_7_3
> > 
> > This is clearly a bug-fix only release and it'd be *really great* to
> > have this included in Bullseye. (I'd be sad not to but..) I understand
> > it's your call to make after analyzing so attaching the debdiff for
> > your reference and help (snipping ChangeLog entries for noise
> > reduction).
> > 
> > Hopefully, it'd be OK to get this included and have an even nicer
> > ruby2.7 for Bullseye. Thanks.
> 
>  99 files changed, 39552 insertions(+), 23134 deletions(-)
> 
> The debian diff looks very big because of 3 generated files: ChangeLog,
> parse.c, and ext/ripper/ripper.c (the last two being bison/yacc
> generated parsers). If you filter those out, the result is a lot more
> palatable:
> 
>  96 files changed, 3761 insertions(+), 886 deletions(-)
> 
> Roughtly 1/3 of the insertions are test cases:
> 
>  32 files changed, 1150 insertions(+), 97 deletions(-)

Since the initial bug report didn't reach the list due the size of the
diff, could you or Utkarsh please prepare a filtered debdiff including
the changes to debian/? This would make it easier for us to reach a
decision. Thanks

Cheers

> 
> I have reviewed the upstream patches and compared the upstream diff with
> the debian diff, and indeed all the changes are bug fixes.
> 
> There was one marked as a "Feature" in the commit message, but it was
> really a follwup to fix an inconsistency in a feature that has been
> added in the 2.7 series already. It will cause formerly invalid syntax
> to be valid, but won't break any currently working code.
> 
> I think the risk with this update is low, and releasing with the latest
> available ruby bugfix release will make it easier to provide stable
> support in bullseye.
> 
> Full disclosure: I am trying to get ruby into new hands, but I'm still a
> comaintainer and care a lot about it, so I'm not an uninterested party
> here.



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#987050: Please add Provides: zabbix-sender

2021-04-16 Thread Thomas Goirand
Package: zabbix-agent
Version: 1:5.0.8+dfsg-1
Severity: normal

Hi,

Upstream packaging has a separate zabbix-sender package. Please add a
"Provides: zabbix-sender" in the zabbix-agent package, to get closer to what
upstream does, and increase compatibility.

Cheers,

Thomas Goirand (zigo)



Bug#987049: acm: Missing documentation

2021-04-16 Thread Umberto Salsi
Package: acm
Version: 6.0+20200416-1
Severity: normal

Dear Maintainer,

I noted the current ACM-6.0+ package is lacking of all the documentation
available from the original package, more specifically:

- The user manual available under doc/manual. Without this manual, the bare
  executable can hardly be used.

- The navigation charts in PDF format available under doc/charts. These charts
  have been generated by several programs and Bash scripts available under
  the directory "tools"; data come from several sources and are partially
  edited by hand to generate the sceneries and the charts. Although possibly
  outdated and incomplete, it's still an useful starting base to learn the basic
  techniques of aerial navigation.



Bug#987048: buster-pu: package node-glob-parent/3.1.0-1+deb10u1

2021-04-16 Thread Yadd
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
node-glob-parent is vulnerable to Regex Denial of Service (ReDoS)
CVE-2020-28469

[ Impact ]
Low vulnerability risk

[ Tests ]
No test backported from 5.1.0 branch

[ Risks ]
Trivial patch

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

[ Changes ]
Just a better regex check. Patch from upstream adapted to 3.1.0

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 74d0753..46486a7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-glob-parent (3.1.0-1+deb10u1) unstable; urgency=medium
+
+  * Team upload
+  * Fix ReDoS (Closes: CVE-2020-28469)
+
+ -- Yadd   Fri, 16 Apr 2021 13:46:41 +0200
+
 node-glob-parent (3.1.0-1) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2020-28469.patch 
b/debian/patches/CVE-2020-28469.patch
new file mode 100644
index 000..663e173
--- /dev/null
+++ b/debian/patches/CVE-2020-28469.patch
@@ -0,0 +1,20 @@
+Description: fix ReDoS vulnerability
+ This change fixes a regular expression denial of service vulnerability.
+Author: Rich Trott 
+Origin: upstream, https://github.com/gulpjs/glob-parent/commit/f9231168
+Bug: https://snyk.io/vuln/SNYK-JS-GLOBPARENT-1016905
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-04-16
+
+--- a/index.js
 b/index.js
+@@ -10,7 +10,7 @@
+   if (isWin32 && str.indexOf('/') < 0) str = str.split('\\').join('/');
+ 
+   // special case for strings ending in enclosure containing path 
separator
+-  if (/[\{\[].*[\/]*.*[\}\]]$/.test(str)) str += '/';
++  if (/[\{\[].*[\}\]]$/.test(str)) str += '/';
+ 
+   // preserves full path in case of trailing path separator
+   str += 'a';
diff --git a/debian/patches/series b/debian/patches/series
index 439519e..421e1b0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 is-glob-4-compat.patch
+CVE-2020-28469.patch


Bug#987047: unblock: node-glob-parent/5.1.1+~5.1.0-2

2021-04-16 Thread Yadd
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package node-glob-parent

[ Reason ]
node-glob-parent is vulnerable to Regex Denial of Service (ReDoS),
CVE-2020-28469

[ Impact ]
Medium vulnerability

[ Tests ]
Test passed (build & autopkgtest), including new upstream check related
to this vulnerability

[ Risks ]
Low risk: upstream patch applied without any change

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

[ Other info ]
Patch is trivial, just a regex update

Cheers,
Yadd

unblock node-glob-parent/5.1.1+~5.1.0-2
diff --git a/debian/changelog b/debian/changelog
index 3e6f1d0..e60f126 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-glob-parent (5.1.1+~5.1.0-2) unstable; urgency=medium
+
+  * Team upload
+  * Fix ReDoS (Closes: CVE-2020-28469)
+
+ -- Yadd   Fri, 16 Apr 2021 13:34:51 +0200
+
 node-glob-parent (5.1.1+~5.1.0-1) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2020-28469.patch 
b/debian/patches/CVE-2020-28469.patch
new file mode 100644
index 000..99478a6
--- /dev/null
+++ b/debian/patches/CVE-2020-28469.patch
@@ -0,0 +1,36 @@
+Description: fix ReDoS vulnerability
+ This change fixes a regular expression denial of service vulnerability.
+Author: Rich Trott 
+Origin: upstream, https://github.com/gulpjs/glob-parent/commit/f9231168
+Bug: https://snyk.io/vuln/SNYK-JS-GLOBPARENT-1016905
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-04-16
+
+--- a/index.js
 b/index.js
+@@ -6,7 +6,7 @@
+ 
+ var slash = '/';
+ var backslash = /\\/g;
+-var enclosure = /[\{\[].*[\/]*.*[\}\]]$/;
++var enclosure = /[\{\[].*[\}\]]$/;
+ var globby = /(^|[^\\])([\{\[]|\([^\)]+$)/;
+ var escaped = /\\([\!\*\?\|\[\]\(\)\{\}])/g;
+ 
+--- a/test/index.test.js
 b/test/index.test.js
+@@ -209,6 +209,13 @@
+ 
+ done();
+   });
++
++  it('should not be susceptible to SNYK-JS-GLOBPARENT-1016905', 
function(done) {
++// This will time out if susceptible.
++gp('{' + '/'.repeat(5000));
++
++done();
++  });
+ });
+ 
+ if (isWin32) {
diff --git a/debian/patches/series b/debian/patches/series
index 439519e..421e1b0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 is-glob-4-compat.patch
+CVE-2020-28469.patch


Bug#922945: [Pkg-shadow-devel] Bug#922945: /var/log/lastlog is a 110 TByte sparse file, seriously affecting backup

2021-04-16 Thread Bálint Réczey
Control: severity -1 wishlist
Control: tags -1 confirmed upstream

Hi Sam,

Sam Morris  ezt írta (időpont: 2021. ápr. 13., K, 19:45):
>
> On Tue, 2021-04-13 at 15:26 +0200, Chris Hofstaedtler wrote:
> > This will then silently hide login failures from userids larger than
> > this ID? Given the original submitter has a user with uid 37940,
> > why whould this not be logged?
> >
> > If they didn't want those uids to be used, maybe dont assign them?
> >
> > Chris
>
> I think login.defs(5) says it best:
>
> "As higher user IDs are usually tracked by remote user identity and
> authentication services there is no need to create a huge sparse
> lastlog file for them."
>
> The design of the lastlog format means you either have an apparantly
> huge (sparse) file, which causes problems for badly written backup
> software, or you don't record information for users with high UIDs in
> this file at all.
>
> In any case, it looks like OpenSSH has its own code to read/write to
> /var/log/lastlog, rather than using pam_lastlog, so in any case
> changing login.defs wouldn't be sufficient.

Lastlog format is stable for a very long time and I don't think it
would be wise to change it and as Chris pointed out shipping a default
low
LASTLOG_UID_MAX would hide login failures which is also not desired as
a default.

Rsync (3.1.3-8) may be optimized to handle sparse files better, please
open a bug against rsync if you agree:

rbalint@zen:~$ fallocate -l 40 test-sparse-file
rbalint@zen:~$ fallocate -p -l 40 test-sparse-file
rbalint@zen:~$ time rsync -vS test-sparse-file test-sparse-file-copy
test-sparse-file

sent 4,000,976,652 bytes  received 35 bytes  533,463,558.27 bytes/sec
total size is 4,000,000,000  speedup is 1.00

real0m6.454s
user0m10.036s
sys0m1.952s
rbalint@zen:~$ ls -s test-sparse-file*
4 test-sparse-file  0 test-sparse-file-copy
rbalint@zen:~$ ls -lh test-sparse-file*
-rw-rw-r-- 1 rbalint rbalint 3.8G Apr 16 13:27 test-sparse-file
-rw-rw-r-- 1 rbalint rbalint 3.8G Apr 16 13:28 test-sparse-file-copy

Cheers,
Balint



Bug#987046: autopkgtest: VirtSubproc's execute_timeout leaves sudoify'd processes behind

2021-04-16 Thread Sebastien Delafond
Package: autopkgtest
Version: 5.16
Severity: normal
User: de...@kali.org
Usertags: origin-kali

If the execution duration exceeds the specified timeout,
`execute_timeout` tries to kill the process it started. This will
systematically fail if the command was wrapped in `sudoify`, because
`execute_timeout` will of course not be able to terminate a process
owned by UID 0.

Here's an actual example, where an lxc test container took too long to
get its networking available (the corresponding call is in
autopkgtest-virt-lxc's `wait_booted` at line 131):

```
autopkgtest-virt-lxc [06:18:24]: ERROR: WARNING: Cannot kill timed out process 
['sudo', 'lxc-attach', '--name', 'ci-106-c7628f8c', '--', 'sh', '-ec', 'if [ -d 
/run/systemd/system ]; then systemctl start network-online.target; else while 
ps -ef | grep -q "/etc/init\\.d/rc"; do sleep 1; done; fi']: [Errno 1] 
Operation not permitted
```

I used the following pytest code to isolate and reproduce the error:

```python
import pytest
import re
import sys
sys.path.append('lib')

import VirtSubproc


@pytest.mark.parametrize("cmd", (["sleep", "10"], ["sudo", "sleep", "10"]))
def test_timeout_one_second(cmd, capfd):
with pytest.raises(VirtSubproc.Timeout):
VirtSubproc.execute_timeout(None, 1, cmd)

out, err = capfd.readouterr()
assert not re.search(r'WARNING.*Cannot.*timed out process', err)
```

I don't see an easy solution to this problem; I am able to work around
the issue by using the attached patch, combined with giving the `debci` user
(that runs our autopkgtests) additional sudo permissions for the
commands that timeout for us, but that's suboptimal.

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.1.20
ii  libdpkg-perl1.20.7.1
ii  procps  2:3.3.17-2
ii  python3 3.9.1-1
ii  python3-debian  0.1.39

Versions of packages autopkgtest recommends:
ii  autodep8  0.24

Versions of packages autopkgtest suggests:
ii  lxc   1:4.0.6-1
pn  lxd   
ii  ovmf  2020.11-2
ii  qemu-efi-aarch64  2020.11-2
ii  qemu-efi-arm  2020.11-2
ii  qemu-system   1:5.2+dfsg-3
ii  qemu-utils1:5.2+dfsg-9
ii  schroot   1.6.10-11+b1
ii  vmdb2 0.22-1

-- no debconf information
commit fc83a3471e7f44d6330e8c88d6d9abe7bcd7ab26
Author: Sébastien Delafond 
Date:   Fri Apr 16 12:57:38 2021 +0200

virtsubproc: use sudo to kill timed-out processes started with sudo

diff --git a/lib/VirtSubproc.py b/lib/VirtSubproc.py
index bf948e6..67bc712 100644
--- a/lib/VirtSubproc.py
+++ b/lib/VirtSubproc.py
@@ -147,10 +147,22 @@ def execute_timeout(instr, timeout, *popenargs, 
**popenargsk):
 out = out.decode('UTF-8', 'replace')
 if err is not None:
 err = err.decode('UTF-8', 'replace')
-except Timeout:
+except Timeout as te:
 try:
 sp.kill()
 sp.wait()
+except PermissionError as pe:
+adtlog.info('INFO: Cannot kill timed out process %s due to 
insufficient permission: %s' %
+ (popenargs[0], pe))
+try:
+cmd = ['sudo', '--non-interactive', 'kill', str(sp.pid)]
+cp = subprocess.run(cmd, timeout=5, capture_output=True)
+if cp.returncode != 0:
+raise OSError(cp.stderr.decode('UTF-8', 'replace'))
+raise te
+except OSError as es:
+adtlog.error('WARNING: Cannot sudo-kill timed out process %s: 
%s' %
+ (popenargs[0], es))
 except OSError as e:
 adtlog.error('WARNING: Cannot kill timed out process %s: %s' %
  (popenargs[0], e))


Bug#987045: skypeforlinux fails to start using supplied profile

2021-04-16 Thread Phil Nightowl
Package: firejail-profiles
Version: 0.9.64.4-1~bpo10+1

Launching skypeforlinux version 8.71.0.36 using supplied profile fails with 
the following error:

Error: tmpfs outside $HOME is only available for root
Error: proc 13576 cannot sync with peer: unexpected EOF

Downgrading skype to 8.67.0.87 does not help, earlier versions are not 
available any longer.

I also tried disabling AppArmor as suggested in upstream's issue #2933 
(https://github.com/netblue30/firejail/issues/2933) by creating 
/etc/firejail/skypeforlinux.local containing

ignore apparmor

This did not help for me, as in fact expected, since the errors mentioned 
in that issue are different.

I assume this has to be fixed upstream anyway.


Best regards,

Phil



Bug#984250: murasaki: ftbfs with GCC-11

2021-04-16 Thread Nilesh Patra
control: tags -1 patch

Fix in salsa:

https://salsa.debian.org/med-team/murasaki/-/commit/9f9af7183630aefb87a0663576db94a2f28b8899

Awaiting upload.

Nilesh


signature.asc
Description: PGP signature


Bug#986821: freecad: Garbled menu makes freecad unusable

2021-04-16 Thread Tobias Frost
On Fri, Apr 16, 2021 at 12:41:28PM +0200, Tobias Frost wrote:
> On Fri, Apr 16, 2021 at 12:19:01PM +0200, Tobias Frost wrote:
> 
> Another possiblity to try: Boot from an Debian live image and install freecad 
> there.
> Hopefully this helps pinpointing if your hardware is part of the equation or 
> if there
> is something with your installation…

Sorry, bad me… There are none for testing…
 



Bug#986821: freecad: Garbled menu makes freecad unusable

2021-04-16 Thread Tobias Frost
On Fri, Apr 16, 2021 at 12:19:01PM +0200, Tobias Frost wrote:

Another possiblity to try: Boot from an Debian live image and install freecad 
there.
Hopefully this helps pinpointing if your hardware is part of the equation or if 
there
is something with your installation…



Bug#987044: libbiosig3: certain files can crash save2gdf and produce invalid json output

2021-04-16 Thread Alois Schlögl

Package: libbiosig3
Version: 2.1.2-3
Severity: important
Tags: patch

Dear Maintainer,


as suggested by you [1], I'm filing this bug report.

  * What led up to the situation?

Trying to handle this files
https://www.physionet.org/files/sleep-edfx/1.0.0/sleep-cassette/SC4001EC-Hypnogram.edf?download
with Biosig-tools causes these two issues :

1) save2gdf -JSON SC4001EC-Hypnogram.edf
fails to produce valid JSON, because it contains the field

    SampleRate : inf

You can check with
    save2gdf -JSON SC4001EC-Hypnogram.edf | json_pp

or python
    import biosig, json
    HDR = json.loads(biosig.header('SC4001EC-Hypnogram.edf'))



2) Converting the edf into a gdf file crashes. You can test with:

   save2gdf SC4001EC-Hypnogram.edf SC4001EC-Hypnogram.edf.gdf

and does not produce the expected output.

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



The patch as suggested [1] solves both issues, and a similar issue for 
other file formats (ACQ, BKR, and HEKA).



The issue was most likely introduced in Jan 2018, when the initial read 
page size was increased from 512 to 4096 bytes.

It most likely affects also libbiosig2 (v1.9.3) in buster.

Moreover, it might also affect the package Stimfit, which uses an 
outdated copy of libbbiosig.


The best solution would be to rebuild stimfit with
   ./configure --with-biosig ...
or
   ./configure --with-biosig2 ...

with a build-dependency on libbiosig-dev, and a runtime dependency on
   libbiosig2 | libbiosig3

The patches are already in upstream (see Jan 2021 in [2]);

The package sigviewer is also affected but updating libbiosig is 
sufficient there because it is dynamically linked, and the API did not 
change.



[1] 
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2021-April/091120.html


[2] https://github.com/neurodroid/stimfit/commits/master



Cheers,
  Alois



Bug#986821: freecad: Garbled menu makes freecad unusable

2021-04-16 Thread Tobias Frost
On Fri, Apr 16, 2021 at 10:53:57AM +0200, Michael Jarosch wrote:
> Am 15.04.21 um 19:40 schrieb Tobias Frost:
> 
> > My third machine, a rusty Thinkpad E130 powered by an i3-3227-U.. Also
> > works…
> …and the E130 uses the same GPU core as my T530. Now, it's getting
> complicated!

Indeed...

Because I'm running out of questions: The T530 has options with an NVidia GPU.
Yours none of those, right?

> > What you can try:
> > - check what over packages have been updated that could bring the breakage
> >(maybe some kernel or intel gfx thingy?)
> This would be a bit of work… I apt update/upgrade about every day, but I
> don't use freecad as often as I upgrade the system…
> Kernel is 5.10.0-5-amd64, now, but I guess this was upgraded, lately. No
> change, whatsoever.
> > - temporarily rename ~/.FreeCAD to something else, to rule out that there is
> >something in the config.
> Done that, no change.
> > - Can you ensure that all freecad packages are updated... (I think a 
> > versioned
> >depdency is missing, possibly #980474) I tried manually to get to an
> invalid combination,
> >but the only "solution" was package freecad at 0.19 and freecad-common at
> >0.18, which makes freecad stop working, but with an different error (no 
> > python
> >module named freecad, completly empty main window)
> 
> On my system, there is freecad, freecad-common, freecad-python3,
> libfreecad-python3-0.19 and every single package is labeled as
> 0.19.1+dfsg1-2.
> 
> Another try: I'm using Gnome on all my 3 systems(, which should all have the
> same Gnome version numbers, since I use Debian Testing on all of those
> machines). Do you use another Desktop Environment?

I'm using Gnome as well. But I'm on unstable for the Nvidia machine and on 
testing
for the others.

Another random idea: Can you try to create a new user and try from there. Just 
to
ensure that there isnt something with your user account (E.g I had a silly bug 
where
I had something in $HOME/.local shadowing stuff some time ago…)

Another possiblity: Do you have obsolete packages installed? (aptitude has
this section "Locally generated packages" which are also packages that have been
removed. Maybe something from there...


> Greets!
> 



Bug#986905: IPAccounting=yes does not work for systemd-run --user,Re: Bug#986905: IPAccounting=yes does not work for systemd-run --user

2021-04-16 Thread Ryutaroh Matsumoto
Control: tags -1 + wontfix

> Not sure what I should do with this bug report (besides closing it).

You are welcome to close this.
It seems a bit strange that IPAccounting=yes is also accepted by
systemd user instance...
Sorry for my initial report not being much pointed...

Best regards, Ryutaroh



Bug#987030: linux-image-5.10.0-6-amd64 - Fans speed maximum - CPU load < 1%

2021-04-16 Thread Hans van Kranenburg
Hi,

On 4/15/21 10:51 PM, klak wrote:
> Package:  linux-image-5.10.0-6-amd64
> Version:  5.10.28-1
> 
> Hello Maintainer,
> 
> every few minutes the fans turn to maximum for a few seconds. The CPU
> load is less than 1 %, but the fans are turning maximum. The problen
> starts with version 5.9. I didn't see anything conspicuous in the
> syslog. The machine is a KVM host and the problem also occurs when it
> is idle.

I have the same issue here, it started at the moment I moved from the
4.19 kernel to 5.9, and now 5.10. For totally non-obvious reasons fans
start blowing like crazy regularly for a few seconds. When observing
system load, it's just hovering around 0.2 - 0.4, no peaks observed.

This is an Intel NUC with just a Buster system used as mostly inactive
desktop.

FWIW, attached are output of lshw and lspci -v.

> Board + CPU :
> =
> DMI: Intel Corporation S5520HC/S5520HC, BIOS
> S5500.86B.01.00.0064.050520141428 05/05/2014
> 
> smpboot: CPU0: Intel(R) Xeon(R) CPU   L5640  @ 2.27GHz (family:
> 0x6, model: 0x2c, stepping: 0x2)
> 
> Performance Events: PEBS fmt1+, Westmere events, 16-deep LBR, Intel PMU
> driver.
> DMAR: Intel(R) Virtualization Technology for Directed I/O

Hans
dorothy
description: Mini PC
product: NUC8i5BEH (BOXNUC8i5BEH)
vendor: Intel(R) Client Systems
version: J72747-305
serial: G6BE94400JDL
width: 64 bits
capabilities: smbios-3.2.1 dmi-3.2.1 smp vsyscall32
configuration: boot=normal chassis=mini family=Intel NUC sku=BOXNUC8i5BEH 
uuid=889D1A9F-A26C-DC8C-5D1C-1C697A09E4C6
  *-core
   description: Motherboard
   product: NUC8BEB
   vendor: Intel Corporation
   physical id: 0
   version: J72692-307
   serial: GEBE94TU
   slot: Default string
 *-firmware
  description: BIOS
  vendor: Intel Corp.
  physical id: 0
  version: BECFL357.86A.0072.2019.0524.1801
  date: 05/24/2019
  size: 64KiB
  capacity: 16MiB
  capabilities: pci upgrade shadowing cdboot bootselect socketedrom edd 
int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int14serial 
int17printer acpi usb biosbootspecification uefi
 *-memory
  description: System Memory
  physical id: 3b
  slot: System board or motherboard
  size: 32GiB
*-bank:0
 description: SODIMM DDR4 Synchronous 2400 MHz (0.4 ns)
 product: CT16G4SFD824A.M16FE
 vendor: 859B
 physical id: 0
 serial: E3029A84
 slot: SODIMM1
 size: 16GiB
 width: 64 bits
 clock: 2400MHz (0.4ns)
*-bank:1
 description: SODIMM DDR4 Synchronous 2400 MHz (0.4 ns)
 product: CT16G4SFD824A.M16FE
 vendor: 859B
 physical id: 1
 serial: E302B39D
 slot: SODIMM2
 size: 16GiB
 width: 64 bits
 clock: 2400MHz (0.4ns)
 *-cache:0
  description: L1 cache
  physical id: 45
  slot: L1 Cache
  size: 256KiB
  capacity: 256KiB
  capabilities: synchronous internal write-back unified
  configuration: level=1
 *-cache:1
  description: L2 cache
  physical id: 46
  slot: L2 Cache
  size: 1MiB
  capacity: 1MiB
  capabilities: synchronous internal write-back unified
  configuration: level=2
 *-cache:2
  description: L3 cache
  physical id: 47
  slot: L3 Cache
  size: 6MiB
  capacity: 6MiB
  capabilities: synchronous internal write-back unified
  configuration: level=3
 *-cpu
  description: CPU
  product: Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
  vendor: Intel Corp.
  physical id: 48
  bus info: cpu@0
  version: Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
  serial: To Be Filled By O.E.M.
  slot: U3E1
  size: 3139MHz
  capacity: 3800MHz
  width: 64 bits
  clock: 100MHz
  capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 
apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht 
tm pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc art arch_perfmon pebs bts 
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 
monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 
x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 
3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp 
tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep 
bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec 
xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp 
md_clear flush_l1d cpufreq
  configuration: cores=4 enabledcores=4 

Bug#986806: CVE-2021-28965

2021-04-16 Thread Pirate Praveen
On Mon, 12 Apr 2021 12:05:29 +0200 Moritz Muehlenhoff  
wrote:
> 
https://www.ruby-lang.org/en/news/2021/04/05/xml-round-trip-vulnerability-in-rexml-cve-2021-28965/

>
> Why is there a separate package duplicating rexml from src:ruby2.7 
in bullseye?


I think the separate package was introduced by mistake without seeing 
the copy embedded in ruby. I think the right way is to fix this in ruby 
and remove this separate package. But I'd like someone from ruby team 
to confirm this.




Bug#986905: IPAccounting=yes does not work for systemd-run --user

2021-04-16 Thread Michael Biebl

Am 16.04.2021 um 06:07 schrieb Ryutaroh Matsumoto:

ryutaroh@raspi4b8gb:~$ systemd-run --user --scope --unit=test -p "IPAccounting=yes" 
sh -c 'wget -O /dev/null http://www.debian.org/ ; sleep 100; exit 0' &



Is it expected to work???



eBPF requires root privileges, so this is supposed to fail. This is a 
kernel limitation.
That's probably the reason by DefaultIPAccounting= was not added to the 


default user.conf in the first place.

Aside from fixing the kernel to allow rootless eBPF, there is not a lot 
systemd can do (and no, making it setuid is not an option).


Not sure what I should do with this bug report (besides closing it).

Michael



OpenPGP_signature
Description: OpenPGP digital signature


Bug#987043: nmu: 4 packages where adequate reports symbol-size-mismatch

2021-04-16 Thread Andreas Beckmann
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

adequate reports symbol-size-mismatch for a few packages, these should
be fixable with binNMUs:

nmu tcpreplay_4.3.3-2 . ANY . unstable . -m "Rebuild to update symbol size for 
pcap_version."
nmu ipband_0.8.1-5.1 . ANY . unstable . -m "Rebuild to update symbol size for 
pcap_version."
nmu mpqc3_0.0~git20170114-4.1 . ANY . unstable . -m "Rebuild to update symbol 
size for libint2_build_eri."
nmu spatialite-gui_2.1.0~beta1-1 . ANY . unstable . -m "Rebuild to update 
symbol size for pj_release."

  tcpreplay: symbol-size-mismatch /usr/bin/tcpbridge => pcap_version
  tcpreplay: symbol-size-mismatch /usr/bin/tcpliveplay => pcap_version
  tcpreplay: symbol-size-mismatch /usr/bin/tcpprep => pcap_version
  tcpreplay: symbol-size-mismatch /usr/bin/tcpreplay => pcap_version
  tcpreplay: symbol-size-mismatch /usr/bin/tcpreplay-edit => pcap_version
  tcpreplay: symbol-size-mismatch /usr/bin/tcprewrite => pcap_version

  ipband: symbol-size-mismatch /usr/sbin/ipband => pcap_version

  mpqc3: symbol-size-mismatch /usr/bin/mpqc3 => libint2_build_eri

  spatialite-gui: symbol-size-mismatch /usr/bin/spatialite-gui => pj_release


Andreas



Bug#986975: libgdal28: please add Breaks: libgdal20

2021-04-16 Thread Sebastiaan Couwenberg
On 4/16/21 10:39 AM, Andreas Beckmann wrote:
> Hi Sebastiaan,
> 
> On 15/04/2021 07.34, Sebastiaan Couwenberg wrote:
>> This issue cannot be fixed in bullseye because gdal cannot be updated
>> via unstable.
> 
> Can you try to get this in via tpu?

>From the freeze policy:

"
 We very strongly prefer changes that can be done via unstable instead
 of testing-proposed-updates. If there are unrelated changes in
 unstable, we ask you to revert these changes instead of making an
 upload to testing-proposed-updates. Hence, and also because it may
 impact other packages in unstable that try to migrate to bullseye, it
 is recommended that, during the freeze, you do not upload to unstable
 any changes for which you do not intend to request an unblock.
"

As I'm not going to revert the changes in unstable for this issue, gdal
cannot be updated before the freeze. It could be fixed with a
stable-update after the release, but I doubt that's worth the effort as
upgrading the kept back packages after full-upgrade is sufficient. This
is something I had to do for other packages on some systems during the
distribution upgrade to buster as well.

> Apply to and upload the sid version first ...
> 
>> The release team is unlikely to unblock the package in unstable because
>> it also has changes for 3.2.2 which was uploaded to unstable by mistake.
>>
>> The issue cannot be reproduced when only gdal-bin and its dependencies
>> are installed. `apt full-upgrade` has no issues.
>>
>> When monteverdi is installed, after `apt upgrade && apt full-upgrade`
>> apt finds a solution when the kept back packages are explicitly
>> installed/upgraded.
>>
>> Shouldn't this issue be fixed in hdf5 since that causes the problem?
> 
> I can fix some of the hdf5 problems by adding some Breaks to libsz2
> (currently being tested). libsz2 is a dependency of libhdf5-103{,-1} and
> usually has a higher score than it. Adding a Breaks against libgdal20
> there too works only for a part of the cases since libgdal20 usually has
> a higher score (that scoring is sometimes a bit like magic), but in
> these cases libgdal28 would have a winning score. (But libsz2 seems to
> solve the cases where libgdal28 loses to libgdal20, so both are needed.)
> 
> The bigger hammer would be gcc-10-base ... I'll need to add some Breaks
> there for some difficult upgrade paths, but would like to keep that as
> minimal as possible.

monteverdi has a very low popcon, so this issue is unlikely to affect
many users. It doesn't seem pressing enough to fix in gdal.

Kind Regards,

Bas

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



Bug#986996: More information

2021-04-16 Thread Thomas Viehmann
...apparently the fix was accidentally not included in the 0.3.14 
release, see

https://github.com/xianyi/OpenBLAS/issues/2715

for more information.

Thank you

Thomas



Bug#986821: freecad: Garbled menu makes freecad unusable

2021-04-16 Thread Michael Jarosch

Am 15.04.21 um 19:40 schrieb Tobias Frost:

My third machine, a rusty Thinkpad E130 powered by an i3-3227-U.. Also 
works… 
…and the E130 uses the same GPU core as my T530. Now, it's getting 
complicated!

What you can try:
- check what over packages have been updated that could bring the breakage
   (maybe some kernel or intel gfx thingy?)
This would be a bit of work… I apt update/upgrade about every day, but I 
don't use freecad as often as I upgrade the system…
Kernel is 5.10.0-5-amd64, now, but I guess this was upgraded, lately. No 
change, whatsoever.

- temporarily rename ~/.FreeCAD to something else, to rule out that there is
   something in the config.

Done that, no change.

- Can you ensure that all freecad packages are updated... (I think a versioned
   depdency is missing, possibly #980474) I tried manually to get to an 

invalid combination,

   but the only "solution" was package freecad at 0.19 and freecad-common at
   0.18, which makes freecad stop working, but with an different error (no 
python
   module named freecad, completly empty main window)


On my system, there is freecad, freecad-common, freecad-python3, 
libfreecad-python3-0.19 and every single package is labeled as 
0.19.1+dfsg1-2.


Another try: I'm using Gnome on all my 3 systems(, which should all have 
the same Gnome version numbers, since I use Debian Testing on all of 
those machines). Do you use another Desktop Environment?


Greets!



Bug#986581: debian-security-support: logic behind version-based filters

2021-04-16 Thread Sylvain Beucler

Hi Christoph,

Thanks a lot for your precisions,

On 13/04/2021 10:02, Christoph Biedl wrote:

Sylvain Beucler wrote...

We could not find a valid use case for this feature, while it is causing
some missing reports as with 'nodejs', as explained in the above BTS entry.

Did we miss something?


Well, I cannot remember the idea behind the logic, so feel free to do
what you (as a group) consider appropriate.

From guessing, I'd say: The case of "Installed package has a version
number higher than the last supported one" - then the security status of
that package is mostly undefined. Possibly I had backports in mind here:
So if a backport is installed *and* that one has proper security
support, I consider it correct to stay silent about that situation; in
fact, alerting is even wrong because it creates unnecessary noise - that
will educate users to ignore such alerts. But it's indeed hard to tell
whether this situation applies (checking apt-cache policy, checking the
security tracker [please don't], yada yade).


Moreover, I see that:
- backports have no official security support so are never supported
  https://backports.debian.org/FAQ/
- the code incorrectly skips packages with no ("0") version

I dropped the version-based check and adapted the test suite:
https://salsa.debian.org/debian/debian-security-support/-/merge_requests/9
pending review with secteam.


The other feature, being able to end support in advance - well I'd call
that a nice hack and I'd certainly keep it. Although I'd agree it will
rarely be used.


Yes, date-based should be enough for this case.

Cheers!
Sylvain



Bug#987042: buster-pu: package node-handlebars/4.1.0-1+deb10u3

2021-04-16 Thread Yadd
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: utka...@debian.org

[ Reason ]
node-handlebars is vulnerable to Arbitrary Code Execution and Remote
Code Execution (CVE-2019-20920 and CVE-2021-23369)

[ Impact ]
Medium vulnerabilities

[ Tests ]
Sadly there are no test launched in Buster even if upstream added some
checks

[ Risks ]
Medium risk, upstream patches were applied without changes

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

[ Changes ]
More checks for given arguments

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index e49c409..e55d497 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-handlebars (3:4.1.0-1+deb10u3) buster; urgency=medium
+
+  * Team upload
+  * Fix arbitrary code execution (Closes: CVE-2019-20920)
+  * Fix remote code execution (Closes: CVE-2021-23369)
+
+ -- Yadd   Fri, 16 Apr 2021 10:31:24 +0200
+
 node-handlebars (3:4.1.0-1+deb10u2) buster; urgency=medium
 
   * Fix regression introduced in 3:4.1.0-1+deb10u1
diff --git a/debian/patches/CVE-2019-20920.patch 
b/debian/patches/CVE-2019-20920.patch
new file mode 100644
index 000..54e3bd3
--- /dev/null
+++ b/debian/patches/CVE-2019-20920.patch
@@ -0,0 +1,114 @@
+Description: fix for CVE-2019-20920
+Author: Nils Knappmeier 
+Origin: upstream, 
https://github.com/handlebars-lang/handlebars.js/commit/1988878
+Bug: https://snyk.io/vuln/SNYK-JS-HANDLEBARS-534478
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2020-10-12
+
+--- a/lib/handlebars/compiler/compiler.js
 b/lib/handlebars/compiler/compiler.js
+@@ -56,7 +56,7 @@
+ 
+ // These changes will propagate to the other compiler components
+ let knownHelpers = options.knownHelpers;
+-options.knownHelpers = {
++options.knownHelpers = extend(Object.create(null), {
+   'helperMissing': true,
+   'blockHelperMissing': true,
+   'each': true,
+@@ -65,15 +65,7 @@
+   'with': true,
+   'log': true,
+   'lookup': true
+-};
+-if (knownHelpers) {
+-  // the next line should use "Object.keys", but the code has been like 
this a long time and changing it, might
+-  // cause backwards-compatibility issues... It's an old library...
+-  // eslint-disable-next-line guard-for-in
+-  for (let name in knownHelpers) {
+-  this.options.knownHelpers[name] = knownHelpers[name];
+-  }
+-}
++}, options.knownHelpers);
+ 
+ return this.accept(program);
+   },
+--- a/lib/handlebars/compiler/javascript-compiler.js
 b/lib/handlebars/compiler/javascript-compiler.js
+@@ -2,6 +2,7 @@
+ import Exception from '../exception';
+ import {isArray} from '../utils';
+ import CodeGen from './code-gen';
++import {dangerousPropertyRegex} from '../helpers/lookup';
+ 
+ function Literal(value) {
+   this.value = value;
+@@ -13,8 +14,9 @@
+   // PUBLIC API: You can override these methods in a subclass to provide
+   // alternative compiled forms for name lookup and buffering semantics
+   nameLookup: function(parent, name/* , type*/) {
+-if (name === 'constructor') {
+-  return ['(', parent, '.propertyIsEnumerable(\'constructor\') ? ', 
parent, '.constructor : undefined', ')'];
++if (dangerousPropertyRegex.test(name)) {
++  const isEnumerable = [ 
this.aliasable('container.propertyIsEnumerable'), '.call(', parent, ',', 
JSON.stringify(name), ')'];
++  return ['(', isEnumerable, '?', _actualLookup(), ' : undefined)'];
+ }
+ if (JavaScriptCompiler.isValidJavaScriptVariableName(name)) {
+   return [parent, '.', name];
+--- a/lib/handlebars/helpers/lookup.js
 b/lib/handlebars/helpers/lookup.js
+@@ -1,5 +1,13 @@
++export const dangerousPropertyRegex = 
/^(constructor|__defineGetter__|__defineSetter__|__lookupGetter__|__proto__)$/;
++
+ export default function(instance) {
+   instance.registerHelper('lookup', function(obj, field) {
+-return obj && obj[field];
++if (!obj) {
++  return obj;
++}
++if (dangerousPropertyRegex.test(String(field)) && 
!obj.propertyIsEnumerable(field)) {
++  return undefined;
++}
++return obj[field];
+   });
+ }
+--- a/spec/security.js
 b/spec/security.js
+@@ -21,6 +21,36 @@
+ });
+ });
+ 
++describe('GH-1563', function() {
++it('should not allow to access constructor after overriding via 
__defineGetter__', function() {
++if (({}).__defineGetter__ == null || ({}).__lookupGetter__ == 
null) {
++return this.skip(); // Browser does not support this exploit 
anyway
++}
++expectTemplate('{{__defineGetter__ "undefined" valueOf }}' +
++'{{#with __lookupGetter__ }}' +
++'{{__defineGetter__ "propertyIsEnumerable" (this.bind 

Bug#986975: libgdal28: please add Breaks: libgdal20

2021-04-16 Thread Andreas Beckmann

Hi Sebastiaan,

On 15/04/2021 07.34, Sebastiaan Couwenberg wrote:

This issue cannot be fixed in bullseye because gdal cannot be updated
via unstable.


Can you try to get this in via tpu? Apply to and upload the sid version 
first ...



The release team is unlikely to unblock the package in unstable because
it also has changes for 3.2.2 which was uploaded to unstable by mistake.

The issue cannot be reproduced when only gdal-bin and its dependencies
are installed. `apt full-upgrade` has no issues.

When monteverdi is installed, after `apt upgrade && apt full-upgrade`
apt finds a solution when the kept back packages are explicitly
installed/upgraded.

Shouldn't this issue be fixed in hdf5 since that causes the problem?


I can fix some of the hdf5 problems by adding some Breaks to libsz2 
(currently being tested). libsz2 is a dependency of libhdf5-103{,-1} and 
usually has a higher score than it. Adding a Breaks against libgdal20 
there too works only for a part of the cases since libgdal20 usually has 
a higher score (that scoring is sometimes a bit like magic), but in 
these cases libgdal28 would have a winning score. (But libsz2 seems to 
solve the cases where libgdal28 loses to libgdal20, so both are needed.)


The bigger hammer would be gcc-10-base ... I'll need to add some Breaks 
there for some difficult upgrade paths, but would like to keep that as 
minimal as possible.



Andreas



Bug#987013: Release goal proposal: Remove Berkeley DB

2021-04-16 Thread Gerardo Ballabio
Bastian Blank wrote:
> Berkeley DB was relicensed to AGPLv3 almost eight years ago.

Sorry but I don't understand, why is that a problem?
I believe the AGPL (you mean the GNU Affero General Public License,
right?) is a free license. Is it not?

Gerardo



Bug#987041: unblock: node-handlebars/4.7.6+~4.1.0-2

2021-04-16 Thread Yadd
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package node-handlebars

[ Reason ]
node-handlebars is vulnerable to Remote Code Execution (RCE)
(CVE-2021-23369).

[ Impact ]
Medium vulnerability

[ Tests ]
Yes, code passed (build & autopkgtest), including new checks

[ Risks ]
Low risk; change is trivial (upstream patch applied without any change)

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

Cheers,
Yadd

unblock node-handlebars/4.7.6+~4.1.0-2
diff --git a/debian/changelog b/debian/changelog
index 675dba0..215d5a2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-handlebars (3:4.7.6+~4.1.0-2) unstable; urgency=medium
+
+  * Team upload
+  * Fix remote code execution (Closes: CVE-2021-23369)
+
+ -- Yadd   Fri, 16 Apr 2021 10:19:56 +0200
+
 node-handlebars (3:4.7.6+~4.1.0-1) unstable; urgency=medium
 
   [ Xavier Guimard ]
diff --git a/debian/patches/CVE-2021-23369.patch 
b/debian/patches/CVE-2021-23369.patch
new file mode 100644
index 000..98ee3fc
--- /dev/null
+++ b/debian/patches/CVE-2021-23369.patch
@@ -0,0 +1,80 @@
+Description: fix Remote Code Execution (RCE)
+ when selecting certain compiling options to compile templates coming from an
+ untrusted source.
+Author: Nils Knappmeier 
+Origin: upstream, 
https://github.com/handlebars-lang/handlebars.js/commit/b6d3de71
+ https://github.com/handlebars-lang/handlebars.js/commit/f0589701
+Bug: https://snyk.io/vuln/SNYK-JS-HANDLEBARS-1056767
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-04-16
+
+--- a/lib/handlebars/compiler/javascript-compiler.js
 b/lib/handlebars/compiler/javascript-compiler.js
+@@ -16,7 +16,12 @@
+ return this.internalNameLookup(parent, name);
+   },
+   depthedLookup: function(name) {
+-return [this.aliasable('container.lookup'), '(depths, "', name, '")'];
++return [
++  this.aliasable('container.lookup'),
++  '(depths, ',
++  JSON.stringify(name),
++  ')'
++];
+   },
+ 
+   compilerInfo: function() {
+--- a/lib/handlebars/runtime.js
 b/lib/handlebars/runtime.js
+@@ -124,7 +124,7 @@
+   loc: loc
+ });
+   }
+-  return obj[name];
++  return container.lookupProperty(obj, name);
+ },
+ lookupProperty: function(parent, propertyName) {
+   let result = parent[propertyName];
+--- a/spec/security.js
 b/spec/security.js
+@@ -320,6 +320,10 @@
+ checkProtoPropertyAccess({ compat: true });
+   });
+ 
++  describe('in strict-mode', function() {
++checkProtoPropertyAccess({ strict: true });
++  });
++
+   function checkProtoPropertyAccess(compileOptions) {
+ it('should be prohibited by default and log a warning', function() {
+   var spy = sinon.spy(console, 'error');
+@@ -418,6 +422,28 @@
+   });
+ });
+   });
++
++  describe('escapes template variables', function() {
++it('in compat mode', function() {
++  expectTemplate("{{'a\\b'}}")
++.withCompileOptions({ compat: true })
++.withInput({ 'a\\b': 'c' })
++.toCompileTo('c');
++});
++
++it('in default mode', function() {
++  expectTemplate("{{'a\\b'}}")
++.withCompileOptions()
++.withInput({ 'a\\b': 'c' })
++.toCompileTo('c');
++});
++it('in default mode', function() {
++  expectTemplate("{{'a\\b'}}")
++.withCompileOptions({ strict: true })
++.withInput({ 'a\\b': 'c' })
++.toCompileTo('c');
++});
++  });
+ });
+ 
+ function wrapToAdjustContainer(precompiledTemplateFunction) {
diff --git a/debian/patches/series b/debian/patches/series
index 35bc292..d613930 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@ skip-some-modules.patch
 disable-bg-shell-plugin.patch
 use-babel7.patch
 use-global-object-this.patch
+CVE-2021-23369.patch


Bug#986519: nheko: FTBFS: internal compiler error

2021-04-16 Thread Andreas Beckmann

On 15/04/2021 01.47, Hubert Chathi wrote:

Upstream has a patch that should remove the affected code, so I think
that I will try to merge that in instead.  If that doesn't work, then I
will apply your patch.


Looks like a better solution than using g++-9.

You should apply the patch to 0.8.0-1 and upload it to sid now, to show 
that it is working. Makes it more likely to be accepted for tpu.


If this isn't accepted as tpu but needs to go through sid, please upload 
0.7.2-3 + your patch versioned as 0.8.0+really0.7.2-1 (or -4) to sid. 
Don't upload the latest upstream to sid now (iirc I've seen 0.8.1 in 
git), s.t. you can go back to "normal" versions immediately after the 
bullseye release.


Andreas

BTW: I couldn't 'debcheckout nheko' and build it from sid with gbp, some 
part of the sources is missing, didn't check the details.




Bug#987017: recommends 3 different ways to find obsolete packages, pick one

2021-04-16 Thread Justin B Rye
Antoine Beaupré wrote
>>> aptitude search '~o'
>>
>> This is nice and simple, but frankly as an aptitude user I wouldn't
>> bother.  Instead I'd do what the text just above mentions - launch
>> aptitude, notice that there was a category for "Obsolete and Locally
>> Created Packages" (which would tell me I'd somehow lost track of my
>> kernel packages), and purge everything in that category from the
>> full-screen interface, without going back to the commandline.
> 
> I think the point here is that you can do:
> 
> aptitude purge '~o'
> 
> ... to avoid loading the GUI.

I'd imagine it's to avoid having to deal with that interface - it's
much more powerful (and indeed faster) if you're used to it, but we
don't want novice users to need to guess it's "↓↓↓_gg"!
 
>>> aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
>>
>> This one (apparently an improvement on the '~i(!~ODebian)' search that
>> was recommended for buster, though the logic is too subtle for me to
>> remember) is looking for a slightly different thing at a different
>> stage in the upgrade process: it's part of the section about getting
>> rid of "non-Debian packages" *before* the upgrade.  The '~o' and
>> '!~ODebian' searches find different kinds of "unwanted" package.
> 
> Maybe it would be worth clarifying that distinction then?

I don't know how we make texts more separate than printing them
in two different places with explanatory paragraphs that talk
about different things!  But let me have a look.

# 4.2.2. Remove non-Debian packages
#
# Below there are two methods for finding installed packages that did
# not come from Debian, using either aptitude or apt-forktracer.
# Please note that neither of them are 100% accurate (e.g. the
# aptitude example will list packages that were once provided by
# Debian but no longer are, such as old kernel packages).

Now that you come to mention it I've always thought that was a bad
example, since after all it isn't exactly a false-positive - old
linux-images really are no-longer-Debian packages, and if you've got
some lying around even before the upgrade, this would be an
appropriate time to get rid of them, as we go on to say a little
later.  Wait, why *is* 4.2.2 before 4.2.3?  shouldn't it be
 * sort out the package database (pending actions or whatever)
 * make sure you're at the latest point release
 * remove any non-Debian packages
 * similarly but separately, remove any obsolete packages
 * tidy any relic configs
 [...]
Maybe this is turning into the sort of disruptive low-priority change
that should wait for next time.
 
> It might help if the former `~o` is expanded to `?obsolete` in the text,
> to make it clearer how it compares with the latter.

Unfortunately people also use "obsolete" to mean "autoremovable"!
And this also makes the search less simple and easier to confuse with
the one in 4.2...
 
[...]
>>> In my personal documentation, I've settled on `apt-forktracer`,
>>
>> I'd be interested to know what you find it useful for.
> 
> I like that it shows the related versions in the archive, and that it
> has very terse output.

Yes, but how do you come to be running a system with non-Debian
repositories in your sources and installing packages to inspect the
gory details without already realising you've done that?

Now that we've got "https://deb.debian.org/debian/;, we're close to
being able to say that standard procedure is "for the duration of the
upgrade, comment out any lines that don't match that URL".
 
>>  [---suture---]
>>> I actually forgot that bullseye itself introduces yet another one:
>>>
>>> apt list ~obsolete
>>
>> And indeed for section 4.8, which is dealing with tidying up *after*
>> the upgrade, it might make sense to recommend the use of apt instead
>> of aptitude here.
> 
> Yeah, and then we get rid of aptitude in the docs in bullseye +1 :)

Aptitude may no longer be recommended for dist-upgrades, but there are
still reasons to prefer it for day-to-day admin on stable systems.
For bullseye-to-bookworm we'll probably want to use apt recipes
wherever possible, with at most a mention that aptitude can also do
this from the fullscreen mode.  But since we also point at 4.8 from
4.2, we can't do that yet; we don't want the extra complication of
having to say "if you haven't upgraded yet then use aptitude".
 
> So, TL;DR: we should have this before, to find and cleanup foreign
> packages:
> 
> aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
> 
> Presumably `apt list` might support that as well in bullseye?

Afraid not - "E: Regex compilation error".
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



Bug#987013: Release goal proposal: Remove Berkeley DB

2021-04-16 Thread Martin Zobel-Helas
Hi,

On 15.04.21 18:12, Bastian Blank wrote:
> Package: release.debian.org
> Severity: wishlist
> 
> Hi
> 
> I would like to propose a release goal:
> 
> Remove Berkeley DB (finally)
> 
> Berkeley DB was relicensed to AGPLv3 almost eight years ago.  Since
> then, Debian stayed with the last version before the license change.
> The license change means, we can't take upstream patches, so security
> support is only provided by other distributions with in the same state.
> 
> After this time we really should try to get rid of this package, which
> even is NMU maintained since three years.
> 
> Affected source packages to remove:
> - db-defaults
> - db5.3

I second this proposal.

Best regards,
Martin

-- 
Martin Zobel-Helas
Technischer Leiter Betrieb
Tel.:   +49 2166 9901-0
Fax:+49 2166 9901-100
E-Mail: martin.zobel-he...@credativ.de
pgp fingerprint: 6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B
http://www.credativ.de

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Sascha Heuer

Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz



OpenPGP_signature
Description: OpenPGP digital signature


Bug#987040: gdm3: Sometimes system locks hard after entering password

2021-04-16 Thread Florian
Package: gdm3
Version: 3.38.2.1-1
Severity: important

This has happened now two times within a week or so (never happened before) on 
an up-to-date debian testing
system.

* Waking up from suspend
* Entering password on login-screen and press enter
* System freezes completely (can't change to terminal, no mouse pointer 
reaction, etc)
* Only reboot helps, loosing work in suspended session

Maybe it is related to entering the wrong PW the first time, and after
entering the correct one it freezes (but I am not 100% certain whether
that was also the case last time it happened).

There is (to my eyes) nothing suspicious in the syslog before the
crash (a lot of annoying tracker messages flooding the log, but that
seems to be "normal").

Unfortunately/fortunately I have not yet found a way to reliably
reproduce it.

Thanks, Florian


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

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.55-3
ii  adduser   3.118
ii  dbus  1.12.20-2
ii  dconf-cli 0.38.0-2
ii  dconf-gsettings-backend   0.38.0-2
ii  debconf [debconf-2.0] 1.5.75
ii  gir1.2-gdm-1.03.38.2.1-1
ii  gnome-session [x-session-manager] 3.38.0-4
ii  gnome-session-bin 3.38.0-4
ii  gnome-session-common  3.38.0-4
ii  gnome-settings-daemon 3.38.1-3
ii  gnome-shell   3.38.4-1
ii  gnome-terminal [x-terminal-emulator]  3.38.3-1
ii  gsettings-desktop-schemas 3.38.0-2
ii  libaccountsservice0   0.6.55-3
ii  libaudit1 1:3.0-2
ii  libc6 2.31-11
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libgdm1   3.38.2.1-1
ii  libglib2.0-0  2.66.8-1
ii  libglib2.0-bin2.66.8-1
ii  libgtk-3-03.24.24-3
ii  libkeyutils1  1.6.1-2
ii  libpam-modules1.4.0-7
ii  libpam-runtime1.4.0-7
ii  libpam-systemd247.3-3
ii  libpam0g  1.4.0-7
ii  librsvg2-common   2.50.3+dfsg-1
ii  libselinux1   3.1-3
ii  libsystemd0   247.3-3
ii  libx11-6  2:1.7.0-2
ii  libxau6   1:1.0.9-1
ii  libxcb1   1.14-3
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  11.1.0
ii  mutter [x-window-manager] 3.38.4-1
ii  policykit-1   0.105-30
ii  procps2:3.3.17-4
ii  ucf   3.0043
ii  x11-common1:7.7+22
ii  x11-xserver-utils 7.7+8

Versions of packages gdm3 recommends:
ii  at-spi2-core2.38.0-2
ii  desktop-base11.0.3
ii  x11-xkb-utils   7.7+5
ii  xserver-xephyr  2:1.20.10-3
ii  xserver-xorg1:7.7+22
ii  zenity  3.32.0-6

Versions of packages gdm3 suggests:
pn  gnome-orca
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.36.0-1

-- debconf information:
* shared/default-x-display-manager: gdm3
  gdm3/daemon_name: /usr/sbin/gdm3



  1   2   >