Bug#983843: xrdp FTBFS on several architectures

[Adrian Bunk]

Source: xrdp
Version: 0.9.15-1
Severity: serious
Tags: patch ftbfs

https://buildd.debian.org/status/package.php?p=xrdp&suite=sid

...
In file included from string_calls.h:24,
 from base64.c:25:
arch.h:91:2: error: #warning unknown arch [-Werror=cpp]
   91 | #warning unknown arch
  |  ^~~


Fixed with the attached patch to set NEED_ALIGN
on unknown architectures.
Description: Default to NEED_ALIGN for unknown archs
Author: Adrian Bunk 

--- xrdp-0.9.15.orig/common/arch.h
+++ xrdp-0.9.15/common/arch.h
@@ -88,7 +88,7 @@ typedef int bool_t;
   defined(__riscv)
 #define NO_NEED_ALIGN
 #else
-#warning unknown arch
+#define NEED_ALIGN
 #endif
 #endif
 

Bug#909804: Excessive CPU usage at system startup

[Philip Hands]

Source: gnome-software
Followup-For: Bug #909804

Hi,

I am seeing what looks like this behaviour on a X230 with 4G RAM, most often on
resuming from suspend (I presume because the update job gets delayed while the
system is suspended and gets kicked of by systemd at resume).

Said machine is currently sitting next to me on the desk, completely
unresponsive (imobile mouse, apparently unable to negotiate WPA) and I'm leaving
it to see if it manages to got over the problem or just needs a power-cycle. The
disk activity LED is on solid. It was responding to pings over WiFi for a while,
but no longer.

My suspicion is that this occurs if one has a reasonable amount of swap already
in use when suspending. IIRC both Firefox and DrRacket were running on this
machine when it was suspended, which between them eat all the RAM.

If you can tell me how to provoke gnome-software into attempting an update in 10
minutes time, say, such that it will try it on resume if I wait till after that
time, then I'll be able to do that, suspend the machine, and perhaps be able to
provide you with a recipe for reporoducing the issue.

BTW I suspected it was gnome-software (or something in it's circle) that was
causing this when I noticed it about a year ago, so deinstalled that and IIRC
packagekit, and the problem went away -- it seems that I installed/upgraded
something recently that pulled them back in, and the problem is back. When the
machine is behaing itself I can probably give you versions and dates (they ought
to be recorded in etckeeper)

Cheers, Phil.

Bug#983365: Info received (Bug#983365: linphone-desktop: chat messages)

[Bernhard Schmidt]

Hi David,

Am 01.03.21 um 20:24 schrieb David Pirotte:

> Thanks all for having worked on this. Sorry for the little delay in
> answering, I actually thought the packages would 'find their way' to
> bullseye, so I was (and still am) updating daily, a few times per day
> actually, but now I see you said sid, not bullseye ...
> 
>> an updated liblinphone has been uploaded to sid yesterday. Could you
>> please try liblinphone10 and liblinphone++10 from sid (4.4.21-2) and
>> report back? If it does not work you might need libsoci-core4.0 and
>> libsoci-sqlite3-4.0 from unstable as well (4.0.1-4).
> 
> I am using bullseye (n idea why reportbug says bullseye/sid), so I
> don't have the right config to pick those 2 from sid, and so many years
> I haven't done this that I forgot my 'apt/preferencesfu' to do that -
> but by all means, the bug is in bullseye, won't you make these packages
> available in bullseye?

There is a ten day migration period from sid to bullseye. If no
regression shows up th new linphone version should migrate to bullseye
about March 9th. I hope it doesn't get delayed, because on 10th the
freeze starts for real.

The easiest way to just install one or two packages from sid would
probably be

- duplicate bullseye line in /etc/apt/sources.list and replace bullseye
with sid
- apt update
- apt install liblinphone10 liblinphone++10
- disable new line from /etc/apt/sources.list
- apt update

Bernhard

Bug#983653: task-japanese-gnome-desktop: no Japanese input method available out of the box

[Nobuhiro Iwamatsu]

Hi all,

2021年3月1日(月) 20:32 YOSHINO Yoshihito :
>
> Hi,
>
> On Mon, Mar 1, 2021 at 7:51 PM Holger Wansing  wrote:
> > May I ask how that interacts with the uim framework?
> >
> > We currently have
> >
> > Recommends:
> > [...]
> > uim,
> > uim-mozc | uim-anthy,
> >
> > in task-japanese-desktop, so if you now add ibus-mozc | ibus-anthy to
> > task-japanese-gnome-desktop, we will have both, uim-mozc and ibus-mozc 
> > installed
> > on a Gnome system.
>
> Yes.
>
> > Is that ok? Or does that cause any harm/conflict/what ever?
>
> This is ok. "im-config" package deals with such an IM framework selection.
> When ibus and uim are both installed, ibus is preferred and used by default.
> (The selection can be changed by user choice.)
> Then no input method in ibus framework is currently installed,
> so its user cannot type Japanese text out of the box.

+1.
As Yoshihito commented, this doesn't cause the problem you considered.

Best regards,
  Nobuhiro
-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#983844: RM: r-cran-sf [s390x] -- ROM; Lacking dependency on s390x

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 983...@bugs.debian.org

Hi,

to fix bug #983749 I have removed s390x from the list of available
architectures.  Please remove the package for this architecture from
the package pool.

Kind regards and thanks for your work as ftpmaster

  Andreas.

Bug#983827: python3-lmfit: copyright file missing (policy 12.5)

[Andreas Beckmann]

Followup-For: Bug #983827
Control: reassign -1 python-lmfit-doc,python3-lmfit 1.0.1-3

Same problem in python-lmfit-doc

0m17.1s ERROR: WARN: Inadequate results from running adequate!
  python-lmfit-doc: missing-copyright-file 
/usr/share/doc/python-lmfit-doc/copyright


Andreas

Bug#982567: openms build-depends on removed package

[Filippo Rusconi]

Greetings, Adrian,

On Mon, Mar 01, 2021 at 02:32:03AM +0200, Adrian Bunk wrote:

On Sat, Feb 20, 2021 at 05:03:45PM +0100, Filippo Rusconi wrote:

Greetings, Andreas and Michael,

I hope you are doing fine.

On Fri, Feb 19, 2021 at 10:19:11PM +0100, Andreas Tille wrote:
> Hi Filippo,
>
> this is extremely unfortunate.  However, I guess the alternative would
> have been to keep some RC buggy seqan-dev which would not have helped
> openms as well.  I tried the same as Peter and replaced the
> Build-Depends seqan-dev by libseqan2-dev.
>
> I can confirm the observation from Peter about the missing header file.
> I simply tried to comment those missing headers (next one is also
> missing):
>
>
> // #include 
> // #include 
[...]

Thank you for your trials and explanations. I am no on vacation, which means
I'll finally find some time to try understand the implications of that SeqAn
upgrade.

I'll keep you posted with my findings.


The brute force approach works for me:
1. install seqan-dev from buster (for step 2)
2. cp -a /usr/include/seqan debian/
3. in debian/control remove the seqan-dev build dependency
4. in debian/rules pass -DSEQAN_INCLUDE_DIR=$(DEBIAN_DIR)
  to dh_auto_configure


I first tried to check if putting some header files in the local source tree
would do. But no, in fact the file handling-related headers pull down almost all
the seqan headers, so this strategy did not work out, leading me to envision
exactly what you tried.  I now wonder where to put the seqan headers when we
install the -dev stuff, so that people working with OpenMS do find them. I
thought creating a seqan subdirectory to the /usr/include/OpenMS directory and
point the compiler to that location by providing -I/usr/include/OpenMS.

But then, how do we inform the users about the unconventional location of the
header files? Do they actually need that location ?

Any idea ?


cu Adrian


Cheers,
Filippo

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org

Bug#932456: Possible Patch

[Reto Buerki]

On 3/1/21 4:04 PM, Fabian Zaremba wrote:
>> Could you provide a binary package for Buster containing this patch? I
>> would like to test this.
> 
> I published a package with this patch to the public Open Build Service
> instance hosted by openSUSE.
> 
> https://build.opensuse.org/package/show/home:fabian-z:libvirt-kt/libvirt
> 
> https://download.opensuse.org/repositories/home:/fabian-z:/libvirt-kt/Debian_10/
> 
> The patched version is 5.0.0-4+deb10u1kt1.

Great thanks!

I can confirm that active blockcommits now work (test procedure: [1]).

Note that I can not assess the security implications of the patch.

It would be great if this could be integrated.

Cheers
- reto

[1] - https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit

Bug#983846: nmu: gnudatalanguage_1.0.0~rc.3-1

[Andreas Beckmann]

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

nmu gnudatalanguage_1.0.0~rc.3-1 . ANY . experimental . -m "Rebuild against 
Python 3.9"

gnudatalanguage/experimental is still linked against Python 3.8.

Andreas

Bug#983847: querybts -m does not escape "\nFrom " sequences; breaks mutt

[Trent W. Buck]

Package: reportbug
Version: 7.10.2
Severity: normal
File: /usr/bin/querybts

These commands are bugged:

bts show -m 928175
querybts -m 928175 >tmp.mbox && mutt -f tmp.mbox

This is because an email in that mailbox containes a byte sequence "\nFrom ".
This sequence is used by mbox to delimit messages, and must be escaped.

(Typically this is done by changing "\nFrom " to "\n>From ", though
IIUC this will break DKIM validation.)

This might need to be fixed on the server side (i.e. in debbugs).
If so, please reassign as appropriate.


-- Package-specific info:
** Environment settings:
EDITOR="twb-emacsclient"
PAGER="twb-pager"
VISUAL="twb-emacsclient"
EMAIL="trentb...@gmail.com"
INTERFACE="text"

** /home/twb/.reportbugrc:
reportbug_version "3.35"
mode expert
ui text
bts debian

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 reportbug depends on:
ii  apt2.2.0
ii  python33.9.1-1
ii  python3-reportbug  7.10.2
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
ii  debconf-utils 1.5.74
ii  debsums   3.0.2
ii  dlocate   1.07+nmu1
ii  emacs-bin-common  1:27.1+1-3
ii  file  1:5.39-3
ii  gnupg 2.2.27-1
ii  msmtp-mta [mail-transport-agent]  1.8.11-2
pn  python3-urwid 
pn  reportbug-gtk 
ii  xdg-utils 1.1.3-4

Versions of packages python3-reportbug depends on:
ii  apt2.2.0
ii  file   1:5.39-3
ii  python33.9.1-1
ii  python3-apt2.1.7
ii  python3-debian 0.1.39
ii  python3-debianbts  3.1.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- debconf-show failed

Bug#983848: Translations are not compiled

[Yohann D'ANELLO]

Package: mailman3-web
Version: 0+20200530-1
Severity: minor
Tags: l10n a11y
X-Debbugs-Cc: r...@crans.org

When installing the mailman3-web package that includes
python3-django-postorius and python3-django-hyperkitty,
translation files are not compiled for the two packages.
gettext should be a build dependency of the two packages, and
`django-admin compilemessages` should be executed during package
building. By that way, compiled translations will exist under
/usr/lib/python3/dist-packages/{postorius,hyperkitty}/locale/{locale}/LC_MESSAGES/django.mo.


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

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

Versions of packages mailman3-web depends on:
ii  dbconfig-sqlite3   2.0.18
ii  debconf [debconf-2.0]  1.5.74
ii  init-system-helpers1.60
ii  lsb-base   11.1.0
ii  python33.9.1-1
ii  python3-django-hyperkitty  1.3.4-1
ii  python3-django-postorius   1.3.4-1
ii  python3-psycopg2   2.8.6-2
ii  python3-whoosh 2.7.4+git6-g9134ad92-5
ii  ucf3.0043
ii  uwsgi  2.0.19.1-6
ii  uwsgi-plugin-python3   2.0.19.1-6

Versions of packages mailman3-web recommends:
ii  nginx   1.18.0-6
ii  nginx-core [nginx]  1.18.0-6+b1

Versions of packages mailman3-web suggests:
pn  postgresql | default-mysql-server | virtual-mysql-server  

-- debconf information:
  mailman3-web/db/basepath: /var/lib/mailman3/web
  mailman3-web/nginx-choice:
  mailman3-web/internal/skip-preseed: false
  mailman3-web/upgrade-backup: true
  mailman3-web/superuser-name: admin
  mailman3-web/database-type: sqlite3
  mailman3-web/upgrade-error: abort
  mailman3-web/passwords-do-not-match:
  mailman3-web/purge: false
  mailman3-web/install-error: abort
  mailman3-web/restart-webserver: true
  mailman3-web/superuser-mail: root@localhost
  mailman3-web/dbconfig-remove: true
  mailman3-web/configure-webserver: none
  mailman3-web/remove-error: abort
  mailman3-web/missing-db-package-error: abort
  mailman3-web/internal/reconfiguring: false
  mailman3-web/emailname: localhost.local
  mailman3-web/dbconfig-install: true
  mailman3-web/dbconfig-reinstall: false
  mailman3-web/db/dbname: mailman3web.db
  mailman3-web/dbconfig-upgrade: true

Bug#983835: base-installer: hostname= is ignored if reverse-dns exists

[Cyril Brulebois]

Hello Phil,

Phil Dibowitz  (2021-03-01):
> When doing a network-install of a system, if one passes `hostname=foo`
> on the kernel commandline, the installer will use that to set the
> hostname of the installed system...
> 
> EXCEPT if there's reverse-DNS for the IP address that we happen to have
> gotten from DHCP, in which case that takes precedence. But it shouldn't,
> we very explicitly are requesting a hostname to set.
> 
> This situation happens in environments with dynamic dns where a client
> may have released an IP, the DHCP gave it out to this new client, but
> there's still a DNS cache with the old mapping.
> 
> The installer should prefer the explicit preference set by the
> adminsitrator over the implicit one. Or, at the very least provide a
> configuration option to enable such a behavior.

In src:netcfg's templates[1]:

Template: netcfg/get_hostname
Type: string
Default: debian
# :sl1:
_Description: Hostname:
 Please enter the hostname for this system.
 .
 The hostname is a single word that identifies your system to the network.
 If you don't know what your hostname should be, consult your network
 administrator. If you are setting up your own home network, you can make
 something up here.

Template: netcfg/hostname
Type: string
Description: for internal use; can be preseeded
 Hostname to set for the system; ignores names provided by DHCP or DNS.

 1. 
https://salsa.debian.org/installer-team/netcfg/-/blob/master/debian/netcfg-common.templates

The preseed doc[2] suggests the former is behind the (bare) hostname
alias. Try setting the latter?

 2. 
https://www.debian.org/releases/bullseye/amd64/apbs02.en.html#preseed-aliases


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


signature.asc
Description: PGP signature

Bug#983849: Executable mailman-web does not exist

[Yohann D'ANELLO]

Package: mailman3-web
Version: 0+20200530-1
Severity: minor
Tags: a11y
X-Debbugs-Cc: r...@crans.org

The documentation of mailman3-web indicates that we can manage Django
with the mailman-web command. However, this command is not provided by
the mailman3-web package.
Maybe you can add a symlink from /usr/bin/mailman-web to
/usr/share/mailman3-web/manage.py.


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

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

Versions of packages mailman3-web depends on:
ii  dbconfig-sqlite3   2.0.18
ii  debconf [debconf-2.0]  1.5.74
ii  init-system-helpers1.60
ii  lsb-base   11.1.0
ii  python33.9.1-1
ii  python3-django-hyperkitty  1.3.4-1
ii  python3-django-postorius   1.3.4-1
ii  python3-psycopg2   2.8.6-2
ii  python3-whoosh 2.7.4+git6-g9134ad92-5
ii  ucf3.0043
ii  uwsgi  2.0.19.1-6
ii  uwsgi-plugin-python3   2.0.19.1-6

Versions of packages mailman3-web recommends:
ii  nginx   1.18.0-6
ii  nginx-core [nginx]  1.18.0-6+b1

Versions of packages mailman3-web suggests:
pn  postgresql | default-mysql-server | virtual-mysql-server  

-- debconf information:
  mailman3-web/remove-error: abort
  mailman3-web/upgrade-error: abort
  mailman3-web/configure-webserver: none
  mailman3-web/dbconfig-upgrade: true
  mailman3-web/install-error: abort
  mailman3-web/dbconfig-remove: true
  mailman3-web/db/basepath: /var/lib/mailman3/web
  mailman3-web/superuser-name: admin
  mailman3-web/dbconfig-reinstall: false
  mailman3-web/db/dbname: mailman3web.db
  mailman3-web/purge: false
  mailman3-web/database-type: sqlite3
  mailman3-web/nginx-choice:
  mailman3-web/internal/skip-preseed: false
  mailman3-web/emailname: localhost.local
  mailman3-web/superuser-mail: root@localhost
  mailman3-web/dbconfig-install: true
  mailman3-web/passwords-do-not-match:
  mailman3-web/internal/reconfiguring: false
  mailman3-web/upgrade-backup: true
  mailman3-web/restart-webserver: true
  mailman3-web/missing-db-package-error: abort

Bug#983850: nmu: gr-hpsdr_2.0-1

[Andreas Beckmann]

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

nmu gr-hpsdr_2.0-1 . ANY . experimental . -m "Rebuild against Python 3.9"

gr-hpsdr/experimental is still linked against Python 3.8

That seems to be the last rebuildable outdated python3 dependency in
experimental ;-)


Andreas

Bug#983851: meld: Python error on svn checkout

[alberto]

Package: meld
Version: 3.20.2-2
Severity: normal

Dear Maintainer,

when I excute "meld ." on a svn branch, meld it is not able anymore to show
the differences between checkout and local modfications.

It just display the local foldr name as if it can't find anything to compare
with.

Executing in terminal gives the following traceback:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/meld/task.py", line 110, in iteration
ret = task()
  File "/usr/lib/python3/dist-packages/meld/vc/_vc.py", line 277, in 
refresh_vc_state
self._update_tree_state_cache(path)
  File "/usr/lib/python3/dist-packages/meld/vc/svn.py", line 188, in 
_update_tree_state_cache
for entry in (t for t in target.getchildren() if t.tag == "entry"):
AttributeError: 'xml.etree.ElementTree.Element' object has no attribute 
'getchildren'


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

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

Versions of packages meld depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-gtksource-3.0 3.24.11-2
ii  libcanberra-gtk3-module  0.30-7
ii  libgtk-3-0   3.24.24-3
ii  libgtksourceview-3.0-1   3.24.11-2
ii  patch2.7.6-7
ii  python3  3.9.1-1
ii  python3-cairo1.16.2-4+b2
ii  python3-gi   3.38.0-2
ii  python3-gi-cairo 3.38.0-2

Versions of packages meld recommends:
ii  yelp  3.38.3-1

meld suggests no packages.

-- no debconf information

Bug#983379: linux uml segfault

[Ritesh Raj Sarraf]

On Wed, 2021-02-24 at 11:44 +, Anton Ivanov wrote:
> In all cases it boots cleanly and there are no segfaults.
> 
> So, frankly, no idea what is causing it to crash - I have run most
> combinations of 5.10 on a 5.10, all work fine here.

Is there any other way I can help you with this issue ?
I do have the core dump available on my local machine.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#983852: python-scrapy: please make the build reproducible

[Chris Lamb]

Source: python-scrapy
Version: 2.4.1-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

This is because it uses the current build year when building the
documentation which, of course, changes depending which year you
build the software.

Patch attached that uses SOURCE_DATE_EPOCH [1] instead.

 [0] https://reproducible-builds.org/
 [1] https://reproducible-builds.org/specs/source-date-epoch/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/2-Reproducible-build.patch 1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/2-Reproducible-build.patch 2021-03-02 
09:06:06.826207329 +
@@ -0,0 +1,28 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2021-03-02
+
+--- python-scrapy-2.4.1.orig/docs/conf.py
 python-scrapy-2.4.1/docs/conf.py
+@@ -9,7 +9,9 @@
+ # All configuration values have a default; values that are commented out
+ # serve to show the default.
+ 
++import os
+ import sys
++import time
+ from datetime import datetime
+ from os import path
+ 
+@@ -49,7 +51,10 @@ master_doc = 'index'
+ 
+ # General information about the project.
+ project = 'Scrapy'
+-copyright = f'2008\u2013{datetime.now().year}, Scrapy developers'
++build_date = datetime.utcfromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
++)
++copyright = f'2008\u2013{build_date.year}, Scrapy developers'
+ 
+ # The version info for the project you're documenting, acts as replacement for
+ # |version| and |release|, also used in various other places throughout the
--- a/debian/patches/2-Reproducible-build.patch~1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/2-Reproducible-build.patch~2021-03-02 
09:05:49.602003318 +
@@ -0,0 +1,28 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2021-03-02
+
+--- python-scrapy-2.4.1.orig/docs/conf.py
 python-scrapy-2.4.1/docs/conf.py
+@@ -9,7 +9,9 @@
+ # All configuration values have a default; values that are commented out
+ # serve to show the default.
+ 
++import os
+ import sys
++import time
+ from datetime import datetime
+ from os import path
+ 
+@@ -49,7 +51,10 @@ master_doc = 'index'
+ 
+ # General information about the project.
+ project = 'Scrapy'
+-copyright = f'2008\u2013{datetime.now().year}, Scrapy developers'
++year = datetime.utcfromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
++).year
++copyright = f'2008\u2013{year}, Scrapy developers'
+ 
+ # The version info for the project you're documenting, acts as replacement for
+ # |version| and |release|, also used in various other places throughout the
--- a/debian/patches/series 2021-03-02 08:55:59.355009205 +
--- b/debian/patches/series 2021-03-02 09:05:31.529789277 +
@@ -1 +1,2 @@
 0001-Disable-hoverxref-and-notfound-Sphinx-extensions.patch
+2-Reproducible-build.patch
--- a/docs/conf.py  2021-03-02 08:55:59.355009205 +
--- b/docs/conf.py  2021-03-02 09:06:05.762194727 +
@@ -9,7 +9,9 @@
 # All configuration values have a default; values that are commented out
 # serve to show the default.
 
+import os
 import sys
+import time
 from datetime import datetime
 from os import path
 
@@ -49,7 +51,10 @@
 
 # General information about the project.
 project = 'Scrapy'
-copyright = f'2008\u2013{datetime.now().year}, Scrapy developers'
+build_date = datetime.utcfromtimestamp(
+int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
+)
+copyright = f'2008\u2013{build_date.year}, Scrapy developers'
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the

Bug#983854: ubuntu-dev-tools: Making SourcePackage abstract class botched backportpackage

[Ondřej Surý]

Package: ubuntu-dev-tools
Version: 0.180
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

commit ee9b8756d9e81003ad199f24a15f69201009bbe7 in upstream package
(included in 0.179) botched the ability to run backportpackage on the
dsc files:

$ /usr/bin/backportpackage -b -w tmp php-grpc_1.35.0+1.33.1-2.dsc # just a 
random package
Traceback (most recent call last):
  File "/usr/bin/backportpackage", line 424, in 
sys.exit(main(sys.argv))
  File "/usr/bin/backportpackage", line 394, in main
pkg = find_package(opts.mirror,
  File "/usr/bin/backportpackage", line 204, in find_package
return SourcePackage(version=version, dscfile=package,
TypeError: Can't instantiate abstract class SourcePackage with abstract 
method distribution

I think this is actually a RC bug because it makes backportpackage
pretty much unusable, but I am letting you decided that.

Cheers,
Ondrej

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

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

Versions of packages ubuntu-dev-tools depends on:
ii  binutils2.36-2
ii  dctrl-tools 2.24-3+b1
ii  devscripts  2.21.1
ii  diffstat1.64-1
ii  distro-info 1.0
ii  dpkg-dev1.20.7.1
ii  dput-ng [dput]  1.32
ii  lsb-release 11.1.0
ii  perl5.32.1-2
ii  python3 3.9.1-1
ii  python3-apt 2.1.7
ii  python3-debian  0.1.39
ii  python3-debianbts   3.1.0
ii  python3-distro-info 1.0
ii  python3-httplib20.18.1-3
ii  python3-launchpadlib1.10.13-1
ii  python3-lazr.restfulclient  0.14.2-2
ii  python3-ubuntutools 0.180
ii  sensible-utils  0.0.14
ii  sudo1.9.5p2-2
ii  tzdata  2021a-1

Versions of packages ubuntu-dev-tools recommends:
pn  arch-test
pn  bzr | brz
pn  bzr-builddeb | brz-debian
ii  ca-certificates  20210119
ii  cowbuilder   0.89
ii  debian-archive-keyring   2019.1
ii  debian-keyring   2020.12.24
ii  debootstrap  1.0.123
pn  genisoimage  
ii  lintian  2.104.0
ii  patch2.7.6-7
ii  pbuilder 0.231
pn  python3-dns  
ii  quilt0.66-2.1
ii  reportbug7.10.2
ii  sbuild   0.81.2
ii  ubuntu-keyring [ubuntu-archive-keyring]  2018.09.18.1-5

Versions of packages ubuntu-dev-tools suggests:
ii  qemu-user-static  1:5.2+dfsg-6

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmA+A6tfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcI5FRAAhgermZ2PciOMzJhp3Q+CYFGo2RQe7sJgyrEr6AsBFRH+Fu5xjvud6Y4c
KWLzYepu52JCjRPFKC9NTo6cMoAbjOHeX+gTepgoHHbfkMfbU66RKZYjp6OAABF5
wGWdQVDSA8myCxTADgu92QgkO+FP81bZbDlOZqQ4s2iLsqlYE4JAYlXBgoHHggmh
3XTvDWdxG6x2OhkEJaOyg7FGtXX87ijdGrjCRtzI2eHkdQKcBBKgOQDsQn/8GX/Y
j/wNvu38d2iE+R+ykTgCAfxqAGti3vvOTbKbPbwljVooXuYwggKy+Dpcztz4Z6x/
DLYrbmyT5LJTHSBeWc4J7IbETZqBGttU4SK2hwVOGD3WNt7ZKttbz2A4OfNcImEy
dwxgFaZMFAabb+Cyyw0lOIjCa192HI5brpS7gDl0tV38cnYyxaAsOpcf50ql/aVf
xBhlcNjhdyarJ/dApbwfZxw6R4D/fRLWmhJcGLzl0cbDdVNyXYuvIZQUkMQculgm
q9gGtA2hEFLoHThVfxTP9xQW+ficbvVJiAurchKozzL9UzCVg8GmEwaGIWtOuCtm
hV0VkHsZZBG3ypSQznkKedu7zQ8ZLVhx2rMr4h66yUHOeaJ966DWi6+nHL3ESvNM
Nmz13wLyV58bGhzowRA9gtigEoPA/STEEmTBHvoRjCDt0QTtEBU=
=sJI+
-END PGP SIGNATURE-

Bug#983855: golang-github-coreos-bbolt-dev: fails to upgrade from 'buster': unable to install new version of '/usr/share/gocode/src/go.etcd.io/bbolt/allocate_test.go': No such file or directory

[Andreas Beckmann]

Package: golang-github-coreos-bbolt-dev
Version: 1.3.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../golang-github-coreos-bbolt-dev_1.3.5-1_all.deb ...
  Unpacking golang-github-coreos-bbolt-dev (1.3.5-1) over (1.3.1-coreos.5-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/golang-github-coreos-bbolt-dev_1.3.5-1_all.deb 
(--unpack):
   unable to install new version of 
'/usr/share/gocode/src/go.etcd.io/bbolt/allocate_test.go': No such file or 
directory
  Preparing to unpack .../libss2_1.46.1-1_amd64.deb ...
  Unpacking libss2:amd64 (1.46.1-1) over (1.44.5-1+deb10u3) ...
  Errors were encountered while processing:
   /var/cache/apt/archives/golang-github-coreos-bbolt-dev_1.3.5-1_all.deb

/usr/share/gocode/src/go.etcd.io/bbolt is a symlink and possibly
dangling at the time the error happens:

lrwxrwxrwx 1 root root 26 Jan 20  2019 /usr/share/gocode/src/go.etcd.io/bbolt 
-> ../github.com/coreos/bbolt

Maybe some symlink_to_dir migration is missing?

cheers,

Andreas


golang-github-coreos-bbolt-dev_1.3.5-1.log.gz
Description: application/gzip

Bug#983856: prometheus-smokeping-prober: [INTL:fr] French debconf templates translation

[Jean-Pierre Giraud]

Package: prometheus-smokeping-prober
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french debconf templates translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me and the Debian
Internationalization  so I can update the French translation.

Kind Regards

Jean-Pierre Giraud


fr.po.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#827956: grub: Doesn't apply default entry from /etc/default/grub

[Diederik de Haas]

Package: grub-pc
Version: 2.04-15
Followup-For: Bug #827956

I have a 'server' with no keyboard or monitor attached. I want to
boot into a 5.9 kernel instead of a 5.10 kernel to see whether there's a
NFS problem with 5.10.
But regardless what I specify as GRUB_DEFAULT in /etc/default/grub, it
always boots the top entry.

I've tried the following things:
- Use the value following "$menuentry_id_option"
- Placed single quotes around previous value
- Placed double quotes around previous value
- Replace "$menuentry_id_option" with "--id" in case it was incorrectly
  not expanded/replaced in the grub entries
- Use a numerical value

None of which resulted in grub booting anything other then the top
entry.
If this can't be fixed, can then at least the documentation be updated
to say that grub only works interactively?


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda2 / btrfs rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 0 0
/dev/sda1 /boot ext4 rw,relatime 0 0
/dev/sdb1 /srv/media btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set 
default="gnulinux-5.9.0-5-amd64-advanced-2f82ed85-9840-4338-a5b2-71c735333ed9"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod btrfs
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 
--hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2  
2f82ed85-9840-4338-a5b2-71c735333ed9
else
  search --no-floppy --fs-uuid --set=root 2f82ed85-9840-4338-a5b2-71c735333ed9
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-2f82ed85-9840-4338-a5b2-71c735333ed9' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  
19f1e309-4c00-46c2-a832-30fe4ac85b47
else
  search --no-floppy --fs-uuid --set=root 
19f1e309-4c00-46c2-a832-30fe4ac85b47
fi
echo'Loading Linux 5.10.0-3-amd64 ...'
linux   /vmlinuz-5.10.0-3-amd64 
root=UUID=2f82ed85-9840-4338-a5b2-71c735333ed9 ro  quiet
echo'Loading initial ramdisk ...'
initrd  /initrd.img-5.10.0-3-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-2f82ed85-9840-4338-a5b2-71c735333ed9' {
menuentry 'Debian GNU/Linux, with Linux 5.10.0-3-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-5.10.0-3-amd64-advanced-2f82ed85-9840-4338-a5b2-71c735333ed9' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_msdos
insmod ext2
 

Bug#982924: what-is-python: The python-is-python3 and python-dev-is-python3 packages should not exist

[Matthias Klose]

On 2/16/21 5:34 PM, Zack Weinberg wrote:
> Unpackaged Python-2-only software
> will continue to exist indefinitely—I am *certain* that I will still
> need a Python 2 interpreter ten years from now, and I fully expect my
> grandchildren will occasionally trip over Python-2-only software even
> a hundred years from now.

Please also consider the burden on other grandparents having to explain their
grandchildren that they have to type "python3" on Debian, when anybody else
running Python on a different platform or running Python on other Linux
distributions is used to type "python" ;)

I don't think there's a good solution for everybody.  I still think it's better
to provide an explicit choice in a package, instead of following instructions
from the web to manage the "python" symlink using update-alternatives.

I'm going to propose an addition to the Debian Python Policy on the
debian-python ML:

+Removal of the unversioned packages
+---
+
+Starting with the Debian 11 release (bullseye), the binary packages
+``python``, ``python-minimal``, ``python-dev``, ``python-dbg`` and
+``python-doc`` are removed.  No package in the archive must use any of
+these packages as build dependencies, dependencies, recommendations or
+suggestions.
+
+
+Unversioned python commands
+---
+
+For the Debian 11 release (bullseye), the :file:`/usr/bin/python`
+command is provided in the ``python-is-python2`` package (pointing to
+:file:`/usr/bin/python2`).  The :file:`/usr/bin/python-config` and
+:file:`/usr/bin/pydoc` commands are provided in the
+``python-dev-is-python2`` package.  These package are not installed by
+default for new installations, but only for upgrades from the Debian
+10 release (buster).  These packages should be removed after an
+upgrade.  These packages will not be part of the Debian 12 release
+(bookworm).
+
+The packages ``python-is-python3`` and ``python-dev-is-python3``
+provide the :file:`/usr/bin/python`, :file:`/usr/bin/python-config`
+and :file:`/usr/bin/pydoc` commands pointing to Python3.  These
+packages can be installed by developers and users to use the
+unversioned commands.  NOTE: Locally installed software not yet ported
+to Python3 is likely to break when installing these packages.
+
+The packages ``python-is-python3``, ``python-dev-is-python3``,
+``python-is-python2`` and ``python-dev-is-python2`` must not be used
+as build dependencies, dependencies, recommendations or suggestions.

I hope this makes it clear that installing python-is-python3 can cause problems,
and that it's an opt-in installation option, which is not enforced by any other
package dependencies.

Matthias

Bug#982567: openms build-depends on removed package

[Andreas Tille]

On Tue, Mar 02, 2021 at 09:16:46AM +0100, Filippo Rusconi wrote:
> > The brute force approach works for me:
> > 1. install seqan-dev from buster (for step 2)
> > 2. cp -a /usr/include/seqan debian/
> > 3. in debian/control remove the seqan-dev build dependency
> > 4. in debian/rules pass -DSEQAN_INCLUDE_DIR=$(DEBIAN_DIR)
> >   to dh_auto_configure
> 
> I first tried to check if putting some header files in the local source tree
> would do. But no, in fact the file handling-related headers pull down almost 
> all
> the seqan headers, so this strategy did not work out, leading me to envision
> exactly what you tried.

Sorry, I'm reading your mail a bit late ...

> I now wonder where to put the seqan headers when we
> install the -dev stuff, so that people working with OpenMS do find them. I
> thought creating a seqan subdirectory to the /usr/include/OpenMS directory and
> point the compiler to that location by providing -I/usr/include/OpenMS.
> 
> But then, how do we inform the users about the unconventional location of the
> header files? Do they actually need that location ?
> 
> Any idea ?

I took the freedom to strip down the headers to those that are really
needed to build the package.  Well, its 8MB extra load - but for this
package its "only about 1%".  Not nice definitely, but given the fact
that we probably will not have the time for a better solution I simply
uploaded to meet the freeze deadline.

The extra files are documented in debian/README.source and I hope for
Debian 11 we will find a better solution.

Hope this helps solving the hassle we created by removing seqan-dev
package.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#983857: nmu: uhd_4.0.0.0-4

[Andreas Beckmann]

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

nmu uhd_4.0.0.0-4 . ANY . experimental . -m "Rebuild against dpdk 20.11"

uhd/experimental still depends on dpdk 19.11 libraries.

Andreas

Bug#982924: The python command in Debian

[Matthias Klose]

I am appending the following two sections to the python policy chapter 2,
documenting what currently is in testing.  There are different opinions, no
perfect solutions, and if we disagree, we should delegate the final decision
whether to include or to not include the binary packages
python{,-dev}-is-python3 built from the what-is-python source to the CTTE.

Matthias

+Removal of the unversioned packages
+---
+
+Starting with the Debian 11 release (bullseye), the binary packages
+``python``, ``python-minimal``, ``python-dev``, ``python-dbg`` and
+``python-doc`` are removed.  No package in the archive must use any of
+these packages as build dependencies, dependencies, recommendations or
+suggestions.
+
+
+Unversioned python commands
+---
+
+For the Debian 11 release (bullseye), the :file:`/usr/bin/python`
+command is provided in the ``python-is-python2`` package (pointing to
+:file:`/usr/bin/python2`).  The :file:`/usr/bin/python-config` and
+:file:`/usr/bin/pydoc` commands are provided in the
+``python-dev-is-python2`` package.  These package are not installed by
+default for new installations, but only for upgrades from the Debian
+10 release (buster).  These packages should be removed after an
+upgrade.  These packages will not be part of the Debian 12 release
+(bookworm).
+
+The packages ``python-is-python3`` and ``python-dev-is-python3``
+provide the :file:`/usr/bin/python`, :file:`/usr/bin/python-config`
+and :file:`/usr/bin/pydoc` commands pointing to Python3.  These
+packages can be installed by developers and users to use the
+unversioned commands.  NOTE: Locally installed software not yet ported
+to Python3 is likely to break when installing these packages.
+
+The packages ``python-is-python3``, ``python-dev-is-python3``,
+``python-is-python2`` and ``python-dev-is-python2`` must not be used
+as build dependencies, dependencies, recommendations or suggestions.

Bug#983858: dh_sphinxdoc doesn't symlink js files for singlehtml builds

[Matthias Klose]

Package: src:sphinx
Version: 3.4.3-1

dh_sphinxdoc doesn't symlink js files for singlehtml builds.  Building the same
documentation for html and singlehtml, the files in html are replaced by
symlinks, but the ones in singlehtml are not.

Bug#983859: bluefish: missing Breaks+Replaces on bluefish-data

[Sebastian Ramacher]

Package: bluefish
Version: 2.2.12-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

Between the version of bluefish in buster and bullsye,
/usr/share/bluefish/jsbeautifier moved from bluefish-data to bluefish.
However, bluefish does not have the corresponding Breaks and Replaces
reletionships defined to handle this properly and thus upgrades from
buster to bullseye fail:
| Preparing to unpack .../032-bluefish_2.2.12-1+b1_amd64.deb ...
| Unpacking bluefish (2.2.12-1+b1) over (2.2.10-1) ...
| dpkg: error processing archive 
/tmp/apt-dpkg-install-m8WUj5/032-bluefish_2.2.12-1+b1_amd64.deb (--unpack):
|  trying to overwrite '/usr/share/bluefish/jsbeautifier/__init__.py', which is 
also in package bluefish-data 2.2.10-1
| Preparing to unpack .../033-bluefish-data_2.2.12-1_all.deb ...
| Unpacking bluefish-data (2.2.12-1) over (2.2.10-1) ...

Found via the buster to bullseye upgrade tests running on
jenkins.debian.net:
https://jenkins.debian.net/job/chroot-installation_buster_install_education-development_upgrade_to_bullseye/

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#983346: Update gitlab to 13.7.7 (installation fails - need help)

[Dragos Jarca]

For upgrade to work on experimental, I also removed

/etc/gitlab/feature_flags/ops/dynamic_image_resizing.yml

/etc/gitlab/initializers/rack_attack_global.rb

I use:

gem 'rugged', '~> 1.1'

gem 'licensee', '~> 9.14'

Best regards,
Dragos Jarca
General manager
Dynamic Puzzle S.R.L.
www.dynamicpuzzle.ro
On 01.03.2021 15:58, Pirate Praveen wrote:



On Sun, Feb 28, 2021 at 11:00 pm, Pirate Praveen 
 wrote:
On Sun, 28 Feb 2021 19:04:24 +0530 Pirate Praveen 
 wrote:

> Asking upstream for help
> https://gitlab.com/gitlab-org/gitlab/-/issues/323024

Removing these 3 files makes the upgrade to proceed,
/usr/share/gitlab/config/feature_flags/ops/api_kaminari_count_with 
_limit.yml
/usr/share/gitlab/config/feature_flags/licensed/resource_access_token.yml 


/usr/share/gitlab/config/feature_flags/ops/marginalia.yml

Of these 3 
/usr/share/gitlab/config/feature_flags/licensed/resource_access_token.yml

can definitely be removed as it is not present in current version.

I think these are safe to remove, but I will wait a few days for an 
answer from upstream (till there is a new security release).


Or if someone else can confirm, this is safe, I can remove it as well.


ok, so the remaining two were also present in 
/usr/share/gitlab/config/feature_flags/development and were obsolete.


I confirmed the upgrade goes smooth after removing these and all other 
obsolete initializers. I have also implemented a check during build if 
any files in config is changed or not.


Moving 'config' directory out of /etc would be another option, but 
then that will need us to move files we would like users or package to 
be able to modify to /etc/gitlab manually (database.yml, gitlab.yml 
and some more .rb files like puma.rb). If anyone wants to give it a 
try, feel free.

Bug#983839: linux-image-5.10.0-3-amd64: /proc/kallsyms shouldn't be readable by non-root

[Russell Coker]

Package: src:linux
Version: 5.10.13-1
Severity: normal

$ wc /proc/kallsyms 
168114 567685 7891149 /proc/kallsyms

https://dustri.org/b/spectre-exploits-in-the-wild.html

The above article says that Fedora no longer makes kallsyms available to
unprivileged users to make attacks on the kernel more difficult.  I think
the Debian kernels should do the same.

-- Package-specific info:
** Version:
Linux version 5.10.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP 
Debian 5.10.13-1 (2021-02-06)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-3-amd64 
root=UUID=6b40496e-ccb0-48fd-8764-167e82fcd779 ro security=selinux nosmt 
lockdown=confidentiality quiet

** Not tainted

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages linux-image-5.10.0-3-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.139
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-3-amd64 recommends:
ii  apparmor 2.13.6-9
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-3-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.04-15
pn  linux-doc-5.10  

Versions of packages linux-image-5.10.0-3-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20201218-3
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#983328: scipy 1.6.1 breaks sparse (COO) matrix construction

[Drew Parsons]

pandas upstream have made a temporary workaround until the fix in scipy 
gets propagated,

https://github.com/pandas-dev/pandas/pull/40020

Bug#983785: wims-lti: fails to install: post-installation script subprocess returned error exit status 2

[Georges Khaznadar]

Dear Andreas,

thank you for the bug report, and for the fix!

Best regards,   Georges.

Andreas Beckmann a écrit :
> Package: wims-lti
> Version: 0.4.4-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.
> 
> >From the attached log (scroll to the bottom...):
> 
>   Setting up wims-lti (0.4.4-2) ...
>   dpkg: error processing package wims-lti (--configure):
>installed wims-lti package post-installation script subprocess returned 
> error exit status 2
>   Processing triggers for libc-bin (2.31-9) ...
>   Processing triggers for ca-certificates (20210119) ...
>   Updating certificates in /etc/ssl/certs...
>   0 added, 0 removed; done.
>   Running hooks in /etc/ca-certificates/update.d...
>   done.
>   Errors were encountered while processing:
>wims-lti
> 
> If I insert set -x in the postinst script, the race ends with
> 
> [...]
> + db_get wims-lti/virtualHost
> + _db_cmd GET wims-lti/virtualHost
> + _db_internal_IFS=
> 
> + IFS=
> + printf %s\n GET wims-lti/virtualHost
> + IFS=
> 
> + read -r _db_internal_line
> + IFS=
> 
> + RET=wims-lti.example.com
> + return 0
> + virtualHost=wims-lti.example.com
> + appDir=/var/lib/wims-lti
> + apacheConfDist=/etc/apache2/sites-available/wims-lti-django.conf-dist
> + apacheConf=/etc/apache2/sites-available/wims-lti-django.conf
> + getent passwd lti
> + lti_entry=
> 
> I'd suggest this change to fix the logic, and something similar for the group:
> 
> -lti_entry=$(getent passwd lti)
> -if [ -z "$lti_entry" ]; then
> +if ! getent passwd lti >/dev/null ; then
> 
> 
> cheers,
> 
> Andreas



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#972214: python3: Some dependencies are missing during the upgrade

[Matthias Klose]

Control: close -1

On 10/14/20 6:06 PM, Stefano Callegari wrote:
> Package: python3
> Version: 3.8.6-1
> Severity: important
> 
> Dear Maintainer,
> 
> with the latest update the package did not install with the following
> errors
> 
> ...
> Exception: cannot get content of devhelp
> error running python rtupdate hook devhelp
> ...
> Exception: cannot get content of libglib2.0-dev-bin
> error running python rtupdate hook libglib2.0-dev-bin
> dpkg: errore nell'elaborare il pacchetto python3 (--configure):
>  il sottoprocesso installato pacchetto python3 script post-installation ha
> restituito lo stato di errore 4
> Si sono verificati degli errori nell'elaborazione:
>  python3
> 
> Only when I installed the 2 reported packages was I able to complete the
> installation.

transient issue, when we built for 3.9. Closing.

Bug#827956: grub: Doesn't apply default entry from /etc/default/grub

[Diederik de Haas]

On dinsdag 2 maart 2021 10:24:41 CET you wrote:
> I have a 'server' with no keyboard or monitor attached. I want to
> boot into a 5.9 kernel instead of a 5.10 kernel to see whether there's a
> NFS problem with 5.10.
> But regardless what I specify as GRUB_DEFAULT in /etc/default/grub, it
> always boots the top entry.
> 
> I've tried the following things:
> - Use the value following "$menuentry_id_option"
> - Placed single quotes around previous value
> - Placed double quotes around previous value
> - Replace "$menuentry_id_option" with "--id" in case it was incorrectly
>   not expanded/replaced in the grub entries
> - Use a numerical value
> 
> None of which resulted in grub booting anything other then the top
> entry.

There was one option that I hadn't tried: using the title.
When I did that and run 'update-grub' I got an interesting warning:

Warning: Please don't use old title `Debian GNU/Linux, with Linux 5.9.0-5-
amd64' for GRUB_DEFAULT, use `Advanced options for Debian GNU/Linux>Debian 
GNU/Linux, with Linux 5.9.0-5-amd64' (for versions before 2.00) or `gnulinux-
advanced-2f82ed85-9840-4338-a5b2-71c735333ed9>gnulinux-5.9.0-5-amd64-
advanced-2f82ed85-9840-4338-a5b2-71c735333ed9' (for 2.00 or later)

So I changed GRUB_DEFAULT to the (latter) value suggested by the warning ... 
and low-and-behold, that worked!

So my compliments for that excellent warning/error message.

> If this can't be fixed, can then at least the documentation be updated
> to say that grub only works interactively?

I would say that the documentation really does need to be updated as what's 
described in "info -f grub -n 'Simple configuration'" is not/no longer correct.
I would've expected an ID to be unique though ...

Cheers,
  Diederik

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

Bug#977116: python3-minimal: python3 cut and paste not working for interperter

[Matthias Klose]

On 12/11/20 1:23 AM, grothe wrote:
> Package: python3-minimal
> Version: 3.9.0-4
> Severity: normal
> X-Debbugs-Cc: ajgro...@yahoo.com
> 
> Dear Maintainer,
> 
> If I run the Python3.9.1 interperter and attempt to print multiple lines of 
> python code to it fails.
> 
> E.g. cut and paste the following three lines into the buffer 
> 
> import os
> import datetime
> import pprint
> 
> and then paste that into an active python interperter get the following.

that should be fixed in python3.9 3.9.2-1

Bug#983842: please add more specific description

[Tomas Pospisek]

Hi Alois,

you write:


Package name: srcode

Description : Tool that help developers to manage their codebase in
  an effective & productive way.

srcode is a tool that help developers to manage their codebase in an 
effective & productive way.


this description however is arguably not productive. What does "manage" 
mean exactly?


* ext4 lets you manage your files in an effective & productive way
* dpkg lets you manage your files in an effictive & productive way
* vim lets you ...
* and so on

Based solely on that description, how do I, the user, browsing the 
Debian packages decide whether I want to install ext4, dpkg, vim or for 
the matter srcode?


As far as I can see "manage" is about as specific as the word "do": 
srcode lets you do "something" with your codebase. Now what is 
it **exactly** that srcode is offering? Could you please describe that 
both in the long as well as in the short description?


Thanks a lot!
*t

Bug#953328: sddm: No login prompt on tty1

[Norbert Preining]

Hi

> Is that actually a sddm or a systemd bug ?

Well, who knows. I would say a systemd bug because it decides to disable
tty1 - maybe because gdm is doing it like this. But honestly, I don't
want to wade into the systemd/gdm/gnome whatever world, I am not
interested in that, it is purged completely from my computer.

Norbert

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

Bug#983209: lynx: differences in documentation when built in parallel

[Andreas Metzler]

Control: tags -1 fixed-upstream

On 2021-02-27 Andreas Metzler  wrote:
> On 2021-02-21 Vagrant Cascadian  wrote:
> [...]
> > The lynx documentation has many differences between two builds:
[...]
> > All of the documentation differences disappeared for me when disabling
> > parallelism in the build (and fixing the usrmerge issue reported in
> > another bug). The attached patch passes --no-parallel to dh in

[...]
> This patch (use a "Grouped Target") fixes the issue for me:
> ---
> --- lynx-2.9.0dev.6.orig/makefile.in
> +++ lynx-2.9.0dev.6/makefile.in
> @@ -338,7 +338,7 @@ LYNX_URL='@HOMEPAGE_URL@release/breakout
>  LYNXDOCS_URL='$(LYNX_URL)/docs/'
>  LYNXHELP_URL='$(LYNX_URL)/lynx_help/'

> -@LYNXCFG_MAKE@$(CFG2HTML) :
> +@LYNXCFG_MAKE@$(CFG2HTML) &:
[...]
> Not sure whether it is upstreamable, since &: is a probably a
> GNU-make-ism.

Hello,

upstream has fixed this in a BSD-make compatible way
https://github.com/ThomasDickey/lynx-snapshots/commit/f100e91840bc2ef2cecf3d0975b734e53637fa55
 (stripped patch attached for reference)

So it will be part of the next upstream release. For Debian I think we
will temporarily use the one-line GNU-make-only fix.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--- lynx-2.9.0dev.6.orig/aclocal.m4
+++ lynx-2.9.0dev.6/aclocal.m4
@@ -3914,6 +3914,89 @@ CF_EOF
 AC_SUBST(cf_cv_makeflags)
 ])dnl
 dnl ---
+dnl CF_MAKE_PHONY version: 3 updated: 2021/01/08 16:08:21
+dnl -
+dnl Check if the make-program handles a ".PHONY" target, e.g,. a target which
+dnl acts as a placeholder.
+dnl
+dnl The ".PHONY" feature was proposed in 2011 here
+dnl https://www.austingroupbugs.net/view.php?id=523
+dnl and is scheduled for release in P1003.1 Issue 8 (late 2022).
+dnl
+dnl This is not supported by SVr4 make (or SunOS 4, 4.3SD, etc), but works with
+dnl a few others (i.e., GNU make and the non-POSIX "BSD" make):
+dnl
+dnl + This is a GNU make feature (since April 1988, but in turn from binutils,
+dnl   date unspecified).
+dnl
+dnl + It was adopted in NetBSD make in June 1995.
+dnl
+dnl + The other BSD make programs are derived from the NetBSD make (and for
+dnl   that reason are not actually different "implementations").
+dnl
+dnl + Some features of NetBSD make were actually adapted from pmake, which
+dnl   began as a modified GNU make starting in 1993.
+dnl
+dnl + Version 3.8 of the dmake program in January 1992 also implemented this
+dnl   GNU make extension, but is less well known than the BSD make.
+AC_DEFUN([CF_MAKE_PHONY],[
+AC_CACHE_CHECK(for \".PHONY\" make-support, cf_cv_make_PHONY,[
+	rm -rf conftest*
+	(
+		mkdir conftest || exit 1
+		cd conftest
+		cat >makefile <<'CF_EOF'
+.PHONY: always
+DATA=0
+always:	always.out
+	@echo "** making [$]@ [$](DATA)"
+once: once.out
+	@echo "** making [$]@ [$](DATA)"
+always.out:
+	@echo "** making [$]@ [$](DATA)"
+	echo [$](DATA) > [$]@
+once.out:
+	@echo "** making [$]@ [$](DATA)"
+	echo [$](DATA) > [$]@
+CF_EOF
+		for cf_data in 1 2 3
+		do
+			${MAKE:-make} always DATA=$cf_data
+			${MAKE:-make} once   DATA=$cf_data
+			${MAKE:-make} -t always once
+			if test -f always ; then
+echo "no (case 1)" > ../conftest.tmp
+			elif test ! -f always.out ; then
+echo "no (case 2)" > ../conftest.tmp
+			elif test ! -f once.out ; then
+echo "no (case 3)" > ../conftest.tmp
+			elif ! cmp -s always.out once.out ; then
+echo "no (case 4)" > ../conftest.tmp
+diff always.out once.out
+			else
+cf_check="`cat always.out`"
+if test "x$cf_check" != "x$cf_data" ; then
+	echo "no (case 5)" > ../conftest.tmp
+else
+	echo yes > ../conftest.tmp
+	rm -f ./*.out
+	continue
+fi
+			fi
+			break
+		done
+	) >&AC_FD_CC 2>&1
+	cf_cv_make_PHONY="`cat conftest.tmp`"
+	rm -rf conftest*
+])
+MAKE_NO_PHONY="#"
+MAKE_PHONY="#"
+test "x$cf_cv_make_PHONY" = xyes && MAKE_PHONY=
+test "x$cf_cv_make_PHONY" != xyes && MAKE_NO_PHONY=
+AC_SUBST(MAKE_NO_PHONY)
+AC_SUBST(MAKE_PHONY)
+])dnl
+dnl ---
 dnl CF_MAKE_TAGS version: 6 updated: 2010/10/23 15:52:32
 dnl 
 dnl Generate tags/TAGS targets for makefiles.  Do not generate TAGS if we have
--- lynx-2.9.0dev.6.orig/configure.in
+++ lynx-2.9.0dev.6/configure.in
@@ -108,6 +108,7 @@ AC_PROG_INSTALL
 AC_PROG_YACC
 CF_PROG_LINT
 CF_MAKEFLAGS
+CF_MAKE_PHONY
 CF_MAKE_TAGS
 
 CF_ACVERSION_CHECK(2.52,
@@ -633,10 +634,14 @@ CF_ARG_ENABLE(htmlized-cfg,
 AC_MSG_RESULT($use_htmlized_cfg)
 
 LYNXCFG_MAKE=''
+LYNXCFG_NO_MAKE=''
 if test $use_htmlized_cfg = no ; then
 	LYNXCFG_MAKE='#'
+else
+	LYNXCFG_NO_MAKE='#'
 fi
 AC_SUBST(LYNXCFG_MAKE)
+AC_SUBST(LYNXCFG_NO_MAKE)
 
 dnl --
 AC_MSG_CHECKING(if local doc directory should be linked to help page)
--- lynx-2

Bug#983852: python-scrapy: please make the build reproducible

[Chris Lamb]

Hi,

> […]

The patch I previously sent was slightly corrupted due to a snafu with me
using quilt locally. Please find a cleaner one attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/0002-Reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0002-Reproducible-build.patch  2021-03-02 
09:06:06.826207329 +
@@ -0,0 +1,28 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2021-03-02
+
+--- python-scrapy-2.4.1.orig/docs/conf.py
 python-scrapy-2.4.1/docs/conf.py
+@@ -9,7 +9,9 @@
+ # All configuration values have a default; values that are commented out
+ # serve to show the default.
+ 
++import os
+ import sys
++import time
+ from datetime import datetime
+ from os import path
+ 
+@@ -49,7 +51,10 @@ master_doc = 'index'
+ 
+ # General information about the project.
+ project = 'Scrapy'
+-copyright = f'2008\u2013{datetime.now().year}, Scrapy developers'
++build_date = datetime.utcfromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
++)
++copyright = f'2008\u2013{build_date.year}, Scrapy developers'
+ 
+ # The version info for the project you're documenting, acts as replacement for
+ # |version| and |release|, also used in various other places throughout the
--- a/debian/patches/series 2021-03-02 08:55:59.355009205 +
--- b/debian/patches/series 2021-03-02 09:05:31.529789277 +
@@ -1 +1,2 @@
 0001-Disable-hoverxref-and-notfound-Sphinx-extensions.patch
+0002-Reproducible-build.patch

Bug#983860: segfaults because tries to use non-free kernels

[Giovanni Mascellani]

Package: intel-media-va-driver
Version: 21.1.1+dfsg1-1
Severity: important

On my CPU iHD_drv_video.so segfaults when decoding an MP4 movie. I can for
example reproduce it by installing gstreamer1.0-vaapi and running:

$ gst-launch-1.0 playbin uri=https://test-
videos.co.uk/vids/bigbuckbunny/mp4/h264/360/Big_Buck_Bunny_360_10s_1MB.mp4

Gdb shows this backtrace (truncated, because it's more than 100 frames,
and the interesting ones are at the top):

#0  KernelDll_AllocateStates(void*, uint32_t, void*, uint32_t, Kdll_RuleEntry
const*, void (*)(PKdll_State)) (pKernelBin=pKernelBin@entry=0x7fffd42e59f0,
uKernelSize=0x0, pFcPatchCache=pFcPatchCache@entry=0x0,
uFcPatchCacheSize=, pDefaultRules=0x0,
ModifyFunctionPointers=0x0) at
./media_driver/agnostic/common/vp/kdll/hal_kerneldll.c:3350
#1  0x7fffd296bfdb in VphalRenderer::Initialize(VphalSettings const*, bool)
(this=0x7fffd4327e30, pSettings=0x71745ac0, isApoEnabled=)
at ./media_driver/agnostic/common/vp/hal/vphal_renderer.cpp:1414
#2  0x7fffd2952e15 in VphalState::Allocate(VphalSettings const*)
(pVpHalSettings=0x71745ac0, this=0x7fffd42e23a0) at
./media_driver/agnostic/common/vp/hal/vphal.cpp:146
#3  VphalState::Allocate(VphalSettings const*) (this=0x7fffd42e23a0,
pVpHalSettings=0x71745ac0) at
./media_driver/agnostic/common/vp/hal/vphal.cpp:75
#4  0x7fffd2b56105 in DdiVp_InitVpHal(DDI_VP_CONTEXT*)
(pVpCtx=0x7fffd42c1680) at
./media_driver/linux/common/vp/ddi/media_libva_vp.c:1800
#5  0x7fffd2b5a59f in DdiVp_InitCtx(VADriverContext*, DDI_VP_CONTEXT*)
(pVaDrvCtx=, pVpCtx=0x7fffd42c1680) at
./media_driver/linux/common/vp/ddi/media_libva_vp.c:1660
#6  0x7fffd2b5a99e in DdiVp_CreateContext(VADriverContext*, unsigned int,
int, int, int, unsigned int*, int, unsigned int*)
(pVaDrvCtx=pVaDrvCtx@entry=0x7fffd4265240, vaConfigID=vaConfigID@entry=0x0,
iWidth=iWidth@entry=0x0, iHeight=iHeight@entry=0x0, iFlag=iFlag@entry=0x0,
vaSurfIDs=vaSurfIDs@entry=0x0, iNumSurfs=0x0, pVaCtxID=0x71745dec) at
./media_driver/linux/common/vp/ddi/media_libva_vp.c:3109
#7  0x7fffd2b21be2 in DdiMedia_PutImage(VADriverContext*, unsigned int,
unsigned int, int, int, unsigned int, unsigned int, int, int, unsigned int,
unsigned int) (ctx=0x7fffd4265240, surface=0x0, image=,
src_x=0x0, src_y=0x0, src_width=0x40, src_height=0x40, dest_x=0x0, dest_y=0x0,
dest_width=0x40, dest_height=0x40) at
./media_driver/linux/common/ddi/media_libva.cpp:5407
#8  0x7006a17c in vaPutImage () at /usr/lib/x86_64-linux-gnu/libva.so.2
#9  0x700efb2c in gst_vaapi_surface_put_image
(surface=surface@entry=0x7fffd4252d60, image=image@entry=0x7fffd42742d0) at
../gst-libs/gst/vaapi/gstvaapisurface.c:761
#10 0x700ae476 in extract_allowed_surface_formats
(img_formats=0x7fffd425c290, display=0x7fffec0046c0
[GstVaapiDisplay|vaapidisplayglx0]) at ../gst/vaapi/gstvaapipluginbase.c:1451
#11 ensure_allowed_raw_caps (plugin=0x7fffd424e910) at
../gst/vaapi/gstvaapipluginbase.c:1483
#12 gst_vaapi_plugin_base_get_allowed_sinkpad_raw_caps
(plugin=plugin@entry=0x7fffd424e910) at ../gst/vaapi/gstvaapipluginbase.c:1515
#13 0x700b567e in ensure_allowed_sinkpad_caps (postproc=0x7fffd424e910)
at ../gst/vaapi/gstvaapipostproc.c:1312
#14 gst_vaapipostproc_transform_caps_impl (direction=,
trans=0x7fffd424e910 [GstBaseTransform|vaapipostproc0]) at
../gst/vaapi/gstvaapipostproc.c:1422
#15 gst_vaapipostproc_transform_caps (trans=0x7fffd424e910
[GstBaseTransform|vaapipostproc0], direction=,
caps=0x7fffd4264ad0, filter=0x7fffd4264c50) at
../gst/vaapi/gstvaapipostproc.c:1445
#16 0x767154b3 in gst_base_transform_transform_caps
(trans=trans@entry=0x7fffd424e910 [GstBaseTransform|vaapipostproc0],
direction=GST_PAD_SRC, caps=caps@entry=0x7fffd4264ad0,
filter=filter@entry=0x7fffd4264c50) at ../libs/gst/base/gstbasetransform.c:474
#17 0x76718e6d in gst_base_transform_query_caps (filter=0x7fffd4264c50,
pad=0x7fffd41f9840 [GstPad|sink], trans=0x7fffd424e910
[GstBaseTransform|vaapipostproc0]) at ../libs/gst/base/gstbasetransform.c:698
#18 gst_base_transform_default_query (trans=0x7fffd424e910
[GstBaseTransform|vaapipostproc0], direction=,
query=0x7fffd4264ca0) at ../libs/gst/base/gstbasetransform.c:1597
#19 0x77eace58 in gst_pad_query (pad=pad@entry=0x7fffd41f9840
[GstPad|sink], query=query@entry=0x7fffd4264ca0) at ../gst/gstpad.c:4144
#20 0x77ead5bb in gst_pad_peer_query (pad=pad@entry=0x7fffd41f95f0
[GstPad|src], query=query@entry=0x7fffd4264ca0) at ../gst/gstpad.c:4276

Debugging more in depth, I discovered that pKernelBin and uKernelSize
(parameters
of KernelDll_AllocateStates, frame #0) are not initialized by the caller. The
caller
(VphalRenderer::Initialize in
media_driver/agnostic/common/vp/hal/vphal_renderer.cpp)
should initialize the parameters from VphalRenderer members pcKernelBin and
dwKernelBinSize, but these members are in turn never changed from their default
zero value. Initialization should happen (on my CPU, at least) in
VphalRendererG9::Ini

Bug#983860: segfaults because tries to use non-free kernels

[Sebastian Ramacher]

Control: tags -1 + moreinfo

On 2021-03-02 12:23:08 +0100, Giovanni Mascellani wrote:
> Package: intel-media-va-driver
> Version: 21.1.1+dfsg1-1
> Severity: important
> 
> On my CPU iHD_drv_video.so segfaults when decoding an MP4 movie. I can for
> example reproduce it by installing gstreamer1.0-vaapi and running:

Which CPU/GPU is that?

Cheers

> 
> $ gst-launch-1.0 playbin uri=https://test-
> videos.co.uk/vids/bigbuckbunny/mp4/h264/360/Big_Buck_Bunny_360_10s_1MB.mp4
> 
> Gdb shows this backtrace (truncated, because it's more than 100 frames,
> and the interesting ones are at the top):
> 
> #0  KernelDll_AllocateStates(void*, uint32_t, void*, uint32_t, Kdll_RuleEntry
> const*, void (*)(PKdll_State)) (pKernelBin=pKernelBin@entry=0x7fffd42e59f0,
> uKernelSize=0x0, pFcPatchCache=pFcPatchCache@entry=0x0,
> uFcPatchCacheSize=, pDefaultRules=0x0,
> ModifyFunctionPointers=0x0) at
> ./media_driver/agnostic/common/vp/kdll/hal_kerneldll.c:3350
> #1  0x7fffd296bfdb in VphalRenderer::Initialize(VphalSettings const*, 
> bool)
> (this=0x7fffd4327e30, pSettings=0x71745ac0, isApoEnabled=)
> at ./media_driver/agnostic/common/vp/hal/vphal_renderer.cpp:1414
> #2  0x7fffd2952e15 in VphalState::Allocate(VphalSettings const*)
> (pVpHalSettings=0x71745ac0, this=0x7fffd42e23a0) at
> ./media_driver/agnostic/common/vp/hal/vphal.cpp:146
> #3  VphalState::Allocate(VphalSettings const*) (this=0x7fffd42e23a0,
> pVpHalSettings=0x71745ac0) at
> ./media_driver/agnostic/common/vp/hal/vphal.cpp:75
> #4  0x7fffd2b56105 in DdiVp_InitVpHal(DDI_VP_CONTEXT*)
> (pVpCtx=0x7fffd42c1680) at
> ./media_driver/linux/common/vp/ddi/media_libva_vp.c:1800
> #5  0x7fffd2b5a59f in DdiVp_InitCtx(VADriverContext*, DDI_VP_CONTEXT*)
> (pVaDrvCtx=, pVpCtx=0x7fffd42c1680) at
> ./media_driver/linux/common/vp/ddi/media_libva_vp.c:1660
> #6  0x7fffd2b5a99e in DdiVp_CreateContext(VADriverContext*, unsigned int,
> int, int, int, unsigned int*, int, unsigned int*)
> (pVaDrvCtx=pVaDrvCtx@entry=0x7fffd4265240, vaConfigID=vaConfigID@entry=0x0,
> iWidth=iWidth@entry=0x0, iHeight=iHeight@entry=0x0, iFlag=iFlag@entry=0x0,
> vaSurfIDs=vaSurfIDs@entry=0x0, iNumSurfs=0x0, pVaCtxID=0x71745dec) at
> ./media_driver/linux/common/vp/ddi/media_libva_vp.c:3109
> #7  0x7fffd2b21be2 in DdiMedia_PutImage(VADriverContext*, unsigned int,
> unsigned int, int, int, unsigned int, unsigned int, int, int, unsigned int,
> unsigned int) (ctx=0x7fffd4265240, surface=0x0, image=,
> src_x=0x0, src_y=0x0, src_width=0x40, src_height=0x40, dest_x=0x0, dest_y=0x0,
> dest_width=0x40, dest_height=0x40) at
> ./media_driver/linux/common/ddi/media_libva.cpp:5407
> #8  0x7006a17c in vaPutImage () at 
> /usr/lib/x86_64-linux-gnu/libva.so.2
> #9  0x700efb2c in gst_vaapi_surface_put_image
> (surface=surface@entry=0x7fffd4252d60, image=image@entry=0x7fffd42742d0) at
> ../gst-libs/gst/vaapi/gstvaapisurface.c:761
> #10 0x700ae476 in extract_allowed_surface_formats
> (img_formats=0x7fffd425c290, display=0x7fffec0046c0
> [GstVaapiDisplay|vaapidisplayglx0]) at ../gst/vaapi/gstvaapipluginbase.c:1451
> #11 ensure_allowed_raw_caps (plugin=0x7fffd424e910) at
> ../gst/vaapi/gstvaapipluginbase.c:1483
> #12 gst_vaapi_plugin_base_get_allowed_sinkpad_raw_caps
> (plugin=plugin@entry=0x7fffd424e910) at ../gst/vaapi/gstvaapipluginbase.c:1515
> #13 0x700b567e in ensure_allowed_sinkpad_caps 
> (postproc=0x7fffd424e910)
> at ../gst/vaapi/gstvaapipostproc.c:1312
> #14 gst_vaapipostproc_transform_caps_impl (direction=,
> trans=0x7fffd424e910 [GstBaseTransform|vaapipostproc0]) at
> ../gst/vaapi/gstvaapipostproc.c:1422
> #15 gst_vaapipostproc_transform_caps (trans=0x7fffd424e910
> [GstBaseTransform|vaapipostproc0], direction=,
> caps=0x7fffd4264ad0, filter=0x7fffd4264c50) at
> ../gst/vaapi/gstvaapipostproc.c:1445
> #16 0x767154b3 in gst_base_transform_transform_caps
> (trans=trans@entry=0x7fffd424e910 [GstBaseTransform|vaapipostproc0],
> direction=GST_PAD_SRC, caps=caps@entry=0x7fffd4264ad0,
> filter=filter@entry=0x7fffd4264c50) at ../libs/gst/base/gstbasetransform.c:474
> #17 0x76718e6d in gst_base_transform_query_caps 
> (filter=0x7fffd4264c50,
> pad=0x7fffd41f9840 [GstPad|sink], trans=0x7fffd424e910
> [GstBaseTransform|vaapipostproc0]) at ../libs/gst/base/gstbasetransform.c:698
> #18 gst_base_transform_default_query (trans=0x7fffd424e910
> [GstBaseTransform|vaapipostproc0], direction=,
> query=0x7fffd4264ca0) at ../libs/gst/base/gstbasetransform.c:1597
> #19 0x77eace58 in gst_pad_query (pad=pad@entry=0x7fffd41f9840
> [GstPad|sink], query=query@entry=0x7fffd4264ca0) at ../gst/gstpad.c:4144
> #20 0x77ead5bb in gst_pad_peer_query (pad=pad@entry=0x7fffd41f95f0
> [GstPad|src], query=query@entry=0x7fffd4264ca0) at ../gst/gstpad.c:4276
> 
> Debugging more in depth, I discovered that pKernelBin and uKernelSize
> (parameters
> of KernelDll_AllocateStates, frame #0) are not initialized by the caller. The
> caller
> (VphalRenderer::Initializ

Bug#983379: linux uml segfault

[Anton Ivanov]

On 02/03/2021 09:09, Ritesh Raj Sarraf wrote:

On Wed, 2021-02-24 at 11:44 +, Anton Ivanov wrote:

In all cases it boots cleanly and there are no segfaults.

So, frankly, no idea what is causing it to crash - I have run most
combinations of 5.10 on a 5.10, all work fine here.


Is there any other way I can help you with this issue ?
I do have the core dump available on my local machine.


If gdb gives you the exact lines, that may be helpful.

I have looked through the bt several times, it is something through which my 
set-up cruises through.

The actual moment you see in the backtrace is this one:

[0.08] random: get_random_u32 called from 
bucket_table_alloc.isra.0+0x115/0x13d with crng_init=0

However, in your case, instead of getting this printk warning out it blows up.

Why - I don't know.

A.





___
linux-um mailing list
linux...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um



--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Bug#981525: nheko login crashes client, can't be used, in urgent need of a version update

[Daniele Scasciafratte]

Any updates for this?
I am compiling on my machine Nheko with patches for debian as there is a
patch that I need to use better
https://github.com/Nheko-Reborn/nheko/commit/7ddcab3902a6b39c3ed8328c245f58a495b4c43f

PS: now marks as read the messages with that patch..

Bug#976340: jellyfish: Fails to build on some architectures

[Adrian Bunk]

On Mon, Mar 01, 2021 at 05:18:40PM +0100, Andreas Tille wrote:
>...
> I admit I have no idea how to debug this or how to force the proper -L
> option into this command line.  Any help is really appreciated.

I've now updated the patch:
https://salsa.debian.org/med-team/jellyfish/-/merge_requests/1

> Kind regards
> 
>  Andreas.
>...

cu
Adrian

Bug#983860: segfaults because tries to use non-free kernels

[Giovanni Mascellani]

Il 02/03/21 12:29, Sebastian Ramacher ha scritto:

Which CPU/GPU is that?


Sorry, I forgot:

$ cat /proc/cpuinfo 
processor	: 0

vendor_id   : GenuineIntel
cpu family  : 6
model   : 158
model name  : Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
stepping: 10
microcode   : 0xde
cpu MHz : 2781.102
cache size  : 12288 KB
physical id : 0
siblings: 12
core id : 0
cpu cores   : 6
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 22
wp  : yes
flags   : fpu 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 lm 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 hle avx2 smep bmi2 erms 
invpcid rtm 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
vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb 
flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml 
ept_mode_based_exec
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs taa itlb_multihit srbds
bogomips: 5799.77
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

> [...]

Thanks, Giovanni.
--
Giovanni Mascellani 

Bug#983862: PVH -- cannot remove vm with pci passthrough

[Adi Kriegisch]

Package: xen-utils-4.11
Version: 4.11.4+57-g41a822c392-2
Severity: minor

Dear maintainers,

we, by accident, added a pci passthrough device config to a pvh vm and were
able to boot that machine. But shutdown did not work with the following
error message:
  | xl: libxl_pci.c:1427: do_pci_remove: Assertion `type == 
LIBXL_DOMAIN_TYPE_PV' failed.
To remove the virtual machine and free its resources a reboot of Dom0 was
necessary. A corresponding assert when creating the machine seems to be
missing.
We consider this to be a bug, because we should not have been able to 'xl
create' that machine in the first place (or would have needed a way to
dispose the vm).

best regards,
Adi Kriegisch


signature.asc
Description: PGP signature

Bug#956782: zeal: Build-Depends (unnecessarily?) on deprecated libappindicator

[Kentaro Hayashi]

I've sent MR to fix.

Remove needless libappindicator-dev from Build-Depends 
https://salsa.debian.org/debian/zeal/-/merge_requests/1

Bug#964090: Status summary

[Ulrike Uhlig]

Hello!

As I ran into this issue I am giving here a short summary from what I 
understand to avoid that others have to re-read everything again:


AFAIU, there are two issues, one is related to Ghostscript, and one to 
ImageMagick itself.


Ghostscript
===

According to https://www.kb.cert.org/vuls/id/332928/ the issue is 
addressed in Ghostscript 9.24.


Except for Debian old-old-stable, Debian does ship versions above 9.24: 
https://tracker.debian.org/pkg/ghostscript


ImageMagick
===

Issue described here: 
https://insert-script.blogspot.com/2020/11/imagemagick-shell-injection-via-pdf.html


This is fixed in ImageMagick 6.9.11 and later, which is available in 
Bullseye but not earlier versions of Debian.


Current status reflected there:
https://security-tracker.debian.org/tracker/CVE-2020-29599


 - ulrike

Bug#976340: jellyfish: Fails to build on some architectures

[Andreas Tille]

Hi Adrian,

On Tue, Mar 02, 2021 at 01:43:47PM +0200, Adrian Bunk wrote:
> 
> I've now updated the patch:
> https://salsa.debian.org/med-team/jellyfish/-/merge_requests/1

Merged and will be uploaded soon.

Thanks a lot

  Andreas.

-- 
http://fam-tille.de

Bug#982510: libfilezilla11: libgnutls30 v3.7.0-5 breaks libfilezilla11 but downgrade to v3.6.15-4 still works

[Adrian Bunk]

Control: reassign -1 libgnutls30 3.7.0-5
Control: close -1 3.7.0-7
Control: affects -1 libfilezilla11

On Sun, Feb 28, 2021 at 02:08:20PM +, Philip Wyett wrote:
> On Sun, 2021-02-28 at 14:09 +0200, Adrian Bunk wrote:
> > Control: tags -1 -patch
> > 
> > On Thu, Feb 11, 2021 at 06:52:43AM +0100, Etilem wrote:
> > > Package: libfilezilla11
> > > Version: 0.26.0-1+b1
> > > Severity: important
> > > Tags: patch
> > > 
> > > Hello,
> > > 
> > > While using
> > > 
> > >   filezilla v3.52.2-3
> > > 
> > > and
> > > 
> > >   libgnutls30 v3.7.0-5
> > > 
> > > I was unable to make a PASV connection to a PureFTP server, but
> > > after
> > > downgrading to
> > > 
> > >   libgnutls30 v3.6.15-4
> > > 
> > > everything worked.
> > > ...
> > 
> > Thanks for the report.
> > 
> > Does it work with libgnutls30 v3.7.0-7 ?
> > 
> > cu
> > Adrian
> > 
> 
> Hi Adrian,

Hi Phil,

> Yes it does work with v3.7.0-7.

thanks, reassigning and closing it there.

> Regards
> 
> Phil

cu
Adrian

Bug#955832: dbus-test-runner: unnecessarily Build-Depends on deprecated dbus-glib

[Kentaro Hayashi]

I've sent MR


Remove needless libdbus-glib-1-dev from Build-Depends 
https://salsa.debian.org/debian/dbus-test-runner/-/merge_requests/2

Regards,

Bug#983863: RM: r-cran-sf [s390x] -- NBS; no longer built on s390x

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

r-cran-sf (0.9-7+dfsg-4) unstable; urgency=medium

  * Revert changes from 0.9-7+dfsg-3 and instead exclude s390x from list of
architectures

 -- Andreas Tille   Mon, 01 Mar 2021 15:10:54 +0100

Bug#983864: RM: abinit [mips64el mipsel] -- RoQA; no longer builds on mips*

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

abinit no longer builds on mips*

Bug#983842: please add more specific description

[Aloïs Micard]

Hello Tomas,



As far as I can see "manage" is about as specific as the word "do": srcode lets you do 
"something" with your codebase. Now what is it **exactly** that srcode is offering? Could you 
please describe that both in the long as well as in the short description?


Thanks for your constructive feedback!

I agree that the description lacks of clarity,
I'll take care of that in the package description &
will update that upstream too.

Thanks.

Cheers,

--
Aloïs Micard (creekorful) 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#983865: [l10n-de] unbenutzte Variable ... verwandt

[Christoph Berg]

Package: dpkg-dev
Version: 1.20.7.1
Severity: normal

Hi,

in dpkg-gencontrol, the translation of

dpkg-gencontrol: warning: Depends field of package elephant-shed: substitution 
variable ${keyring:Depends} used, but is not defined

is

dpkg-gencontrol: Warnung: Feld Depends von Paket elephant-shed: unbenutzte 
Variable ${keyring:Depends} verwandt, aber nicht definiert

... which translates into "unused variable ... used", which is
weird. The correct translation would be:

dpkg-gencontrol: Warnung: Feld Depends von Paket elephant-shed: Variable 
${keyring:Depends} verwandt, aber nicht definiert

-- Package-specific info:

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

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

Versions of packages dpkg-dev depends on:
ii  binutils  2.35.1-7
ii  bzip2 1.0.8-4
ii  libdpkg-perl  1.20.7.1
ii  make  4.3-4
ii  patch 2.7.6-7
ii  perl  5.32.1-2
ii  tar   1.34+dfsg-1
ii  xz-utils  5.2.5-1.0

Versions of packages dpkg-dev recommends:
ii  build-essential  12.9
ii  clang-10 [c-compiler]1:10.0.1-8+b1
ii  clang-11 [c-compiler]1:11.0.1-2
ii  fakeroot 1.25.3-1.1
ii  gcc [c-compiler] 4:10.2.1-1
ii  gcc-10 [c-compiler]  10.2.1-6
ii  gnupg2.2.27-1
ii  gpgv 2.2.27-1
pn  libalgorithm-merge-perl  

Versions of packages dpkg-dev suggests:
pn  debian-keyring  

-- no debconf information

Christoph

Bug#983860: segfaults because tries to use non-free kernels

[Sebastian Ramacher]

Control: tags -1 = upstream
Control: forwarded -1 https://github.com/intel/media-driver/issues/1132

On 2021-03-02 12:41:17 +0100, Giovanni Mascellani wrote:
> Il 02/03/21 12:29, Sebastian Ramacher ha scritto:
> > Which CPU/GPU is that?
> 
> Sorry, I forgot:
> 
> > $ cat /proc/cpuinfo processor   : 0
> > vendor_id   : GenuineIntel
> > cpu family  : 6
> > model   : 158
> > model name  : Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
> > stepping: 10
> > microcode   : 0xde
> > cpu MHz : 2781.102
> > cache size  : 12288 KB
> > physical id : 0
> > siblings: 12
> > core id : 0
> > cpu cores   : 6
> > apicid  : 0
> > initial apicid  : 0
> > fpu : yes
> > fpu_exception   : yes
> > cpuid level : 22
> > wp  : yes
> > flags   : fpu 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 lm 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 hle 
> > avx2 smep bmi2 erms invpcid rtm 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
> > vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb 
> > flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml 
> > ept_mode_based_exec
> > bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass 
> > l1tf mds swapgs taa itlb_multihit srbds
> > bogomips: 5799.77
> > clflush size: 64
> > cache_alignment : 64
> > address sizes   : 39 bits physical, 48 bits virtual
> > power management:
> > [...]

Thanks, in that case it's most likely the issue at
https://github.com/intel/media-driver/issues/1132

Cheers

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#983860: segfaults because tries to use non-free kernels

[Giovanni Mascellani]

Hi,

Il 02/03/21 13:08, Sebastian Ramacher ha scritto:

Thanks, in that case it's most likely the issue at
https://github.com/intel/media-driver/issues/1132


Seems likely, thanks.

Giovanni.
--
Giovanni Mascellani 

Bug#983866: mark symbol as optional, not seen when building with -O3

[Matthias Klose]

Package: src:libunivalue
Version: 1.1.1+20191112-1
Tags: patch

Mark another symbol as optional, not seen when building with -O3.

patch at
http://launchpadlibrarian.net/525810427/libunivalue_1.1.1+20191112-1_1.1.1+20191112-1ubuntu1.diff.gz

Bug#983842: please add more specific description

[Tomas Pospisek]

:+1 ! Thank you!
*t

On Tue, 2 Mar 2021, Aloïs Micard wrote:


Hello Tomas,



As far as I can see "manage" is about as specific as the word "do": srcode 
lets you do "something" with your codebase. Now what is it **exactly** that 
srcode is offering? Could you please describe that both in the long as well 
as in the short description?


Thanks for your constructive feedback!

I agree that the description lacks of clarity,
I'll take care of that in the package description &
will update that upstream too.

Thanks.

Cheers,

--
Aloïs Micard (creekorful) 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#983845: doas does not autocomplete apt

[Ferdinand]

Subject: reportbug: doas does not autocomplete apt commands
Package: doas
Version: 6.8.1-2
Severity: wishlist

Dear Maintainer,

   * What led up to the situation?
Trying to use autocomplete for apt with doas

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
doas ap TAB
doas apt upd TAB

   * What was the outcome of this action?
both attempts do nothing
   * What outcome did you expect instead?
I expected tab completion to complete my commands to apt and to apt update

Completion works fine with paths, not with apt though.

With FreeBSD you add 'complete -cf doas' to ~/.bashrc, but that does not 
work with Debian.


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

Kernel: Linux 5.10.17-towo.1-siduction-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages doas depends on:
ii  libc6 2.31-9
ii  libpam0g  1.4.0-6

doas recommends no packages.

doas suggests no packages.

-- no debconf information

Bug#983867: O: comgt -- Option GlobeTrotter and Vodafone datacard control tool

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of comgt has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

https://tracker.debian.org/pkg/comgt


Package: comgt
Binary: comgt
Version: 0.32-3
Maintainer: Andreas "Jimmy" Gredler 
Build-Depends: debhelper (>= 9.0.0)
Architecture: any
Standards-Version: 3.9.8
Format: 3.0 (quilt)
Files:
 66a516bf65899decd7df48cf0ca4ca21 1656 comgt_0.32-3.dsc
 db2452680c3d953631299e331daf49ef 39021 comgt_0.32.orig.tar.gz
 daf294c765cd95bf70db6a002e996efe 5680 comgt_0.32-3.debian.tar.xz
Checksums-Sha256:
 396283b6ec9f77253e2b6ee36a8faf046db45e5a4cd9e825f42e9f5601a1387a 1656 
comgt_0.32-3.dsc
 0cedb2a5aa608510da66a99aab74df3db363df495032e57e791a2ff55f1d7913 39021 
comgt_0.32.orig.tar.gz
 fbb01745cb7495a82eb4ec76bde4d09767ac7cecff50b423fcdf5a4c86f98af6 5680 
comgt_0.32-3.debian.tar.xz
Homepage: http://www.pharscape.org/
Package-List: 
 comgt deb net optional arch=any
Directory: pool/main/c/comgt
Priority: source
Section: net


Package: comgt
Version: 0.32-3
Installed-Size: 103
Maintainer: Andreas "Jimmy" Gredler 
Architecture: amd64
Replaces: gcom
Depends: libc6 (>= 2.7)
Conflicts: gcom
Description-en: Option GlobeTrotter and Vodafone datacard control tool
 Comgt is a scripting language interpreter useful for establishing
 communications on serial lines and through PCMCIA modems as well as
 GPRS and 3G datacards. Works with Option GlobeTrotter
 GPRS/EDGE/3G/HSDPA and Vodafone 3G/GPRS datacards.
Description-md5: f964e8faba4818d02deaf27ab6ddcba3
Homepage: http://www.pharscape.org/
Tag: hardware::modem, implemented-in::c, role::program, scope::utility
Section: net
Priority: optional
Filename: pool/main/c/comgt/comgt_0.32-3_amd64.deb
Size: 38982
MD5sum: b01b000c6432b2edd61ab07343092777
SHA256: 7343c1e98705e8ef8d621809ce4e9689bc598f6c791d2f2244e01a9df4ba6e3b

Bug#981985: lyx: Frequently takes 100% CPU and hangs, sometimes until killed, sometimes just for seconds

[Dr. Axel Stammler]

On Fri 2021-02-05 15.45.25, Pavel Sanda wrote:

On Fri, 05 Feb 2021 15:35:13 +0100 Axel Stammler  
wrote:

Package: lyx
Version: 2.3.2-1
Severity: important

Dear Maintainer,

Lyx again and again suddenly stops reacting to pointer and keyboard and takes 
all CPU
capacity. Sometimes it quickly recovers without any errors, sometimes it needs 
to be killed
after, say, an hour.


This will be hard to fix unless some more information is provided.
Is there recipy how to reproduce this behaviour? Does it happen with
some particular document?


It happens with all documents in different situations, one of them reproducibly 
being:

- file → save as
- trying to copy the filename by pressing ^C
- pressing  to close the file dialogue
- Lyx now freezes for about 30s
- you get impatient and try to click on something (like ‘cancel’) or to close 
the file dialogue or Lyx by clicking on the window decoration

I suspect it has something to do with Lyx's interaction with the window manager.


If you look on top report is 100% taken by lyx process itself or some
conversion routine in background (e.g. conversion of figure).


Lyx

Bug#983868: gsequencer ftbfs with -Werror=maybe-uninitialized

[Matthias Klose]

Package: src:gsequencer
Version: 3.7.38-1
Severity: important
Tags: sid bullseye
X-Debbugs-CC: Joël Krähemann 

gsequencer ftbfs with -Werror=maybe-uninitialized, with gcc-10 and gcc-11 from
experimental.

ags/audio/midi/ags_midi_buffer_util.c:2606:17: error: ‘current_delta_time’ may
be used uninitialized in this function [-Werror=maybe-uninitialized]
 2606 | *delta_time = current_delta_time;
  | ^~~~
cc1: some warnings being treated as errors

You don't see the error in a build log, because the libtool output is redirected
to /dev/null.

Forwarded to https://gcc.gnu.org/PR99340

The warning is only seen with -fPIE, not -fPIC, which is a bug in GCC.

The warning itself is correct, ags_midi_buffer_util_get_varlength doesn't always
return a value in varlength.

Bug#983786: affects to bullseye too

[PICCORO McKAY Lenz]

The relevant commit is
2ebfa0325b501e308e43b451561a06cb18bb28ec (1) in the courier-libs repo.

But i'm afraid that backporting to bullseye will need another more big
commit, i'm asking to SAM for..

[1]
https://github.com/svarshavchik/courier-libs/commit/2ebfa0325b501e308e43b451561a06cb18bb28ec





Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com


El lun, 1 de mar. de 2021 a la(s) 18:03, PICCORO McKAY Lenz (
mckaygerh...@gmail.com) escribió:

> Source: courier
> Version: 1.0.14-2
> Severity: serious
>
> hi markus.. sorry but this bug also affected freeze released bulleye..
> but noted that the commit is a changelog only entry.. so i asked to
> SAM
>
>
> https://sourceforge.net/p/courier/mailman/courier-users/?viewmonth=202103&viewday=1
>
> so this bug is closed only for uinstable but not for freeze testing
> bullseye
>
> --
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
>

Bug#815196: Hello

[Ella Oliver]

Hello Dear How are you doing? Ella

Bug#981985: lyx: Frequently takes 100% CPU and hangs, sometimes until killed, sometimes just for seconds

[Pavel Sanda]

On Sat, Feb 27, 2021 at 02:25:28PM +0100, Dr. Axel Stammler wrote:
> It happens with all documents in different situations, one of them 
> reproducibly being:
> 
> - file ??? save as
> - trying to copy the filename by pressing ^C
> - pressing  to close the file dialogue
> - Lyx now freezes for about 30s
> - you get impatient and try to click on something (like ???cancel???) or to 
> close the file dialogue or Lyx by clicking on the window decoration

Unfortunately I can not reproduce, though I am not sure I understand step 2 in 
the recipy.

> I suspect it has something to do with Lyx's interaction with the window 
> manager.

That migh well be. What WM do you use? 

It might also be that Qt version plays a role so we might want to recheck
the problem once bullseye becomes stable.

> > If you look on top report is 100% taken by lyx process itself or some
> > conversion routine in background (e.g. conversion of figure).
> 
> Lyx

Is it in your capability to provide gdb backtrace from the freezing period
or perhaps look whether strace reports something interesting at that time?
(You might need something like 
$ strace /usr/bin/lyx 2>&1|grep -vE 
'localtime|gettimeofday|clock_gettime|^read|POLLIN'
to avoid excessive overreporting).

Please keep bugs.debian.org CC-ed, thanks :)
Pavel

Bug#983605: dicomscope: Files missing from distribution

[Andreas Tille]

Control: tags -1 moreinfo
Control: severity -1 important


Hi John,

thanks a lot for your attempt to use Debian packaged dicomscope and your
bug report as response to our work.

On Sat, Feb 27, 2021 at 08:01:55AM +, John Talbut wrote:
> After attempting to install this package it does not work

What exactly does not work.  When I do

   sudo apt install dicomscope
   dicomscope

I can see some graphical user interface.  I'm not a user of this
software myself and have no good idea how to really test that program
but we simply need more information what you expect and what is
happening instead.

> and various
> files seem to be missing.

Which files are missing?

> At
> https://packages.debian.org/bullseye/all/dicomscope/filelist I get the
> message "No such package in this suite on this architecture."

https://packages.debian.org/bullseye/dicomscope
https://tracker.debian.org/pkg/dicomscope

These links are locking pretty normal to me.  I do not use this
.../filelist link, but if you can install the package than you
can get the list of files via

dpkg -L dicomscope

For the moment I took the freedom to set the severity of the bug to
important since we have no chance to reproduce the problem you are
facing and need more information (so I've also set tag moreinfo).

Kind regards

   Andreas.

> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.13-20210224 (SMP w/2 CPU threads)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages dicomscope depends on:
> ii  default-jre2:1.11-72
> ii  jarwrapper 0.78
> ii  libdicomscope-jni  3.6.0-22+b1
> ii  tk8.6  8.6.11-2
> 
> dicomscope recommends no packages.
> 
> dicomscope suggests no packages.
> 
> -- no debconf information
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#983869: lsblk does not report mount point for all members of btrfs filesystems

[vasilis g]

Package: util-linux

Version: 2.33.1-0.1

lsblk --version:   lsblk from util-linux 2.33.1

Kernel: 4.19.0-14-cloud-amd64

Debian: 10.8


With BTRFS filesystems with multiple devices (e.g.  a single topology of 
a filesystem consisting 2 devices) lsblk does not populate the 
MOUNTPOINT field (as it does for LVM multiple device filesystems). This 
can cause confusion (lsblk tends to be one of the most important 
commands to examine a system's block device topology). While on the more 
traditional LVM stack one gets the mount point, for the newer btrfs we 
don't get the same information.



Example on a system with a multi device btrfs filesystem

# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
...
vdb    254:16   0    2T  0 disk
└─vdb1 254:17   0    2T  0 part /data
vdc    254:32   0    2T  0 disk
└─vdc1 254:33   0    2T  0 part


# lsblk -f

vdb
└─vdb1 btrfs    be86d428-b3f2-4fb7-ac07-a4b41f92a4ac 2,1T    47% /data
vdc
└─vdc1 btrfs be86d428-b3f2-4fb7-ac07-a4b41f92a4ac

while examining btrfs commands we can see the relationship

# btrfs device usage /data
/dev/vdb1, ID: 1
   Device size: 2.00TiB
...
/dev/vdc1, ID: 2
   Device size: 2.00TiB
...


For comparison here is a listing from another system (also debian 10.8 
and same lsblk version) with LVM formatted filesystem


# lsblk

vdb  254:16   0    2T  0 disk
└─vdb1   254:17   0    2T  0 part
  └─vg-data 253:0    0    3T  0 lvm  /data
vdc  254:32   0    2T  0 disk
└─vdc1   254:33   0    2T  0 part
  └─vg-data 253:0    0    3T  0 lvm  /data


Kind Regards

V.G.

Bug#982730: properly disable parallel builds

[Matthias Klose]

Control: tags -1 + patch

setting MAKEFLAGS to -j , taken from DEB_BUILD_OPTIONS=parallel= doesn't
disable the parallel build.

patch at
http://launchpadlibrarian.net/525714744/freedict_2021.01.05-2_2021.01.05-2ubuntu1.diff.gz

Bug#983645: laminard: SIGPIPE kills it

[meskio]

Jan-Benedict, thanks for the report.

Quoting Jan-Benedict Glaw (2021-02-27 23:31:57)
> I gave laminar a try, but laminard dies on SIGPIPE:
> 
> (gdb) bt
> #0  0x7f7f95d53da3 in __GI___writev (fd=16, iov=0x7ffdebf13860, iovcnt=3) 
> at ../sysdeps/unix/sysv/linux/writev.c:26
> #1  0x7f7f963d8269 in non-virtual thunk to kj::(anonymous 
> namespace)::AsyncStreamFd::write(kj::ArrayPtr const> const>) () at src/kj/async-inl.h:403
> #2  0x7f7f96487dc6 in kj::(anonymous 
> namespace)::HttpOutputStreamoperator() 
> (__closure=0x56237a1a5410) at src/kj/compat/http.c++:1661
> #3  kj::_::MaybeVoidCaller 
> >::apply namespace)::HttpOutputStream::writeBodyData(kj::ArrayPtr kj::ArrayPtr >):: > (func=..., func=..., 
> in=...) at ./src/kj/async-prelude.h:148
> #4  kj::_::TransformPromiseNode, kj::_::Void, 
> kj::(anonymous namespace)::HttpOutputStream::writeBodyData(kj::ArrayPtr kj::ArrayPtr >)::, 
> kj::_::PropagateException>::getImpl(kj::_::ExceptionOrValue &) 
> (this=0x56237a1a53f0, output=...) at ./src/kj/async-inl.h:401
> #5  0x7f7f9638c502 in 
> kj::_::TransformPromiseNodeBaseoperator() 
> (__closure=0x7ffdebf14188, __closure=0x7ffdebf14188) at src/kj/async.c++:703
> #6  
> kj::_::RunnableImpl
>  >::run(void) (this=0x7ffdebf14180) at src/kj/exception.h:302
> #7  0x7f7f96305f9b in kj::_::runCatchingExceptions (runnable=warning: 
> RTTI symbol not found for class 
> 'kj::_::RunnableImpl'
> ...) at src/kj/exception.c++:1023
> #8  0x7f7f9638b6fa in 
> kj::runCatchingExceptions
>  > (func=...) at src/kj/common.h:514
> #9  kj::_::TransformPromiseNodeBase::get (this=, output=...) 
> at src/kj/async.c++:703
> #10 0x7f7f963901e9 in kj::_::ChainPromiseNode::fire (this=0x56237a1b2cd0) 
> at src/kj/async.c++:855
> #11 0x7f7f9638be3c in kj::EventLoop::turn (this=0x56237a17df98) at 
> src/kj/async.c++:373
> #12 0x7f7f963910c5 in kj::_::waitImpl (node=..., result=..., 
> waitScope=...) at src/kj/async.c++:440
> #13 0x562378dde1cc in kj::Promise::wait (waitScope=..., 
> this=0x7ffdebf14cf0) at /usr/include/kj/async-inl.h:902
> #14 Server::start (this=0x56237a17e1e0) at ./src/server.cpp:56
> #15 0x562378d9eeba in main (argc=, argv=) 
> at ./src/main.cpp:98
> 
> 
> This is while one job is running and I'm following it's build log on
> the /jobs/xxx/nn page. Quite easy to reproduce.

I'm using laminar myself and I haven't seeing this issue. Can you provide an 
example job that produces this issue for you?

> (Another small issue: /var/log/laminar.log isn't pre-created and
> daemon drops permissions before creating the file, so it fails
> creating it altogether.)

>From that report I guess you use sysv-init instead of systemd isn't it? Maybe 
the SIGPIPE error is also related to that. I have to say I didn't test it on 
any 
other setup than systemd. I don't have at hand a sysv-init system, I'll try to 
setup one.

If you are able to test your laminar with systemd tell me if your problem 
persist there.

-- 
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.

signature.asc
Description: signature

Bug#983861: k3b: Permissions of external program should be of group "cdrom" and not "operator"

[Norbert Preining]

Hi,

not that I am an expert, and cd burning is anyway only for maniacs (like
me!!!) who want to get into contact with whom-who-must-not-be-named.

> With k3b, when wanting to set the external program permissions, it wants to 
> set them with user "operator" instead of "cdrom" which may be more adequate

>  while (::group *g = ::getgrent()) {
>  const QString groupName = QString::fromLocal8Bit(g->gr_name);
> -if (groupName == "cdrom" ||
> -groupName == "optical" ||
> -groupName == "operator" ) {
> +if (groupName == "cdrom") {
>  m_permissionModel->setBurningGroup(groupName);
>  }
>  }

Well, the original code is rather bad indeed, because it relies on the
order of groups returned by getgrent, and picks the *last* available
one. In your case, if you have an "operator" group, it will be used.

I am not sure, maybe this is intended, but I guess there should be
either a break out of the loop after the first groupname is found,
or something else. 

Best

Norbert

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

Bug#983645: laminard: SIGPIPE kills it

[Jan-Benedict Glaw]

Hi meskio!

On Tue, 2021-03-02 14:01:13 +0100, meskio  wrote:
> Jan-Benedict, thanks for the report.
> Quoting Jan-Benedict Glaw (2021-02-27 23:31:57)
> > I gave laminar a try, but laminard dies on SIGPIPE:
> > 
> > (gdb) bt
> > #0  0x7f7f95d53da3 in __GI___writev (fd=16, iov=0x7ffdebf13860, 
> > iovcnt=3) at ../sysdeps/unix/sysv/linux/writev.c:26
> > #1  0x7f7f963d8269 in non-virtual thunk to kj::(anonymous 
> > namespace)::AsyncStreamFd::write(kj::ArrayPtr > const> const>) () at src/kj/async-inl.h:403
> > #2  0x7f7f96487dc6 in kj::(anonymous 
> > namespace)::HttpOutputStreamoperator() 
> > (__closure=0x56237a1a5410) at src/kj/compat/http.c++:1661
> > #3  kj::_::MaybeVoidCaller 
> > >::apply > namespace)::HttpOutputStream::writeBodyData(kj::ArrayPtr > kj::ArrayPtr >):: > (func=..., func=..., 
> > in=...) at ./src/kj/async-prelude.h:148
> > #4  kj::_::TransformPromiseNode, kj::_::Void, 
> > kj::(anonymous 
> > namespace)::HttpOutputStream::writeBodyData(kj::ArrayPtr > kj::ArrayPtr >)::, 
> > kj::_::PropagateException>::getImpl(kj::_::ExceptionOrValue &) 
> > (this=0x56237a1a53f0, output=...) at ./src/kj/async-inl.h:401
> > #5  0x7f7f9638c502 in 
> > kj::_::TransformPromiseNodeBaseoperator() 
> > (__closure=0x7ffdebf14188, __closure=0x7ffdebf14188) at src/kj/async.c++:703
> > #6  
> > kj::_::RunnableImpl
> >  >::run(void) (this=0x7ffdebf14180) at src/kj/exception.h:302
> > #7  0x7f7f96305f9b in kj::_::runCatchingExceptions (runnable=warning: 
> > RTTI symbol not found for class 
> > 'kj::_::RunnableImpl'
> > ...) at src/kj/exception.c++:1023
> > #8  0x7f7f9638b6fa in 
> > kj::runCatchingExceptions
> >  > (func=...) at src/kj/common.h:514
> > #9  kj::_::TransformPromiseNodeBase::get (this=, output=...) 
> > at src/kj/async.c++:703
> > #10 0x7f7f963901e9 in kj::_::ChainPromiseNode::fire 
> > (this=0x56237a1b2cd0) at src/kj/async.c++:855
> > #11 0x7f7f9638be3c in kj::EventLoop::turn (this=0x56237a17df98) at 
> > src/kj/async.c++:373
> > #12 0x7f7f963910c5 in kj::_::waitImpl (node=..., result=..., 
> > waitScope=...) at src/kj/async.c++:440
> > #13 0x562378dde1cc in kj::Promise::wait (waitScope=..., 
> > this=0x7ffdebf14cf0) at /usr/include/kj/async-inl.h:902
> > #14 Server::start (this=0x56237a17e1e0) at ./src/server.cpp:56
> > #15 0x562378d9eeba in main (argc=, argv=) 
> > at ./src/main.cpp:98
> > 
> > 
> > This is while one job is running and I'm following it's build log on
> > the /jobs/xxx/nn page. Quite easy to reproduce.
> 
> I'm using laminar myself and I haven't seeing this issue. Can you provide an 
> example job that produces this issue for you?

This was while I was setting things up to do CI builds for
binutils/gas/gdb/gcc.  I observed crashing laminard with any job,
though not in a clear reproducible way. My impression is that this is
in conjunction with logs and reloads (browser tab.)

  So testing this hypothesis would mean "reload the browser tab" while
following the log, or reload the (raw) log file frequently while it is
still being appended by the run.

> > (Another small issue: /var/log/laminar.log isn't pre-created and
> > daemon drops permissions before creating the file, so it fails
> > creating it altogether.)
> 
> From that report I guess you use sysv-init instead of systemd isn't it? Maybe 
> the SIGPIPE error is also related to that. I have to say I didn't test it on 
> any 
> other setup than systemd. I don't have at hand a sysv-init system, I'll try 
> to 
> setup one.

Right, that's an older Debian (unstable) system updated to what's
current right now, but I tried to keep systemd out of that box.

  I do not think that SysV init has something to do with the SIGPIPE.
It's probably being a close()d / shutdown()ed FD (at the browser side)
while it tries to chunk-send data.

  However, with systemd you'd probably get a restart of laminard. You
may observe a failed / missing run, but because daemon(1) won't do
a restart, laminard dies for me without getting a recovery by restart.

> If you are able to test your laminar with systemd tell me if your problem 
> persist there.

I'll try to pin down in which circumstances this actually happens.

MfG, JBG

-- 


signature.asc
Description: PGP signature

Bug#983835: base-installer: hostname= is ignored if reverse-dns exists

[Holger Wansing]

Am 2. März 2021 09:52:06 MEZ schrieb Cyril Brulebois :
>The preseed doc[2] suggests the former is behind the (bare) hostname
>alias. Try setting the latter?

Yes, the installation-guide under
https://www.debian.org/releases/bullseye/amd64/apbs04.en.html
even explicitly states this, indeed:

# If you want to force a hostname, regardless of what either the DHCP # server 
returns or what the reverse DNS entry for the IP is, uncomment # and adjust the 
following line. #d-i netcfg/hostname string somehost


Holger

Hi,
-- 
Sent from /e/ Mail on Fairphone3

Bug#983737: open-iscsi: configuration does not finish with sysvinit-core

[Ritesh Raj Sarraf]

On Tue, 2021-03-02 at 10:52 +0900, Ryutaroh Matsumoto wrote:
> > I see nothing wrong here. What is the output you expect ?
> 
> On the qemu default configuration by virt-manager in Bullseye,
> "apt-get install open-iscsi" finishes with no problem when
> /sbin/init==systemd-sysv,
> while "apt-get install open-iscsi" never finishes when
> /sbin/init==systemd-sysv.
> 

I guess you meant sysvinit in the latter case.

> Is it expected? If this is an expected behavior, I am happy to attach
> "wontfix" tag
> and/or close this issue.
> 

The installation of the open-iscsi package shouldn't have any
difference in regard to the init system.

While I don't test with sysvinit any more, I don't recollect dropping
support for it. So if there's any specific issue, we could try to
resolve it.

> The reason behind reporting this different behavior of "apt-get
> install open-iscsi"
> is that it let autopkgtest of src:tgt always fail on the qemu testbed
> when /sbin/init==systemd-sysv.

I really don't know the behavior yet. The autopkgtest thing is not
something I'm versed with but nevertheless if there's a problem with
the actual package, it'd be nice to fix it.

So can you please point me to what the actual problem with the package
is, when run on a system with sysvinit-core being active ?


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#983870: ITP: webdriver-manager - Webdriver Manager for Python

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist

* Package name: webdriver-manager
  Upstream Author : Sergey Pirogov
* URL : https://pypi.org/project/webdriver-manager/
* License : Apache-2.0
  Programming Lang: Python
  Description : Webdriver Manager for Python

Binary package names: python3-webdriver-manager

 The Webdriver Manager for Python simplifies management of binary drivers
 for different browsers.  It supports ChromeDriver, GeckoDriver,
 IEDriver, OperaDriver and EdgeChromiumDriver.  It is used by calling
 "from selenium import webdriver" from your Python code.

I'm planning to work on the webdriver-manager packaging using
python-team's git at Salsa, at
https://salsa.debian.org/python-team/packages/webdriver-manager .

Bye,

Joost

-- 
Joost van Baal-Ilić   http://abramowitz.uvt.nl/
 Tilburg University
mailto:joostvb.uvt.nl   The Netherlands


signature.asc
Description: PGP signature

Bug#983379: linux uml segfault

[Ritesh Raj Sarraf]

On Tue, 2021-03-02 at 11:34 +, Anton Ivanov wrote:
> If gdb gives you the exact lines, that may be helpful.

It doesn't. But it does show drawbacks in my packaging. The debug
symbols packaged are not read/honored by gdb at all.

```
Reading symbols from /usr/bin/linux.uml...
Reading symbols from /usr/lib/debug/.build-
id/6f/ea141539149074c72e80fb8004de124fda115b.debug...
(No debugging symbols found in /usr/lib/debug/.build-
id/6f/ea141539149074c72e80fb8004de124fda115b.debug)

warning: Can't open file /dev/shm/#20817 (deleted) during file-backed
mapping note processing
[New LWP 18788]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-
gnu/libthread_db.so.1".
Core was generated by `linux ubd0=qemu-linux-image.img'.
Program terminated with signal SIGABRT, Aborted.
#0  0x7f51842c0087 in kill () at ../sysdeps/unix/syscall-
template.S:120
120 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x7f51842c0087 in kill () at ../sysdeps/unix/syscall-
template.S:120
#1  0x6049dc20 in uml_abort ()
#2  0x6049de7a in os_dump_core ()
#3  0x60486e47 in panic_exit ()
#4  0x604c0a03 in notifier_call_chain ()
#5  0x604c0a98 in atomic_notifier_call_chain ()
#6  0x60a26b85 in panic ()
#7  0x604869e1 in segv ()
#8  0x60486ba9 in segv_handler ()
#9  0x6049ccc0 in sig_handler_common ()
#10 0x6049d1ec in sig_handler ()
#11 0x6049cdc6 in hard_handler ()
#12 
#13 0x604d45b4 in vprintk_store ()
#14 0x604d4aa8 in vprintk_emit ()
#15 0x604d4d86 in vprintk_deferred ()
#16 0x60a27a02 in printk_deferred ()
#17 0x609031b2 in get_random_u32 ()
#18 0x6088ff65 in bucket_table_alloc.isra ()
#19 0x60890740 in rhashtable_init ()
#20 0x607efaa2 in ipc_init_ids ()
#21 0x600153c9 in sem_init ()
```

So the best I can extract for you is to compile the kernel with as much
information as possible.

Thanks,
Ritesh

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'

[Thorsten Glaser]

Package: libvirt-daemon
Version: 7.0.0-2
Severity: important
X-Debbugs-Cc: t...@mirbsd.de

After an upgrade+reboot I cannot start VMs *again* with some cgroup error:

$ wirrsh start Netboot  
  
error: Failed to start domain 'Netboot'
error: internal error: failed to get cgroup backend for 'pathOfController'

To unconfuse:

$ alias wirrsh
wirrsh='virsh -c qemu:///system'

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libvirt-daemon depends on:
ii  libblkid1   2.36.1-7
ii  libc6   2.31-9
ii  libdevmapper1.02.1  2:1.02.175-2.1
ii  libgcc-s1   10.2.1-6
ii  libglib2.0-02.66.7-1
ii  libnetcf1   1:0.2.8-1.1
ii  libparted2  3.4-1
ii  libpcap0.8  1.10.0-2
ii  libpciaccess0   0.16-1
ii  libselinux1 3.1-3
ii  libudev1247.3-1
ii  libvirt-daemon-driver-qemu  7.0.0-2
ii  libvirt07.0.0-2
ii  libxml2 2.9.10+dfsg-6.3+b1

Versions of packages libvirt-daemon recommends:
pn  libvirt-daemon-driver-lxc   
pn  libvirt-daemon-driver-vbox  
pn  libvirt-daemon-driver-xen   
ii  libxml2-utils   2.9.10+dfsg-6.3+b1
ii  netcat-openbsd  1.217-3
ii  qemu-system 1:5.2+dfsg-6

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-iscsi-direct  
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   7.0.0-2
pn  numad   

-- no debconf information

Bug#983842: ITP: srcode -- Tool that help developers to manage their codebase in an effective & productive way.

[Colin Watson]

On Tue, Mar 02, 2021 at 08:55:58AM +0100, Alois Micard wrote:
> * Package name: srcode
>   Version : 0.7.2-1
>   Upstream Author : Aloïs Micard
> * URL : https://github.com/creekorful/srcode
> * License : GPL-3.0
>   Programming Lang: Go
>   Description : Tool that help developers to manage their codebase in an 
> effective & productive way.
> 
>  srcode is a tool that help developers to manage their codebase in an 
> effective
>  & productive way.

I can think of a lot of different ways in which I might manage codebases
more effectively, but I expect this doesn't do all of them; for example,
it looks as though it's more about managing multiple repositories rather
than being something like a refactoring tool or a code indexing tool.
Would it be possible to be a bit more specific in the package
description, perhaps with an example or two to give a general idea of
the sort of thing that this tool does?

If I'm correct that this is mainly for managing multiple repositories,
it would also be a good idea to consider the existing "myrepos" package,
and how this differs from it: why might somebody use one or the other?

(I don't know whether I'm in your target audience or not; this just
caught my eye as I was reading -devel.)

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#953328: sddm: No login prompt on tty1

[Fab Stz]

Hello,

I confirm this is still present in latest bullseye having sddm version 
0.19.0-2 (amd64)

Maybe this is somehow linked to https://github.com/systemd/systemd/issues/
12345 ?

Is that actually a sddm or a systemd bug ?

Regards


On Sat, 07 Mar 2020 20:55:57 + Andy Wood  wrote:
> Package: sddm
> Version: 0.18.1-1
> Severity: important
> Tags: patch
> 
> Dear Maintainer,
> 
> * What led up to the situation?
> Installed version 0.18.1-1 as provided in bullseye [reboot]
> 
> * What was the outcome of this action?
> No login prompt on tty1 [but it is present on other tty's]
> 
> * What outcome did you expect instead?
> Normal login prompt on tty1
> 
> This seems to be caused by entries in /lib/systemd/system/sddm.service
> 
> Changing:
>Conflicts=getty@tty1.service getty@tty7.service
>After=getty@tty1.service getty@tty7.service
> 
> back to [as per the previous version]:
>Conflicts=getty@tty7.service
>After=getty@tty7.service
> 
> fixes the problem.
> 
> Andy.
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (300, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages sddm depends on:
> ii  adduser   3.118
> ii  debconf [debconf-2.0] 1.5.73
> ii  libc6 2.29-10
> ii  libgcc-s1 10-20200222-1
> ii  libpam0g  1.3.1-5
> ii  libqt5core5a  5.12.5+dfsg-9
> ii  libqt5dbus5   5.12.5+dfsg-9
> ii  libqt5gui55.12.5+dfsg-9
> ii  libqt5network55.12.5+dfsg-9
> ii  libqt5qml55.12.5-5
> ii  libqt5quick5  5.12.5-5
> ii  libstdc++610-20200222-1
> ii  libsystemd0   244.3-1
> ii  libxcb-xkb1   1.13.1-5
> ii  libxcb1   1.13.1-5
> ii  qml-module-qtquick2   5.12.5-5

Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'

[Thorsten Glaser]

Dixi quod…

> After an upgrade+reboot I cannot start VMs *again* with some cgroup error:
> 
> $ wirrsh start Netboot
> 
> error: Failed to start domain 'Netboot'
> error: internal error: failed to get cgroup backend for 'pathOfController'

Matching log entry:

2021-03-02 14:33:48.839+: 3883: error : virCgroupSetValueRaw:502 : Unable 
to write to 
'/sys/fs/cgroup/machine/qemu-3-Netboot.libvirt-qemu/vcpu0/cgroup.threads': 
Operation not supported
2021-03-02 14:33:48.839+: 3883: error : virCgroupPathOfController:1395 : 
internal error: failed to get cgroup backend for 'pathOfController'

Things are mounted and set up, though:

tglase@tglase:~ $ ll /sys/fs/cgroup/machine
total 0
-r--r--r-- 1 root root 0  2. Mär 15:41 cgroup.controllers
-r--r--r-- 1 root root 0  2. Mär 15:41 cgroup.events
-rw-r--r-- 1 root root 0  2. Mär 15:41 cgroup.freeze
-rw-r--r-- 1 root root 0  2. Mär 15:41 cgroup.max.depth
-rw-r--r-- 1 root root 0  2. Mär 15:41 cgroup.max.descendants
-rw-r--r-- 1 root root 0  2. Mär 15:41 cgroup.procs
-r--r--r-- 1 root root 0  2. Mär 15:41 cgroup.stat
-rw-r--r-- 1 root root 0  2. Mär 15:39 cgroup.subtree_control
-rw-r--r-- 1 root root 0  2. Mär 15:41 cgroup.threads
-rw-r--r-- 1 root root 0  2. Mär 15:41 cgroup.type
-rw-r--r-- 1 root root 0  2. Mär 15:41 cpu.max
-rw-r--r-- 1 root root 0  2. Mär 15:41 cpu.pressure
-r--r--r-- 1 root root 0  2. Mär 15:41 cpu.stat
-rw-r--r-- 1 root root 0  2. Mär 15:41 cpu.weight
-rw-r--r-- 1 root root 0  2. Mär 15:41 cpu.weight.nice
-rw-r--r-- 1 root root 0  2. Mär 15:41 cpuset.cpus
-r--r--r-- 1 root root 0  2. Mär 15:41 cpuset.cpus.effective
-rw-r--r-- 1 root root 0  2. Mär 15:41 cpuset.cpus.partition
-rw-r--r-- 1 root root 0  2. Mär 15:41 cpuset.mems
-r--r--r-- 1 root root 0  2. Mär 15:41 cpuset.mems.effective
-rw-r--r-- 1 root root 0  2. Mär 15:41 io.max
-rw-r--r-- 1 root root 0  2. Mär 15:41 io.pressure
-r--r--r-- 1 root root 0  2. Mär 15:41 io.stat
-rw-r--r-- 1 root root 0  2. Mär 15:41 io.weight
-r--r--r-- 1 root root 0  2. Mär 15:41 memory.current
-r--r--r-- 1 root root 0  2. Mär 15:41 memory.events
-r--r--r-- 1 root root 0  2. Mär 15:41 memory.events.local
-rw-r--r-- 1 root root 0  2. Mär 15:41 memory.high
-rw-r--r-- 1 root root 0  2. Mär 15:41 memory.low
-rw-r--r-- 1 root root 0  2. Mär 15:41 memory.max
-rw-r--r-- 1 root root 0  2. Mär 15:41 memory.min
-r--r--r-- 1 root root 0  2. Mär 15:41 memory.numa_stat
-rw-r--r-- 1 root root 0  2. Mär 15:41 memory.oom.group
-rw-r--r-- 1 root root 0  2. Mär 15:41 memory.pressure
-r--r--r-- 1 root root 0  2. Mär 15:41 memory.stat
-r--r--r-- 1 root root 0  2. Mär 15:41 memory.swap.current
-r--r--r-- 1 root root 0  2. Mär 15:41 memory.swap.events
-rw-r--r-- 1 root root 0  2. Mär 15:41 memory.swap.high
-rw-r--r-- 1 root root 0  2. Mär 15:41 memory.swap.max
tglase@tglase:~ $ mount | fgrep cgroup  

 
cgroup2 on /sys/fs/cgroup type cgroup2 
(rw,nosuid,nodev,noexec,relatime,nsdelegate)

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

*

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*

Bug#983868: gsequencer ftbfs with -Werror=maybe-uninitialized

[Joël Krähemann]

Hi,

This is not a GSequencer bug!

This behavior is wanted.

delta_time was properly initialized in ags_midi_buffer_util_seek_message().

it would be wrong if delta_time was overridden by
ags_midi_buffer_util_get_varlength().
it does only return 0 length so varlength shall not be set.

If you output 0 length, this means you can't use return location, so why
should I set it?

regards,
Joël

On Tue, Mar 2, 2021 at 1:45 PM Matthias Klose  wrote:
>
> Package: src:gsequencer
> Version: 3.7.38-1
> Severity: important
> Tags: sid bullseye
> X-Debbugs-CC: Joël Krähemann 
>
> gsequencer ftbfs with -Werror=maybe-uninitialized, with gcc-10 and gcc-11 from
> experimental.
>
> ags/audio/midi/ags_midi_buffer_util.c:2606:17: error: ‘current_delta_time’ may
> be used uninitialized in this function [-Werror=maybe-uninitialized]
>  2606 | *delta_time = current_delta_time;
>   | ^~~~
> cc1: some warnings being treated as errors
>
> You don't see the error in a build log, because the libtool output is 
> redirected
> to /dev/null.
>
> Forwarded to https://gcc.gnu.org/PR99340
>
> The warning is only seen with -fPIE, not -fPIC, which is a bug in GCC.
>
> The warning itself is correct, ags_midi_buffer_util_get_varlength doesn't 
> always
> return a value in varlength.

Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'

[Thorsten Glaser]

notfound 983871 6.9.0-4
thanks

> Package: libvirt-daemon
> Version: 7.0.0-2

> After an upgrade+reboot I cannot start VMs *again* with some cgroup error:

Downgrading the entire bunch of involved packages fixes this:

tglase@tglase:~/a $ sudo apt-get install $PWD/*.deb
Reading package lists... 0%Reading package lists... 0%Reading package lists... 
7%Reading package lists... 7%Reading package lists... 7%Reading package 
lists... 8%Reading package lists... 8%Reading package lists... 9%Reading 
package lists... 9%Reading package lists... 21%Reading package lists... 
21%Reading package lists... 22%Reading package lists... 22%Reading package 
lists... 25%Reading package lists... 25%Reading package lists... 32%Reading 
package lists... 32%Reading package lists... 96%Reading package lists... 
96%Reading package lists... Done
Building dependency tree... 0%Building dependency tree... 0%Building dependency 
tree... 50%Building dependency tree... 50%Building dependency tree... 
96%Building dependency tree... Done
Reading state information... 0% Reading state information... 0%Reading state 
information... Done
Note, selecting 'libvirt-clients' instead of 
'/home/tglase/a/libvirt-clients_6.9.0-4_x32.deb'
Note, selecting 'libvirt-daemon-config-network' instead of 
'/home/tglase/a/libvirt-daemon-config-network_6.9.0-4_all.deb'
Note, selecting 'libvirt-daemon-config-nwfilter' instead of 
'/home/tglase/a/libvirt-daemon-config-nwfilter_6.9.0-4_all.deb'
Note, selecting 'libvirt-daemon-driver-qemu' instead of 
'/home/tglase/a/libvirt-daemon-driver-qemu_6.9.0-4_x32.deb'
Note, selecting 'libvirt-daemon-system-sysv' instead of 
'/home/tglase/a/libvirt-daemon-system-sysv_6.9.0-4_all.deb'
Note, selecting 'libvirt-daemon-system' instead of 
'/home/tglase/a/libvirt-daemon-system_6.9.0-4_x32.deb'
Note, selecting 'libvirt-daemon' instead of 
'/home/tglase/a/libvirt-daemon_6.9.0-4_x32.deb'
Note, selecting 'libvirt0' instead of '/home/tglase/a/libvirt0_6.9.0-4_x32.deb'
Note, selecting 'python3-libvirt' instead of 
'/home/tglase/a/python3-libvirt_6.1.0-1+b3_x32.deb'
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
Suggested packages:
  libvirt-daemon-driver-storage-gluster 
libvirt-daemon-driver-storage-iscsi-direct
  libvirt-daemon-driver-storage-rbd libvirt-daemon-driver-storage-zfs numad 
apparmor auditd nfs-common
  open-iscsi radvd systemd systemtap zfsutils
Recommended packages:
  libvirt-login-shell libvirt-daemon-driver-lxc libvirt-daemon-driver-vbox 
libvirt-daemon-driver-xen
  dnsmasq-base mdevctl
The following packages will be DOWNGRADED:
  libvirt-clients libvirt-daemon libvirt-daemon-config-network 
libvirt-daemon-config-nwfilter
  libvirt-daemon-driver-qemu libvirt-daemon-system libvirt-daemon-system-sysv 
libvirt0 python3-libvirt
0 upgraded, 0 newly installed, 9 downgraded, 0 to remove and 7 not upgraded.
Need to get 0 B/6184 kB of archives.
After this operation, 178 kB disk space will be freed.
Do you want to continue? [Y/n] 
0% [Working]Get:1 /home/tglase/a/python3-libvirt_6.1.0-1+b3_x32.deb 
python3-libvirt x32 6.1.0-1+b3 [223 kB]
0% [1 python3-libvirt 0 B/223 kB 0%]5% 
[Working]Get:2 
/home/tglase/a/libvirt-daemon-driver-qemu_6.9.0-4_x32.deb 
libvirt-daemon-driver-qemu x32 6.9.0-4 [751 kB]
17% [Working] Get:3 /home/tglase/a/libvirt0_6.9.0-4_x32.deb 
libvirt0 x32 6.9.0-4 [3930 kB]
70% [Working] Get:4 
/home/tglase/a/libvirt-daemon-system-sysv_6.9.0-4_all.deb 
libvirt-daemon-system-sysv all 6.9.0-4 [110 kB]
74% [Working] Get:5 
/home/tglase/a/libvirt-daemon-config-nwfilter_6.9.0-4_all.deb 
libvirt-daemon-config-nwfilter all 6.9.0-4 [56.7 kB]
77% [Working] Get:6 
/home/tglase/a/libvirt-daemon-config-network_6.9.0-4_all.deb 
libvirt-daemon-config-network all 6.9.0-4 [54.5 kB]
80% [Working] Get:7 
/home/tglase/a/libvirt-daemon-system_6.9.0-4_x32.deb libvirt-daemon-system x32 
6.9.0-4 [145 kB]
84% [Working] Get:8 /home/tglase/a/libvirt-daemon_6.9.0-4_x32.deb 
libvirt-daemon x32 6.9.0-4 [470 kB]
92% [Working] Get:9 /home/tglase/a/libvirt-clients_6.9.0-4_x32.deb 
libvirt-clients x32 6.9.0-4 [446 kB]
100% [Working]  [master 5224eb6] saving uncommitted changes in /etc 
prior to apt run
 Author: mirabilos 
 6 files changed, 117 insertions(+), 20 deletions(-)
 create mode 100644 libvirt/qemu/ci-busyapps.xml
Preconfiguring packages ...
dpkg: warning: downgrading python3-libvirt from 7.0.0-2 to 6.1.0-1+b3
(Reading database ... (Reading database ... 5%(Reading database ... 10%(Reading 
database ... 15%(Reading database ... 20%(Reading database ... 25%(Reading 
database ... 30%(Reading database ... 35%(Reading database ... 40%(Reading 
database ... 45%(Reading database ... 50%(Reading database ... 55%(Reading 
database ... 60%(Reading database ... 65%(Reading database ... 70%(Reading 
database ... 75%(Reading database ... 80%

Bug#923998: openvpn: Openvpn tun0 loses IP and route

[Sebastian Schrader]

Hi,

On Freitag, 8. März 2019 05:30:38 CET Stefan Monnier wrote:
> My OpenVPN client setup just stopped working, maybe/likely linked to a recent
> update of Debian (testing).
> 
> The end result is that the openvpn daemon looks happy and gives me the right
> syslog messages, yet the interface gets no IP address (and no routes either, 
> of
> course):

One of our VPN users encountered the same issue on Ubuntu 20.04, which lead
us to investigate this. The cause of this issue is netscript-2.4[1], a rather
old and obscure alternative ifup/ifdown implementation. In its default 
configuration a netscript systemd service instance is automatically started
shortly after the OpenVPN tunnel interface is created:

> Jan 25 11:12:41 ceviche systemd[1]: Started Netscript ifup for tun0.
> [...]
> Jan 25 11:12:41 ceviche sh[9617]: Configuring interface: tun0.

netscript then overwrites/removes the interface configuration set by OpenVPN,
which in turn removes the routes.

We did not investigate further, how to configure netscript-2.4 correctly, as
the user replaced it with ifupdown, which is what they wanted in the first
place anyway.

HTH
Best regards
Sebastian Schrader

Bug#983645: laminard: SIGPIPE kills it

[Jan-Benedict Glaw]

Hi!

On Tue, 2021-03-02 14:01:13 +0100, meskio  wrote:
> Quoting Jan-Benedict Glaw (2021-02-27 23:31:57)
> > I gave laminar a try, but laminard dies on SIGPIPE:
[...]
> From that report I guess you use sysv-init instead of systemd isn't it? Maybe 
> the SIGPIPE error is also related to that. I have to say I didn't test it on 
> any 
> other setup than systemd. I don't have at hand a sysv-init system, I'll try 
> to 
> setup one.
> 
> If you are able to test your laminar with systemd tell me if your problem 
> persist there.

So by now, I'm quite convinced that you don't "see" these errors
because systemd just restarts laminard. Just started to pull the
Debian source and the upstream and realized that the Debian package is
nearly about the same as GIT master.  That's great news!  Thanks for
providing a really up-to-date package! :)

MfG, JBG

-- 


signature.asc
Description: PGP signature

Bug#983335: sdbus-cpp: support Multiarch and nodoc/nocheck build profiles/options

[Luca Boccassi]

On Mon, 2021-02-22 at 20:05 +, Luca Boccassi wrote:
> On Tue, 2021-02-23 at 01:52 +0800, Shengjing Zhu wrote:
> > On Mon, Feb 22, 2021 at 05:44:16PM +, Luca Boccassi wrote:
> > > > I have verified with `sbuild --profiles=nodoc --no-arch-all`.
> > > > Is there anything I miss?
> > > 
> > > I was testing in a pbuilder chroot, and without doxygen installed
> > > "DEB_BUILD_OPTIONS=nodoc DEB_BUILD_PROFILES=nodoc dpkg-buildpackage"
> > > would fail at the arch-dependent configure.
> > > 
> > 
> > Could you try `dpkg-buildpackage --build-profiles=nodoc`?
> > 
> > At least I can't find a way to run this command.
> > Whenever I pass DEB_BUILD_PROFILES=nodoc to sbuild, or --profiles=nodoc,
> > the actual dpkg-buildpackage command becomes:
> > 
> > dpkg-buildpackage --sanitize-env -Pnodoc -us -uc -G -rfakeroot
> 
> Ok, that works - interesting.
> 
> Attached patch to make the -bin package Multiarch: allowed, verified in
> a chroot that libsdbus-c++-dev:i386 can be installed with libsdbus-c++-
> bin:amd64. Would be great to have this in Buster, so that multiarch
> works.

Gentle ping - the current version has migrated to testing. Any chance
for a new upload with these fixes so that they have time to make it
into bullseye?

Thank you!

-- 
Kind regards,
Luca Boccassi


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

Bug#983842: ITP: srcode -- Tool that help developers to manage their codebase in an effective & productive way.

[Aloïs Micard]

Hello,


I can think of a lot of different ways in which I might manage codebases
more effectively, but I expect this doesn't do all of them; for example,
it looks as though it's more about managing multiple repositories rather
than being something like a refactoring tool or a code indexing tool.
Would it be possible to be a bit more specific in the package
description, perhaps with an example or two to give a general idea of
the sort of thing that this tool does?


Thanks for your feedback. I agree that the description lacks of clarity,
I'll take care of that in the package description & will update that
upstream in the same way.

TBH I'm really struggling to explain what this tool do, I like the
idea of using examples to describe the functionalities, so I'll give
a try, thank you!



If I'm correct that this is mainly for managing multiple repositories,
it would also be a good idea to consider the existing "myrepos" package,
and how this differs from it: why might somebody use one or the other?

(I don't know whether I'm in your target audience or not; this just
caught my eye as I was reading -devel.)



I'll take a deeper look at myrepos & see how they differs,
thanks for the pointer.

Cheers,

--
Aloïs Micard (creekorful) 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#983872: xrdp: again (still?) writes internal messages to the console during startup

[Thorsten Glaser]

Package: xrdp
Version: 0.9.15-1
Severity: minor
X-Debbugs-Cc: t...@mirbsd.de

$ sudo cleanenv / /etc/init.d/xrdp start
Starting Remote Desktop Protocol server: xrdp-sesmanlogging configuration:
LogFile:   /var/log/xrdp-sesman.log
LogLevel:  [INFO ]
ConsoleLevel:  
SyslogLevel:   [INFO ]
 xrdp.



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

Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages xrdp depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libc62.31-9
ii  libfuse2 2.9.9-5
ii  libjpeg62-turbo  1:2.0.6-2
ii  libopus0 1.3.1-0.1
ii  libpam0g 1.4.0-6
ii  libssl1.11.1.1j-1
ii  libx11-6 2:1.7.0-2
ii  libxfixes3   1:5.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  lsb-base 11.1.0
ii  ssl-cert 1.1.0

Versions of packages xrdp recommends:
ii  fuse3 [fuse]  3.10.2-2
ii  xorgxrdp  1:0.2.15-1

Versions of packages xrdp suggests:
pn  guacamole  

Versions of packages xorgxrdp depends on:
ii  libc6  2.31-9
ii  libepoxy0  1.5.5-1
pn  xorg-input-abi-24  
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.10-3

Versions of packages xorgxrdp recommends:
ii  xorg  1:7.7+22

Versions of packages xrdp is related to:
ii  tigervnc-standalone-server [vnc-server]  1.11.0+dfsg-1
ii  xserver-xorg-legacy  2:1.20.10-3

-- no debconf information

Bug#983873: retroarch: Menu freezes shortly after start

[Pelle]

Package: retroarch
Version: 1.7.3+dfsg1-1.1+b2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When launching RetroArch, the menu freezes up instantly or after a couple of
seconds.

A work-around is to change the settings in .config/retroarch/retroarch.cfg
menu_driver = "rgui"
video_driver = "sdl2"

The issue appears to be resolved in v1.9.0 which is the version currently
available as flatpak.

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 retroarch depends on:
ii  fonts-dejavu-core 2.37-2
ii  libasound21.2.4-1.1
ii  libavcodec58  7:4.3.2-0+deb11u1
ii  libavformat58 7:4.3.2-0+deb11u1
ii  libavutil56   7:4.3.2-0+deb11u1
ii  libc6 2.31-9
ii  libdrm2   2.4.104-1
ii  libegl1   1.3.2-1
ii  libfreetype6  2.10.4+dfsg-1
ii  libgbm1   20.3.4-1
ii  libgcc-s1 10.2.1-6
ii  libgl11.3.2-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.17~dfsg-1
ii  libminiupnpc172.2.1-1
ii  libopenal11:1.19.1-2
ii  libpulse0 14.2-2
ii  libqt5core5a  5.15.2+dfsg-5
ii  libqt5gui55.15.2+dfsg-5
ii  libqt5widgets55.15.2+dfsg-5
ii  libretro-core-info1.3.6+git20160816-1
ii  libsdl2-2.0-0 2.0.14+dfsg2-3
ii  libstdc++610.2.1-6
ii  libswresample37:4.3.2-0+deb11u1
ii  libswscale5   7:4.3.2-0+deb11u1
ii  libudev1  247.3-1
ii  libusb-1.0-0  2:1.0.24-2
ii  libv4l-0  1.20.0-2
ii  libwayland-client01.18.0-2~exp1.1
ii  libwayland-cursor01.18.0-2~exp1.1
ii  libwayland-egl1   1.18.0-2~exp1.1
ii  libx11-6  2:1.7.0-2
ii  libxext6  2:1.3.3-1.1
ii  libxinerama1  2:1.1.4-2
ii  libxkbcommon0 1.0.3-2
ii  libxv12:1.0.11-1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  retroarch-assets  1.3.6+git20160731+dfsg1-2
ii  zlib1g1:1.2.11.dfsg-2

retroarch recommends no packages.

retroarch suggests no packages.

Bug#981699: thinkfan: fails on upgrade

[Thorsten Glaser]

Package: thinkfan
Version: 1.2.1-3
Followup-For: Bug #981699
X-Debbugs-Cc: t...@mirbsd.de
Control: reopen 981699
Control: severity 981699 serious

Unfortunately, thinkfan still fails to work:

tglase@tglase-nb:~ $ sudo cleanenv / /etc/init.d/thinkfan stop
Stopping fan control tool: thinkfan.
tglase@tglase-nb:~ $ sudo cleanenv / /etc/init.d/thinkfan start
Starting fan control tool: thinkfan
ERROR: Error scanning /sys/devices/pci:00/:00:03.1/:27:00.0/hwmon: 
No such file or directory
 failed!

There’s no thinkfan binary running now.

(I’ve not yet touched its new configuration, as it’s not even working.)


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

Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages thinkfan depends on:
ii  init-system-helpers  1.60
ii  libatasmart4 0.19-5
ii  libc62.31-9
ii  libgcc-s110.2.1-6
ii  libstdc++6   10.2.1-6
ii  libyaml-cpp0.6   0.6.3-9

thinkfan recommends no packages.

thinkfan suggests no packages.

-- Configuration Files:
/etc/default/thinkfan changed:
START=yes
DAEMON_ARGS="-q"

/etc/thinkfan.conf changed:
(0, 0, 58)
(1, 47, 60)
(2, 55, 66)
(5, 60, 77)
(7, 70, 32767)


-- no debconf information

Bug#923560: newer release (0.4.0) is available for 2 years by now

[Emmanuel Arias]

Hi Yaroslav, 

citeproc-py is on 0.5.1 version on testing

So, we can mark as done this bug?

Cheers, 
Emmanuel

Bug#923998: openvpn: Openvpn tun0 loses IP and route

[Stefan Monnier]

> One of our VPN users encountered the same issue on Ubuntu 20.04, which lead
> us to investigate this. The cause of this issue is netscript-2.4[1], a rather
> old and obscure alternative ifup/ifdown implementation. In its default 
> configuration a netscript systemd service instance is automatically started
> shortly after the OpenVPN tunnel interface is created:

Indeed, I also discovered that the problem disappeared when I removed
the `netscript` package (not sure why it was installed).
Thanks,


Stefan

Bug#983007: tqdm breaks backblaze-b2 autopkgtest: The wheel package is not available.

[Sebastian Ramacher]

Control: notfound -1 backblaze-b2/1.3.8-4
Control: retitle -1 tqdm: tqdm's egg-info has its version set to 0.0.0

(I hope the notfound is enough and no reassign is necessary.)

On 2021-02-18 07:21:30 +0100, Paul Gevers wrote:
> Source: tqdm, backblaze-b2
> Control: found -1 tqdm/4.56.2-1
> Control: found -1 backblaze-b2/1.3.8-4
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainer(s),
> 
> With a recent upload of tqdm the autopkgtest of backblaze-b2 fails in
> testing when that autopkgtest is run with the binary packages of tqdm
> from unstable. It passes when run with only packages from testing. In
> tabular form:
> 
>passfail
> tqdm   from testing4.56.2-1
> backblaze-b2   from testing1.3.8-4
> all others from testingfrom testing

This is a bug in tqdm and is caused by
debian/patches/dont-use-setuptools-scm.patch (as far as I can tell). The
issue is that tqdm's egg-info has the version set to 0.0.0, so
backblaze-b2, which requires tqdm >= 4.5.0, is unable to satisfy the
dependency.

Please update the patch to set the correct version.

Cheers

> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration of tqdm to testing
> [1]. Due to the nature of this issue, I filed this bug report against
> both packages. Can you please investigate the situation and reassign the
> bug to the right package?
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=tqdm
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/b/backblaze-b2/10523984/log.gz
> 
> [*] testing on python3.9:
> running nosetests
> running egg_info
> creating b2.egg-info
> writing b2.egg-info/PKG-INFO
> writing dependency_links to b2.egg-info/dependency_links.txt
> writing entry points to b2.egg-info/entry_points.txt
> writing requirements to b2.egg-info/requires.txt
> writing top-level names to b2.egg-info/top_level.txt
> writing manifest file 'b2.egg-info/SOURCES.txt'
> reading manifest file 'b2.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> writing manifest file 'b2.egg-info/SOURCES.txt'
> WARNING: The wheel package is not available.
> /usr/bin/python3.9: No module named pip
> error: Command '['/usr/bin/python3.9', '-m', 'pip',
> '--disable-pip-version-check', 'wheel', '--no-deps', '-w',
> '/tmp/tmp7u77k0jh', '--quiet', 'tqdm>=4.5.0']' returned non-zero exit
> status 1.
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#983007: tqdm breaks backblaze-b2 autopkgtest: The wheel package is not available.

[Sebastian Ramacher]

Control: reassign -1 src:tqdm 4.56.2-1

On 2021-03-02 16:21:14 +0100, Sebastian Ramacher wrote:
> Control: notfound -1 backblaze-b2/1.3.8-4
> Control: retitle -1 tqdm: tqdm's egg-info has its version set to 0.0.0
> 
> (I hope the notfound is enough and no reassign is necessary.)

It wasn't, also reassigning.

Cheers

> 
> On 2021-02-18 07:21:30 +0100, Paul Gevers wrote:
> > Source: tqdm, backblaze-b2
> > Control: found -1 tqdm/4.56.2-1
> > Control: found -1 backblaze-b2/1.3.8-4
> > Severity: serious
> > Tags: sid bullseye
> > X-Debbugs-CC: debian...@lists.debian.org
> > User: debian...@lists.debian.org
> > Usertags: breaks needs-update
> > 
> > Dear maintainer(s),
> > 
> > With a recent upload of tqdm the autopkgtest of backblaze-b2 fails in
> > testing when that autopkgtest is run with the binary packages of tqdm
> > from unstable. It passes when run with only packages from testing. In
> > tabular form:
> > 
> >passfail
> > tqdm   from testing4.56.2-1
> > backblaze-b2   from testing1.3.8-4
> > all others from testingfrom testing
> 
> This is a bug in tqdm and is caused by
> debian/patches/dont-use-setuptools-scm.patch (as far as I can tell). The
> issue is that tqdm's egg-info has the version set to 0.0.0, so
> backblaze-b2, which requires tqdm >= 4.5.0, is unable to satisfy the
> dependency.
> 
> Please update the patch to set the correct version.
> 
> Cheers
> 
> > 
> > I copied some of the output at the bottom of this report.
> > 
> > Currently this regression is blocking the migration of tqdm to testing
> > [1]. Due to the nature of this issue, I filed this bug report against
> > both packages. Can you please investigate the situation and reassign the
> > bug to the right package?
> > 
> > More information about this bug and the reason for filing it can be found on
> > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> > 
> > Paul
> > 
> > [1] https://qa.debian.org/excuses.php?package=tqdm
> > 
> > https://ci.debian.net/data/autopkgtest/testing/amd64/b/backblaze-b2/10523984/log.gz
> > 
> > [*] testing on python3.9:
> > running nosetests
> > running egg_info
> > creating b2.egg-info
> > writing b2.egg-info/PKG-INFO
> > writing dependency_links to b2.egg-info/dependency_links.txt
> > writing entry points to b2.egg-info/entry_points.txt
> > writing requirements to b2.egg-info/requires.txt
> > writing top-level names to b2.egg-info/top_level.txt
> > writing manifest file 'b2.egg-info/SOURCES.txt'
> > reading manifest file 'b2.egg-info/SOURCES.txt'
> > reading manifest template 'MANIFEST.in'
> > writing manifest file 'b2.egg-info/SOURCES.txt'
> > WARNING: The wheel package is not available.
> > /usr/bin/python3.9: No module named pip
> > error: Command '['/usr/bin/python3.9', '-m', 'pip',
> > '--disable-pip-version-check', 'wheel', '--no-deps', '-w',
> > '/tmp/tmp7u77k0jh', '--quiet', 'tqdm>=4.5.0']' returned non-zero exit
> > status 1.
> -- 
> Sebastian Ramacher



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#983645: laminard: SIGPIPE kills it

[meskio]

Quoting Jan-Benedict Glaw (2021-03-02 14:44:33)
>   I do not think that SysV init has something to do with the SIGPIPE.
> It's probably being a close()d / shutdown()ed FD (at the browser side)
> while it tries to chunk-send data.
> 
>   However, with systemd you'd probably get a restart of laminard. You
> may observe a failed / missing run, but because daemon(1) won't do
> a restart, laminard dies for me without getting a recovery by restart.

At least on my case this is not the problem. I see the laminard hasn't being 
restarted in my server for the last 20 days, and I do run several jobs per day 
and some of them I do watch them while they play. But there might be something 
different on my setup.

> > If you are able to test your laminar with systemd tell me if your problem 
> > persist there.
> 
> I'll try to pin down in which circumstances this actually happens.

Good luck with it. If you don't find anything we can open an issue upstream, 
Oliver is pretty responsive and helpful.


-- 
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.

signature.asc
Description: signature

Bug#983861: k3b: Permissions of external program should be of group "cdrom" and not "operator"

[Fab Stz]

Package: k3b
Version: 20.12.2-1
Severity: normal
Tags: patch

Dear Maintainer,

With k3b, when wanting to set the external program permissions, it wants to 
set
them with user "operator" instead of "cdrom" which may be more adequate
according to the description of the groups in
https://wiki.debian.org/SystemGroups

- operator: Operator was (historically) the only 'user' account that could
login remotely.
- cdrom: This group can be used locally to give a set of users access to a
CDROM drive and other optical drives.

This will patch k3b to use "cdrom" instead.

BTW, in buster, permissions used to be set to "root.root". I don't know why
it's not the same since that piece of code didn't change.


-- Package-specific info:
Device was not specified. Trying to find an appropriate drive...
Detected CD-R drive: /dev/cdrw
Using /dev/cdrom of unknown capabilities
Device type: Removable CD-ROM
Version: 5
Response Format: 2
Capabilities   : 
Vendor_info: 'HL-DT-ST'
Identification : 'DVD+-RW GSA-H31L'
Revision   : 'W618'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE 
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R

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

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

Versions of packages k3b depends on:
ii  cdparanoia 3.10.2+debian-13.1
ii  cdrdao 1:1.2.4-2
ii  genisoimage9:1.1.11-3.2
ii  k3b-data   20.12.2-1
ii  kio5.78.0-4
ii  libc6  2.31-9
ii  libk3b720.12.2-1
ii  libkf5archive5 5.78.0-2
ii  libkf5authcore55.78.0-2
ii  libkf5bookmarks5   5.78.0-2
ii  libkf5cddb54:20.12.0-1
ii  libkf5completion5  5.78.0-3
ii  libkf5configcore5  5.78.0-4
ii  libkf5configwidgets5   5.78.0-2
ii  libkf5coreaddons5  5.78.0-2
ii  libkf5i18n55.78.0-2
ii  libkf5iconthemes5  5.78.0-2
ii  libkf5jobwidgets5  5.78.0-2
ii  libkf5kcmutils55.78.0-3
ii  libkf5kiocore5 5.78.0-4
ii  libkf5kiofilewidgets5  5.78.0-4
ii  libkf5kiowidgets5  5.78.0-4
ii  libkf5newstuff55.78.0-2
ii  libkf5notifications5   5.78.0-2
ii  libkf5notifyconfig55.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  libqt5core5a   5.15.2+dfsg-4
ii  libqt5dbus55.15.2+dfsg-4
ii  libqt5gui5 5.15.2+dfsg-4
ii  libqt5webkit5  5.212.0~alpha4-11
ii  libqt5widgets5 5.15.2+dfsg-4
ii  libqt5xml5 5.15.2+dfsg-4
ii  libstdc++6 10.2.1-6
ii  udisks22.9.2-1
ii  wodim  9:1.1.11-3.2

Versions of packages k3b recommends:
ii  dvd+rw-tools 7.1-14+b1
ii  growisofs7.1-14+b1
ii  libk3b7-extracodecs  20.12.2-1
ii  vcdimager2.0.1+dfsg-5

Versions of packages k3b suggests:
pn  k3b-extrathemes  
ii  k3b-i18n 20.12.2-1
ii  kde-config-cddb  4:20.12.0-1
pn  movixmaker-2 
ii  normalize-audio  0.7.7-16
ii  sox  14.4.2+git20190427-2

-- no debconf information
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 k3b (20.12.2-1.0~fab1) UNRELEASED; urgency=medium
 .
   * Personnal changelog entry 03/02/21 11:53:38
Author: Anonymous 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 2021-03-02

--- k3b-20.12.2.orig/src/option/k3bexternalbinwidget.cpp
+++ k3b-20.12.2/src/option/k3bexternalbinwidget.cpp
@@ -152,9 +152,7 @@ K3b::ExternalBinWidget::ExternalBinWidge
 
 while (::group *g = ::getgrent()) {
 const QString groupName = QString::fromLocal8Bit(g->gr_name);
-if (groupName == "cdrom" ||
-groupName == "optical" ||
-groupName == "operator" ) {
+if (groupName == "cdrom") {
 m_permissionModel->setBurningGroup(groupName);
 }
 }

Bug#983874: gitaly: fails to install: Could not find gem 'rugged (~> 0.28)'

[Andreas Beckmann]

Package: gitaly
Version: 13.4.6+dfsg1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up gitaly (13.4.6+dfsg1-2) ...
  [ESC][31mCould not find gem 'rugged (~> 0.28)' in any of the gem sources 
listed in your
  Gemfile.[ESC][0m
  dpkg: error processing package gitaly (--configure):
   installed gitaly package post-installation script subprocess returned error 
exit status 7
  Processing triggers for ca-certificates (20210119) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   gitaly


cheers,

Andreas


gitaly_13.4.6+dfsg1-2.log.gz
Description: application/gzip

Bug#983875: sphinx-argparse: KeyError: 'prog'

[Bas Couwenberg]

Source: sphinx-argparse
Version: 0.2.5-1
Severity: important
Tags: patch
Control: affects -1 src:python-pyproj

Dear Maintainer,

As reported in #982698, python-pyproj FTBFS due to sphinx failing:

 PYTHONPATH=/build/python-pyproj/.pybuild/cpython3_3.9_pyproj/build make -C 
/build/python-pyproj/docs man
 make[2]: Entering directory '/build/python-pyproj/docs'
 Running Sphinx v3.4.3
 making output directory... done
 building [mo]: targets for 0 po files that are out of date
 building [man]: all manpages
 updating environment: [new config] 33 added, 0 changed, 0 removed
 reading sources... [  3%] advanced_examples
 reading sources... [  6%] api/aoi
 reading sources... [  9%] api/crs/coordinate_operation
 reading sources... [ 12%] api/crs/coordinate_system
 reading sources... [ 15%] api/crs/crs
 reading sources... [ 18%] api/crs/datum
 reading sources... [ 21%] api/crs/enums
 reading sources... [ 24%] api/crs/index
 reading sources... [ 27%] api/database
 reading sources... [ 30%] api/datadir
 reading sources... [ 33%] api/enums
 reading sources... [ 36%] api/exceptions
 reading sources... [ 39%] api/geod
 reading sources... [ 42%] api/global_context
 reading sources... [ 45%] api/index
 reading sources... [ 48%] api/list
 reading sources... [ 51%] api/network
 reading sources... [ 54%] api/proj
 reading sources... [ 57%] api/show_versions
 reading sources... [ 60%] api/sync
 reading sources... [ 63%] api/transformer
 reading sources... [ 66%] build_crs
 reading sources... [ 69%] build_crs_cf
 reading sources... [ 72%] cli
 
 Exception occurred:
   File "/usr/lib/python3/dist-packages/sphinxarg/parser.py", line 40, in 
_try_add_parser_attribute
 data[attribname] = attribval % {'prog': data['prog']}
 KeyError: 'prog'
 The full traceback has been saved in /tmp/sphinx-err-c2bpk2op.log, if you want 
to report the issue to the developers.
 Please also report this if it was a user error, so that a better error message 
can be provided next time.
 A bug report can be filed in the tracker at 
. Thanks!

The content of /tmp/sphinx-err-c2bpk2op.log:

 # Sphinx version: 3.4.3
 # Python version: 3.9.2 (CPython)
 # Docutils version: 0.16 release
 # Jinja2 version: 2.11.3
 # Last messages:
 #   reading sources... [ 45%] api/index
 #   reading sources... [ 48%] api/list
 #   reading sources... [ 51%] api/network
 #   reading sources... [ 54%] api/proj
 #   reading sources... [ 57%] api/show_versions
 #   reading sources... [ 60%] api/sync
 #   reading sources... [ 63%] api/transformer
 #   reading sources... [ 66%] build_crs
 #   reading sources... [ 69%] build_crs_cf
 #   reading sources... [ 72%] cli
 # Loaded extensions:
 #   sphinx.ext.mathjax (3.4.3) from 
/usr/lib/python3/dist-packages/sphinx/ext/mathjax.py
 #   alabaster (0.7.8) from /usr/lib/python3/dist-packages/alabaster/__init__.py
 #   sphinx.ext.autodoc.type_comment (3.4.3) from 
/usr/lib/python3/dist-packages/sphinx/ext/autodoc/type_comment.py
 #   sphinx.ext.autodoc (3.4.3) from 
/usr/lib/python3/dist-packages/sphinx/ext/autodoc/__init__.py
 #   sphinx.ext.viewcode (3.4.3) from 
/usr/lib/python3/dist-packages/sphinx/ext/viewcode.py
 #   sphinx.ext.napoleon (3.4.3) from 
/usr/lib/python3/dist-packages/sphinx/ext/napoleon/__init__.py
 #   sphinx.ext.intersphinx (3.4.3) from 
/usr/lib/python3/dist-packages/sphinx/ext/intersphinx.py
 #   sphinxarg.ext (unknown version) from 
/usr/lib/python3/dist-packages/sphinxarg/ext.py
 Traceback (most recent call last):
   File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 280, in 
build_main
 app.build(args.force_all, filenames)
   File "/usr/lib/python3/dist-packages/sphinx/application.py", line 346, in 
build
 self.builder.build_update()
   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 293, 
in build_update
 self.build(['__all__'], to_build)
   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 310, 
in build
 updated_docnames = set(self.read())
   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 417, 
in read
 self._read_serial(docnames)
   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 438, 
in _read_serial
 self.read_doc(docname)
   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 478, 
in read_doc
 doctree = read_doc(self.app, self.env, self.env.doc2path(docname))
   File "/usr/lib/python3/dist-packages/sphinx/io.py", line 221, in read_doc
 pub.publish()
   File "/usr/lib/python3/dist-packages/docutils/core.py", line 217, in publish
 self.document = self.reader.read(self.source, self.parser,
   File "/usr/lib/python3/dist-packages/sphinx/io.py", line 126, in read
 self.parse()
   File "/usr/lib/python3/dist-packages/docutils/readers/__init__.py", line 77, 
in parse
 self.parser.parse(self.input, document)
   File "/usr/lib/python3/dist-packages/sphinx/parsers.py", line 104, in parse
 self.statem

Bug#983605: dicomscope: Files missing from distribution

[John Talbut]

Hi Andreas

This bug applies to the Debian Testing, Bullseye, distribution.  The
list of files link is at the bottom of the developer information page at
https://packages.debian.org/bullseye/dicomscope.

If I go the the same link for the stable distribution I get a list of files.

A file that is in the stable distribution that appears to be missing
when I try to install dicomscope is /usr/bin/dicomscope

~$ dicomscope
bash: /usr/bin/dicomscope: cannot execute binary file: Exec format error

~$ dpkg -L dicomscope
/.
/etc
/etc/dcmtk
/etc/dcmtk/DICOMscope.cfg
/usr
/usr/bin
/usr/share
/usr/share/dcmtk
/usr/share/dcmtk/codes.dic
/usr/share/dicomscope
/usr/share/dicomscope/codes.dic
/usr/share/dicomscope/lut
/usr/share/dicomscope/lut/darken256us.lut
/usr/share/dicomscope/lut/darken4096us.lut
/usr/share/dicomscope/lut/lighten256us.lut
/usr/share/dicomscope/lut/lighten4096us.lut
/usr/share/dicomscope/lut/linear256us.lut
/usr/share/dicomscope/lut/linear4096us.lut
/usr/share/dicomscope/lut/midtone256us.lut
/usr/share/dicomscope/lut/midtone4096us.lut
/usr/share/dicomscope/lut/philips256us.lut
/usr/share/dicomscope/lut/philips4096us.lut
/usr/share/dicomscope/reports
/usr/share/dicomscope/reports/reportki.dcm
/usr/share/dicomscope/reports/reportsi.dcm
/usr/share/dicomscope/tcl
/usr/share/dicomscope/tcl/dcmpschk.tcl
/usr/share/dicomscope/tcl/dcmpsdmp.tcl
/usr/share/doc
/usr/share/doc/dicomscope
/usr/share/doc/dicomscope/README.Debian
/usr/share/doc/dicomscope/changelog.Debian.gz
/usr/share/doc/dicomscope/copyright
/usr/share/java
/usr/share/java/DICOMscope-3.6.0.jar
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/dicomscope.1.gz
/usr/bin/dicomscope
/usr/share/java/DICOMscope.jar

Kind regards

John

Bug#983876: unblock: otrs2/6.0.32-1

[Patrick Matthäi]

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

Hello release team,

I try to citize from my mails to the security team:, it's about #982927:


Yesterday I had a videocall with the owner and lead developer of OTOBO. They
want to support me keeping the otrs2 source package in a good shape for
Bullseye, so that users of the package dont have to worry now.
Kicking the package out of Debian would not be optimal.
They also showed me https://github.com/znuny/Znuny (https://www.znuny.com/) - 
they
also forked OTRS CE 6 and fixing bugs and security bugs, also all known open 
bugs
in CVE/Debian atm. So the plan would be now:
* Switch the source of the otrs2 package to the znuny one, so that we have 
releases
  based on an open(source) maintained safe codebase => can I get the go from 
you for that?
* otrs packaging at all is obsolete for bullseye+1. I will package otobo, also 
with
  otobo support, and we will work on a easy way so that users later can migrate
  from otrs to otobo
We also spoke about the open security issues, there is indeed one in the 
CKEditor, but:
#980891:
They way otrs uses this library it should not be possible to attack the user, 
mostly only the attacker himself
#982586:
Thats a wrong information from the OTRS AG, because it does not affect otrs 6 
CE.
It depends on that you use an external interface, which is available in OTRS 7 
and 8
(not free) and maybe in the not-free otrs 6 package via addon, but not in the 
community edition, which is also packaged in Debian.

XX itself is not helpful at all anymore and just wrote me **
I hope switching as fast as possible to the znuny fork for the otrs2 source 
package is also an option for you, I dont want to release bullseye without it 


-

I just uploaded the otrs2 6.0.32 package to experimental.  Could I have your 
ACK for bullseye? :-)

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

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

Bug#777326: cuyo: please make the build reproducible

[Emmanuel Arias]

Hi Chris, 

Sorry for this delay. It will not happen again. New cuyo version seems
to be reproducible [0].

Do you consider necessary apply the patch right now? or we can mark as
done this bug.

[0] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/cuyo.html

Cheers, 
Emmanuel 

Bug#983877: aptly: Please backport upstream PR to store MD5 in a separate metadata field instead of ETag

[Andrej Shadura]

Package: src:aptly
Version: 1.4.0+ds1-2
Severity: normal
Control: found -1 1.3.0+ds1-2
Control: tags -1 upstream fixed-upstream
Control: forwarded -1 https://github.com/aptly-dev/aptly/issues/923

Hello,

A year ago I found an issue with aptly with S3 backend: it relies on
ETag always being the MD5 hashsum of a file, while it’s not necessarily
true, as demonstrated in the comments to 
https://github.com/minio/minio/pull/:

> The entity tag is a hash of the object. The ETag reflects changes only
> to the contents of an object, not its metadata. The ETag may or may not
> be an MD5 digest of the object data. Whether or not it depends on how
> the object was created and how it is encrypted as described below:
>
> Objects created by the PUT Object, POST Object, or Copy operation,
> or through the AWS Management Console, and are encrypted by SSE-S3 or
> plaintext, have ETags that are an MD5 digest of their object data.
>
> Objects created by the PUT Object, POST Object, or Copy operation,
> or through the AWS Management Console, and are encrypted by SSE-C or
> SSE-KMS, have ETags that are not an MD5 digest of their object data.
>
> If an object is created by either the Multipart Upload or Part Copy
> operation, the ETag is not an MD5 digest, regardless of the method
> of encryption.

I have proposed changes fixing this in a pull request that’s been merged
today. It’s quite self-contained and only affects the S3 backend. The
idea is to store the MD5 of an object in a separate metadata field as well
to make sure it isn’t lost, so when the value returned in ETag clearly
doesn’t look like a valid MD5 hash (length isn’t exactly 32 characters),
this metadata field is used instead.

See https://github.com/aptly-dev/aptly/pull/924 for more details.

Please consider applying these patches and shipping them in Bullseye.

Thanks!

-- 
Cheers,
  Andrej