Bug#959932: manpage incorrectly points to "info hey"

[Josh Triplett]

Package: hey
Version: 0.1.2-2
Severity: normal

The manpage for hey says:

SEE ALSO
   The  full  documentation for hey is maintained as a Texinfo manual.  If
   the info and hey programs are properly installed at your site, the com‐
   mand

  info hey

   should give you access to the complete manual.

But hey doesn't seem to ship info documentation; this looks like an
artifact from help2man or similar.

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hey depends on:
ii  libc6  2.30-7

hey recommends no packages.

hey suggests no packages.

-- no debconf information

Bug#937769: logfury

[Gordon Ball]

I just uploaded python-logfury dropping the funcsigs dependency, so
that's one step closer.

Bug#959843: gajim: Fails to start video sessions

[Bruno Kleinert]

Am Mittwoch, den 06.05.2020, 12:41 +0200 schrieb Martin:
> On 2020-05-06 06:16, Bruno Kleinert wrote:
> > gajim fails to start video sessions to contacts (Audio sessions work, 
> > though.).It displays a window with the following message when I attempt to 
> > start a videocall:
> 
> This seems to be solved already by 
> upstream:https://dev.gajim.org/gajim/gajim/-/issues/9832
> 
> Maybe you can try gajim from Debian experimental?You might like to backup 
> your configuration and data before that!I'm not sure, whether a downgrade 
> would work smoothly.
> Thank you!
> PS: For readers of this bug report, here is how to use experimental:
> $ echo deb "https:"//deb.debian.org/debian/ experimental main \  | sudo tee 
> /etc/apt/sources.list.d/experimental.list$ sudo apt update$ sudo apt install 
> -t experimental gajim gajim-omemo gajim-urlimagepreview

Hi Martin,

thanks for the reply! I tried with 1.1.99~20200429.65506e31-1 and that snapshot 
doesn't work either, but in another way. Still it looks promising because the 
error message does no longer show up! Since it's a development snapshot, I'm 
looking forward for a next stable release.

I can confirm that one really should backup her/his gajim configuration as the 
downgrade did not work smooth on my computer! I had a backup :)

Cheers,
Bruno





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

Bug#959934: pagure: Unneeded dependency on python3-funcsigs

[Gordon Ball]

Source: pagure
Severity: normal

Dear Maintainer

Please drop the build-depends on python3-funcsigs.

It doesn't appear to be used anywhere in the package (the string
"funcsigs" only appears in d/control), and shouldn't be needed - it's a
backport of a stdlib function added in python 3.3.

This is blocking removal of this package, #937769

Bug#959933: RM: node-vue-template-compiler -- ROM; Provided by node-vue 2.6.11

[Xavier Guimard]

Package: ftp.debian.org
Severity: normal

Hi,

node-vue-template-compiler has the same source than node-vue. Since
node-vue 2.6.11+dfsg-1, this package is provided by node-vue

Cheers,
Xavier

Bug#959909: debian-policy: complete implementation of ctte decision to forbid vendor-specific series files

[gregor herrmann]

On Wed, 06 May 2020 13:28:53 -0700, Sean Whitton wrote:

> Quoting from #904302:
> 
> > The Committee therefore resolves that:
> >
> > 1. Any use of dpkg's vendor-specific patch series feature is a bug for
> >packages in the Debian archive (including contrib and non-free).
> >
> >This should be implemented in Debian Policy by declaring that a
> >package SHOULD NOT contain a non-default series file.
> >
> > 2. After Buster is released, use of the vendor-specific patch series
> >feature is forbidden in the Debian archive.
> >
> >This should be implemented in Debian Policy by declaring that a
> >package MUST NOT contain a non-default series file.
> 
> Here is a patch to finish implementing this; I am seeking seconds:
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 1a4e871..58da61e 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -811,8 +811,8 @@ Vendor-specific patch series
>  
> 
>  Packages in the Debian archive using the 3.0 (quilt) source package
> -format should not contain a non-default series file.  That is, there
> -should not exist a file ``debian/patches/foo.series`` for any ``foo``.
> +format must not contain a non-default series file.  That is, there
> +must not exist a file ``debian/patches/foo.series`` for any ``foo``.
> 
>  .. [#]
> Rationale:
> diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
> index 2a8cc99..cae05c7 100644
> --- a/policy/upgrading-checklist.rst
> +++ b/policy/upgrading-checklist.rst
> @@ -39,6 +39,18 @@ The sections in this checklist match the values for the
>  except in the two anomalous historical cases where normative
>  requirements were changed in a minor patch release.
> 
> +Version 4.5.1
> +-
> +
> +Unreleased.
> +
> +4.17
> +Packages must not contain a non-default series file.  That is,
> +dpkg's vendor-specific patch series feature must not be used for
> +packages in the Debian archive.
> +
> +(previously a "should not")
> +
>  Version 4.5.0
>  -
> 


Seconded.


Cheers,
gregor


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: La Tresca: Caravanserraglio


signature.asc
Description: Digital Signature

Bug#959924: gnome-shell: gnome screen lock and screen blank no longer works after 3.36.2-1 update

[Simon McVittie]

Control: tags -1 + moreinfo

On Wed, 06 May 2020 at 23:26:29 -0400, terroreek wrote:
> After the upgrades from gnome-shell 3.36.2-1 screen locking pressing
> super + l or from the menu to and screen locking
> no longer works.  I have noticed Screen blanking, is also no longer
> working.

Are you using any GNOME Shell extensions? If you are, does this problem
persist when you disable them using gnome-shell-extension-prefs or
gnome-tweaks?

When you try to lock the screen, what messages appear in the systemd
journal?

(This is working fine for me; I suspect others in the GNOME team would
also quickly notice if the lock screen was entirely broken.)

> Kernel: Linux 5.6.11-towo.1-siduction-amd64 (SMP w/48 CPU cores; PREEMPT)

siduction is not Debian (it's a derivative with some modified packages,
like Ubuntu), and if a bug is not reproducible on a purely Debian system
we are unlikely to be able to fix it.

smcv

Bug#959935: ros-bond-core: please drop unnecessary boost-signal dependency

[Gianfranco Costamagna]

Source: ros-bond-core
Version: 1.8.3-3
Tags: patch

Hello, please consider dropping it. It makes the package FTBFS with newer 
boosts and it is unused.

thanks


--- ros-bond-core-1.8.3/debian/control  2020-05-05 12:14:32.0 +0200
+++ ros-bond-core-1.8.3/debian/control  2020-05-06 11:45:44.0 +0200
@@ -12,7 +13,6 @@
libroscpp-core-dev, libboost-dev,
libboost-thread-dev,
libroscpp-msg-dev, ros-roscpp-msg,
-   libboost-signals-dev,
libboost-filesystem-dev, libboost-regex-dev,
dh-python,
libconsole-bridge-dev

Bug#956828: This bug creates noise (Was: bedtools: fails to migrate to testing for too long: FTBFS on several archs)

[Michael Crusoe]

That's fine by me

--
Michael R. Crusoe

On Thu, May 7, 2020, 09:53 Andreas Tille  wrote:

> Hi Michael,
>
> this bug continuously creates noise on the testing removal front.  I'd
> really love to ask for removal the failing arches for the moment.
>
> What do you think?
>
> Kind regards
>
>  Andreas.
>
> --
> http://fam-tille.de
>

Bug#956828: This bug creates noise (Was: bedtools: fails to migrate to testing for too long: FTBFS on several archs)

[Andreas Tille]

Hi Michael,

this bug continuously creates noise on the testing removal front.  I'd
really love to ask for removal the failing arches for the moment.

What do you think?

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#959937: tomcat9: update to tomcat9:amd64 9.0.31-1~deb10u1 breaks application

[Michael Meier]

Package: tomcat9
Version: 9.0.16-4
Severity: grave
Justification: renders package unusable

I've just been called out of bed.
As it seems unattended-upgrades upgraded on a debian buster server
from:9.0.16-4 to 9.0.31-1~deb10u1
One of the installed webapps throws following error when trying to use it:

[https-openssl-nio-8443-exec-13] ERROR org.zkoss.zk.ui.metainfo.Property -
Failed to assign [value=${i18n:rt('Benutzername')}] to 
Unable to find ExpressionFactory of type: # Licensed to the Apache Software
Foundation (ASF) under one or more

Downgrading to 9.0.16-4 solves the issue.



-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (400, 'testing'), (300, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_WARN, 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 tomcat9 depends on:
ii  lsb-base10.2019051400
ii  systemd 245.5-2~bpo10+1
ii  tomcat9-common  9.0.16-4
ii  ucf 3.0038+nmu1

Versions of packages tomcat9 recommends:
pn  libtcnative-1  

Versions of packages tomcat9 suggests:
pn  tomcat9-admin 
pn  tomcat9-docs  
pn  tomcat9-examples  
pn  tomcat9-user  

-- no debconf information

Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'

[Adrian Bunk]

On Fri, Mar 06, 2020 at 10:57:20AM +0100, Paul Gevers wrote:
>...
> However, it fails on arm64. I copied some of the output at the bottom of
> this report.
> 
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it?
>...
> https://ci.debian.net/data/autopkgtest/testing/amd64/v/vtkplotter/4281870/log.gz
> 
> autopkgtest [12:57:24]: test python3: [---
> Processing test_actors.py script..
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/vtk/vtkIOFFMPEG.py", line 5, in
> 
> from .vtkIOFFMPEGPython import *
> ImportError: /lib/aarch64-linux-gnu/libgomp.so.1: cannot allocate memory
> in static TLS block
>...

This is a toolchain problem affecting many packages:
https://sourceware.org/bugzilla/show_bug.cgi?id=25051

There is nothing a binary-all python module can do to fix
architecture-specific toolchain bugs.

Is there a non-manual way to express that the autopkgtest must not run 
on arm64 and powerpc64el?

cu
Adrian

Bug#959938: ITP: [packageurl-python] - Parser and builder for purl Package URLs for Python

[Alvin Chen]

Package: wnpp
Severity: wishlist
Owner: Alvin Chen 

* Package name : packageurl-python
  Version : 0.8.7
  Upstream Author : the purl authors
* URL : https://github.com/package-url/packageurl-python
* License : Expat
  Lang: Python language
  Description :  Parser and builder for purl Package URLs for Python

Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'

[Paul Gevers]

Dear Adrian,

On 07-05-2020 10:07, Adrian Bunk wrote:
> This is a toolchain problem affecting many packages:
> https://sourceware.org/bugzilla/show_bug.cgi?id=25051

Do you have any rough estimate how many? Is there any way to predict
which packages are effected, or to detect which packages are effected?

> There is nothing a binary-all python module can do to fix
> architecture-specific toolchain bugs.

Ack.

> Is there a non-manual way to express that the autopkgtest must not run 
> on arm64 and powerpc64el?

There is currently not even a manual way except for marking the test as
skippable and exitting with error code 77 on unsupported architectures.
Mind you, I don't think toolchain issues should be marked at the package
level (but maybe you didn't mean that). If we can detect this failure
mode (and similar ones in the future) we can of course generate hints
based on this heuristics and have the failures ignored until the
toolchain issues are fixed.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#851810:

[James Adomako]

Ich habe Ihnen diesen Brief vor einem Monat geschickt, bin mir aber nicht
sicher, ob Sie ihn erhalten haben, und ich habe nichts von Ihnen gehört.
Ich wiederhole es deshalb. Ich bin ein Anwalt, James Adomako, der
persönliche Anwalt meines verstorbenen Mandanten, der bei seiner Reise in
das Nachbarland bei einem Autounfall mit seiner Familie ums Leben kam. Ich
habe von seiner Bank das Mandat erhalten, die nächsten Angehörigen seines
Fonds zu versorgen (USD 13.580.000,00), also habe ich Sie kontaktiert. Nach
meinen erfolglosen Versuchen, einen seiner Verwandten zu finden, habe ich
beschlossen, Sie zu kontaktieren. Ich möchte, dass Sie mich für weitere
Informationen kontaktieren.
Grüße.
Rechtsanwalt James Adomako (Esq).

Bug#956868: Use Realtek's r8101 driver

[Camaleón]

Hello,

Thanks for confirming the new kernel has dropped support for this 
ethernet controller.

This arises some questions, tough:

1. The chipset is not that old (?). It comes embedded on a Compaq Mini 
CQ10-520ES (netbook), bought circa mid' 2011.

2. As many users are not able to manually compile the driver, could you 
please reconsider your decision of dropping this chipset? Having 
an ethernet link available for a first Debian install (or whatever 
distribution) is a must under some restricted environments.

3. Can you please pinpoint the latest kernel version where this chipset
was last supported?

Thanks,

-- 
Camaleón 

Bug#959939: IP address ping-pong

[Harald Dunkel]

Package: isc-dhcp-server
Version: 4.4.1-2

My dhcp client (isc-dhcp-client 4.4.1-2) gets 10.0.102.161 or
10.0.102.162 on every other reboot.

AFAIR this is not supposed to happen. The client is supposed to
keep "his" IP address, unless it is given to another host.

Leases files are attached.

The client is an LXC container, i.e. it reboots within 1 or
2 seconds. If I shutdown the container, wait for a minute
(literally) and boot it again, then there is no such problem.


Regards
Harri


dhclient.eth0.leases.gz
Description: application/gzip


dhcpd.leases.gz
Description: application/gzip

Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

[Ansgar]

Dmitry Smirnov writes:
> On Wednesday, 6 May 2020 9:58:03 PM AEST Ansgar wrote:
>> > Clearly there is a problem in "php7.4-fpm" which should not depend on
>> > "systemd" in first place because it is perfectly functional without
>> > "systemd- tmpfiles" and without "systemd" as far as I can tell.
>> 
>> It might or might not be; adding wrong dependency information to other
>> packages to work around that isn't a solution.
>
> I insist that "adding wrong dependency information to other packages"
> is not a situation here, if you misled to think that from unfortunate 
> changelog entry in "systemctl" package.

So all packages that want systemd-tmpfiles need "Depends: systemd" and
"Conflicts: systemctl" now? (Same for anything else provided by systemd,
but not systemctl.)

That's what would be required thanks to the changes in systemctl now
because you have some disagreement with the php maintainer.  Note that
in particular "php7.4-fpm" would need that Conflicts now...

That's not a correct solution.  systemctl is clearly wrong here;
php7.4-fpm might also be wrong, but two wrongs don't make a right.

>> With php7.4-fpm 7.4.5-1 and systemctl 1.4.4181-1 installed in a current
>> Debian unstable:
>> 
>> +---
>> 
>> | root@09f957efac98:/# /etc/init.d/php7.4-fpm start
>> | /etc/init.d/php7.4-fpm: 99: systemd-tmpfiles: not found
>> 
>> +---
>> 
>> That's what the dependency is for and it's broken because of the
>> `Provides`.
>
> No, it is broken because of the bug in SysV init script which explicitly
> calls `systemd-tmpfiles` binary hence _requires_ systemd facility.

That is not a bug, even if you might not like the init script doing
that.

> Arguably it is a bad idea to hard-depend on "systemd" for SysV services and
> this is precisely the systemd zealotry that makes maintenance of alternatives
> so hard, creates bad reputation to Debian and poisons debates with toxic
> arguments... :(

Please read https://www.debian.org/vote/2019/vote_002.

Also accusations of "systemd zealotry" and such poisons debates with
toxic arguments.  I would appreciate if you could stop doing that.

Ansgar

Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

[Julien Cristau]

Control: severity -1 serious
Justification: in the release manager's opinion, makes the package unsuitable 
for release

On Thu, May 07, 2020 at 08:19:48AM +1000, Dmitry Smirnov wrote:
> We do not have a problem with "Provides: systemd" in "systemctl" package on 
> systems where "systemd" is installed by default because admins knowingly 
> install "systemctl" in order to replace "systemd".
> 
> We do not have a problem with "Provides: systemd" in "systemctl" package on 
> systems where "systemctl" is installed from scratch to manage services 
> without systemd hence avoiding installation of "systemd".
> 
> I can't see where we would have a problem at all so I'll downgrade severity 
> once again.
> 
This use of Provides is not acceptable.  The systemctl package does not
in any way provide the same functionality / interfaces as the systemd
package, and as such it does not get to pretend that it does and cause
problems to other packages.

Please stop severity ping-pong on this.

Cheers,
Julien

Bug#959940: hdmf FTBFS with h5py 2.10.0

[Adrian Bunk]

Source: hdmf
Version: 1.5.4-1
Severity: serious
Tags: ftbfs
Control: affects -1 src:pynwb

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/hdmf.html

...
==
ERROR: test_dynamic_container_constructor_name_default_name 
(tests.unit.build_tests.test_io_map.TestDynamicContainer)
--
Traceback (most recent call last):
  File 
"/build/1st/hdmf-1.5.4/.pybuild/cpython3_3.8_hdmf/build/tests/unit/build_tests/test_io_map.py",
 line 313, in test_dynamic_container_constructor_name_default_name
with self.assertWarns(Warning):
  File "/usr/lib/python3.8/unittest/case.py", line 255, in __enter__
if getattr(v, '__warningregistry__', None):
  File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/h5py_warnings.py", 
line 36, in __getattr__
return getattr(self._mod, attr)
  File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/h5py_warnings.py", 
line 35, in __getattr__
self._mod = self._import()
  File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/h5py_warnings.py", 
line 39, in _import
return import_module(self._mod)
  File "/usr/lib/python3.8/importlib/__init__.py", line 118, in import_module
if name.startswith('.'):
  File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/h5py_warnings.py", 
line 35, in __getattr__
self._mod = self._import()
  File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/h5py_warnings.py", 
line 39, in _import
return import_module(self._mod)
  File "/usr/lib/python3.8/importlib/__init__.py", line 118, in import_module
if name.startswith('.'):
...
  File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/h5py_warnings.py", 
line 35, in __getattr__
self._mod = self._import()
  File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/h5py_warnings.py", 
line 39, in _import
return import_module(self._mod)
  File "/usr/lib/python3.8/importlib/__init__.py", line 118, in import_module
if name.startswith('.'):
  File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/h5py_warnings.py", 
line 35, in __getattr__
self._mod = self._import()
RecursionError: maximum recursion depth exceeded

--
Ran 464 tests in 3.412s

FAILED (errors=8)
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd 
/build/1st/hdmf-1.5.4/.pybuild/cpython3_3.8_hdmf/build; python3.8 -m unittest 
discover -v 
dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned exit 
code 13
make: *** [debian/rules:7: build] Error 25

Bug#959668: os-prober: translated auto-added items in other installs are not recognized as such

[Benno Schulenberg]

Op 07-05-2020 om 08:19 schreef Cyril Brulebois:
> My first hunch would be, given languages are tricky: “Don't assume
> anything! Can it be that depending on the language, the device might
> get mentioned first, and other words get postfixed instead?”

Good catch.

> In which case maybe matching '(.*/dev/[^)]\+.*)' would make the fix a
> little more general? (Don't trust that pattern too much, -ENOCOFFEE…)

True.  The final ".*" is superfluous, though.

> po/pa.po-msgstr "(%s ਉੱਤੇ)"
> po/tr.po-msgstr "(%s üzerinde)"

Right.  However... looking at the latest grub POT file
(https://translationproject.org/POT-files/grub-2.04-pre1.pot),
it no longer contains the "(on %s)" msgid.  In fact, it does
not contain anything from '30_os-prober.in' at all any more.  :|

Did something go wrong in the packaging of grub?  Or did they
eliminate the script?  Or were the scripts moved to a separate
package?

Benno



signature.asc
Description: OpenPGP digital signature

Bug#959920: systemctl,elogind: No more co-installable

[Mark Hindley]

Axelm,

Thanks for this.

I haven't used systemctl myself, but it clearly has similar usage case to
elogind so it would be ideal if they were coinstallable. I am very happy to work
to find a solution that provides that.

On Thu, May 07, 2020 at 04:38:26AM +0200, Axel Beckert wrote:
> Hi,
> 
> Axel Beckert wrote:
> > I currently don't see a satisfying solution for that, [...]
> 
> actually I just came up with an idea which would also solve #959828.
> But unfortunately it requires cooperation from the systemd package
> maintainers — which from my experience makes chances rather low that
> this will be implemented.
> 
> Anyway, here's the idea:
> 
> If the systemd package would provide Provides for at least those
> interface also offered by alternatives (e.g. systemd-systemctl,
> systemd-logind), then elogind would just need to have to Conflict with
> "systemd-logind" and systemd-systemctl would just need to Provide
> "systemd-systemctl" or similar. And they would be co-installable
> again, because they both provide replacements for different interfaces
> of systemd.

This already partially exists in that the logind and default-logind virtual
packages are in use to resolve the libpam-systemd libpam-elogind issue.

However, that does not help in this case. elogind has to conflict with systemd
as they include some duplicate files. I have to admit to being less convinced by
the systemctl Provides: systemd. I understand the idea behind it, but systemd is
much (much, much!) more than systemctl(1). Wouldn't having systemctl Conflicts:
and Replaces: systemd be sufficient? AFAICS, that would restore the
coinstallability with elogind and resolve #959828?

Mark

Bug#959941: RFP: codium -- Code editing. Redefined.

[Harri T.]

Package: wnpp
Severity: wishlist

* Package name: codium
  Version : 1.44.2
  Upstream Author : Peter Squicciarini 
* URL : https://vscodium.com/
* License : MIT
  Programming Lang: TypeScript, JavaScript, Electron Framework
  Description : Code editing. Redefined.

https://en.wikipedia.org/wiki/Visual_Studio_Code
> Visual Studio Code is a source-code editor developed by Microsoft for
> Windows, Linux and macOS. It includes embedded Git and support for
> debugging, syntax highlighting, intelligent code completion, snippets,
> and code refactoring. It is highly customizable, allowing users to
> change the theme, keyboard shortcuts, preferences, and install
> extensions that add additional functionality.
>
> In the Stack Overflow 2019 Developer Survey, Visual Studio Code was
> ranked the most popular developer environment tool, with 50.7% of
> 87,317 respondents claiming to use it.

https://vscodium.com/
> The VSCodium project exists so that you don’t have to download+build
> from source. This project includes special build scripts that clone
> Microsoft’s vscode repo, run the build commands, and upload the
> resulting binaries for you to GitHub releases. These binaries are
> licensed under the MIT license. Telemetry is disabled.

Bug#958059: mumble: push-to-talk not working with some media keys

[nfb]

On Thu, May 07, 2020 at 03:30:21AM +, Chris Knadle wrote:
> forwarded 958059 https://github.com/mumble-voip/mumble/issues/4140
> thanks
> 
> nfb:
> > Package: mumble
> > Version: 1.3.0~git20190125.440b173+dfsg-2
> > Severity: normal
> > Tags: upstream
> > 
> > Dear Maintainer,
> > 
> > some multimedia keys are not working when bound to the push-to-talk
> > shortcut, but some of them do work fine.
> > 
> > For example the ThinkVantage button on a Thinkpad x230 keyboard
> > generates XF86Launch1 keysym. Output from xev:
> > 
> > KeyPress event, serial 34, synthetic NO, window 0x161,
> > root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374),
> > state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen 
> > YES,
> > XLookupString gives 0 bytes: 
> > XmbLookupString gives 0 bytes: 
> > XFilterEvent returns: False
> > 
> > KeyRelease event, serial 34, synthetic NO, window 0x161,
> > root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374),
> > state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen 
> > YES,
> > XLookupString gives 0 bytes: 
> > XFilterEvent returns: False
> > 
> > The key is correctly detected and saved (as XF86Launch1) by the
> > shortcut setting dialog in mumble, but when pushing it, the voice is
> > not activated.
> > Also, there should be no interference by the rest of the system, since
> > this button, but also all other media keys i chose for testing, are
> > not used by the window manager, nor by any running application.
> > 
> > The same for e.g. XF86Display. Other media keys such as XF86AudioPlay
> > instead, work as expected, as all other "standard" keys do, afaict.
> > 
> > I already reported on the #mumble irc channel and was told to file a
> > bug because it probably is, but i decided to open it here so we can
> > track it in Debian and also because i dont't know if the package in
> > the stable repo is a bit outdated and the issue has been recently
> > fixed somehow...
> > 
> > Let me know if you need more details.
> > 
> > Thanks for the support.
> 
> Thank you for opening a bug upstream about this; if upstream is able to fix 
> the
> bug then I'll be able to upload a new package with the fix for unstable and 
> testing.
> 
> It is doubtful that this can be fixed for Debian stable though; the only bugs
> that are possible to fix for stable are bugs that are serious, and any fixes 
> for
> serious bugs would have to be targeted for only the serious issues 
> specifically.
>  I don't think this bug passes that threshold.

Yes sure, that's totally fine.

> Out of curiosity, have you tested to see if Mumble 1.3.0+dfsg-1 in Debian
> unstable and testing exhibits the same bug?

No I'm sorry, I don't have right now a testing environment and on
stable there is dependency on a newer libc6. I could try a virtual
machine, yet I wanted to keep it non-virtualized to avoid another
layer of uncertainty in keystrokes passing and configurations to make
it work (and indeed it looks like the vm I have doesn't detect media
keys at all, must be something with the default generic keyboard
emulation). If I find some spare time to set it up I can maybe give
it a try.


P.S. Thanks a lot for including me in To. I was already subscribed so
if you find it easier to skip the hassle of including me everytime I
will still receive replies.



-- 
free as in freedom, not free beer

Bug#959920: systemctl,elogind: No more co-installable

[Mark Hindley]

Dimitry,

On Thu, May 07, 2020 at 09:52:18AM +0100, Mark Hindley wrote:
> However, that does not help in this case. elogind has to conflict with systemd
> as they include some duplicate files. I have to admit to being less convinced 
> by
> the systemctl Provides: systemd. I understand the idea behind it, but systemd 
> is
> much (much, much!) more than systemctl(1). Wouldn't having systemctl 
> Conflicts:
> and Replaces: systemd be sufficient? AFAICS, that would restore the
> coinstallability with elogind and resolve #959828?

I have just found #959174 and now understand more fully your motivation for
adding Provides: systemd to systemctl. I sympathise and have come across a
number of similar (unresolved) situations -- see #935304 for example.

And the common systemd-tmpfiles/opentmpfiles interface remains unresolved in
#952897.

Best wishes

Mark

Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

[Dmitry Smirnov]

On Thursday, 7 May 2020 6:58:49 PM AEST Ansgar wrote:
> So all packages that want systemd-tmpfiles need "Depends: systemd" and
> "Conflicts: systemctl" now? (Same for anything else provided by systemd,
> but not systemctl.)

You are over-reacting. "systemctl" is a niche package that is used only under 
a very specific requirements.

I might consider making a quick shell implementation of `systemd-tmpfiles` 
but without upstream support that won't be enough.


> That's what would be required thanks to the changes in systemctl now
> because you have some disagreement with the php maintainer.

That disagreement led me to think that "Provides: systemd" would be useful in 
other similar situations. Why would you not apply pressure to maintainer of 
PHP-FPM instead of me?


> Note that in particular "php7.4-fpm" would need that Conflicts now...

Of course not.


> > No, it is broken because of the bug in SysV init script which explicitly
> > calls `systemd-tmpfiles` binary hence _requires_ systemd facility.
> 
> That is not a bug, even if you might not like the init script doing
> that.

You don't want to call it a bug? OK, then let's call it sloppy design, misuse 
of systemd facility and problematic mixing of init systems functionality.

Don't you see how it cause this and few other bugs?


> Please read https://www.debian.org/vote/2019/vote_002.

Vote have nothing to do with poor technical decisions. This is not a debate 
against systemd and I was never against it. Please stop trying to portray me 
as anti-systemd activist.


> Also accusations of "systemd zealotry" and such poisons debates with
> toxic arguments.  I would appreciate if you could stop doing that.

OK, I may have spoke a bit too emotionally but Ondřej was un-provokingly and 
unexpectedly rude to me first.
I do express strong disapproval and disagreement with his decision to 
leverage `systemd-tmpfiles` for php-fpm SysV init script.
Maybe he would listen to you if you wish to convey this message with grace of 
your eloquence, lack of which you are blaming on me.

-- 
All the best,
 Dmitry Smirnov.

---

Good luck happens when preparedness meets opportunity.


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

Bug#959828: requires support on systemd side

[Adam Borowski]

The real culprit here, is that pkg:systemd provides many many distinct
interfaces, without letting any consumers say _which_ interfaces they want.

Thus, all of this would be solved if systemd declared Provides:systemctl
and relevant consumers depended on that.

Same with systemd-revolvd, tmpfiles, etc.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#959942: src:caffe: missing (unversioned) Breaks+Replaces: libcaffe-cpu1/libcaffe-cpu-dev/caffe-tools-cpu

[Andreas Beckmann]

Source: caffe
Version: 1.0.0+git20180821.99bd997-6
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Unpacking libcaffe1:amd64 (1.0.0+git20180821.99bd997-6) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libcaffe1_1.0.0+git20180821.99bd997-6_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libcaffe.so.1.0.0', which is 
also in package libcaffe-cpu1:amd64 1.0.0+git20180821.99bd997-5+b5
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Preparing to unpack .../libcaffe-dev_1.0.0+git20180821.99bd997-6_amd64.deb ...
  Unpacking libcaffe-dev:amd64 (1.0.0+git20180821.99bd997-6) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libcaffe-dev_1.0.0+git20180821.99bd997-6_amd64.deb 
(--unpack):
   trying to overwrite '/usr/include/caffe/blob.hpp', which is also in package 
libcaffe-cpu-dev:amd64 1.0.0+git20180821.99bd997-5+b5
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libcaffe1_1.0.0+git20180821.99bd997-6_amd64.deb
   /var/cache/apt/archives/libcaffe-dev_1.0.0+git20180821.99bd997-6_amd64.deb

  Preparing to unpack .../libcaffe1_1.0.0+git20180821.99bd997-6_amd64.deb ...
  Unpacking libcaffe1:amd64 (1.0.0+git20180821.99bd997-6) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libcaffe1_1.0.0+git20180821.99bd997-6_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libcaffe.so.1.0.0', which is 
also in package libcaffe-cpu1:amd64 1.0.0+git20180821.99bd997-5+b5
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Preparing to unpack .../caffe_1.0.0+git20180821.99bd997-6_amd64.deb ...
  Unpacking caffe (1.0.0+git20180821.99bd997-6) ...
  dpkg: error processing archive 
/var/cache/apt/archives/caffe_1.0.0+git20180821.99bd997-6_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/caffe', which is also in package 
caffe-tools-cpu 1.0.0+git20180821.99bd997-5+b5
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libcaffe1_1.0.0+git20180821.99bd997-6_amd64.deb
   /var/cache/apt/archives/caffe_1.0.0+git20180821.99bd997-6_amd64.deb

Since the packages have been renamed in experimental without providing
transitional packages, the B+R can be unversioned.

Would a transitional package for caffe-tools-cpu be useful?
Then use versioning (<< 1.0.0+git20180821.99bd997-6).
(A Provides will not help upgrades to switch to the new name,
a real package is needed in that case.)


cheers,

Andreas


libcaffe-cpu1=1.0.0+git20180821.99bd997-5+b5_libcaffe1=1.0.0+git20180821.99bd997-6.log.gz
Description: application/gzip

Bug#959943: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:mesa
Version: 20.0.6-1
Control: tags -1 ftbfs

--

Dear maintainer,
mesa fails to build on ppc64el since 20.0.4-2 as shown here :
https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=ppc64el&ver=20.0.6-1&stamp=1588668604&raw=0
I've prepared a patch for review.

Regards,


F.


pgppFuVlSjAk3.pgp
Description: PGP signature

Bug#959944: ITP: xdg-desktop-portal-wlr -- xdg-desktop-portal backend for wlroots

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 

* Package name: xdg-desktop-portal-wlr
  Version : 0.1.0
  Upstream Author : Simon Ser
* URL : https://github.com/emersion/xdg-desktop-portal-wlr
* License : MIT
  Programming Lang: C
  Description : xdg-desktop-portal backend for wlroots

This package will provide support for the screenshot, screencast, and
possibly remote-desktop xdg-desktop-portal interfaces for wlroots based
compositors.
I plan to maintain it in the swaywm-team.

Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

[Dmitry Smirnov]

On Thursday, 7 May 2020 7:04:17 PM AEST Julien Cristau wrote:
> This use of Provides is not acceptable.  The systemctl package does not
> in any way provide the same functionality / interfaces as the systemd
> package, and as such it does not get to pretend that it does and cause
> problems to other packages.

Would you care to define criteria regarding what level of "pretend" would be 
acceptable?? I'm interested in reasoning, not your authority.

You have provided no reasoning whatsoever. Did you even look at the package 
to say "does not in any way provide the same functionality / interfaces as 
the systemd" when it clearly implements a "systemctl" interface??

On what ground do you make this judgement? Or perhaps what are your concerns?

I recommend to point your energy and attention to #959174.

Thanks.

-- 
Regards,
 Dmitry Smirnov.

---

For a creative writer possession of the 'truth' is less important than
emotional sincerity.
-- George Orwell


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

Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4

[Pete Batard]

I would really like to get an update on this, because I really can't 
understand what the holdup is, or why non related issues seem to be be 
shoved into this bug, with the apparent end result of completely 
distracting from the matter at hand.


This bug is about one thing and one thing only: Enabling Raspberry Pi 4 
users to perform a netinstall using the next official aarch64 ISO of 
Debian 10.x. Therefore it is only about backporting the Genet ACPI 
driver into the 4.19 kernel, for which an effective backport patch was 
actually submitted.


It is *NOT* about tracking whether the 5.x kernel packages have Genet 
support. And it is *NOT* about troubleshooting network issues with the 
5.x kernel.


The sole focus for the bug, as it was opened by the submitter (myself) 
is to add Genet support to the kernel that is used by the Debian ISO 
installer, and, seeing that no progress appears to have been made on 
that front, despite the fact that a patch to *SOLVE* the reported issue 
has been submitted along with the bug report, I would greatly appreciate 
if we could reframe the problem and drop all references to 5.x genet 
support as being linked to this bug, as it looks to me like this is 
hindering the resolution of the one and only issue that prompted the 
creation of this bug.


I would also greatly appreciate if this could actually be treated with 
the level of urgency it requires on account of the following.


- As of March 2020, the Raspberry Pi Foundation announced that it had 
sold 640 000 Raspberry Pi 4 units, and one can reasonably expect that 1 
million units will have been sold by year's end, which clearly makes the 
platform one of the most popular ARM64 targets, if not the most popular, 
and therefore, one can reasonably expect many of its users to want to 
install Debian 10.x on it. By not applying the proposed patch and 
enabling netinst from official Debian 10.x ISOs as a matter of urgency, 
Debian maintainers will be doing a major disservice to their users.


- The required patch to *SOLVE* the issue has been provided, so it's not 
like Debian maintainers have to invest time to create the backport 
themselves. And for the record, I did work with Jeremy Linton, the 
person who upstreamed the main patch for 5.x kernels, and used the code 
that he was in the process of submitting at that time to create the 
backport (which is actually tailored for easy review by Debian 
maintainers), so the attached patch was not produced in isolation.


- Though it may look that way at first glance, this patch is not being 
requested because we are using a custom/toy bootloader. On the contrary, 
the very reason why we can use the official aarch64 ISO is because we 
are following industry standards pretty much to the letter. We are using 
both ACPI and UEFI in a very official manner, and as a matter of fact, 
the UEFI firmware that is meant to be used with the official ISOs is 
fully integrated with the EDK2 [1]. So this is not a "it would be nice 
if Debian could do this so that it would work with our custom 
bootloader" but really a "If Debian is to follow industry standards for 
the Raspberry Pi 4 and other UEFI platforms that use a Broadcom Genet 
NIC, then it should provide the functionality requested above, for which 
we have conveniently provided a patch".


So, if the integration of the proposed patch into the kernel used by the 
next Debian ISO release is going to be delayed further, I would really 
like the Debian maintainers to explain why that is the case.


We have been *EXCEEDINGLY* patient about this and waited in the hope 
that Debian maintainers would understand the urgency, but, seeing that 
Debian 10.4, which is planned to be released in 2 days, does not appear 
to integrate the patch we proposed (either that or this bug tracker was 
not updated as it should), I feel that we might as well tell the 
thousands of Raspberry Pi 4 users who we are seeing downloading the UEFI 
firmware in the hope of using it to install GNU/Linux, that they should 
just forget about Debian, because it seems Debian maintainers have 
either very little interest in ensuring that their OS can be installed 
on what is, by far, be the most popular ARM64 platforms out there, or 
have failed to grasp the implications of not applying the patch that can 
solve this very important issue and which was proposed *MONTHS* ago...


Regards,

/Pete

[1] 
https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4

Bug#959602: gtkmm3.0: FTBFS: gtk-demo/demowindow.cc:54:1: error: ‘demo_columns’ function uses ‘auto’ type specifier without trailing return type

[Gianfranco Costamagna]

control: tags -1 patch

Changing stdc++11 to stdc++14 fixed the build failure

--- gtkmm3.0-3.24.2/debian/patches/series   1970-01-01 00:00:00.0 
+
+++ gtkmm3.0-3.24.2/debian/patches/series   2020-05-07 10:03:05.0 
+
@@ -0,0 +1 @@
+stdc++14.patch
diff -Nru gtkmm3.0-3.24.2/debian/patches/stdc++14.patch 
gtkmm3.0-3.24.2/debian/patches/stdc++14.patch
--- gtkmm3.0-3.24.2/debian/patches/stdc++14.patch   1970-01-01 
00:00:00.0 +
+++ gtkmm3.0-3.24.2/debian/patches/stdc++14.patch   2020-05-07 
10:03:05.0 +
@@ -0,0 +1,16 @@
+Description:
+   * Use std=c++14 for build, to fix a build failure on i386
+Author: Gianfranco Costamagna 
+Last-Update: 2020-05-07
+
+--- gtkmm3.0-3.24.2.orig/configure.ac
 gtkmm3.0-3.24.2/configure.ac
+@@ -45,7 +45,7 @@ MM_CONFIG_DOCTOOL_DIR([docs])
+ AC_SUBST([LIBGTKMM_SO_VERSION], [2:0:1])
+ 
+ AC_PROG_CXX
+-MM_AX_CXX_COMPILE_STDCXX([11], [noext],[mandatory])
++MM_AX_CXX_COMPILE_STDCXX([14], [noext],[mandatory])
+ 
+ AC_DISABLE_STATIC
+ LT_INIT([win32-dll])

On Sun, 3 May 2020 14:37:53 +0200 Lucas Nussbaum  wrote:
> Source: gtkmm3.0
> Version: 3.24.2-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200501 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > g++ -std=c++11 -DHAVE_CONFIG_H   -I.. -I../gdk  -I../gtk  -pthread -pthread 
> > -I/usr/include/atkmm-1.6 -I/usr/include/giomm-2.4 
> > -I/usr/lib/x86_64-linux-gnu/giomm-2.4/include -I/usr/include/pangomm-1.4 
> > -I/usr/lib/x86_64-linux-gnu/pangomm-1.4/include -I/usr/include/glibmm-2.4 
> > -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/cairomm-1.0 
> > -I/usr/lib/x86_64-linux-gnu/cairomm-1.0/include -I/usr/include/sigc++-2.0 
> > -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include 
> > -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 
> > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 
> > -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
> > -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo 
> > -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz 
> > -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 
> > -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 
> > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid 
> > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
> > -DDEMOCODEDIR=\"""\"  -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
> > -DGLIBMM_DISABLE_DEPRECATED -DGIOMM_DISABLE_DEPRECATED 
> > -DGTKMM_DISABLE_DEPRECATED -DGDKMM_DISABLE_DEPRECATED -g -O2 
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -c -o gtk-demo/gtkmm_demo-example_appwindow.o `test 
> > -f 'gtk-demo/example_appwindow.cc' || echo 
> > './'`gtk-demo/example_appwindow.cc
> > gtk-demo/demowindow.cc:54:1: error: ‘demo_columns’ function uses ‘auto’ 
> > type specifier without trailing return type
> >54 | const auto& demo_columns()
> >   | ^
> > gtk-demo/demowindow.cc:54:1: note: deduced return type only available with 
> > ‘-std=c++14’ or ‘-std=gnu++14’
> > make[4]: *** [Makefile:733: gtk-demo/gtkmm_demo-demowindow.o] Error 1
> 
> The full build log is available from:
>http://qa-logs.debian.net/2020/05/01/gtkmm3.0_3.24.2-1_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
> 
> 

Bug#959944: ITP: xdg-desktop-portal-wlr -- xdg-desktop-portal backend for wlroots

[Birger Schacht]

Control: block -1 by 954022

This will need libpipewire 0.3, see #954022

Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'

[Adrian Bunk]

On Thu, May 07, 2020 at 10:28:33AM +0200, Paul Gevers wrote:
>...
> On 07-05-2020 10:07, Adrian Bunk wrote:
> > This is a toolchain problem affecting many packages:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=25051
> 
> Do you have any rough estimate how many?
>...

Other bugs I can quickly find are #930039 and #945878.

AFAIR I have seen maintainers adding workarounds for arm64+ppc64el FTBFS
caused by this bug that did not have bugs in the BTS.

#951704 looks like a similar but unrelated problem with jemalloc.

> Is there any way to predict which packages are effected,

Anything loading a plugin that is directly or indirectly linked
with libgomp might or might not have this problem.

Python C extensions are the most frequent ones.

Heavy usage of Python code with C extensions tends to be in the more
scientific areas of the archive, I'd guess many of these packages have
no users at all on ppc64el or arm64 who would report bugs (Raspbian is armhf).

python3-vtkplotter -> python3-vtk7 -> libvtk -> FFmpeg libraries
  -> libsoxr -> libgomp

> or to detect which packages are effected?

"import vtk" works, but "import vtkplotter" blows up when importing vtk.

This is similar to the two different OpenSSL versions in stretch, where 
module load order might determine whether Apache segfaults or starts.

>...
> > Is there a non-manual way to express that the autopkgtest must not run 
> > on arm64 and powerpc64el?
> 
> There is currently not even a manual way except for marking the test as
> skippable and exitting with error code 77 on unsupported architectures.
> Mind you, I don't think toolchain issues should be marked at the package
> level (but maybe you didn't mean that).

vtkplotter: flagged for removal in 6.3 days

The big hammer would be to remove the autopkgtest...

> If we can detect this failure
> mode (and similar ones in the future) we can of course generate hints
> based on this heuristics and have the failures ignored until the
> toolchain issues are fixed.

A failing arm64 or ppc64el autopkgtest log containing the string
"libgomp.so.1: cannot allocate memory in static TLS block"
is this bug.

> Paul

cu
Adrian

Bug#959920: systemctl,elogind: No more co-installable

[Thorsten Glaser]

On Thu, 7 May 2020, Mark Hindley wrote:

> I have just found #959174 and now understand more fully your motivation for
> adding Provides: systemd to systemctl. I sympathise and have come across a

OUCH!

I think adding the Provides is wrong, as it doesn’t fully provide
everything, but Ondřej is behaving very aggressively and uncon‐
structive here so… ☹ Debian has become an unwelcome place if you
actually wish for the “universal operating system” ☹

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

Bug#956868: Use Realtek's r8101 driver

[Heiner Kallweit]

RTL8401 (XID 240) was never supported by r8169.
Having said that nothing was dropped from the driver.
And most likely you don't have to compile r8101 yourself,
most distro's have a pre-compiled package.

Bug#959924: gnome-shell: gnome screen lock and screen blank no longer works after 3.36.2-1 update

[terroreek]

Yep, looks like it was the gtile extension.  I turned it off and now all is
working.  I will report the issue to the extension.

On Thu, May 7, 2020 at 3:39 AM Simon McVittie  wrote:

> Control: tags -1 + moreinfo
>
> On Wed, 06 May 2020 at 23:26:29 -0400, terroreek wrote:
> > After the upgrades from gnome-shell 3.36.2-1 screen locking pressing
> > super + l or from the menu to and screen locking
> > no longer works.  I have noticed Screen blanking, is also no longer
> > working.
>
> Are you using any GNOME Shell extensions? If you are, does this problem
> persist when you disable them using gnome-shell-extension-prefs or
> gnome-tweaks?
>
> When you try to lock the screen, what messages appear in the systemd
> journal?
>
> (This is working fine for me; I suspect others in the GNOME team would
> also quickly notice if the lock screen was entirely broken.)
>
> > Kernel: Linux 5.6.11-towo.1-siduction-amd64 (SMP w/48 CPU cores; PREEMPT)
>
> siduction is not Debian (it's a derivative with some modified packages,
> like Ubuntu), and if a bug is not reproducible on a purely Debian system
> we are unlikely to be able to fix it.
>
> smcv
>

Bug#959920: systemctl,elogind: No more co-installable

[Axel Beckert]

Hi Mark,

Mark Hindley wrote:
> I haven't used systemctl myself, but it clearly has similar usage case to
> elogind so it would be ideal if they were coinstallable.

As far as I understand it from the package descriptions (and really
not more than that), they're providing quite some different parts of
the plethora of systemd functionality:

* elogind mostly provides the session manager functionality (i.e.
  systemd-logind), i.e. is only related to providing additional
  functionality around user logins, cron sessions, etc.
* systemctl mostly provides the binary "systemctl" which is related to
  controlling services, i.e. a part of the init system functionality.

For me these are two completely different things which are both united in
systemd, but IMHO don't need to.

> > If the systemd package would provide Provides for at least those
> > interface also offered by alternatives (e.g. systemd-systemctl,
> > systemd-logind), then elogind would just need to have to Conflict with
> > "systemd-logind" and systemd-systemctl would just need to Provide
> > "systemd-systemctl" or similar. And they would be co-installable
> > again, because they both provide replacements for different interfaces
> > of systemd.
> 
> This already partially exists in that the logind and default-logind virtual
> packages are in use to resolve the libpam-systemd libpam-elogind issue.

Ah, right. But this is only for these two packages, not for whatever
exactly separates libpam-elogind and elogind itself.

> However, that does not help in this case. elogind has to conflict
> with systemd as they include some duplicate files.

*nod*

> I have to admit to being less convinced by the systemctl Provides:
> systemd.

Actually, yes, this solution is far from perfect (and probably far
from good, too), but it's still the right way to go IMHO.

As Dmitry wrote: »on what percentage of interface compatibility
warrants "Provides"«. And I think there is no hard limit, but there
are some percentages which IMHO say clearly yes (e.g. 99%) or clearly
"no" (e.g. 10%). It's though very difficult to determine the
percentage values. E.g. is systemctl providing rather 5% or rather 30% of
systemd. ;-)

Actually, In contrary to Dmitry, I would like to discuss this. But not
here. So I'll stop here. The above should only serve as example why I
think that what Dmitry did is the right direction, but not yet really
good. :-)

Oh, and thanks for the pointer to #959174 in the other mail. It hurts
to read the hostility in there. :-(

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

Bug#959945: python3-dev: missing -specs=... flag in python3-config breaks linking

[ux]

Package: python3-dev
Version: 3.7.3-1
Severity: important

Dear Maintainer,

Compilation fails on Debian when relying on `python3-config`. The reason is
that `python3-config --cflags` returns the custom debian `-specs=...` thing,
but `python3-config --ldflags` doesn't:

% python3-config --cflags
-I/usr/include/python3.7m -I/usr/include/python3.7m  -Wno-unused-result
-Wsign-compare -g -fdebug-prefix-map=/build/python3.7-3.7.3=.
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector -Wformat
-Werror=format-security  -DNDEBUG -g -fwrapv -O3 -Wall
% python3-config --ldflags
-L/usr/lib/python3.7/config-3.7m-x86_64-linux-gnu -L/usr/lib -lpython3.7m
-lcrypt -lpthread -ldl  -lutil -lm  -Xlinker -export-dynamic -Wl,-O1
-Wl,-Bsymbolic-functions

On Debian side, it was decided to have the following injected:
- CFLAGS="-specs=/usr/share/dpkg/no-pie-compile.specs"
- LDFLAGS="-specs=/usr/share/dpkg/no-pie-link.specs"

And unfortunately, the former can not go without the latter: otherwise there is
a link error:

This -fPIE is a workaround for the following link issue:
relocation R_X86_64_32 against `.rodata.str1.8' can not be used
when making a PIE object; recompile with -fPIE

Note: the `python3-config --ldflags` is a superset of `python3-config --libs`
(the latter only returns the libraries but never the flags such as `-L` so it's
pretty much useless) and is the actual equivalent of `pkg-config --libs`.

On Python side, `python3-config` is a script generated from a template using a
global `CFLAGS`. But at the same time, the script uses `LIBS` and `SYSLIBS` to
construct the `LDFLAGS` (and not `LDFLAGS` for some moronic reason).

Regards,

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

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

Versions of packages python3-dev depends on:
ii  dh-python  3.20190308
ii  libpython3-dev 3.7.3-1
ii  python33.7.3-1
ii  python3-distutils  3.7.3-1
ii  python3.7-dev  3.7.3-2+deb10u1

python3-dev recommends no packages.

python3-dev suggests no packages.

-- no debconf information

Bug#959946: grace: fails to start: failed request: 12 (X_ConfigureWindow)

[Drew Parsons]

Package: grace
Version: 1:5.1.25-8
Severity: grave
Justification: renders package unusable

On a clean installation, grace fails to launch:

$ xmgrace
X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  12 (X_ConfigureWindow)
  Value in failed request:  0x0
  Serial number of failed request:  2821
  Current serial number in output stream:  2822


This happens both with the latest official build from the archive and
with a fresh local rebuild.


backtrace from gdb adds a reference to libthread_db.so:

Starting program: /usr/bin/xmgrace 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
X Error of failed request:  BadValue (integer parameter out of range for 
operation)



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

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

Versions of packages grace depends on:
ii  fontconfig2.13.1-4
ii  gsfonts   1:8.11+urwcyr1.0.7~pre44-4.4
ii  libc6 2.30-7
ii  libfftw3-double3  3.3.8-2
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libnetcdf18   1:4.7.4-1
ii  libpng16-16   1.6.37-2
ii  libx11-6  2:1.6.9-2+b1
ii  libxbae4m 4.60.4-7+b11
ii  libxm42.3.8-2
ii  libxmhtml1.1  1.1.10-3
ii  libxmu6   2:1.1.2-2+b3
ii  libxpm4   1:3.5.12-1
ii  libxt61:1.1.5-1+b3
ii  xterm 356-1

Versions of packages grace recommends:
ii  xfonts-100dpi  1:1.0.4+nmu1
ii  xfonts-75dpi   1:1.0.4+nmu1

Versions of packages grace suggests:
ii  gconf2   3.2.6-6
ii  ghostscript  9.52~dfsg-1
pn  texlive-extra-utils  

-- no debconf information

Bug#959928: backuppc-rsync FTCBFS: does not pass --host to ./configure

[Axel Beckert]

Hi Helumt,

Helmut Grohne wrote:
> backuppc-rsync fails to cross build from source, because it does not
> pass --host to ./configure. The easiest way of doing so - using
> dh_auto_configure - makes backuppc-rsync cross buildable. Please
> consider applying the attached patch.

Thanks for the bug report and patch!

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

Bug#959947: python-m2crypto-doc: missing Breaks+Replaces: m2crypto-doc (<< 0.35.2-2)

[Andreas Beckmann]

Package: python-m2crypto-doc
Version: 0.35.2-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../python-m2crypto-doc_0.35.2-2_all.deb ...
  Unpacking python-m2crypto-doc (0.35.2-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python-m2crypto-doc_0.35.2-2_all.deb (--unpack):
   trying to overwrite '/usr/share/doc-base/m2crypto-documentation', which is 
also in package m2crypto-doc 0.31.0-9
  Errors were encountered while processing:
   /var/cache/apt/archives/python-m2crypto-doc_0.35.2-2_all.deb


cheers,

Andreas


m2crypto-doc=0.31.0-9_python-m2crypto-doc=0.35.2-2.log.gz
Description: application/gzip

Bug#959880: FTBFS on ppc64el

[Frédéric Bonnard]

Control: tags -1 patch

--

Here is a merge request for review :
https://salsa.debian.org/med-team/spoa/-/merge_requests/1

Regards,


F.


pgpWvO7pZsIro.pgp
Description: PGP signature

Bug#959940: hdmf FTBFS with h5py 2.10.0

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/hdmf-dev/hdmf/issues/343

Bug#948041: IMPORTANT

[Cheickna Toure]

Hello,
I have an important and favourable information/proposal which might
interest you to know, Contact me for details, it's important
Regards,
M.Cheickna
mecheicknato...@consultant.com

Bug#947844: also affected by libservlet3.1-java: 8.5.50-0+deb9u1 breaks upgrades to Buster, fix not in proposed-updates

[Markus Koschany]

Am 06.05.20 um 17:22 schrieb Thomas Arendsen Hein:
> * Thomas Arendsen Hein  [20200506 17:09]:
>> I just encountered this bug, too, when upgrading a machine.
> 
> For others reading here:
> Running "apt-get install -f" seems to work to continue the upgrade.

The fixed packages are currently in stable-proposed-updates only but
there will be a new point update for stable within a few days.



signature.asc
Description: OpenPGP digital signature

Bug#959943: FTBFS on ppc64el

[Frédéric Bonnard]

Control: tags -1 patch

--

Here is a merge request for review :
https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/13

Regards,


F.


pgphsIBUavl8n.pgp
Description: PGP signature

Bug#959937: tomcat9: update to tomcat9:amd64 9.0.31-1~deb10u1 breaks application

[Markus Koschany]

Am 07.05.20 um 10:04 schrieb Michael Meier:
> Package: tomcat9
> Version: 9.0.16-4
> Severity: grave
> Justification: renders package unusable
> 
> I've just been called out of bed.
> As it seems unattended-upgrades upgraded on a debian buster server
> from:9.0.16-4 to 9.0.31-1~deb10u1
> One of the installed webapps throws following error when trying to use it:
> 
> [https-openssl-nio-8443-exec-13] ERROR org.zkoss.zk.ui.metainfo.Property -
> Failed to assign [value=${i18n:rt('Benutzername')}] to 
> Unable to find ExpressionFactory of type: # Licensed to the Apache Software
> Foundation (ASF) under one or more
> 
> Downgrading to 9.0.16-4 solves the issue.

Have you read the changelog or the Debian security announcement before
upgrading Tomcat 9 ? Does your application require the AJP protocol to
work? Then you probably need to slightly change your Tomcat
configuration. For more information please also refer to the official
documentation at

  https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html


If that does not solve your problem, then we need more information about
your setup and configuration to debug the problem but note that we ship
the latest upstream version basically unmodified, so this would be most
likely an upstream bug.

Regards,

Markus Koschany



signature.asc
Description: OpenPGP digital signature

Bug#959684: [External] Bug#959684: salt: CVE-2020-11652: [cveh...@saltstack.com] Action Required: SaltStack CVE Follow-Up Patch

[Graham Clinch]

Hi,


I would like to get some testing feedback on the stretch packages, if
you have such instance
https://people.debian.org/~carnil/tmp/salt/stretch/ contains testing
packages.


These packages look good to me.

I updated two stretch instances from 2016.11.2+ds-1+deb9u3 to 
2016.11.2+ds-1+deb9u4, for the following packages:


salt-api, salt-common, salt-master, salt-minion.

There were no errors during the update, and minions at various releases 
(including 9u2, 9u3 and 9u4) connect to the salt master as expected.


Additionally a test tool reports the deb9u4 master as not vulnerable (it 
reported the deb9u3 master as vulnerable to 'read_token').


Graham

Bug#959942: src:caffe: missing (unversioned) Breaks+Replaces: libcaffe-cpu1/libcaffe-cpu-dev/caffe-tools-cpu/python3-caffe-cpu

[Andreas Beckmann]

Followup-For: Bug #959942
Control: retitle -1 src:caffe: missing (unversioned) Breaks+Replaces: 
libcaffe-cpu1/libcaffe-cpu-dev/caffe-tools-cpu/python3-caffe-cpu

I overlooked another occurrence in python3-caffe:

  Preparing to unpack .../libcaffe1_1.0.0+git20180821.99bd997-6_amd64.deb ...
  Unpacking libcaffe1:amd64 (1.0.0+git20180821.99bd997-6) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libcaffe1_1.0.0+git20180821.99bd997-6_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libcaffe.so.1.0.0', which is 
also in package libcaffe-cpu1:amd64 1.0.0+git20180821.99bd997-5+b5
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Preparing to unpack .../python3-caffe_1.0.0+git20180821.99bd997-6_amd64.deb 
...
  Unpacking python3-caffe (1.0.0+git20180821.99bd997-6) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-caffe_1.0.0+git20180821.99bd997-6_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/python3/dist-packages/caffe/__init__.py', 
which is also in package python3-caffe-cpu 1.0.0+git20180821.99bd997-5+b5
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libcaffe1_1.0.0+git20180821.99bd997-6_amd64.deb
   /var/cache/apt/archives/python3-caffe_1.0.0+git20180821.99bd997-6_amd64.deb


Andreas

Bug#959950: RFS: afio/2.5.2-1 [ITA] -- archive file manipulation program

[atzlinux 肖盛文]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "afio"

* Package name : afio
  Version : 2.5.2-1
  Upstream Author : Koen Holtman 
* URL : https://github.com/kholtman/afio
* License : Custom
* Vcs : https://salsa.debian.org/debian/afio
Section : utils

It builds those binary packages:

afio - archive file manipulation program

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

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

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

dget -x https://mentors.debian.net/debian/pool/main/a/afio/afio_2.5.2-1.dsc

Changes since the last upload:

[ 肖盛文 ]
* New upstream version 2.5.2
* add debian/gbp.conf
* update patch files for new upstream 2.5.2
* Set upstream metadata fields: Repository Repository-Browse

Regards,

-- 
肖盛文 Faris Xiao
微信：atzlinux
ＱＱ：909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com




signature.asc
Description: OpenPGP digital signature

Bug#959949: sensord: not available in stable o testing

[Francesco Potortì]

Package: sensord
Version: 1:3.4.0-3+b1
Severity: wishlist

Dear Maintainer,

please re-add this package to the latest distributions

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=C:en_GB:en:en_US:it:fr:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sensord depends on:
ii  libc62.30-4
ii  librrd8  1.7.2-3+b4
pn  libsensors4  
ii  lm-sensors   1:3.6.0-2
ii  lsb-base 11.1.0

sensord recommends no packages.

Versions of packages sensord suggests:
ii  rrdtool  1.7.2-3+b4

-- Configuration Files:
/etc/default/sensord changed:
exit
SYSLOG_FACILITY=daemon

/etc/logcheck/ignore.d.workstation/sensord [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.workstation/sensord'

Bug#959948: RM: bedtools [armel armhf i386 mipsel] -- ROM; Issues on some architectures should not prevent testing migration

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi ftpmasters,

since those architectures that are used in practice for bedtools
are building nicely I'd lower the severity of bug #956828 and
enable testing migration of the package.  So please remove bedtools
for the said architectures.

Kind regards and thanks for your work as ftpmaster

  Andreas.

Bug#959951: RM: clustalo [mipsel] -- ROM; Failed mipsel build should not block testing migragtion

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi,

the failed build on mipsel definitely needs investigation.  However, the
issue causes lots of testing removal warnings for rdepends of clustalo.
Thus I'd like to reduce severity of bug #956324 to important and move
on with all those architectures that are used in practice.

Kind regards and thanks for your work as ftpmaster

  Andreas.

Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

[Dmitry Smirnov]

On Thursday, 7 May 2020 7:04:17 PM AEST Julien Cristau wrote:
> This use of Provides is not acceptable.  The systemctl package does not
> in any way provide the same functionality / interfaces as the systemd
> package, and as such it does not get to pretend that it does and cause
> problems to other packages.

I have to challenge that. "systemctl" provides enough functionality to 
replace "systemd" inside application containers. Therefore there are 
situations where "Provides: systemd" is justified.

Just like "runit" and "supervisor", "systemctl" is a niche package intended 
to be used in application containers. It makes little sense to install it to 
"normal" (default) systemd-managed system and attempt to do so would warn 
admin by prompt to uninstall "systemd". What is the problem with that?

"systemctl" can be useful on SysV managed systems to start/stop services 
without SysV init scripts.

These days Debian usability inside application containers should be our 
strategic goal that became much closer thanks to "systemctl" package.

It is OK that we have have established "systemd" hegemony. But systemd is not 
an answer to everything and I feel that "systemctl" is being penalised for 
honest attempt to provide a semi-compatible "systemctl" interface.

Obviously unlike "runit" and "supervisor", "systemctl" can not be installed 
side-by-side with "systemd" as that would be much worse than "Provides: 
systemd".

Is there are any other options?


> Please stop severity ping-pong on this.

Not until I get an answer that make sense.

-- 
Best wishes,
 Dmitry Smirnov.

---

It is a fine thing to be honest, but it is also very important to be right.
-- Winston Churchill


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

Bug#956324: Lower severity

[Andreas Tille]

Control: severity -1 important

The builds for the failed architectures are requested for removal.  So
the bug is set to severity important to move on with architectures that
are used in practical applications without creating noise in form of
lots of testing removal warnings of rdepends.

Kind regards
Andreas.

Bug#959936: mt7601u: WARNING: CPU: 2 PID: 0 at drivers/net/wireless/mediatek/mt7601u/mac.c

[ryooxxx]

Package: src:linux
Version: 4.19.98-1+deb10u1
Severity: important
File: mt7601u

Dear Maintainer,

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

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

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


-- Package-specific info:
** Version:
Linux version 4.19.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1+deb10u1 (2020-04-27)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-8-amd64 
root=UUID=8789ded0-11fa-41db-a2fb-a9d396977fbe ro quiet

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[ 2060.253001] RSP: 0018:9e781ba83e68 EFLAGS: 00010246
[ 2060.253002] RAX: 0024 RBX: 9e7818806600 RCX: 
[ 2060.253002] RDX:  RSI: 9e781ba966b8 RDI: 9e781ba966b8
[ 2060.253003] RBP: ffc9 R08: 27ac R09: 0004
[ 2060.253003] R10:  R11: 0001 R12: 000a
[ 2060.253004] R13: 9e7815228004 R14: 9e7815228020 R15: 9e7819d8f540
[ 2060.253005] FS:  () GS:9e781ba8() 
knlGS:
[ 2060.253005] CS:  0010 DS:  ES:  CR0: 80050033
[ 2060.253005] CR2: 7fff40f11b2c CR3: 000116f92000 CR4: 06e0
[ 2060.253007] Call Trace:
[ 2060.253009]  
[ 2060.253013]  mt7601u_rx_tasklet+0x22a/0x570 [mt7601u]
[ 2060.253017]  tasklet_action_common.isra.21+0x5a/0x100
[ 2060.253020]  __do_softirq+0xde/0x2d8
[ 2060.253022]  irq_exit+0xba/0xc0
[ 2060.253022]  do_IRQ+0x7f/0xe0
[ 2060.253025]  common_interrupt+0xf/0xf
[ 2060.253025]  
[ 2060.253026] RIP: 0010:native_safe_halt+0xe/0x10
[ 2060.253027] Code: ff ff 7f c3 65 48 8b 04 25 40 5c 01 00 f0 80 48 02 20 48 
8b 00 a8 08 75 c4 eb 80 90 e9 07 00 00 00 0f 00 2d 46 c7 4d 00 fb f4  90 e9 
07 00 00 00 0f 00 2d 36 c7 4d 00 f4 c3 90 90 0f 1f 44 00
[ 2060.253027] RSP: 0018:ab6c806a7ea8 EFLAGS: 00010246 ORIG_RAX: 
ffdd
[ 2060.253028] RAX: a412b290 RBX: 0002 RCX: a4a4f390
[ 2060.253028] RDX: 00554bfe RSI: a4a4aff8 RDI: 01dfaf62d7d0
[ 2060.253029] RBP: 0002 R08: 0363b07a610b R09: 
[ 2060.253029] R10: 9e781346dda8 R11:  R12: 
[ 2060.253030] R13:  R14:  R15: 
[ 2060.253031]  ? __sched_text_end+0x7/0x7
[ 2060.253032]  default_idle+0x1c/0x140
[ 2060.253034]  do_idle+0x1e3/0x270
[ 2060.253035]  cpu_startup_entry+0x6f/0x80
[ 2060.253037]  start_secondary+0x1a4/0x1f0
[ 2060.253039]  secondary_startup_64+0xa4/0xb0
[ 2060.253040] ---[ end trace 2ef85b11182a4cbd ]---
[ 2061.317482] [ cut here ]
[ 2061.317551] WARNING: CPU: 2 PID: 22 at 
drivers/net/wireless/mediatek/mt7601u/mac.c:411 
mt76_mac_process_rx.cold.3+0x2a/0x36 [mt7601u]
[ 2061.317552] Modules linked in: arc4 vmwgfx mt7601u ttm drm_kms_helper 
mac80211 cfg80211 drm sg rfkill evdev vboxguest pcspkr video joydev serio_raw 
button ac ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic 
fscrypto ecb crypto_simd cryptd glue_helper aes_x86_64 hid_generic usbhid hid 
sr_mod cdrom sd_mod ata_generic ohci_pci ehci_pci ahci ata_piix ohci_hcd 
libahci ehci_hcd libata usbcore crc32c_intel psmouse scsi_mod i2c_piix4 e1000 
usb_common
[ 2061.317573] CPU: 2 PID: 22 Comm: ksoftirqd/2 Tainted: GW 
4.19.0-8-amd64 #1 Debian 4.19.98-1+deb10u1
[ 2061.317574] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
VirtualBox 12/01/2006
[ 2061.317576] RIP: 0010:mt76_mac_process_rx.cold.3+0x2a/0x36 [mt7601u]
[ 2061.317577] Code: 48 c7 c7 10 ed 40 c0 89 14 24 e8 18 56 6d e3 0f 0b 31 c0 
8b 14 24 e9 de eb ff ff 48 c7 c7 10 ed 40 c0 89 14 24 e8 fd 55 6d e3 <0f> 0b 31 
c0 8b 14 24 e9 ca ec ff ff 48 c7 c7 d8 ed 40 c0 e8 e5 55
[ 2061.317578] RSP: 0018:ab6c80707d90 EFLAGS: 00010246
[ 2061.317579] RAX: 0024 RBX: 9e7818806600 RCX: 
[ 2061.317579] RDX:  RSI: 9e781ba966b8 RDI: 9e781ba966b8
[ 2061.317580] RBP: ffc9 R08: 27d4 R09: 0004
[ 2061.317580] R10:  R11: 0001 R12: 000a
[ 2061.317581] R13: 9e7815228004 R14: 9e7815228020 R15: 9e7819d8f540
[ 2061.317582] FS:  () GS:9e781ba8() 
knlGS:
[ 2061.317582] CS:  0010 DS:  ES:  CR0: 80050033
[ 2061.317583] CR2: 7ffddc8d5ff8 CR3: 00010be0a000 CR4: 06e0
[ 2061.317584] Call Trace:
[ 2061.317590]  mt7601u_rx_tasklet+0x22a/0x570 [mt7601u]
[ 2061.317594]  tasklet_action_common.isra.21+0x5a/0x100
[ 2061.317597]  __do_softirq+0xde/0x2d8
[ 2061.317599]  ? sort_range+0x20/0x20
[ 2061.317600]  run_ks

Bug#959953: RFS: urlwatch/2.18-1 -- monitors webpages for you

[Maxime Werlen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "urlwatch"

 * Package name: urlwatch
   Version : 2.18-1
   Upstream Author : Thomas Perl 
 * URL : https://thp.io/2008/urlwatch/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/mwerlen/urlwatch
   Section : web

It builds those binary packages:

  urlwatch - monitors webpages for you

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/u/urlwatch/urlwatch_2.18-1.dsc

Changes since the last upload:

   * New upstream release
   * Updated Standards-Version to 4.5.0
   * Update Python minimum version to 3.5
   * Adjust patches to changed files
   * Removing Dockerfile from package
   * Add optional dependency on jsbeautifier

Regards,

--
  Maxime Werlen

Bug#959952: RFS: minidb/2.0.4-1 -- simple SQLite3-based store for Python objects

[Maxime Werlen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "minidb"

 * Package name: minidb
   Version : 2.0.4-1
   Upstream Author : Thomas Perl 
 * URL : https://thp.io/2010/minidb/
 * License : ISC
 * Vcs : None
   Section : python

It builds those binary packages:

  python3-minidb - simple SQLite3-based store for Python objects

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/minidb/minidb_2.0.4-1.dsc

Changes since the last upload:

   * New upstream release 2.0.4
   * Change upstream test framework in build dependencies (nose to pytest)
   * Update VCS URL after salsa username policy change (-guest removal)

Regards,

--
Maxime Werlen

Bug#959954: pyte: accesses internet during build?

[Gianfranco Costamagna]

Source: pyte
Version: 0.8.0-1
Severity: serious

Hello, in Ubuntu the network is more strictly disabled, and the package FTBFS

I'm not sure if this is a change in sphinx or the new release

dh_auto_build
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build
running build_py
creating /<>/.pybuild/cpython3_3.8/build/pyte
copying pyte/compat.py -> /<>/.pybuild/cpython3_3.8/build/pyte
copying pyte/graphics.py -> /<>/.pybuild/cpython3_3.8/build/pyte
copying pyte/control.py -> /<>/.pybuild/cpython3_3.8/build/pyte
copying pyte/__main__.py -> /<>/.pybuild/cpython3_3.8/build/pyte
copying pyte/__init__.py -> /<>/.pybuild/cpython3_3.8/build/pyte
copying pyte/charsets.py -> /<>/.pybuild/cpython3_3.8/build/pyte
copying pyte/escape.py -> /<>/.pybuild/cpython3_3.8/build/pyte
copying pyte/modes.py -> /<>/.pybuild/cpython3_3.8/build/pyte
copying pyte/streams.py -> /<>/.pybuild/cpython3_3.8/build/pyte
copying pyte/screens.py -> /<>/.pybuild/cpython3_3.8/build/pyte
python3 -m sphinx -b html -d docs/build/doctrees docs docs/build/html
Running Sphinx v2.4.3

Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
  File "/usr/lib/python3.8/urllib/request.py", line 1326, in do_open
h.request(req.get_method(), req.selector, req.data, headers,
  File "/usr/lib/python3.8/http/client.py", line 1240, in request
self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.8/http/client.py", line 1286, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.8/http/client.py", line 1235, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.8/http/client.py", line 1006, in _send_output
self.send(msg)
  File "/usr/lib/python3.8/http/client.py", line 946, in send
self.connect()
  File "/usr/lib/python3.8/http/client.py", line 1402, in connect
super().connect()
  File "/usr/lib/python3.8/http/client.py", line 917, in connect
self.sock = self._create_connection(
  File "/usr/lib/python3.8/socket.py", line 787, in create_connection
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
  File "/usr/lib/python3.8/socket.py", line 918, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/config.py", line 348, in 
eval_config_file
execfile_(filename, namespace)
  File "/usr/lib/python3/dist-packages/sphinx/util/pycompat.py", line 81, in 
execfile_
exec(code, _globals)
  File "/<>/docs/conf.py", line 106, in 
tag = resolve_tag()
  File "/<>/docs/conf.py", line 99, in resolve_tag
urlopen(linkcode_base_url + release)
  File "/usr/lib/python3.8/urllib/request.py", line 222, in urlopen
return opener.open(url, data, timeout)
  File "/usr/lib/python3.8/urllib/request.py", line 525, in open
response = self._open(req, data)
  File "/usr/lib/python3.8/urllib/request.py", line 542, in _open
result = self._call_chain(self.handle_open, protocol, protocol +
  File "/usr/lib/python3.8/urllib/request.py", line 502, in _call_chain
result = func(*args)
  File "/usr/lib/python3.8/urllib/request.py", line 1369, in https_open
return self.do_open(http.client.HTTPSConnection, req,
  File "/usr/lib/python3.8/urllib/request.py", line 1329, in do_open
raise URLError(err)
urllib.error.URLError: 

make[1]: *** [debian/rules:11: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:7: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Build finished at 20200507-1159

looking at the diff of the new version, my guess is to blame the new 
resolve_tag function
+linkcode_base_url = "https://github.com/selectel/pyte/tree/";
+
+def resolve_tag():
+from urllib.request import urlopen
+from urllib.error import HTTPError
+try:
+urlopen(linkcode_base_url + release)
+except HTTPError:
+return "master"
+else:
+return release
+
+
+tag = resolve_tag()



G.

Bug#959955: libsis-jhdf5-jni: ships /usr/lib/jni/libjhdf5.so already provided by libjhdf5-jni

[Andreas Beckmann]

Package: libsis-jhdf5-jni
Version: 19.04.0+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../libsis-jhdf5-jni_19.04.0+dfsg-1_amd64.deb ...
  Unpacking libsis-jhdf5-jni (19.04.0+dfsg-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libsis-jhdf5-jni_19.04.0+dfsg-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/jni/libjhdf5.so', which is also in package 
libjhdf5-jni 2.11.0+dfsg-4
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libsis-jhdf5-jni_19.04.0+dfsg-1_amd64.deb


cheers,

Andreas


libjhdf5-jni=2.11.0+dfsg-4_libsis-jhdf5-jni=19.04.0+dfsg-1.log.gz
Description: application/gzip

Bug#959949: sensord: not available in stable o testing

[Aurelien Jarno]

On 2020-05-07 13:40, Francesco Potortì wrote:
> Package: sensord
> Version: 1:3.4.0-3+b1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> please re-add this package to the latest distributions

Unfortunately sensord is too broken to work correctly and this hasn't
been fixed upstream. The only thing we might consider is to re-add the
package without RRD support (I haven't checked if it is easily doable).

Aurelien

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

Bug#959956: No out of space check_snmp_storage warning on btrfs

[IB Development Team]

Package: nagios-snmp-plugins
Version: 2.0.0-1

Hello,

We've noticed out of space condition in one of btrfs filesystems
monitored with check_snmp_storage; problem was not detected by
check_snmp_storage.

Filesystem status:

root@mysrv:~# btrfs fi df -b /mnt
Data, single: total=194688, used=194688
System, DUP: total=8388608, used=16384
System, single: total=4194304, used=0
Metadata, DUP: total=484835328, used=163921920
Metadata, single: total=8388608, used=0
GlobalReserve, single: total=16777216, used=0

root@mysrv:~# df -B1 /mnt
Filesystem   1B-blocks   Used Available Use% Mounted on
/dev/mapper/myvg 3221225472   2566848512 0  100% /mnt

Net-snmp snmp infos for this fs:

hrStorageTable (used by check_snmp_storage):

iso.3.6.1.2.1.25.2.3.1.1.69 = INTEGER: 69  //
hrStorageIndex
iso.3.6.1.2.1.25.2.3.1.2.69 = OID: iso.3.6.1.2.1.25.2.1.4  //
hrStorageType
iso.3.6.1.2.1.25.2.3.1.3.69 = STRING: "/mnt"   //
hrStorageDescr
iso.3.6.1.2.1.25.2.3.1.4.69 = INTEGER: 4096//
hrStorageAllocationUnits
iso.3.6.1.2.1.25.2.3.1.5.69 = INTEGER: 786432  //
hrStorageSize
iso.3.6.1.2.1.25.2.3.1.6.69 = INTEGER: 626672  //
hrStorageUsed

dskTable (not used by check_snmp_storage):

iso.3.6.1.4.1.2021.9.1.1.19 = INTEGER:
19 // dskIndex
iso.3.6.1.4.1.2021.9.1.2.19 = STRING:
"/mnt"  // dskPath
iso.3.6.1.4.1.2021.9.1.3.19 = STRING: "/dev/mapper/myvg"   //
dskDevice
iso.3.6.1.4.1.2021.9.1.4.19 = INTEGER:
-1 // dskMinimum
iso.3.6.1.4.1.2021.9.1.5.19 = INTEGER:
10 // dskMinPercent
iso.3.6.1.4.1.2021.9.1.6.19 = INTEGER:
3145728// dskTotal (Total size of the
disk/partion (kBytes))
iso.3.6.1.4.1.2021.9.1.7.19 = INTEGER:
0  // dskAvail (Available space on the
disk)
iso.3.6.1.4.1.2021.9.1.8.19 = INTEGER:
2506688// dskUsed (Used space on the disk)
iso.3.6.1.4.1.2021.9.1.9.19 = INTEGER:
80 // dskPercent (Percentage of space
used on disk)
iso.3.6.1.4.1.2021.9.1.10.19 = INTEGER:
0 // dskPercentNode (Percentage of
inodes used on disk)
iso.3.6.1.4.1.2021.9.1.11.19 = Gauge32:
3145728   // dskTotalLow Total size of the
disk/partion (kBytes). Together with dskTotalHigh composes 64-bit
number)
iso.3.6.1.4.1.2021.9.1.12.19 = Gauge32:
0 // dskTotalHigh (Total size of the
disk/partion (kBytes). Together with dskTotalLow composes 64-bit
number.)
iso.3.6.1.4.1.2021.9.1.13.19 = Gauge32:
0 // dskAvailLow (Available space on
the disk (kBytes). Together with dskAvailHigh composes 64-bit number.)
iso.3.6.1.4.1.2021.9.1.14.19 = Gauge32:
0 // dskAvailHigh (Available space on
the disk (kBytes). Together with dskAvailLow composes 64-bit number.)
iso.3.6.1.4.1.2021.9.1.15.19 = Gauge32:
2506688   // dskUsedLow (Used space on the disk
(kBytes). Together with dskUsedHigh composes 64-bit number.)
iso.3.6.1.4.1.2021.9.1.16.19 = Gauge32:
0 // dskUsedHigh (Used space on the
disk (kBytes). Together with dskUsedLow composes 64-bit number.)
iso.3.6.1.4.1.2021.9.1.100.19 = INTEGER:
1// dskErrorFlag (Error flag signaling
that the disk or partition is under the minimum required space
configured for it.)
iso.3.6.1.4.1.2021.9.1.101.19 = STRING: "/mnt: less than 10% free (=
0%)" // dskErrorMsg (A text description providing a warning and the
space left on the disk.)

The cause of problem is that in btrfs free space may be less than
total-used and by default check_snmp_storage checks used space which
was in this case about 80% (with 0% available in the same time and OS
was throwing OOS errors on write).

The solution is to configure warn/crit levels for %free not %used and
use avail from dskTable because hrStorageTable does not provide this
info (check_snmp_storage calculates free=total-used which is wrong for
btrfs as above).

Attached please find patch generated for upstream source

https://raw.githubusercontent.com/dnsmichi/manubulon-snmp/master/plugins/check_snmp_storage.pl

that works ok for us (this allows one to use new -u switch to use
dskTable and its avail info instead of default hrStorageTable and its
free=total-used calculation). This also adds a few spaces to plugin
output for better message readability.

-- 
Regards,
Pawel Boguslawski

IB Development Team
https://dev.ib.pl/

diff -Nur a/check_snmp_storage.pl b/check_snmp_storage.pl
--- a/check_snmp_storage.pl	2020-05-07 14:00:20.145179580 +0200
+++ b/check_snmp_storage.pl	2020-05-07 12:53:08.0 +0200
@@ -1,11 +1,11 @@
 #!/usr/bin/perl -w
 ## check_snmp_storage ##
-# Version : 1.3.3
-# Date :  Jun 1 200

Bug#959917: systemd: unit file Alias= leads to dangling symlink

[Michael Biebl]

Control: reassign -1 smartmontools

Hi

Am 07.05.20 um 02:51 schrieb Christoph Anton Mitterer:
> Package: systemd
> Version: 245.5-2
> Severity: normal
> 
> 
> Hey.
> 
> I've just noted the following behaviour.
> 
> /lib/systemd/system/smartmontools.service has:
> [Install]
> WantedBy=multi-user.target
> Alias=smartd.service
> 
> 
> Which leads to:
> # tree /etc/systemd/system
> /etc/systemd/system
> ├── multi-user.target.wants
> │   ├── smartd.service -> /lib/systemd/system/smartd.service
> │   ├── smartmontools.service -> /lib/systemd/system/smartmontools.service
> │   └── ...
> ├── smartd.service -> /lib/systemd/system/smartmontools.service
> ...
> 
> With /etc/systemd/system/multi-user.target.wants/smartmontools.service being
> a dangling symlink to the non-existant /lib/systemd/system/smartd.service .
> 
> /etc/systemd/system/smartd.service is however created with the correct
> destination.
> 
> 
> This stays if one disables/enables the unit, i.e. it's re-created with
> the dangling symlink.
> 

I was pointed to
https://salsa.debian.org/debian/smartmontools/-/commit/2a6b57611eba015de539f4e3686e2f5f161acdb3

The smartmontools package renamed the service unit from smartd.service
to smartmontools.service. That's the reason for the old, dangling symlink.

The cleanup of the old enablement symlinks needs to be done manually by
the smartmontools package.
Reassigning to the smartmontools package accordingly.

Regards,
Michael




signature.asc
Description: OpenPGP digital signature

Bug#959684: [External] Bug#959684: salt: CVE-2020-11652: [cveh...@saltstack.com] Action Required: SaltStack CVE Follow-Up Patch

[Salvatore Bonaccorso]

Hi Graham,

On Thu, May 07, 2020 at 11:25:00AM +0100, Graham Clinch wrote:
> Hi,
> 
> > I would like to get some testing feedback on the stretch packages, if
> > you have such instance
> > https://people.debian.org/~carnil/tmp/salt/stretch/ contains testing
> > packages.
> 
> These packages look good to me.
> 
> I updated two stretch instances from 2016.11.2+ds-1+deb9u3 to
> 2016.11.2+ds-1+deb9u4, for the following packages:
> 
> salt-api, salt-common, salt-master, salt-minion.
> 
> There were no errors during the update, and minions at various releases
> (including 9u2, 9u3 and 9u4) connect to the salt master as expected.
> 
> Additionally a test tool reports the deb9u4 master as not vulnerable (it
> reported the deb9u3 master as vulnerable to 'read_token').

Thanks for testing those, much appreciated. I will send out the
followup advisory with the fixed packages later today.

Regards,
Salvatore

Bug#959935: ros-bond-core: please drop unnecessary boost-signal dependency

[Graham Inggs]

On Thu, 7 May 2020 at 09:42, Gianfranco Costamagna
 wrote:
> Hello, please consider dropping it. It makes the package FTBFS with newer 
> boosts and it is unused.

If it makes the package FTBFS, shouldn't there be a Build-Conflicts on
libboost-signals-dev?

Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps

[Johannes Schauer]

Control: severity -1 grave

On Tue, 21 Apr 2020 21:54:57 +0300 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= 
 wrote:
> I noticed my builds started failing today with error message:
> 
> Step 4/7 : RUN DEBIAN_FRONTEND=noninteractive mk-build-deps -r -i
> control -t 'apt-get -y -o Debug::pkgProblemResolver=yes
> --no-install-recommends'
>  ---> Running in 912092c7ebbd
> dpkg-buildpackage: info: source package mariadb-10.5-build-deps
> dpkg-buildpackage: info: source version 1.0
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by root 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
> dpkg-checkbuilddeps: error: Unmet build dependencies: build-essential:native
> dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
> dpkg-buildpackage: warning: (Use -d flag to override.)
> Error in the build process: exit status 3
> dpkg: error: cannot access archive
> 'mariadb-10.5-build-deps_1.0_amd64.deb': No such file or directory
> mk-build-deps: dpkg --unpack failed
> The command '/bin/sh -c DEBIAN_FRONTEND=noninteractive mk-build-deps
> -r -i control -t 'apt-get -y -o Debug::pkgProblemResolver=yes
> --no-install-recommends'' returned a non-zero code: 2
> 
> I am pretty sure this is related to the recent equivs 2.3.0 release,
> but I have not figured out the details yet.

It is quite certain that the problem was introduced with the equivs 2.3.0
release. If you run the "debbisect" script from this merge request
https://salsa.debian.org/debian/devscripts/-/merge_requests/177#note_148500
then you will get:

$ ./scripts/debbisect --depends=equivs --cache=./cache 2020-04-18 
2020-04-20 'chroot "$1" equivs-build 
/usr/share/doc/equivs/examples/webserver.ctl'
[...]
bisection finished successfully
  last good timestamp: 2020-04-19 06:52:31.476563+02:00
  first bad timestamp: 2020-04-19 10:35:09.156250+02:00
only one package differs: equivs is the culprit

Notice that the test-command executes equivs-build with one of the provided
examples (webserver.ctl), so the problem is not mk-build-deps specific.

I wrote an autopkgtest which also demonstrates the problem:

https://salsa.debian.org/perl-team/modules/packages/equivs/-/merge_requests/5

Since all examples fail with the message "Unmet build dependencies:
build-essential:native" I'm raising the severity to grave. I'm not able to find
a way to craft a control file that is still working with equivs.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#959388: [Pkg-privacy-maintainers] Bug#959388: torbrowser fails to start due to lacking fonts/* entry in apparmor

[Santiago R.R.]

El 05/05/20 a las 20:27, Roger Shimizu escribió:
> control: tags -1 +pending
> control: forwarded -1 
> https://github.com/micahflee/torbrowser-launcher/pull/468
> 
> Dear Santiago,
> 
> Thanks for your report and patch!
> 
> On Sat, May 2, 2020 at 4:51 AM Santiago R.R.  wrote:
> >
> > Package: torbrowser-launcher
> > Version: 0.3.2-10
> >
> > The attached patch seems to have fixed here the issue.
> 
> I guess you meet this issue because I fixed the language locale issue
> in previous upload.
> However I didn't reproduce this in my buster-bpo system. Maybe this
> only occurs in sid?

I have unsuccessfully tried to reproduce the bug in the same machine,
even removing my .local/share/torbrowser/ directory. I still see the
apparmor DENIED message in the logs, but torbrowser starts without
issues.

So sorry if this bug is just noise.

> 
> Anyway, I upstreamed your patch:
> - https://github.com/micahflee/torbrowser-launcher/pull/468
…

Thanks!

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4

[Ben Hutchings]

Pete Batard wrote:
> I would really like to get an update on this, because I really can't 
> understand what the holdup is, or why non related issues seem to be be 
> shoved into this bug, with the apparent end result of completely 
> distracting from the matter at hand.
[...]
> It is *NOT* about tracking whether the 5.x kernel packages have Genet 
> support. And it is *NOT* about troubleshooting network issues with the 
> 5.x kernel.

The Debian bug tracking system is quite capable of recording *which*
versions an issue is found and fixed in.  So it's fine that this bug is
marked fixed in 5.x; we still know that it's unfixed in 4.19.

Also, there would be no point in enabling this driver in 4.19, only to
have people find on upgrade to the next version on Debian that we
didn't enable it there.  That's why we're concerned with both versions.

[...]
> I would also greatly appreciate if this could actually be treated with 
> the level of urgency it requires on account of the following.

All "missing hardware support" bugs have severity "important".

[...]
> - The required patch to *SOLVE* the issue has been provided, so it's not 
[...]

I acknowledge that you have provided a patch, which I appreciate, and
I'm sorry you haven't had a specific response to that yet.

Generally we want patches that correspond closely to upstream commits. 
For 5.5 I had to backport these 6 commits:

ce69e2162f15 mdio_bus: Add generic mdio_find_bus()
480ded265205 net: bcmgenet: refactor phy mode configuration
6ef31c8bee5b net: bcmgenet: enable automatic phy discovery
99c6b06a37d4 net: bcmgenet: Initial bcmgenet ACPI support
26bd9cc64faf net: bcmgenet: Fetch MAC address from the adapter
ae200c26b32b net: bcmgenet: reduce severity of missing clock warnings

Can you please provide separate backports of these, instead of a single
patch where it's hard to see what changed?

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS teams


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

Bug#959057: RFS: dh-cmake/0.4 [ITP] -- Debhelper programs for CMake projects

[Paul Wise]

On Thu, 2020-05-07 at 08:44 -0400, Kyle Edwards wrote:

> * Putting different CMake install components into different binary
> packages (for example, putting the "Libraries" component into
> libexample and the "Development" component into libexample-dev), which
> is easier than listing individual files

Seems like this would be useful in debhelper itself.

> * Running the CMake project's test suite inside the build process and
> submitting the results to CDash (this is more useful for continuous
> integration than production builds)

Possibly this too.

> * Extracting CPack component metadata from the project and
> incorporating that into the binary packages (for example, knowing that
> the "Development" component depends on the "Libraries" component allows
> libexample-dev to automatically depend on libexample)

This too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#873596: avahi FTCBFS: needs to run host python

[Simon McVittie]

Control: severity -1 wishlist
Control: retitle -1 avahi FTCBFS: needs to run host python
Control: tags -1 - patch

On Wed, 20 Nov 2019 at 18:58:01 +, Simon McVittie wrote:
> On Tue, 29 Aug 2017 at 13:41:43 +0200, Helmut Grohne wrote:
> > --- avahi-0.6.32/debian/control 2017-01-23 09:41:58.0 +0100
> > +++ avahi-0.6.32/debian/control 2017-08-29 13:24:45.0 +0200
> > @@ -21,10 +21,11 @@
> > libexpat-dev,
> > libdaemon-dev (>= 0.11),
> > libdbus-1-dev (>= 0.60),
> > -   python-all-dev (>= 2.6.6-3~),
> > -   python-gdbm (>= 2.4.3),
> > -   python-dbus ,
> > -   python-gtk2 (>= 2.8.6-2) ,
> > +   python-all-dev:any (>= 2.6.6-3~),
> > +   libpython-all-dev (>= 2.6.6-3~),
> > +   python-gdbm:native (>= 2.4.3),
> > +   python-dbus:native ,
> > +   python-gtk2:native (>= 2.8.6-2) ,
> > libqt4-dev ,
> > xmltoman,
> > intltool (>= 0.35.0)
> 
> This part hasn't been applied.

On closer inspection, I don't think (the modernized version of) this
change is necessarily correct.

I have changed this part to use python2 instead of python-all-dev.
avahi doesn't actually compile an extension or use Python development
headers - it just wants the interpreter. Normally, the obvious response
to this would be "then you should use python2:any, python-dbus:native
and so on".

However, python2 is run during the build to convert a text file listing
mDNS service types into a gdbm database. gdbm databases appear to be
endianness- and word-size-specific, so we need to build a database that
matches the host architecture's endianness and word size, even if they
differ from the build architecture's endianness and word size; so using
python2:any (or more generally, python2:${build-arch} when cross-compiling
on ${build-arch} for ${host-arch}) would not be correct.

I realize this makes it impossible to cross-compile avahi, which is
unfortunate - but I don't think that's fixable with the package's current
content.

Making it cross-compilable would require either a database format that
does not vary between architectures (which the upstream C code would need
to be taught to load), or a conversion step: for example, the package
could install service-type-database/service-types directly, and maintainer
scripts could "compile" it into each appropriate architecture's gdbm format.

To be honest this all seems massively overengineered for a table of just
over 100 service types, but that's an upstream design decision rather
than a packaging choice.

smcv

Bug#882584: Found the salsa package

[Mike Gabriel]

Hi Yanu,

On  Mi 06 Mai 2020 21:44:59 CEST, yanu wrote:

On Sun, 15 Mar 2020 12:26:28 + Mike Gabriel  
 wrote:

On  So 15 Mär 2020 03:10:03 CET, Martin Quinson wrote:
> On Sat, Mar 14, 2020 at 09:02:49PM +, Mike Gabriel wrote:
>> On  Sa 14 Mär 2020 00:36:21 CET, Martin Quinson wrote:
>>
>> > https://salsa.debian.org/debian-edu-pkg-team/openboard/
>> >
>> > could we however modify this git repository to use git-buildpackage?
>> > It makes things so much easier to maintain...
>> >
>> > Thanks for your work,
>> > Mt
>>
>> Sorry, no. I see myself in a constant process of removing more and more
>> files from the upstream Git tag/tarball, because files are  
non-DFSG for this

>> or that reason. I am not willing to pollute the salsa repo with these
>> changes.
>
> Ok, you know that better than I do.
>
>> To get openboard on salsa built, these steps should work:
>>
>>   $ git clone https://salsa.debian.org/debian-edu-pkg-team/openboard.git
>>   $ cd openboard
>>   $ debian/rules get-orig-source
>>   $ debuild -uc -us -S -Zxz -d
>>   $ dpkg-source -x openboard_.dsc
>>   $ cd openboard-
>>   $ debuild -uc -us
>
> I just tried, and it fails on the last step because of missing
> dependencies. Maybe we could add a .gitlab-ci attempting these steps
> so that we see where we currently stand?
>
>> IIRC, the current version on the repo's master branch only works / builds
>> well on Debian testing/unstable.

I'll try to invest some time on OpenBoard during the next week to
bring myself and then you up to speed. I have a long feedback mail (in
German) from a teacher in Germany with several suggestions. I'll try
to translate the gist of that and post it to you (and the
debian-edu-pkg-team's mailing list).


I'm on debian/unstable (desktop and laptop) and confirms that  
openboard is working, not perfect, but good.


With the compile-steps from Mike, I could compile all the  
openboard-packages, after installing a lot of dependencies (I saved  
the list).

  openboard - Interactive White Board Application
  openboard-common - Interactive White Board Application (common files)
  openboard-dbgsym - debug symbols for openboard
  openboard-fonts-nonfree - Interactive White Board Application  
(non-free fonts)


As a electric teacher in corana-times, I'm using openboard everyday  
as my main tool to teach.

Once in a while there is a crash, but after a quick restart, nothing is lost.

I would like to use this also after they find a vaccin against corona.
Then I would like to use it more often to evaluate papers, instead  
of printing them (saving the trees).
Also bought a wacom tablet to draw sketches, graphics, ... The wacom  
pen-top is melting fast ;-)

So, it would be great to have this software in debian repositories.

My software-knowledge doesn't go further than some hobby-programming  
on arduino.

I'm willing to donate some developping-time ?

Keep up the good work !


I am sorry, that work on this is s delayed. My goal is to get this  
openboard beast into bullseye.


I'll try to give this some prio before the school term ends. Sigh...

Mike

--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpNo08Zg4hh_.pgp
Description: Digitale PGP-Signatur

Bug#959884: hardening-runtime: max_user_namespaces breaks uuid-runtime

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2020-05-06 at 21:56 -0400, Aaron M. Ucko wrote:
> Yves-Alexis Perez  writes:
> > kernel.unprivileged_userns_clone is already set to 0 by default so it's
> > not
> > really needed here.
> 
> Hence "explicitly", for the sake of anyone running a custom kernel that
> accidentally wound up with a lax default.

Yes indeed, that's a good point.

> > I'm not a fan of lifting the max_user_namespace restriction here since
> > it's
> > there as runtime hardening. I can understand the pain with PrivateUsers
> > but I
> > still don't think exposing root-designed kernel code to unprivileged users
> > is
> > a good idea.
> 
> Sure, and I don't advocate for lifting unprivileged_userns_clone, but
> AFAICT allowing root to create user namespaces doesn't raise nearly so
> many concerns, and can even help security insofar as it allows for
> better isolation.

Yes but once a user namespace has been created (by root or a simple user),
anyone on that namespace can in turn create new users namespace. I considered
raising the limit to 1 (so root can create a user namespace and that's it) but
it's not enough for PrivateUsers, it needs 2.
> 
> > hardening-runtime is not installed by default so admins installing it are
> > supposed to understand what they do. They can also locally override the
> > restriction if needed (for example set it to 1 or 2).
> 
> Fair enough, and I may go this route.  It's perhaps unfortunate that
> there's no clean way to keep the default setting of this limit alongside
> 10-hardening.conf's other settings, but the default looks like massive
> overkill anyway, so I suppose that's no great loss.

I'm unsure what you mean here. Overriding it is a simple as adding a
/etc/sysctl.d/10-hardening-override.conf with user.max_user_namespace=1 (or 2,
3 etc.). You don't have to provide anything else or copy any other setting
from /usr/lib/sysctl.d/10-hardening.conf
> 
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl60B4cACgkQ3rYcyPpX
RFuB8wf+Kr2jM4YLEai2IrwTE/TElu+Tjt6EDieZCj39Lkh/iWxwFfpwT9g9Hwnc
1uc5jyVaFItaOOqnsdTjrrvTIecQKiIx0UqTiF8tITHeDPyPvaDSdrOmOw4U7b9u
VHFs4myUlO2kjrNU+uyEUaFd17VE5+GhQ5rHd3I1Qf2/S72Y7oN7Vr/X57l7nPud
elR3k6Zu3zDeVhRbleJ9yjNeR76jpwHbW/dgM38oc/4V+tZ8diiWfd0GXp3Cn1Nu
9DtlUr+jRd9A0fam2E3iBd2kxWZK572nSxUOiMUG8wdE7OUNIRUlgKj0bYukrA4S
ObMt7uBqxWeeams4pXO7yVtXloWjJQ==
=AdZc
-END PGP SIGNATURE-

Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files

[Olek Wojnar]

On Thu, May 7, 2020 at 5:51 AM Yun Peng  wrote:

> Thanks Andrej & Olek for helping clarify this issue.
>
> If the old library indeed has a LICENSE issue, we should definitely
> migrate to the newer version. Same for other Google projects. I'll initiate
> this from Google internally.
>

Great, thanks!


> PS. The migration is indeed simple, I did it for Bazel in this commit
> 
> .
>

Perfect! I'll cherry-pick that to satisfy the diffutils dependency and I'll
close this bug. Thanks!

-Olek

Bug#959884: hardening-runtime: max_user_namespaces breaks uuid-runtime

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2020-05-07 at 15:05 +0200, Yves-Alexis Perez wrote:
> On Wed, 2020-05-06 at 21:56 -0400, Aaron M. Ucko wrote:
> > Yves-Alexis Perez  writes:
> > > kernel.unprivileged_userns_clone is already set to 0 by default so it's
> > > not
> > > really needed here.
> > 
> > Hence "explicitly", for the sake of anyone running a custom kernel that
> > accidentally wound up with a lax default.
> 
> Yes indeed, that's a good point.

Actually no, it's not. kernel.unprivileged_userns_clone comes from a Debian
specific patch which is not mainline:

- - a non-Debian kernel won't have it (and the sysctl will result in an error)
- - a rebuilt Debian kernel will have it and set to 0 by default
- - a rebuild Debian kernel with the patch removed or set to 1 by default would
have been done explicitely, so I don't see the use of the sysctl either.

All in all I don't think it's worth changing the file (there's already a
comment in there).

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl60CK0ACgkQ3rYcyPpX
RFs2WAf/Ua5JUgUHyggwMTFiZ7DDgY8CHAFV8H+QnhmQIY9gEE6ILXEqzHt8SWfo
62zwfjUZ3MGhnPuJG9c7Mvy4Sl+I7TUwT9PMubKkRK1jqckTVFJVA3J2VSI9CrB0
Ph9pfwMbvlXE6UJNuH+nPYqhA3k0w6n1kXr9S6lxVbUdHKzK74W7Bg3l7dOUhzkT
ZD1dBm6PT4x1drpkfs6fm2qP4CPAK0yoBu4ePnCo+lyq66FgPU4BLjQk1swqN4/9
3g5TtVGVyLdakZa6yCUJ0n17pvjxHsSbU8HuDhz8rR7a6r4/yfYDkuqigZcEoITF
ir3d6DWTzustbNztXbELgubTizGPUg==
=JfRx
-END PGP SIGNATURE-

Bug#959958: pymupdf: Upload version with Built-Using set

[Bastian Germann]

Package: pymupdf
Severity: normal

Please upload the current git version to unstable so that commit
ebcde596e1dfa86552c11c2f30a ("Set Built-Using according to Policy 7.8")
is included. This will take care of keeping libmupdf-dev in the archive
in the right version even if is updated to the 1.17.0 upstream version.

Bug#959684: salt: CVE-2020-11652: [cveh...@saltstack.com] Action Required: SaltStack CVE Follow-Up Patch

[Guilhem Moulin]

Hi Salvatore,

On Thu, 07 May 2020 at 08:18:34 +0200, Salvatore Bonaccorso wrote:
> I would like to get some testing feedback on the stretch packages, if
> you have such instance
> https://people.debian.org/~carnil/tmp/salt/stretch/ contains testing
> packages.

Unfortunately I don't, would have been able to help with Buster (you
were faster though ;-)) but I currently don't have a running stretch
instance and won't find time to deploy one before the week-end.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#959883: gnome-shell: randomly crashes: segfaults and restarts

[Antonio Terceiro]

On Wed, May 06, 2020 at 08:40:47PM +0100, Simon McVittie wrote:
> On Wed, 06 May 2020 at 15:21:30 -0300, Antonio Terceiro wrote:
> > The actual core dump is 19MB compresses, is it useful?
> 
> Not particularly, because I probably don't have precisely the same
> versions of libraries that you do. I might need to ask you to install
> -dbgsym packages and get a backtrace with `coredumpctl gdb` if we can't
> work out what's going on any other way.
> 
> > Stack trace of thread 86099:
> > #0  0x7f5b6079408d __strncmp_avx2 (libc.so.6 + 0x15a08d)
> > #1  0x7f5b61481f9d g_str_has_prefix (libglib-2.0.so.0 + 
> > 0x71f9d)
> > #2  0x7f5b605df475 _st_theme_node_ensure_background 
> > (libst-1.0.so + 0x39475)
> > #3  0x7f5b605e31a5 st_theme_node_paint_equal 
> > (libst-1.0.so + 0x3d1a5)
> > #4  0x7f5b605edc73 n/a (libst-1.0.so + 0x47c73)
> > #5  0x7f5b605edfc3 st_widget_style_changed 
> > (libst-1.0.so + 0x47fc3)
> 
> This looks like it could be
> . If so, there's
> a fix in upstream git (not uploaded to Debian yet).

ack. I discovered I can reproduce this by simply pressing Super+L ("lock
screen").

I may try the upstream fix locally to see it if helps.


signature.asc
Description: PGP signature

Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4

[Pete Batard]

On 2020.05.07 13:45, Ben Hutchings wrote:

Also, there would be no point in enabling this driver in 4.19, only to
have people find on upgrade to the next version on Debian that we
didn't enable it there.  That's why we're concerned with both versions.


Yes, I did consider that, but I feel that this is an issue that should 
have been tracked separately (especially as, like we have seen, this 
polluted this issue with unrelated queries), as it doesn't have the same 
level of severity. Vanilla breakage vs optional breakage should not be 
grouped together IMO. But of course, you're free to do what you want.



[...]

I would also greatly appreciate if this could actually be treated with
the level of urgency it requires on account of the following.


All "missing hardware support" bugs have severity "important".


And I will assert that bugs should be evaluated in terms of potential 
users that are going to be impacted.


Support for a NIC that's used in niche hardware should not have the same 
level of severity as support for a NIC that is used on hardware that 
sold a quarter of a million units in less than a year.



[...]

- The required patch to *SOLVE* the issue has been provided, so it's not

[...]

I acknowledge that you have provided a patch, which I appreciate, and
I'm sorry you haven't had a specific response to that yet.

Generally we want patches that correspond closely to upstream commits.
For 5.5 I had to backport these 6 commits:

ce69e2162f15 mdio_bus: Add generic mdio_find_bus()
480ded265205 net: bcmgenet: refactor phy mode configuration
6ef31c8bee5b net: bcmgenet: enable automatic phy discovery
99c6b06a37d4 net: bcmgenet: Initial bcmgenet ACPI support
26bd9cc64faf net: bcmgenet: Fetch MAC address from the adapter
ae200c26b32b net: bcmgenet: reduce severity of missing clock warnings

Can you please provide separate backports of these, instead of a single
patch where it's hard to see what changed?


Sigh.

I specifically designed the patch I submitted for easy review and 
integration, because there are missing elements from 4.x that are 
present in 5.x, that we have to compensate for. I would rather not have 
to split it, especially as I believe it should be included as a matter 
of priority and we're simply adding delays.


If Debian 11 was planning to continue to use a 4.x kernel, I could see 
some point in splitting the patch and ensuring, so that it *might* be 
easier to maintain for many years to come. But, from what I gather, 
Debian 11 will bump kernel major, so any work being done making the 4.x 
backport (which is not that complex, sorry, especially as I made sure to 
already group the code changes in a manner that makes it easier to 
handle) easier to maintain in the long run seems like a waste of time, 
even if 10.x may see long time support for a few more years...


If you had made that point a few months ago, I would have been more 
inclined to do it, but at this stage, considering that it's too late for 
10.4 anyway, and considering that I feel like I've wasted more than 
enough time trying to push for this change to be included to help RPi4 
Debian users, and that 2 releases have gone by without any progress, I 
will respectfully decline to provide alterations to the submission 
unless it has to do with something that effectively prevents its 
integration, sorry.


Regards,

/Pete

Bug#933439: amule: Please rebuild against wxWidgets GTK 3 package

[Scott Talbert]

On Wed, 6 May 2020, Sandro Tosi wrote:


Any update on moving amule to use libwxgtk3.0-gtk3-dev?  amule is one of
the last couple of packages keeping the gtk2 wx package in unstable (as
cruft).  We keep getting bug reports about those cruft packages
periodically.


Sadly no: upstream hasnt ported amule to WX GTK3 and it doesnt look
like it's gonna happen anytime soon (help with the port is of course
welcome, probably better to sync upstream if someone wants to lend a
hand) so feel free to ask FTP Masters to force the decruft


Does the crash you referenced here require connecting to file sharing 
networks to reproduce?


Scott

Bug#950198: restinio

[Alexandre Viau]

Yes, go ahead!

Sorry I couldn't do it myself quicker, I tend to work on Debian only
on the weekends.

Thank you for your work!! :)

The next step would now be to update OpenDHT, which should be quick
once restinio passes new.

Cheers,

--
Alexandre Viau
av...@debian.org

On Thu, May 7, 2020 at 2:47 AM Sébastien Delafond  wrote:
>
> On 04/05 10:31, Sébastien Delafond wrote:
> > > I add a basic d/salsa-ci.yml, that should tell us what's going on.
> >
> > All the unit tests are passing in salsa:
> >
> >   https://salsa.debian.org/debian/restinio/-/jobs/717236#L1500
>
> Hi Alexandre,
>
> in the current state, do you think I should upload restinio to NEW?
>
> Cheers,
>
> --
> Seb

Bug#959388: [Pkg-privacy-maintainers] Bug#959388: torbrowser fails to start due to lacking fonts/* entry in apparmor

[Roger Shimizu]

On Thu, May 7, 2020 at 9:41 PM Santiago R.R.  wrote:
>
> I have unsuccessfully tried to reproduce the bug in the same machine,
> even removing my .local/share/torbrowser/ directory. I still see the
> apparmor DENIED message in the logs, but torbrowser starts without
> issues.

If you see the DENIED log in dmesg, the problem still exists.
And if after the apparmor patch, the DENIED log gets gone, that tells
us the patch is valid.

> So sorry if this bug is just noise.

Just double confirm my question above. and we'll decide whether to
move forward to the pull-request.
Thank you!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#959959: texlive-fonts-extra: XeLaTeX does not find font Fira Math.

[Braun Gábor]

Package: texlive-fonts-extra
Version: 2018.20190227-2
Severity: normal

Dear Maintainer,


With the minimal input file named as test.tex, the following command produces 
error:

$ xelatex -recorder test

the error message is

Requested font "Fira Math Regular/OT" at 9.7pt
 -> font not found, using "nullfont"

! Package fontspec Error: The font "Fira Math Regular" cannot be found.

The full log file is attached below.

The minimal input file compiles without error (but with warnings) using

$ lualatex test

Best wishes,

Gábor

##
minimal input file

\documentclass{article}

\usepackage{firamath-otf}

\begin{document}
\(2 + 2 = 5\)
\end{document}
##
.fls file (with the directory on first line removed for privacy reasons)

PWD ---removed-for-privacy---
INPUT /etc/texmf/web2c/texmf.cnf
INPUT /usr/share/texmf/web2c/texmf.cnf
INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
INPUT /var/lib/texmf/web2c/xetex/xelatex.fmt
INPUT test.tex
OUTPUT test.log
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/firamath-otf/firamath-otf.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/firamath-otf/firamath-otf.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/xkeyval/xkeyval.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/xkeyval/xkeyval.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/xkeyval/xkeyval.tex
INPUT /usr/share/texlive/texmf-dist/tex/generic/xkeyval/xkvutils.tex
INPUT /usr/share/texlive/texmf-dist/tex/generic/xkeyval/keyval.tex
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/textcomp.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/textcomp.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/unicode-math/unicode-math.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/unicode-math/unicode-math.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3-code.tex
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3-code.tex
INPUT /usr/share/texlive/texmf-dist/fonts/map/fontname/texfonts.map
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/UnicodeData.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/UnicodeData.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/CaseFolding.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/CaseFolding.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/SpecialCasing.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/SpecialCasing.txt
INPUT /dev/null
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/l3xdvipdfmx.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/l3xdvipdfmx.def
INPUT 
/usr/share/texlive/texmf-dist/tex/latex/unicode-math/unicode-math-xetex.sty
INPUT 
/usr/share/texlive/texmf-dist/tex/latex/unicode-math/unicode-math-xetex.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3packages/l3keys2e/l3keys2e.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3packages/l3keys2e/l3keys2e.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/tuenc.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
INPUT /usr/share/texlive/texmf-dist/tex/

Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps

[Axel Beckert]

Hi Josch,

thanks for bringing this to my attention. It seems as if I have
overseen Otto's bug report wen it came in two weeks ago. (Sorry,
Otto.)

Johannes Schauer wrote:
> Otto Kekäläinen wrote:
> > I am pretty sure this is related to the recent equivs 2.3.0 release,
> > but I have not figured out the details yet.

Some things have changed slightly in equivs and might need adaptions
in scripts using them where they make assumptions never guaranteed and
now no more true, like that only a .deb file is produced. E.g. now it
also produces .changes and .buildinfo files, see e.g.
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/154

> bisection finished successfully
>   last good timestamp: 2020-04-19 06:52:31.476563+02:00
>   first bad timestamp: 2020-04-19 10:35:09.156250+02:00
> only one package differs: equivs is the culprit

Yeah, but we know that already. I still haven't understood what
exactly causes this issue. If it's similar as with mk-ci-build-deps
above, this is likely a bug in mk-build-deps then, just triggered by equivs.

> Notice that the test-command executes equivs-build with one of the provided
> examples (webserver.ctl), so the problem is not mk-build-deps specific.

Ok, will have a look at this closer.

> I wrote an autopkgtest which also demonstrates the problem:
> 
> https://salsa.debian.org/perl-team/modules/packages/equivs/-/merge_requests/5

Will likely merge it once I've understood the cause of issue. Thanks
for the test!

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

Bug#949133: z3: request for backport to buster

[Fabian Wolff]

Hi Benjamin,

sorry for the very late reply, I kept putting it off...

Anyway, I have now set up a stable sbuild chroot and built z3 there, and, almost
surprisingly (and embarrassingly, because I waited so long to give it a try), it
built immediately, without me having to change anything, and the autopkgtests
passed, too.

So in principle, I could upload it now, but I'm kind of hesitant with regards to
how this would make me responsible for the package until buster's EOL [1]. Do
you have any experience with backports, is it really such a big commitment as
they make it sound in [1]? Because my personal focus is definitely on testing.

Best regards,
Fabian

[1] https://backports.debian.org/Contribute/

On Fri, 17 Jan 2020 10:55:54 +0100 Benjamin Albrecht  wrote:
> Package: z3
> Version: 4.8.7-2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I'm happy to see that z3 is actively being maintained again in Debian.
> 
> The version shipped in buster is quite old by now. Is there any chance you
> might be interested in providing a backport of the current version?
> 
> Sincerely
> 
> Benjamin Albrecht
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#746814: Should build against and link with system's libtrio

[Matthias Andree]

trio is only used when the system libraries are insufficient, which
should not be the case with GNU libc.

If a recent Debian build of bogofilter were to include libtrio in the
build, please report that upstream via Gitlab (preferred) or mailing
list with full logs so we can fix that.

trio is also going away in future releases.

So I'd say NEEDINFO WONTFIX - please tag this bug accordingly, and
possibly demote severity.

Bug#956868: Use Realtek's r8101 driver

[Camaleón]

On Thu, 7 May 2020 12:20:54 +0200, Heiner Kallweit wrote:

Hello,

> RTL8401 (XID 240) was never supported by r8169.
> Having said that nothing was dropped from the driver.
> And most likely you don't have to compile r8101 yourself,
> most distro's have a pre-compiled package.

How that can be? This computer perfectly detected the ethernet card 
years ago (2013), using kernel 3.9.0-rc2 (Debian nomenclature) and r8169
driver:

(dmesg excerpt)

[0.00] Linux version 3.9.0-rc2 (root@stt300) (gcc version 4.7.2 (Debian 
4.7.2-5) ) #1 SMP Sun Mar 17 22:49:53 CET 2013

[0.00] DMI: Hewlett-Packard Compaq Mini CQ10-500 /148A, BIOS F.15 
01/14/2011

[6.558651] [drm] Initialized drm 1.1.0 20060810
[6.573693] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[6.574014] r8169 :01:00.0 (unregistered net_device): unknown MAC, using 
family default
[6.574358] r8169 :01:00.0: irq 43 for MSI/MSI-X
[6.575005] r8169 :01:00.0 eth0: RTL8101e at 0xf8268000, 
68:b5:99:d3:c1:d8, XID 0400 IRQ 43:

(pci devices excerpt)

01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8101E/RTL8102E PCI Express Fast Ethernet controller [10ec:8136] (rev 04)
Subsystem: Hewlett-Packard Company Device [103c:148a]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: r8169

Greetings,

-- 
Camaleón 

Bug#733622: bogofilter: Crash on several emails with realloc(): invalid next size

[Matthias Andree]

https://sourceforge.net/p/bogofilter/bugs/116/#52a0

i. e. this was fixed 91 commits before bogofilter-1.2.5.rc1. I don't
know if the commit (Git cd33fc00802a75fe7b3b8a967bf879f7bc33c320) works
standalone or only in context, and I'm not researching this because for
me as upstream maintainer, this is done with the 1.2.5 release.

=> I think someone should package 1.2.5 for sid/unstable... more than
half a year after its release.

Bug#959961: Prefix not properly set?

[Laurent Bigonville]

Package: virt-p2v
Version: 1.42.0-1
Severity: grave

Hi,

When running virt-p2v-make-disk or virt-p2v-make-kiwi, I get the
folowing errors:

# virt-p2v-make-disk -o plop
virt-p2v-make-disk: cannot find /lib/x86_64-linux-gnu/virt-p2v/virt-p2v.xz

# virt-p2v-make-kiwi
/usr/bin/virt-p2v-make-kiwi: cannot find dependencies file 
(/share/virt-p2v/dependencies.suse)

The files are installed under
/usr/lib/x86_64-linux-gnu/virt-p2v/virt-p2v.xz and
/usr/share/virt-p2v/dependencies.suse.

Looks like the prefix is not properly set

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#759230: shell: Always use explicit large file API

[Herbert Xu]

There are some remaining stat/readdir calls in dash that may lead
to spurious EOVERFLOW errors on 32-bit platforms.  This patch changes
them (as well as open(2)) to use the explicit large file API.

Reported-by: Tatsuki Sugiura 
Signed-off-by: Herbert Xu 

diff --git a/configure.ac b/configure.ac
index 5dab5aa..dbd97d8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -144,8 +144,13 @@ AC_CHECK_FUNC(stat64,, [
AC_DEFINE(fstat64, fstat, [64-bit operations are the same as 32-bit])
AC_DEFINE(lstat64, lstat, [64-bit operations are the same as 32-bit])
AC_DEFINE(stat64, stat, [64-bit operations are the same as 32-bit])
+   AC_DEFINE(readdir64, readdir,
+ [64-bit operations are the same as 32-bit])
+   AC_DEFINE(dirent64, dirent,
+ [64-bit operations are the same as 32-bit])
 ])
 
+dnl OS X apparently has stat64 but not open64.
 AC_CHECK_FUNC(open64,, [
AC_DEFINE(open64, open, [64-bit operations are the same as 32-bit])
 ])
diff --git a/src/bltin/test.c b/src/bltin/test.c
index b7188df..c7fc479 100644
--- a/src/bltin/test.c
+++ b/src/bltin/test.c
@@ -473,17 +473,17 @@ static int isoperand(char **tp)
 static int
 newerf (const char *f1, const char *f2)
 {
-   struct stat b1, b2;
+   struct stat64 b1, b2;
 
 #ifdef HAVE_ST_MTIM
-   return (stat (f1, &b1) == 0 &&
-   stat (f2, &b2) == 0 &&
+   return (stat64(f1, &b1) == 0 &&
+   stat64(f2, &b2) == 0 &&
( b1.st_mtim.tv_sec > b2.st_mtim.tv_sec ||
 (b1.st_mtim.tv_sec == b2.st_mtim.tv_sec && (b1.st_mtim.tv_nsec 
> b2.st_mtim.tv_nsec )))
);
 #else
-   return (stat (f1, &b1) == 0 &&
-   stat (f2, &b2) == 0 &&
+   return (stat64(f1, &b1) == 0 &&
+   stat64(f2, &b2) == 0 &&
b1.st_mtime > b2.st_mtime);
 #endif
 }
@@ -491,17 +491,17 @@ newerf (const char *f1, const char *f2)
 static int
 olderf (const char *f1, const char *f2)
 {
-   struct stat b1, b2;
+   struct stat64 b1, b2;
 
 #ifdef HAVE_ST_MTIM
-   return (stat (f1, &b1) == 0 &&
-   stat (f2, &b2) == 0 &&
+   return (stat64(f1, &b1) == 0 &&
+   stat64(f2, &b2) == 0 &&
(b1.st_mtim.tv_sec < b2.st_mtim.tv_sec ||
 (b1.st_mtim.tv_sec == b2.st_mtim.tv_sec && (b1.st_mtim.tv_nsec 
< b2.st_mtim.tv_nsec )))
);
 #else
-   return (stat (f1, &b1) == 0 &&
-   stat (f2, &b2) == 0 &&
+   return (stat64(f1, &b1) == 0 &&
+   stat64(f2, &b2) == 0 &&
b1.st_mtime < b2.st_mtime);
 #endif
 }
@@ -509,10 +509,10 @@ olderf (const char *f1, const char *f2)
 static int
 equalf (const char *f1, const char *f2)
 {
-   struct stat b1, b2;
+   struct stat64 b1, b2;
 
-   return (stat (f1, &b1) == 0 &&
-   stat (f2, &b2) == 0 &&
+   return (stat64(f1, &b1) == 0 &&
+   stat64(f2, &b2) == 0 &&
b1.st_dev == b2.st_dev &&
b1.st_ino == b2.st_ino);
 }
diff --git a/src/cd.c b/src/cd.c
index b6742af..1ef1dc5 100644
--- a/src/cd.c
+++ b/src/cd.c
@@ -96,7 +96,7 @@ cdcmd(int argc, char **argv)
const char *path;
const char *p;
char c;
-   struct stat statb;
+   struct stat64 statb;
int flags;
int len;
 
@@ -132,7 +132,7 @@ dotdot:
c = *p;
p = stalloc(len);
 
-   if (stat(p, &statb) >= 0 && S_ISDIR(statb.st_mode)) {
+   if (stat64(p, &statb) >= 0 && S_ISDIR(statb.st_mode)) {
if (c && c != ':')
flags |= CD_PRINT;
 docd:
diff --git a/src/expand.c b/src/expand.c
index 4a5d75a..ecd7ee5 100644
--- a/src/expand.c
+++ b/src/expand.c
@@ -1286,7 +1286,7 @@ expmeta(char *name, unsigned name_len, unsigned 
expdir_len)
int metaflag;
struct stat64 statb;
DIR *dirp;
-   struct dirent *dp;
+   struct dirent64 *dp;
int atend;
int matchdot;
int esc;
@@ -1363,7 +1363,7 @@ expmeta(char *name, unsigned name_len, unsigned 
expdir_len)
p++;
if (*p == '.')
matchdot++;
-   while (! int_pending() && (dp = readdir(dirp)) != NULL) {
+   while (! int_pending() && (dp = readdir64(dirp)) != NULL) {
if (dp->d_name[0] == '.' && ! matchdot)
continue;
if (pmatch(start, dp->d_name)) {
diff --git a/src/input.c b/src/input.c
index 177fd0a..7d6be63 100644
--- a/src/input.c
+++ b/src/input.c
@@ -397,7 +397,7 @@ setinputfile(const char *fname, int flags)
int fd;
 
INTOFF;
-   if ((fd = open(fname, O_RDONLY)) < 0) {
+   if ((fd = open64(fname, O_RDONLY)) < 0) {
if (flags & INPUT_NOFILE_OK)
goto out;
exitstatus = 127;
diff --git a/src/jobs.c b/src/jobs.c
index a9e6524..f65435d 100644
--- a/src/jobs.c
+++ b/src/jobs.c
@@ -1

Bug#959962: Missing dependencies?

[Laurent Bigonville]

Package: virt-p2v
Version: 1.42.0-1
Severity: serious

Hello,

virt-p2v has no dependencies defined, but quickly looking which external
tools it's using it should IMVHO at least requires the following
dependencies:

xz-utils for xzcat
binutils for strip
libguestfs-tools for virt-builder

It's also using bash and gzip but these are essentials and should
probably not be added to the dependencies.

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#959963: qterminal: Bump request to 0.15.0

[Jeff Lang]

Package: qterminal
Version: 0.14.1-1+b1
Severity: wishlist

I would like to request a package for qterminal 0.15.0 as it includes several 
bug fixes and a feature to disable menu bar accelerators, which can be highly 
annoying in the current version. 

-- System Information:
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2020.2
Codename:   kali-rolling
Architecture: x86_64

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

Versions of packages qterminal depends on:
ii  libc6  2.30-2
ii  libqt5core5a   5.12.5+dfsg-10
ii  libqt5dbus55.12.5+dfsg-10
ii  libqt5gui5 5.12.5+dfsg-10
ii  libqt5widgets5 5.12.5+dfsg-10
ii  libqt5x11extras5   5.12.5-1
ii  libqtermwidget5-0  0.14.1-3
ii  libstdc++6 10-20200324-1
ii  libx11-6   2:1.6.9-2+b1

Versions of packages qterminal recommends:
ii  qterminal-l10n  0.14.1-1

qterminal suggests no packages.

-- no debconf information

Bug#959964: What about moving bitshuffle into debian-science

[Picca Frédéric-Emmanuel]

Package: bitshuffle
Version: 0.3.5-3.1
Severity: wishlist

Dear Maintainer,

I would like to help improving bitshuffle by

1) unbranding lzf and lz4
2) providing hdf( plugins at the system level for hdf5-serial and hdf5-mpi

So would you considere moving bitshuffle under the debian-science team umbrella.

thanks

Frederic


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

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

Versions of packages bitshuffle depends on:
ii  cython30.29.14-1
ii  libc6  2.30-7
ii  libgomp1   10-20200502-1
ii  libhdf5-openmpi-103-1  1.10.6+repack-2
ii  python33.8.2-3
ii  python3-h5py   2.10.0-7
ii  python3-numpy  1:1.18.4-1
ii  python3-pkg-resources  46.1.3-1

bitshuffle recommends no packages.

bitshuffle suggests no packages.

-- no debconf information

Bug#959668: os-prober: translated auto-added items in other installs are not recognized as such

[Cyril Brulebois]

Hi,

Benno Schulenberg  (2020-05-07):
> 
> Op 07-05-2020 om 08:19 schreef Cyril Brulebois:
> > My first hunch would be, given languages are tricky: “Don't assume
> > anything! Can it be that depending on the language, the device might
> > get mentioned first, and other words get postfixed instead?”
> 
> Good catch.
> 
> > In which case maybe matching '(.*/dev/[^)]\+.*)' would make the fix a
> > little more general? (Don't trust that pattern too much, -ENOCOFFEE…)
> 
> True.  The final ".*" is superfluous, though.

Right, I thoughtlessly “unanchored” the existing pattern (that I treated
as a constant) by padding it with .* on each side. :)
> 
> > po/pa.po-msgstr "(%s ਉੱਤੇ)"
> > po/tr.po-msgstr "(%s üzerinde)"
> 
> Right.  However... looking at the latest grub POT file
> (https://translationproject.org/POT-files/grub-2.04-pre1.pot),
> it no longer contains the "(on %s)" msgid.  In fact, it does
> not contain anything from '30_os-prober.in' at all any more.  :|
> 
> Did something go wrong in the packaging of grub?  Or did they
> eliminate the script?  Or were the scripts moved to a separate
> package?

Let's ask grub2 maintainers (cc'd). :)


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


signature.asc
Description: PGP signature

Bug#959965: reprepro: Using $fullfilename with --list-format uses basedir even if a different outdir is configured

[Silas McCroskey]

Package: reprepro
Version: 5.3.0-1.1
Severity: normal

The reprepro manual states the following about $fullfilename:

The special field names $basename, $filekey and $fullfilename
denote the first package file part of this entry (i.e.  usually
the .deb, .udeb or .dsc file) as basename, as filekey (filename
relative to the outdir) and the full filename with outdir
prepended (i.e.  as relative or absolute as your outdir (or
basedir if you did not set outdir) is).

But reprepro unconditionally uses the basedir to populate
$fullfilename, regardless of whether or not an outdir was set:

} else { /* fullfilename */
value = calc_dirconcat(global.basedir,
filekeys.values[0]);
if (FAILEDTOALLOC(value))
return RET_ERROR_OOM;
v = value;
}

(source is from a fresh clone from git, using the debian branch).

$fullfilename should use outdir as described.


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

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

Versions of packages reprepro depends on:
ii  libarchive13   3.4.0-1+b1
ii  libbz2-1.0 1.0.8-2
ii  libc6  2.29-10
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  libgpg-error0  1.37-1
ii  libgpgme11 1.13.1-6
ii  liblzma5   5.2.4-1+b1
ii  zlib1g 1:1.2.11.dfsg-1.2

Versions of packages reprepro recommends:
ii  apt  1.8.4

Versions of packages reprepro suggests:
ii  gpg-agent [gnupg-agent]  2.2.19-1
ii  inoticoming  0.2.3-2+b1
pn  lzip 
ii  pinentry-curses  1.1.0-3+b1

-- no debconf information

Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions

[Marc Lehmann]

On Mon, May 04, 2020 at 12:19:43PM +0200, Chris Hofstaedtler  
wrote:
> > On Sun, May 03, 2020 at 09:01:49PM +0200, Chris Hofstaedtler 
> >  wrote:
> 
> > I wouldn't assume this is necessary, though, as this is almost certainly
> > a relatively simple bug to fix - since the partition type differs for
> > partitions on the same disk it is unlikely to be caused by something weird
> > in the partition tables. That, or the algorithm is completely hosed, as it
> > shouldn't depend on the partition at all, only on the disk.
> 
> Well, I tried recreating your setup on a loop blockdev, and it works
> for me:

Hi, and thanks for your efforts. I jumped the gun and upgraded to testing,
and the bug still exists - at this point, I assume lsblk somehow looks at
the partition data to detect PTTYPE (which makes no sense to me), or maybe
it looks at some gpt data not visible in gdisk output:

   # lsblk --version
   lsblk from util-linux 2.35.1
   #  lsblk -o PATH,KNAME,MAJ:MIN,TYPE,PTTYPE,PTUUID,PARTUUID,LABEL,FSTYPE
   PATH  KNAME MAJ:MIN TYPE  PTTYPE PTUUID  
 PARTUUID LABEL  FSTYPE
   /dev/sda  sda 8:0   disk  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd
   /dev/sda1 sda18:1   part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI   
 vfat
   /dev/sda2 sda28:2   part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119   
 LVM2_member
   /dev/sda3 sda38:3   part  dos
81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d 
SSDCER ntfs

I might be able to creat some test image, or maybe I'll look at the
util-linux sources to see what issue is going on here, but either will
take some time for me.

> Which fdisk is this, because it omits important info (partition
> table type) and also doesn't show the GPT partitions?

Oh right, sorry - that is actually fdisk v1.17.3, which I use because it
doesn't support gpt and also lacks many of tghe safeguards of newer versions
that kept getting into my way. I use it for so long I forgot it's not the
debian one :().

OTOH, the current fdisk version doesn't show the mbr data on -l, so maybe
that was a good thing after all.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions

[Marc Lehmann]

On Mon, May 04, 2020 at 12:19:43PM +0200, Chris Hofstaedtler  
wrote:
> > partitions on the same disk it is unlikely to be caused by something weird
> > in the partition tables. That, or the algorithm is completely hosed, as it
> > shouldn't depend on the partition at all, only on the disk.
> 
> Well, I tried recreating your setup on a loop blockdev, and it works
> for me:

As an intermediate result, I did sgdisk -R /dev/sde /dev/sda, and the
problem does not travel:

   # lsblk -o PATH,KNAME,MAJ:MIN,TYPE,PTTYPE,PTUUID,PARTUUID,LABEL,FSTYPE 
/dev/sda /dev/sde
   PATH  KNAME MAJ:MIN TYPE  PTTYPE PTUUID  
 PARTUUID LABEL FSTYPE
   /dev/sda  sda 8:0   disk  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd

   /dev/sda1 sda18:1   part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI   
vfat
   /dev/sda2 sda28:2   part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119   
LVM2_member
   /dev/sda3 sda38:3   part  dos
81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d 
SSDCERntfs
   /dev/sde  sde 8:64  disk  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd

   /dev/sde1 sde18:65  part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d   

   /dev/sde2 sde28:66  part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119   

   /dev/sde3 sde38:67  part  gpt
81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d   


So I guess replicating this is not trivial.

I think it would be more fruitful for somebody who knows the code to look
at this, as obviously lsblk takes information from some place that is not
the disk partition info, which should be more obvious (i.e. PTTYPE should
simply not differ between partitions on the same disk).

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#959684: [cveh...@saltstack.com] Action Required: SaltStack CVE Follow-Up Patch

[Elimar Riesebieter]

Hi Salvatore and others,

* Salvatore Bonaccorso  [2020-05-06 13:09 +0200]:

> Hi Elimar,
> 
> On Wed, May 06, 2020 at 10:36:42AM +0200, Elimar Riesebieter wrote:
> > Hi all,
> > 
> > please notice the attached note from saltstack! I assume this is not
> > integrated into DSA 4676-1, isn't it?
> 
> Yes this is right, those parts were missing. 
> 
> Do you have possibility to test updated salt packages for stretch?

we fired up your kindly provided deb9u4 packages and run the
verification script http://em.saltstack.com/F1sH900oN0P0M17U000Qhf7
with the following result:

CVE-2020-11651 - OK
CVE-2020-11652 - OK

Thanks for cooperation
Elimar
-- 
  Never make anything simple and efficient when a way
  can be found to make it complex and wonderful ;-)

Bug#808724: gdc: "switch" requires a "default" case

[Witold Baryluk]

Package: gdc
Version: 4:9.2.1-3.1
Followup-For: Bug #808724

This bug seems to be fixed long time ago:

$ gdc example.d
dlang.d:10:9: error: switch statement without a default; use 'final switch' or 
add 'default: assert(0);' or add 'default: break;'
   10 | switch (1) {
$


So, bug can be closed.

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

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

Versions of packages gdc depends on:
ii  gdc-9   9.3.0-11
ii  libgphobos-dev  9.2.1-3.1

gdc recommends no packages.

gdc suggests no packages.

-- no debconf information