Bug#968545: RFP: gap-hap -- Homological Algebra Programming

[Joachim Zobel]

Package: wnpp
Severity: wishlist

* Package name: gap-hap
  Version : 1.26
  Upstream Author : Graham Ellis 
* URL : https://gap-packages.github.io/hap/
* License : GPL
  Programming Lang: GAP
  Description : Homological Algebra Programming

HAP is a homological algebra library for use with the GAP computer algebra
system.

It might be easy for Bill Allombert to add this package to the gap packages he
is maintaining.
Otherwise I will do it myself using existing gap packages as examples.

Bug#968543: RFS: ungoogled-chromium/83.0.4103.116-3 [ITP] -- web browser

[Thomas]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ungoogled-chromium":

* Package name : ungoogled-chromium
Version : 83.0.4103.116-3
Upstream Author : Eloston 
* URL : https://github.com/Eloston/ungoogled-chromium
* License : LGPL-2.0+, GPL-2+, ISC, LGPL-2+, LGPL-2.1+, BSD-3-clause or 
LGPL-2+, MIT, zlib, BSD-3-Clause, MPL-1.1 or GPL-2+ or LGPL-2.1+, Ms-PL, ICU, 
Apache-2.0, Public-domain, BSD-2-clause, MPL-1.1 or GPL-2.0 or LGPL-2.1, 
APPLE-license, BSD-3-clause, GPL-2.0, LGPL-2, MPL-2.0, LGPL-2.1, BSD-3-clause 
or LGPL-2.1+ or MPL-1.1, LGPL-2+ or MPL-1.1, PHP, LGPL-2.1+ or MPL-1.1
* Vcs : https://github.com/Eloston/ungoogled-chromium
Section : web

It builds those binary packages:

ungoogled-chromium - web browser
ungoogled-chromium-l10n - web browser - language packs
ungoogled-chromium-shell - web browser - minimal shell
ungoogled-chromium-driver - web browser - WebDriver support
ungoogled-chromium-common - web browser - common resources used by 
ungoogled-chromium packages
ungoogled-chromium-sandbox - web browser - setuid security sandbox for 
ungoogled-chromium

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

https://mentors.debian.net/package/ungoogled-chromium/

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

dget -x 
https://mentors.debian.net/debian/pool/main/u/ungoogled-chromium/ungoogled-chromium_83.0.4103.116-3.dsc

Changes for the initial release:

ungoogled-chromium (83.0.4103.116-3) unstable; urgency=low
.
* Initial Release. (Closes: #939406)
* Released 83.x instead of 84.x due to bugs found in 84.x

Best Regards,
--
Thomas Liang

Bug#967082: grub-customizer: dmesg has error info:segfault at 50 ip 0000558a7f3024e1

[铜豌豆 Linux]

Dear Bernhard Übelacker ,

 Thanks for your feedback.

Today ,I use the grub-customizer again, dmesg has not display the error
info again, all things is looked normally.

This bug isn't reproduceable in my notebook.

I didn't know the reason, sorry!

在 2020/8/17 上午4:35, Bernhard Übelacker 写道:
> Dear Maintainer,
> I tried to have a look, but can just tell the location,
> the dmesg output points to, is the following location.
> And at this point the register rdi contains the value of "this",
> at the submitters system 0x50, therefore causing the segfault.
>
> Maybe install debug symbols and running at submitters system
> inside valgrind could give some more pointers ... [1].
>
> Kind regards,
> Bernhard
>
>
> Thread 1 "grub-customizer" hit Breakpoint 1, 
> Trait_ActionLoggerAware::logActionBegin (action="update-timeout-setting", 
> this=0x55f619eb7680) at 
> ./src/main/../Controller/Common/../../lib/Trait/ActionLoggerAware.hpp:42
> 42  
> this->logger->logActionBegin(this->_controllerName, action);
> 1: x/i $pc
> => 0x55f6199c94e1 :  
>   mov(%rdi),%rax
> (gdb) bt
> #0  0x55f6199c94e1 in 
> Trait_ActionLoggerAware::logActionBegin(std::__cxx11::basic_string std::char_traits, std::allocator > const&) const 
> (action="update-timeout-setting", this=0x55f619eb7680) at 
> ./src/main/../Controller/Common/../../lib/Trait/ActionLoggerAware.hpp:42
> #1  0x55f6199c94e1 in SettingsController::updateTimeoutSettingAction() 
> (this=0x55f619eb7680) at ./src/main/../Controller/SettingsController.hpp:285
> ...
>
> [1] 
> https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

-- 
肖盛文 xiao sheng wen Faris Xiao 
微信(wechat)：atzlinux
《铜豌豆 Linux》 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com




signature.asc
Description: OpenPGP digital signature

Bug#968544: extrepo: 'extrepo help' is mostly useless, and syntax error on 'extrepo --help'

[Raja R Harinath]

Package: extrepo
Version: 0.8
Severity: minor
X-Debbugs-Cc: harin...@hurrynot.org

Dear Maintainer,

Here's a sample interaction:

--8<--
$ extrepo --help
Usage:
/usr/bin/extrepo search search for repositories
/usr/bin/extrepo update update a repository to the latest metadata
/usr/bin/extrepo disabledisable an extrepo-configured repository
/usr/bin/extrepo enable (re-)enable an extrepo repository

For more info, please read extrepo(1)
syntax error at (eval 13) line 1, near "Debian::ExtRepo::Commands::--"
...propagated at /usr/bin/extrepo line 123.

$ extrepo help
Undefined subroutine ::ExtRepo::Commands::Help::run called at (eval 13)
line 1.
...propagated at /usr/bin/extrepo line 123.
--8<--

Firstly, the syntax error is somewhat unseemly.  The second, is that, typically
for a command with sub-commands, 'help' is usually an useful subcommand.  Also,
often, help on subcommands is found on one or both of:

  extrepo help search
  extrepo search --help

Neither of with has useful behaviour,

--8<--
$ extrepo help search
Undefined subroutine ::ExtRepo::Commands::Help::run called at (eval 13)
line 1.
...propagated at /usr/bin/extrepo line 123.

$ extrepo search --help


No matches found for --help
--8<--



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

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

Versions of packages extrepo depends on:
ii  gpgv  2.2.20-1
ii  libcryptx-perl0.068-1
ii  libdpkg-perl  1.20.5
ii  libwww-perl   6.46-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  perl  5.30.3-4

extrepo recommends no packages.

extrepo suggests no packages.

-- Configuration Files:
/etc/extrepo/config.yaml changed:
---
url: http://extrepo-team.pages.debian.net/extrepo-data
dist: debian
version: bullseye
enabled_policies:
- main
- contrib
- non-free


-- no debconf information

Bug#960047: [Pkg-phototools-devel] Bug#960047: darktable: Superfluous dependencies

[astian]

David Bremner:
> astian  writes:
>
>> Control: found -1 3.2.1-2
>>
>> What's the problem with fixing this? It's a one-liner FFS.
>>
>
> The problem is a lack of time and motivation. You are not helping with
> either by sending such messages.
>
> d

Ah, lack of motivation is a bitch.  I can also feel lack of motivation towards
Debian lately.  Still I laughed, I sent 2 short such messages, months apart,
adding factual data in both, but sadly I still wasn't helping!  Maybe it
annoyed you that it annoyed me ;-).

Thanks for packaging the new release, BTW.  Cheers.

-- 


sed -r -i 's/, libjs-prototype, libjs-scriptaculous//' debian/control; rm 
debian/darktable.links1

Bug#968543: RFS: ungoogled-chromium/83.0.4103.116-3 [ITP] -- web browser

[Daniel Gröber]

Hi Thomas,

Thanks for working on this package!

I did a quick review I noticed the Vcs-* fields in debian/control are
pointing at the upstream git repo when they should be pointing to the
debianized one instead, see
https://www.debian.org/doc/debian-policy/ch-controlfields.html#version-control-system-vcs-fields.

--Daniel

On Mon, Aug 17, 2020 at 12:41:10AM +, Thomas wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "ungoogled-chromium":
> 
> * Package name : ungoogled-chromium
> Version : 83.0.4103.116-3
> Upstream Author : Eloston 
> * URL : https://github.com/Eloston/ungoogled-chromium
> * License : LGPL-2.0+, GPL-2+, ISC, LGPL-2+, LGPL-2.1+, BSD-3-clause or 
> LGPL-2+, MIT, zlib, BSD-3-Clause, MPL-1.1 or GPL-2+ or LGPL-2.1+, Ms-PL, ICU, 
> Apache-2.0, Public-domain, BSD-2-clause, MPL-1.1 or GPL-2.0 or LGPL-2.1, 
> APPLE-license, BSD-3-clause, GPL-2.0, LGPL-2, MPL-2.0, LGPL-2.1, BSD-3-clause 
> or LGPL-2.1+ or MPL-1.1, LGPL-2+ or MPL-1.1, PHP, LGPL-2.1+ or MPL-1.1
> * Vcs : https://github.com/Eloston/ungoogled-chromium
> Section : web
> 
> It builds those binary packages:
> 
> ungoogled-chromium - web browser
> ungoogled-chromium-l10n - web browser - language packs
> ungoogled-chromium-shell - web browser - minimal shell
> ungoogled-chromium-driver - web browser - WebDriver support
> ungoogled-chromium-common - web browser - common resources used by 
> ungoogled-chromium packages
> ungoogled-chromium-sandbox - web browser - setuid security sandbox for 
> ungoogled-chromium
> 
> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/ungoogled-chromium/
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/u/ungoogled-chromium/ungoogled-chromium_83.0.4103.116-3.dsc
> 
> Changes for the initial release:
> 
> ungoogled-chromium (83.0.4103.116-3) unstable; urgency=low
> .
> * Initial Release. (Closes: #939406)
> * Released 83.x instead of 84.x due to bugs found in 84.x
> 
> Best Regards,
> --
> Thomas Liang

Bug#963659: pybind11: FTBFS with Sphinx 3.1: File "/usr/lib/python3/dist-packages/sphinx/domains/c.py", line 3093, in object_type / raise NotImplementedError())

[Drew Parsons]

Wait for sphinx 3.2.1 I mean.

Bug#960342: obs-plugins: Please include v4lsink plugin for video loopback under linux

[gregor herrmann]

Control: forwarded -1 https://github.com/obsproject/obs-studio/pull/3182

On Mon, 11 May 2020 23:04:02 +0200, Michael Gebetsroither wrote:

> Package: obs-plugins
> Version: 25.0.3+dfsg1-2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Please include the v4lsink plugin for video loopback under linux.

This is currently happening upstream:
https://github.com/obsproject/obs-studio/pull/3182

So I guess the chances are high we'll see it in Debian after an
upstream release.
 

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: Eric Clapton: After Midnight


signature.asc
Description: Digital Signature

Bug#963512: RFP: obs-v4l2sink -- obs-studio plugin to send output to a Video4Linux2 loopback device

[gregor herrmann]

Control: reassign -1 obs-studio
Control: forcemerge 960342 -1

On Mon, 22 Jun 2020 20:07:04 +0100, Pedro Ângelo wrote:

> * Package name: obs-v4l2sink
>   Version : 0.1.0
>   Upstream Author : Han-Tai Chen 
> * URL : https://github.com/CatxFish/obs-v4l2sink
> * License : GPL v2
>   Programming Lang: C++
>   Description : obs-studio  plugin to send output to a Video4Linux2
> loopback device
> 
> obs-v4l2sink is an OBS Studio plugin that provides output capabilities to a
> Video4Linux2 device. It is basically a Linux version of obs-virtual-cam, but
> only contains the video sink part. You can use it with v4l2loopback to achieve
> cross-program video transfer between OBS Studio and third party software
> supporting Video4Linux2, e.g. to present an OBS session in proprietary 
> browser-
> based conferencing systems by selecting the OBS session as a webcam.

This is in the process of being included into obs-studio:
https://github.com/obsproject/obs-studio/pull/3182

Merging this bug with the one in obs-studio about the plugin.

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: Don McLean: Little Child


signature.asc
Description: Digital Signature

Bug#904839: bsdmainutils: cal still highlights though -h option is gone

[Dylan Thurston]

Package: ncal
Followup-For: Bug #904839

This is really a follow-up bug, but the '-h' option is still
documented in the man page (as an option for both cal and ncal).

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

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

Versions of packages ncal depends on:
ii  libc6  2.31-3
ii  libtinfo6  6.2-1

ncal recommends no packages.

ncal suggests no packages.

-- no debconf information

Bug#968519: dropbear-initramfs: race condition prevents launch at boot

[Forest]

On Sun, 16 Aug 2020 23:10:34 +0200, Guilhem Moulin wrote:

>configure_networking() is run in the backround, yup (and the dropbear
>server is started afterwards if successful) see #806884.  But that's done
>at init-premount stage, after udev and the required modules are loaded.
>Is your network interface brought up by a script in init-premount or
>local-top?

It doesn't appear so.

Both of these dirs are empty:
/etc/initramfs-tools/scripts/{init-premount,local-top}

/usr/share/initramfs-tools/scripts/init-premount contains only the
"dropbear" script from dropbear-initramfs.

/usr/share/initramfs-tools/scripts/local-top contains only "cryptopensc" and
"cryptroot", neither of which look like they bring up a network interface.

>Please also try the attached patch (with and without delay).

Was there supposed to be an attachment? The only one I received is your pgp
signature. I don't see a patch in the bugs.debian.org copy of this thread,
either.

Bug#968439: Please package emacs 27

[Rob Browning]

Nicholas D Steeves  writes:

> Hi Thomas,
>
> Thomas Koch  writes:
>
>> Package: emacs
>> Severity: wishlist
>> X-Debbugs-CC: debian-emac...@lists.debian.org
>>
>> Thank you! Any help needed?
>>
>> https://www.gnu.org/savannah-checkouts/gnu/emacs/news/NEWS.27.1
>
> :-) Rob is working on it.  Maybe join #debian-emacs for up-to-the-minute
> updates?

Ahh, right, sorry -- meant to reply here, and was going to add this bug
to the "Closes" when we finish.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#968531: littler: probably shouldn't use install -s

[Dirk Eddelbuettel]

Hi Simon,

On 16 August 2020 at 23:53, Simon McVittie wrote:
| Source: littler
| Version: 0.3.11-1
| Severity: minor
| 
| A bug report against fteqcc (#968524) prompted me to look for other
| instances of the same anti-pattern on codesearch.debian.net.
| 
| d/rules in littler invokes 'install -s'. However, 'install -s' is usually
| only harmful for a Debian package, not helpful: it discards debugging
| symbols that could otherwise have gone into a -dbgsym package, when
| cross-compiling it uses the wrong strip(1) implementation (from the build
| rather than host architecture), and it results in the nostrip option in
| DEB_BUILD_OPTIONS being ignored (see Policy §4.9.1). Unconditionally
| using INSTALL_PROGRAM = install would likely be better.

Thanks for the heads-up. Easy enough to fix in

  common-binary-post-install-arch::
  dh_installdirs usr/bin usr/share/man/man1
  install -s -v -m 0644 $(debRlib)/littler/bin/r
$(CURDIR)/debian/$(package)/usr/bin/
  install-v -m 0644 $(debRlib)/littler/man-page/r.1 
$(CURDIR)/debian/$(package)/usr/share/man/man1/

The package is a bit of an odd-ball -- I am the upstream author, and we at
first had "non-standard" distribution (in that it is an R package but wasn't
going to CRAN).

There is an added difficulty in that R packages only ever install in their
own director and below it, but this one is meant for common $PATH -- which is
where the line above comes from as R has no means to install in, say,
/usr/bin or /usr/local/bin

I made the change in my package sources, this will go out with the next littler 
update.

Best, Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#937665: Waiting for Python 2-depending reverse dependencies

[Ben Finney]

Control: block 967200 by -1

On 17-Aug-2020, Ben Finney wrote:

> The updated package is ready, and waiting for reverse-dependencies (as
> described in bug reports blocking this one) to drop Python 2 support.

-- 
 \   “I have a map of the United States; it's actual size. It says |
  `\‘1 mile equals 1 mile’. Last summer, I folded it.” —Steven |
_o__)   Wright |
Ben Finney 

signature.asc
Description: PGP signature

Bug#968527: Problem caused by proxy

[christian_k...@gmx.net]

Hello,

I had used a proxy in the LAN. After deactivating the proxy,
it works for konqueror, too.


Best regards,
Christian

Bug#968540: O: mailnag -- extensible mail notification daemon

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the mailnag package.

Prospective maintainers should also consider adopting gnome-shell-mailnag.

The package description is:
 Mailnag is a daemon program that checks POP3 and IMAP servers for new mail.
 On mail arrival it performs various actions provided by plugins. Mailnag
 comes with a set of desktop-independent default plugins for visual/sound
 notifications, script execution etc. and can be extended with additional
 plugins easily

Bug#968541: O: gnome-shell-mailnag -- mail notification extension for GNOME Shell

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the gnome-shell-mailnag package.

Prospective maintainers should also consider adopting the mailnag package.

The package description is:
 This package provides GNOME Shell integration for Mailnag. It includes the
 following features:
 .
   - Notifies about new mails via the messaging tray (including a counter
 badge)
   - Shows an indicator in the top panel (including counter badge and popup
 menu)
   - Lock screen integration

Bug#968539: O: exaile

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the exaile package.

Exaile has been removed from sid (due to the current packaged version being
written in python2 and depending on multiple py2 libraries), but upstream has
since released 4.x which now supports python3. Packaging likely needs extensive
updates as a result.

Description: flexible, full-featured audio player
 Exaile is a media player which incorporates many of the cool things from
 Amarok (and other media players) like automatic fetching of album art,
 handling of large libraries, lyrics fetching, artist/album information via
 Wikipedia, last.fm support, and optional iPod support (assuming you have
 python-gpod installed).
 .
 In addition, Exaile also includes tabbed playlists (so you can have more
 than one playlist open at a time), blacklisting of tracks (so they don't
 get scanned into your library), downloading of guitar tablature from
 fretplay.com, and submitting played tracks on your iPod to last.fm.
 .
 Exaile aims to be similar to AmaroK, but uses Python and GTK+.

Bug#968537: O: tolua++ -- Tool to integrate C/C++ code with Lua - development files

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the tolua++ package.

Note that upstream is effectively dead and this package does not support newer
lua releases.

The package description is:
 tolua++5.1 is an extension of toLua, a tool to integrate C/C++ code with
 Lua. tolua++5.1 includes new features oriented to c++, such as class
 templates and is compiled with the newest lua 5.1.
 .
 Based on a "cleaned" header file, tolua++ automatically generates
 the binding code to access C/C++ features from Lua. Using Lua-5.1 API and
 metamethod facilities, the current version automatically maps C/C++
 constants, external variables, functions, namespace, classes, and methods
 to Lua. It also provides facilities to create Lua modules.
 tolua is a tool that greatly simplifies the integration of C/C++ code with
 Lua. Based on a cleaned header file, tolua automatically generates the
 binding code to access C/C++ features from Lua. Using Lua API and tag
 method facilities, tolua maps C/C++ constants, external variables,
 functions, classes, and methods to Lua.

Bug#968538: O: dbus-c++ -- C++ API for D-Bus (documentation)

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the dbus-c++ package.

The package description is:
 Dbus-c++ attempts to provide a C++ API for D-Bus. The library has a glib/gtk
 and an Ecore mainloop integration. It also offers an optional own main loop.

Bug#968536: O: cherrytree -- hierarchical note taking application

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the cherrytree package.

This package was removed from Debian due to python2 removals; upstream
currently has a WIP C++/gtkmm rewrite that can be packaged by a prospective
maintainer.

The package description is:
 CherryTree is a hierarchical note taking application, featuring rich text,
 syntax highlighting, images handling, hyperlinks, import/export with support
 for multiple formats, support for multiple languages, and more.

Bug#968535: O: logisim -- graphical tool for designing and simulating logic circuits

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the logisim package.

Upstream is no longer actively maintaining this package, but there are a number
of forks which are actively maintained that could be packaged instead.

The package description is:
 Logisim is an educational tool for designing and simulating digital logic
 circuits. With its simple toolbar interface and simulation of circuits as
 you build them, it is simple enough to facilitate learning the most basic
 concepts related to logic circuits. With the capacity to build larger circuits
 from smaller subcircuits, and to draw bundles of wires with a single mouse
 drag, Logisim can be used (and is used) to design and simulate entire CPUs
 for educational purposes.

Bug#968534: libsignon-glib: New upstream version 2.1

[Kurt Kremitzki]

Source: libsignon-glib
Severity: wishlist

Dear Maintainer,

A new upstream version 2.1 of the package is available at
https://gitlab.com/accounts-sso/libsignon-glib. Please consider
packaging it.


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

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

Bug#968533: gdb: probably shouldn't use install -s

[Simon McVittie]

Source: gdb
Version: 9.2-1
Severity: minor

A bug report against fteqcc (#968524) prompted me to look for other
instances of the same anti-pattern on codesearch.debian.net.

d/rules in gdb invokes 'install -s'. However, 'install -s' is usually
only harmful for a Debian package, not helpful: it discards debugging
symbols that could otherwise have gone into a -dbgsym package, when
cross-compiling it uses the wrong strip(1) implementation (from the build
rather than host architecture), and it results in the nostrip option in
DEB_BUILD_OPTIONS being ignored (see Policy §4.9.1). Removing the -s
option would probably be better, unless there's some specific reason to
be using it.

smcv

Bug#968532: atari800: probably shouldn't use install -s

[Simon McVittie]

Source: atari800
Version: 4.1.0-1
Severity: normal

A bug report against fteqcc (#968524) prompted me to look for other
instances of the same anti-pattern on codesearch.debian.net.

d/rules in atari800 invokes 'install -s'. However, 'install -s' is usually
only harmful for a Debian package, not helpful: it discards debugging
symbols that could otherwise have gone into a -dbgsym package, when
cross-compiling it uses the wrong strip(1) implementation (from the build
rather than host architecture), and it results in the nostrip option in
DEB_BUILD_OPTIONS being ignored (see Policy §4.9.1). Using install
without the -s option, then using debhelper's dh_strip to do the right
Policy-compliant things, would probably be better.

Similarly, d/rules unconditionally strips certain fields from
debian/tmp/usr/bin/atari800, which is unhelpful for all the same reasons.
Again, dh_strip does this right.

smcv

Bug#964248: marked as done (base-installer: Pass "--extra-suites=unreleased" to debootstrap on ports arches)

[John Paul Adrian Glaubitz]

Hi!

On 8/17/20 12:49 AM, Samuel Thibault wrote:
> AIUI it was only tested on the mini iso.

Well, then it should not have been merged :(.

> I noticed the issue, and worked on it, there is:
> 
> https://salsa.debian.org/images-team/debian-cd/-/merge_requests/7
> 
> and then a couple other changes, I'm waiting for the above to be merged
> before I can submit them.

What happens when a port does not have any packages in "unreleased"? I checked
the patch and it enables "unreleased" unconditionally. I'm not sure whether
that's a good idea.

FWIW, I have commit access to debian-cd, so I can merge your changes but I would
like to discuss first whether enabling "unreleased" unconditionally will work
even if a port doesn't have any package in this suite.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#968531: littler: probably shouldn't use install -s

[Simon McVittie]

Source: littler
Version: 0.3.11-1
Severity: minor

A bug report against fteqcc (#968524) prompted me to look for other
instances of the same anti-pattern on codesearch.debian.net.

d/rules in littler invokes 'install -s'. However, 'install -s' is usually
only harmful for a Debian package, not helpful: it discards debugging
symbols that could otherwise have gone into a -dbgsym package, when
cross-compiling it uses the wrong strip(1) implementation (from the build
rather than host architecture), and it results in the nostrip option in
DEB_BUILD_OPTIONS being ignored (see Policy §4.9.1). Unconditionally
using INSTALL_PROGRAM = install would likely be better.

smcv

Bug#968530: mgetty: probably shouldn't use install -s

[Simon McVittie]

Source: mgetty
Version: 1.2.1-1
Severity: minor

A bug report against fteqcc (#968524) prompted me to look for other
instances of the same anti-pattern on codesearch.debian.net.

d/rules in mgetty invokes 'install -s' for some executables. However,
invoking 'install -s' is usually only harmful for a Debian package, not
helpful: it discards debugging symbols that could otherwise have gone
into a -dbgsym package, when cross-compiling it uses the wrong strip(1)
implementation (from the build rather than host architecture), and it
results in not respecting the nostrip item in DEB_BUILD_OPTIONS (Policy
§4.9.1). Using install without the -s option would likely be better.

smcv

Bug#937665: Waiting for Python 2-depending reverse dependencies

[Ben Finney]

Control: forcemerge -1 967200
Control: block -1 by 933750
Control: outlook -1 0

The updated package is ready, and waiting for reverse-dependencies (as
described in bug reports blocking this one) to drop Python 2 support.

On 16-Aug-2020, Jann Haber wrote:
> It seems like, there are no more rdeps of python-coverage now. Not
> sure about pypy-coverage.

Yes, I see no reverse dependencies for Python 2 ‘pypy-coverage’:

$ aptitude search '~Dpypy-coverage'

But one remaining for Python 2 ‘python-coverage’:

$ aptitude search '~Dpython-coverage'
p   paleomix

So, it seems we are waiting for ‘paleomix’ to drop Python 2 support. I
am recording bug#933750 as a blocker for bug#933750.

-- 
 \  “When I wake up in the morning, I just can't get started until |
  `\ I've had that first, piping hot pot of coffee. Oh, I've tried |
_o__)other enemas...” —Emo Philips |
Ben Finney 

signature.asc
Description: PGP signature

Bug#964248: marked as done (base-installer: Pass "--extra-suites=unreleased" to debootstrap on ports arches)

[Samuel Thibault]

Hello,

John Paul Adrian Glaubitz, le lun. 17 août 2020 00:38:15 +0200, a ecrit:
> This seems to have broken debian-installer on Debian Ports.
> 
> Installing the base system now fails with:
> 
> Aug 16 22:34:35 debootstrap: /usr/sbin/debootstrap --components=main 
> --debian-installer --resolve-deps 
> --include=debian-ports-archive-keyring,debian-ports-archive-keyring 
> --extra-suites=unreleased --no-check-gpg sid /target file:///cdrom/  
> Aug 16 22:34:40 base-installer: error: exiting on error 
> base-installer/debootstrap-failed 
>   
> Aug 16 22:34:41 main-menu[235]: WARNING **: Configuring 'bootstrap-base' 
> failed with error code 1  
>  
> Aug 16 22:34:41 main-menu[235]: WARNING **: Menu item 'bootstrap-base' failed.
> 
> Has this actually been tested to work?

AIUI it was only tested on the mini iso.


I noticed the issue, and worked on it, there is:

https://salsa.debian.org/images-team/debian-cd/-/merge_requests/7

and then a couple other changes, I'm waiting for the above to be merged
before I can submit them.

Samuel

Bug#968529: s3switch: probably shouldn't use install -s

[Simon McVittie]

Source: s3switch
Version: 0.1-1
Severity: normal

A bug report against fteqcc (#968524) prompted me to look for other
instances of the same anti-pattern on codesearch.debian.net.

d/rules in s3switch sets INSTALL_PROGRAM to 'install -s'. However,
invoking 'install -s' is usually only harmful for a Debian package,
not helpful: it discards debugging symbols that could otherwise
have gone into a -dbgsym package, and when cross-compiling it uses
the wrong strip(1) implementation (from the build rather than host
architecture). Unconditionally using INSTALL_PROGRAM = install would
likely be better. Or, you could just use

s3switch usr/bin

in debian/s3switch.install, and you wouldn't need the install step at all.

smcv

Bug#968528: multipath-tools: probably shouldn't use install -s

[Simon McVittie]

Source: multipath-tools
Version: 0.8.4-3
Severity: minor

A bug report against fteqcc (#968524) prompted me to look for other
instances of the same anti-pattern on codesearch.debian.net.

d/rules in multipath-tools sets INSTALL_PROGRAM to 'install -s'. However,
invoking 'install -s' is usually only harmful for a Debian package,
not helpful: it discards debugging symbols that could otherwise
have gone into a -dbgsym package, and when cross-compiling it uses
the wrong strip(1) implementation (from the build rather than host
architecture). Unconditionally using INSTALL_PROGRAM = install would
likely be better.

smcv

Bug#964248: marked as done (base-installer: Pass "--extra-suites=unreleased" to debootstrap on ports arches)

[John Paul Adrian Glaubitz]

Hi!

This seems to have broken debian-installer on Debian Ports.

Installing the base system now fails with:

Aug 16 22:34:35 debootstrap: /usr/sbin/debootstrap --components=main 
--debian-installer --resolve-deps 
--include=debian-ports-archive-keyring,debian-ports-archive-keyring 
--extra-suites=unreleased --no-check-gpg sid /target file:///cdrom/  
Aug 16 22:34:40 base-installer: error: exiting on error 
base-installer/debootstrap-failed   

Aug 16 22:34:41 main-menu[235]: WARNING **: Configuring 'bootstrap-base' failed 
with error code 1   
Aug 16 22:34:41 main-menu[235]: WARNING **: Menu item 'bootstrap-base' failed.

Has this actually been tested to work?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#968527: WebSocket in konqueror not working?

[christian_k...@gmx.net]

Package:    konqueror
Version: 4:18.12.0-1
Platform:   amd64


Hello,

I'm using JavaScript WebSockets to connect a web application to a target
within the LAN. To check the functionality of the browser,
I have visit the URL https://www.websocket.org/echo.html, containing a
small demo application. Here I can see the
notice "This browser supports WebSocket."

Following the instructions, I have pressed the "connect" button at
first. However, instead of the expected message "CONNECTED",
I see the message "ERROR: undefined" andtwo lines below "DISCONNECTED"
after some seconds.

In the configuration settings, I have not found a possibility to set
Websockets, but JavaScript is enabled. However, this demo page
seems to work with other browsers (Firefox, Opera).

I'm using Debian GNU/Linux 10.5, kernel 4.19.0-9-amd64.

Best regards,
Christian

Bug#968526: smartmontools: d/rules unnecessarily sets CFLAGS and INSTALL_PROGRAM

[Simon McVittie]

Package: smartmontools
Version: 7.1-1
Severity: minor

A bug report against fteqcc (#968524) prompted me to look for other
instances of the same anti-pattern on codesearch.debian.net. It looks
as though smartmontools is *mostly* a false positive, but there are some
improvements that could be made.

d/rules in smartmontools sets INSTALL_PROGRAM to 'install -s'. However,
this variable doesn't actually seem to be used for anything: if it was,
presumably no -dbgsym package would have been produced. I would suggest
just not setting it.

If there is a use that I have missed, invoking 'install -s' is usually
only harmful for a Debian package, not helpful: it discards debugging
symbols that could otherwise have gone into a -dbgsym package, and when
cross-compiling it uses the wrong strip(1) implementation (from the build
rather than host architecture). INSTALL_PROGRAM = install would likely be
better.

Similarly, smartmontools appends either -O0 or -O2 to CFLAGS, but there's
no need to do that, because dpkg-buildflags already chooses one of those
as appropriate for the presence or absence of noopt in DEB_BUILD_OPTIONS.

smcv

Bug#340947: Info received ()

[Phuong Phạm]

ow...@bugs.debian.org

Vào 05:30, T.2, 17 Th8, 2020 Debian Bug Tracking System <
ow...@bugs.debian.org> đã viết:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Apache Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 340...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 340947: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340947
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#340947: Info received ()

[Phuong Phạm]

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=0;bug=340947;msg=19

Vào 05:30, T.2, 17 Th8, 2020 Debian Bug Tracking System <
ow...@bugs.debian.org> đã viết:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Apache Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 340...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 340947: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340947
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#340947:

[Phuong Phạm]

 https://bugs.debian.org/cgi-bin/bugreport.cgi?att=0;bug=340947;msg=19

Bug#968106: phosh: Shell doesn't start

[Michel Le Bihan]

Hello,

With `sudo mmdebstrap --include=linux-image-amd64,live-boot,xserver-
xorg-video-all,phosh,gnome-session-bin,libglib2.0-bin,gnome-settings-
daemon,policykit-1,phosh-osk-stub --arch amd64 bullseye debian-live-
root http://ftp.pl.debian.org/debian/` I got a working phosh setup with
a 966M root.

Michel Le Bihan

Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

[Aurelien Jarno]

Package: lintian
Version: 2.90.0
Severity: normal
X-Debbugs-Cc: debian-gl...@lists.debian.org

Hi,

Since recent version of lintian, the following tags are reported against
the libc6-dev package:

W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libBrokenLocale.so -> 
lib/x86_64-linux-gnu/libBrokenLocale.so.1
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libanl.so -> 
lib/x86_64-linux-gnu/libanl.so.1
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libdl.so -> 
lib/x86_64-linux-gnu/libdl.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libmvec.so -> 
lib/x86_64-linux-gnu/libmvec.so.1
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnsl.so -> 
lib/x86_64-linux-gnu/libnsl.so.1
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnss_compat.so -> 
lib/x86_64-linux-gnu/libnss_compat.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnss_dns.so -> 
lib/x86_64-linux-gnu/libnss_dns.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnss_files.so -> 
lib/x86_64-linux-gnu/libnss_files.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnss_hesiod.so -> 
lib/x86_64-linux-gnu/libnss_hesiod.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnss_nis.so -> 
lib/x86_64-linux-gnu/libnss_nis.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnss_nisplus.so -> 
lib/x86_64-linux-gnu/libnss_nisplus.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libpthread.so -> 
lib/x86_64-linux-gnu/libpthread.so.0
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libresolv.so -> 
lib/x86_64-linux-gnu/libresolv.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/librt.so -> 
lib/x86_64-linux-gnu/librt.so.1
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libthread_db.so -> 
lib/x86_64-linux-gnu/libthread_db.so.1
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libutil.so -> 
lib/x86_64-linux-gnu/libutil.so.1

The library is shipped in /lib/$(DEB_HOST_MULTIARCH) and the .so
symlinks are shipped in /usr/lib/$(DEB_HOST_MULTIARCH):

lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libBrokenLocale.so -> 
/lib/x86_64-linux-gnu/libBrokenLocale.so.1
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libanl.so -> /lib/x86_64-linux-gnu/libanl.so.1
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libdl.so -> /lib/x86_64-linux-gnu/libdl.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libmvec.so -> /lib/x86_64-linux-gnu/libmvec.so.1
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libnsl.so -> /lib/x86_64-linux-gnu/libnsl.so.1
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libnss_compat.so -> 
/lib/x86_64-linux-gnu/libnss_compat.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libnss_dns.so -> 
/lib/x86_64-linux-gnu/libnss_dns.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libnss_files.so -> 
/lib/x86_64-linux-gnu/libnss_files.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libnss_hesiod.so -> 
/lib/x86_64-linux-gnu/libnss_hesiod.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libnss_nis.so -> 
/lib/x86_64-linux-gnu/libnss_nis.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libnss_nisplus.so -> 
/lib/x86_64-linux-gnu/libnss_nisplus.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libpthread.so -> 
/lib/x86_64-linux-gnu/libpthread.so.0
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libresolv.so -> /lib/x86_64-linux-gnu/libresolv.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/librt.so -> /lib/x86_64-linux-gnu/librt.so.1
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libthread_db.so -> 
/lib/x86_64-linux-gnu/libthread_db.so.1
lrwxrwxrwx root/root 0 2020-08-04 17:02 
./usr/lib/x86_64-linux-gnu/libutil.so -> /lib/x86_64-linux-gnu/libutil.so.1

Is it something not allowed anymore?

I know there are plans to (almost) empty /lib/ and move everything to
/usr/lib, but I am not sure we are there yet.

Thanks,
Aurelien


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

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

Versions of packages lintian depends on:
ii  binutils  2.35-1
ii  bzip2 1.0.8-4
ii  diffstat  1.63-1
ii  dpkg  1.20.5
ii  dpkg-dev 

Bug#968106: phosh: Shell doesn't start

[Michel Le Bihan]

Hello,

I added `--aptopt='Apt::Install-Recommends "true"'` to mmdebstrap
options, so my command was `sudo mmdebstrap --aptopt='Apt::Install-
Recommends "true"' --include=linux-image-amd64,live-boot,xserver-xorg-
video-all,phosh --arch amd64 bullseye debian-live-root 
http://ftp.pl.debian.org/debian/`. I ended up with a 2.5G root that had
gdm3 and gnome-shell that aren't quite useful or even wanted on mobile
devices. When I selected Phosh as my shell and entered my password,
Phosh didn't start and I ended up back on the login screen. I was able
to start gnome-shell normally.

Also, why would a package required for Phosh to function only be
recommended? Are there setups where Phosh can be started without those
packages being installed?

Michel Le Bihan

Bug#968524: fteqcc FTCBFS: strips with the wrong strip

[Helmut Grohne]

Source: fteqcc
Version: 3343+svn3400-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

fteqcc fails to cross build from source, because debian/rules strips via
install -s with the build architecture strip. Beyond breaking cross
compilation, this also breaks DEB_BUILD_OPTIONS=nocheck as well as
generation of -dbgsym packages. Please consider applying the attached
patch to drop the -s flag and fixing all of these issues as dh_strip
knows when to strip and how.

Helmut
diff --minimal -Nru fteqcc-3343+svn3400/debian/changelog 
fteqcc-3343+svn3400/debian/changelog
--- fteqcc-3343+svn3400/debian/changelog2020-08-10 12:15:41.0 
+0200
+++ fteqcc-3343+svn3400/debian/changelog2020-08-16 23:17:13.0 
+0200
@@ -1,3 +1,10 @@
+fteqcc (3343+svn3400-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 16 Aug 2020 23:17:13 +0200
+
 fteqcc (3343+svn3400-4) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru fteqcc-3343+svn3400/debian/rules 
fteqcc-3343+svn3400/debian/rules
--- fteqcc-3343+svn3400/debian/rules2020-08-10 12:15:41.0 +0200
+++ fteqcc-3343+svn3400/debian/rules2020-08-16 23:17:11.0 +0200
@@ -6,7 +6,7 @@
 
 override_dh_auto_install:
mkdir -p debian/fteqcc/usr/bin
-   install -s fteqcc.bin debian/fteqcc/usr/bin/fteqcc
+   install fteqcc.bin debian/fteqcc/usr/bin/fteqcc
 
 override_dh_auto_clean:
rm -f *.o fteqcc.bin fteqcc.log

Bug#968210: statsmodels: arm* test failures/crashes

[Rebecca N. Palmer]

The TestZeroInflatedModel_probit issue appears to be a failure to 
converge: as it does trigger warnings of that, and it's already skipped 
on i386, I intend to ignore it.


qemu-arm64:

>>> a
object at 0x4000d31130>

>>> a.res1.params
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'TestZeroInflatedModel_probit' object has no attribute 
'res1'

>>> a.setup_class()
/usr/lib/python3/dist-packages/statsmodels/base/model.py:567: 
ConvergenceWarning: Maximum Likelihood optimization failed to converge. 
Check mle_retvals

  warn("Maximum Likelihood optimization failed to converge. "
>>> a.res1.params
array([ 0.06225336, -0.64293239, -0.08217881,  0.00856726, -0.02679518,
1.4823691 ])
>>> 
alpha=np.ones(6);alpha[-2:]=0;res_reg=a.res1.model.fit_regularized(alpha=alpha*0.01,disp=0,maxiter=500)
/usr/lib/python3/dist-packages/statsmodels/base/l1_solvers_common.py:71: 
ConvergenceWarning: QC check did not pass for 4 out of 4 parameters
Try increasing solver accuracy or number of iterations, decreasing 
alpha, or switch solvers

  warnings.warn(message, ConvergenceWarning)
/usr/lib/python3/dist-packages/statsmodels/base/l1_solvers_common.py:144: 
ConvergenceWarning: Could not trim params automatically due to failed QC 
check. Trimming using trim_mode == 'size' will still work.

  warnings.warn(msg, ConvergenceWarning)
>>> res_reg.params
array([ 0.,  0.,  0.,  0., -0.02679517,
1.48236838])
>>> 
alpha=np.ones(6);alpha[-2:]=0;res_reg=a.res1.model.fit_regularized(alpha=alpha*0.0,disp=0,maxiter=500)

>>> res_reg.params
array([ 0.0622522 , -0.6429312 , -0.08217381,  0.00856762, -0.02679573,
1.48237116])
>>> 
alpha=np.ones(6);alpha[-2:]=0;res_reg=a.res1.model.fit_regularized(alpha=alpha*1e-6,disp=0,maxiter=500)
/usr/lib/python3/dist-packages/statsmodels/base/l1_solvers_common.py:71: 
ConvergenceWarning: QC check did not pass for 4 out of 4 parameters
Try increasing solver accuracy or number of iterations, decreasing 
alpha, or switch solvers

  warnings.warn(message, ConvergenceWarning)
/usr/lib/python3/dist-packages/statsmodels/base/l1_solvers_common.py:144: 
ConvergenceWarning: Could not trim params automatically due to failed QC 
check. Trimming using trim_mode == 'size' will still work.

  warnings.warn(msg, ConvergenceWarning)
/usr/lib/python3/dist-packages/statsmodels/base/l1_solvers_common.py:71: 
ConvergenceWarning: QC check did not pass for 4 out of 6 parameters
Try increasing solver accuracy or number of iterations, decreasing 
alpha, or switch solvers

  warnings.warn(message, ConvergenceWarning)
/usr/lib/python3/dist-packages/statsmodels/base/l1_solvers_common.py:144: 
ConvergenceWarning: Could not trim params automatically due to failed QC 
check. Trimming using trim_mode == 'size' will still work.

  warnings.warn(msg, ConvergenceWarning)
>>> res_reg.params
array([ 0.06225361, -0.64293282, -0.08218008,  0.0085677 , -0.02679533,
1.48236748])
>>> 
alpha=np.ones(6);alpha[-2:]=0;res_reg=a.res1.model.fit_regularized(alpha=alpha*1,disp=0,maxiter=500)
/usr/lib/python3/dist-packages/statsmodels/base/l1_solvers_common.py:71: 
ConvergenceWarning: QC check did not pass for 2 out of 4 parameters
Try increasing solver accuracy or number of iterations, decreasing 
alpha, or switch solvers

  warnings.warn(message, ConvergenceWarning)
/usr/lib/python3/dist-packages/statsmodels/base/l1_solvers_common.py:144: 
ConvergenceWarning: Could not trim params automatically due to failed QC 
check. Trimming using trim_mode == 'size' will still work.

  warnings.warn(msg, ConvergenceWarning)
>>> res_reg.params
array([ 0., -0.64270273, -0.08204933,  0., -0.02679321,
1.48237335])
>>> 
alpha=np.ones(6);alpha[-2:]=0;res_reg=a.res1.model.fit_regularized(alpha=alpha*100,disp=0,maxiter=500)

>>> res_reg.params
array([ 0.05531257, -0.62025715, -0.06936752,  0.00781262, -0.02661252,
1.48282813])
>>> 
alpha=np.ones(6);alpha[-2:]=0;res_reg=a.res1.model.fit_regularized(alpha=alpha*1e-4,disp=0,maxiter=500)
/usr/lib/python3/dist-packages/statsmodels/base/l1_solvers_common.py:71: 
ConvergenceWarning: QC check did not pass for 4 out of 4 parameters
Try increasing solver accuracy or number of iterations, decreasing 
alpha, or switch solvers

  warnings.warn(message, ConvergenceWarning)
/usr/lib/python3/dist-packages/statsmodels/base/l1_solvers_common.py:144: 
ConvergenceWarning: Could not trim params automatically due to failed QC 
check. Trimming using trim_mode == 'size' will still work.

  warnings.warn(msg, ConvergenceWarning)
/usr/lib/python3/dist-packages/statsmodels/base/l1_solvers_common.py:71: 
ConvergenceWarning: QC check did not pass for 4 out of 6 parameters
Try increasing solver accuracy or number of iterations, decreasing 
alpha, or switch solvers

  warnings.warn(message, ConvergenceWarning)
/usr/lib/python3/dist-packages/statsmodels/base/l1_solvers_common.py:144: 
ConvergenceWarning: Could not trim params 

Bug#968523: ITP: libnsl -- Public client interface for NIS(YP) and NIS+

[Aurelien Jarno]

Package: wnpp
Severity: wishlist
Owner: Aurelien Jarno 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-gl...@lists.debian.org

* Package name: libnsl
  Version : 1.3.0
  Upstream Author : Thorsten Kukuk 
* URL : https://github.com/thkukuk/libnsl
* License : LGPL-2.1, LGPL-2.1+, BSD-3-clause
  Programming Lang: C 
  Description : Public client interface for NIS(YP) and NIS+

This package contains the libnsl library, which contains the public
client interface for NIS(YP) and NIS+. This code was formerly part of
glibc, but is now standalone to be able to link against TI-RPC for IPv6
support.

glibc 2.32 removed support for linking against the libnsl.so.1 library,
although the library is still shipped. The libnsl library, providing
libnsl.so.2 (so that it is co-installable), now replaces it.

This package will be maintained within the glibc team.

Bug#968519: dropbear-initramfs: race condition prevents launch at boot

[Guilhem Moulin]

Hi,

On Sun, 16 Aug 2020 at 12:31:38 -0700, Forest wrote:
> When it fails, I see this message repeated several times, scattered
> between various other messages on the serial console:
> 
> ipconfig: no devices to configure
> 
> Finally, this message appears:
> 
> /scripts/init-premount/dropbear: .: line 279:
> can't open '/run/net-*.conf': No such file or directory

This comes from initramfs-tools's configure_networking()
https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/v0.137/scripts/functions#L279

> However, editing /usr/share/initramfs-tools/scripts/init-premount/dropbear
> does get it working. Making that script wait for a /run/net-*.conf file to
> appear before it calls configure_networking appears to be a solution.

No idea if that's a valid workaround, but I don't think that's something
to implement in dropbear-initramfs: presumably NFS rootfs are affected
as well on your hardware, in which case it has nothing do with
dropbear-initramfs (nor cryptsetup/LUKS).

> Based on this workaround and the fact that the aforementioned error messages
> are interleaved with other boot messages, it looks to me like dropbear's
> init-premount script is being run in parallel with driver and network setup,
> and often executing before the rk3399's onboard ethernet has a chance to
> finish initializing.

configure_networking() is run in the backround, yup (and the dropbear
server is started afterwards if successful) see #806884.  But that's done
at init-premount stage, after udev and the required modules are loaded.
Is your network interface brought up by a script in init-premount or
local-top?

Please also try the attached patch (with and without delay).  If this
alone doesn't help BUT the addition of some delay *before* running
configure_networking() fixes the race condition, then this bug should
probably reassigned to initramfs-tools.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#968522: libextractor: disable apparmor support on !linux archs

[Pino Toscano]

Source: libextractor
Version: 1:1.10-1
Severity: minor
Tags: patch

Hi,

AppArmor is a Linux Security Manager, and as such it is specific for
Linux. Hence, enable the AppArmor support only on Linux, as it is
useless on non-Linux architectures.

Thanks,
-- 
Pino
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Bertrand Marc 

Bug#967082: grub-customizer: dmesg has error info:segfault at 50 ip 0000558a7f3024e1

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look, but can just tell the location,
the dmesg output points to, is the following location.
And at this point the register rdi contains the value of "this",
at the submitters system 0x50, therefore causing the segfault.

Maybe install debug symbols and running at submitters system
inside valgrind could give some more pointers ... [1].

Kind regards,
Bernhard


Thread 1 "grub-customizer" hit Breakpoint 1, 
Trait_ActionLoggerAware::logActionBegin (action="update-timeout-setting", 
this=0x55f619eb7680) at 
./src/main/../Controller/Common/../../lib/Trait/ActionLoggerAware.hpp:42
42  
this->logger->logActionBegin(this->_controllerName, action);
1: x/i $pc
=> 0x55f6199c94e1 :
mov(%rdi),%rax
(gdb) bt
#0  0x55f6199c94e1 in 
Trait_ActionLoggerAware::logActionBegin(std::__cxx11::basic_string, std::allocator > const&) const 
(action="update-timeout-setting", this=0x55f619eb7680) at 
./src/main/../Controller/Common/../../lib/Trait/ActionLoggerAware.hpp:42
#1  0x55f6199c94e1 in SettingsController::updateTimeoutSettingAction() 
(this=0x55f619eb7680) at ./src/main/../Controller/SettingsController.hpp:285
...

[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols


# Buster/stable amd64 qemu VM 2020-08-16


apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg openbox xterm mc gdb 
grub-customizer grub-customizer-dbgsym
apt build-dep grub-customizer



mkdir /home/benutzer/source/grub-customizer/orig -p
cd/home/benutzer/source/grub-customizer/orig
apt source grub-customizer
cd



export DISPLAY=:0
export XAUTHORITY=/home/benutzer/.Xauthority
export LANG=zh_CN.utf8

grub-customizer




echo -n "find /b ..., ..., 0x" && \
echo "00 48 89 84 24 98 00 00 00 31 c0 48 8d 6c 24 40 48 8d 45 10 48 89 ef 48 
89 44 24 40 e8 e8 bb fa ff 48 8b 7b 08 48 85 ff 74 0d <48> 8b 07 48 8d 73 18 48 
89 ea ff 50 18 48 8b 7c 24 40 48 8d 45 10" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'

find /b ..., ..., 0x00, 0x48, 0x89, 0x84, 0x24, 0x98, 0x00, 0x00, 0x00, 0x31, 
0xc0, 0x48, 0x8d, 0x6c, 0x24, 0x40, 0x48, 0x8d, 0x45, 0x10, 0x48, 0x89, 0xef, 
0x48, 0x89, 0x44, 0x24, 0x40, 0xe8, 0xe8, 0xbb, 0xfa, 0xff, 0x48, 0x8b, 0x7b, 
0x08, 0x48, 0x85, 0xff, 0x74, 0x0d, 0x48, 0x8b, 0x07, 0x48, 0x8d, 0x73, 0x18, 
0x48, 0x89, 0xea, 0xff, 0x50, 0x18, 0x48, 0x8b, 0x7c, 0x24, 0x40, 0x48, 0x8d, 
0x45, 0x10



gdb -q --pid $(pidof grub-customizer)

(gdb) directory /home/benutzer/source/grub-customizer/orig/grub-customizer-5.1.0

(gdb) info target
Entry point: 0x560dab1723e0
0x55f6198a82a8 - 0x55f6198a82c4 is .interp
...
0x55f619a9d0e0 - 0x55f619a9d230 is .bss
0x7ffb4989d238 - 0x7ffb4989d25c is .note.gnu.build-id in 
/lib/x86_64-linux-gnu/libgtkmm-3.0.so.1
...

(gdb) find /b 0x55f6198a82a8, 0x55f619a9d230, 0x00, 0x48, 0x89, 0x84, 
0x24, 0x98, 0x00, 0x00, 0x00, 0x31, 0xc0, 0x48, 0x8d, 0x6c, 0x24, 0x40, 0x48, 
0x8d, 0x45, 0x10, 0x48, 0x89, 0xef, 0x48, 0x89, 0x44, 0x24, 0x40, 0xe8, 0xe8, 
0xbb, 0xfa, 0xff, 0x48, 0x8b, 0x7b, 0x08, 0x48, 0x85, 0xff, 0x74, 0x0d, 0x48, 
0x8b, 0x07, 0x48, 0x8d, 0x73, 0x18, 0x48, 0x89, 0xea, 0xff, 0x50, 0x18, 0x48, 
0x8b, 0x7c, 0x24, 0x40, 0x48, 0x8d, 0x45, 0x10
0x55f6199c94b7 
1 pattern found.

(gdb) b * (0x55f6199c94b7 + 42)
Breakpoint 2 at 0x560dab1ee4e1: file 
./src/main/../Controller/Common/../../lib/Trait/ActionLoggerAware.hpp, line 42.
(gdb) cont

(gdb) cont
Continuing.
[Thread 0x7ffb43244700 (LWP 19172) exited]
[New Thread 0x7ffb43244700 (LWP 19174)]

Thread 1 "grub-customizer" hit Breakpoint 1, 
Trait_ActionLoggerAware::logActionBegin (action="update-timeout-setting", 
this=0x55f619eb7680)
at ./src/main/../Controller/Common/../../lib/Trait/ActionLoggerAware.hpp:42
42  
this->logger->logActionBegin(this->_controllerName, action);
1: x/i $pc
=> 0x55f6199c94e1 :
mov(%rdi),%rax
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  0x55f6199c94e1 in 
Trait_ActionLoggerAware::logActionBegin(std::__cxx11::basic_string, std::allocator > const&) const 
(action="update-timeout-setting", this=0x55f619eb7680) at 
./src/main/../Controller/Common/../../lib/Trait/ActionLoggerAware.hpp:42
#1  0x55f6199c94e1 in SettingsController::updateTimeoutSettingAction() 
(this=0x55f619eb7680) at ./src/main/../Controller/SettingsController.hpp:285
#2  0x7ffb49793dc8 in 
Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () at 
/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#3  0x7ffb495bdc8d in g_closure_invoke () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x7ffb495d0e64 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x7ffb495da2be in g_signal_emit_valist () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x7ffb495da97f in g_signal_emit () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x7ffb487a5fc0 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#8  

Bug#968053: [Help] Re: seqan autopkg test failures triggered by gcc-defaults

[Aaron M. Ucko]

Andreas Tille  writes:

> make[4]: *** [test/view/CMakeFiles/view.chunk.dir/build.make:66: 
> test/view/CMakeFiles/view.chunk.dir/chunk.cpp.o] Error 1

I can reproduce this error (below), which parallel make somewhat buries,
but don't have a suggested fix offhand, sorry.

In file included from /.../include/range/v3/range/concepts.hpp:37,
 from /.../include/range/v3/action/concepts.hpp:23,
 from /.../include/range/v3/range/conversion.hpp:23,
 from /.../test/view/chunk.cpp:16:
/.../include/range/v3/iterator/concepts.hpp: In instantiation of ‘constexpr 
const bool 
ranges::forward_iterator, false>::outer_cursor> >’:
[...]
/.../include/range/v3/range/concepts.hpp:88:21:   required from ‘constexpr 
const bool ranges::input_range > 
>’
/.../test/view/chunk.cpp:41:9:   required from here
/.../include/range/v3/iterator/concepts.hpp:334:9: error: the value of 
‘ranges::input_iterator, false>::outer_cursor> >’ is not usable in a constant expression
  334 | input_iterator &&
  | ^
/.../include/range/v3/iterator/concepts.hpp:327:17: note: 
‘ranges::input_iterator, false>::outer_cursor> >’ used in its own initializer
  327 | CPP_concept input_iterator =
  | ^~

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

Bug#968521: linux-image-4.19.0-10-cloud-amd64: not listening to ACPI shutdown

[Alexandre IOOSS]

Package: src:linux
Version: 4.19.132-1
Severity: important

Dear Maintainer,

When a new virtual machine is created using Debian Cloud image
(debian-10-openstack-amd64.qcow2) it ships with linux-image-cloud-amd64.
On the one hand, this looks nice as it deactivates many useless kernel modules,
but on the other hand, our Proxmox host (using KVM) is not able to send a
shutdown signal.

When removing linux-image-cloud-amd64 (and
linux-image-4.19.0-10-cloud-amd64) and installing linux-image-amd64,
then Proxmox can shut down the virtual machine.

This seems to be quite an annoying bug as it forces the user to remove a
cloud-optimized kernel to be able to shut down virtual machines from the
host.

I expected that the Debian Cloud-optimized kernel works well with
Proxmox, and it is not the case.

-- Package-specific info:
** Version:
Linux version 4.19.0-10-cloud-amd64 (debian-ker...@lists.debian.org) (gcc 
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.132-1 (2020-07-24)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-cloud-amd64 
root=UUID=42338e15-f98e-4b67-a46a-ea8f4a4225af ro nosplash text biosdevname=0 
net.ifnames=0 console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200 
consoleblank=0 systemd.show_status=true

** Not tainted

** Kernel log:
[1.380168] NET: Registered protocol family 17
[1.382207] mpls_gso: MPLS GSO support
[1.383914] sched_clock: Marking stable (1361387673, 20661333)->(1382940204, 
-891198)
[1.387713] registered taskstats version 1
[1.389518] Loading compiled-in X.509 certificates
[1.482539] Loaded X.509 cert 'Debian Secure Boot CA: 
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[1.486021] Loaded X.509 cert 'Debian Secure Boot Signer 2020: 00b55eb3b9'
[1.488780] AppArmor: AppArmor sha1 policy hashing enabled
[1.491830] rtc_cmos 00:00: setting system clock to 2020-08-16 19:35:09 UTC 
(1597606509)
[1.499376] Freeing unused kernel image memory: 1472K
[1.517096] Write protecting the kernel read-only data: 16384k
[1.522820] Freeing unused kernel image memory: 2028K
[1.525762] Freeing unused kernel image memory: 1340K
[1.528269] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[1.531018] x86/mm: Checking user space page tables
[1.533133] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[1.535686] Run /init as init process
[1.745256] SCSI subsystem initialized
[1.763647] libata version 3.00 loaded.
[1.767305] ata_piix :00:01.1: version 2.13
[1.770999] scsi host0: ata_piix
[1.772101] scsi host1: ata_piix
[1.772923] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xe100 irq 14
[1.774285] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xe108 irq 15
[1.783433] PCI Interrupt Link [LNKC] enabled at IRQ 11
[1.808934] PCI Interrupt Link [LNKA] enabled at IRQ 10
[1.834355] PCI Interrupt Link [LNKD] enabled at IRQ 11
[1.860095] PCI Interrupt Link [LNKB] enabled at IRQ 10
[1.896526] scsi host2: Virtio SCSI HBA
[1.899003] scsi 2:0:0:0: Direct-Access QEMU QEMU HARDDISK2.5+ 
PQ: 0 ANSI: 5
[1.901025] scsi 2:0:0:1: Direct-Access QEMU QEMU HARDDISK2.5+ 
PQ: 0 ANSI: 5
[1.917925] random: fast init done
[1.933879] ata1.01: NODEV after polling detection
[1.934252] ata1.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100
[1.936621] scsi 0:0:0:0: CD-ROMQEMU QEMU DVD-ROM 2.5+ 
PQ: 0 ANSI: 5
[1.946146] sd 2:0:0:0: Power-on or device reset occurred
[1.947729] sd 2:0:0:1: Power-on or device reset occurred
[1.949614] sd 2:0:0:0: [sda] 10485760 512-byte logical blocks: (5.37 
GB/5.00 GiB)
[1.951235] sd 2:0:0:0: [sda] Write Protect is off
[1.951238] sd 2:0:0:1: [sdb] 33554432 512-byte logical blocks: (17.2 
GB/16.0 GiB)
[1.952231] sd 2:0:0:0: [sda] Mode Sense: 63 00 00 08
[1.953834] sd 2:0:0:1: [sdb] Write Protect is off
[1.954824] sd 2:0:0:1: [sdb] Mode Sense: 63 00 00 08
[1.954897] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[1.956723] sd 2:0:0:1: [sdb] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[1.961032] sr 0:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
[1.961759]  sda: sda1
[1.962809] cdrom: Uniform CD-ROM driver Revision: 3.20
[1.964743]  sdb: sdb1
[1.964971] sr 0:0:0:0: Attached scsi CD-ROM sr0
[1.969214] sd 2:0:0:0: [sda] Attached SCSI disk
[1.970485] sd 2:0:0:1: [sdb] Attached SCSI disk
[2.158540] cryptd: max_cpu_qlen set to 1000
[2.335065] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
(null)
[2.574347] systemd[1]: Inserted module 'autofs4'
[2.608224] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 
default-hierarchy=hybrid)
[2.616291] systemd[1]: Detected 

Bug#968520: nmu: rust-xml-rs_0.8.0-1 and rust-rusty-tags_3.5.1-2

[Adrian Bunk]

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

nmu rust-xml-rs_0.8.0-1 . ANY . unstable . -m "Rebuild for updating Built-Using"
nmu rust-rusty-tags_3.5.1-2 . ANY . unstable . -m "Rebuild for updating 
Built-Using"

These were forcing to keep old rustc versions as Extra-Source-Only.

Bug#961386: fontconfig-config: 60-latin.conf should prefer the most complete font DejaVu

[Vincent Lefevre]

Control: tags -1 upstream fixed-upstream
Control: forwarded -1 
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/26

On 2020-05-23 22:56:19 +0200, Vincent Lefevre wrote:
> Since fonts-dejavu 2.37-2, 60-latin.conf is no longer overridden
> by the default fonts-dejavu-core configuration. As a consequence,
> Bitstream Vera is preferred to DejaVu, e.g. for monospace:
> 
> 
> monospace
> 
> Bitstream Vera Sans Mono
> DejaVu Sans Mono
> Inconsolata
> Andale Mono
> Courier New
> Cumberland AMT
> Luxi Mono
> Nimbus Mono L
> Nimbus Mono
> Nimbus Mono PS
> Courier
> 
> 
> 
> This is an issue since Bitstream Vera is very incomplete, at least
> compared to DejaVu.

Moreover, it does not have true italics, which can be rather ugly when
this is used for math formulas (as in some cases on Wikipedia).

This is now fixed upstream by dropping Bitstream Vera:

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/fcb042028126d79ea5a5fa015b2b034b98656e73

So the default is now DejaVu.

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

Bug#968519: dropbear-initramfs: race condition prevents launch at boot

[Forest]

Package: dropbear-initramfs
Version: 2020.80-1
Severity: important

Dear Maintainer,

About four times out of five, dropbear fails to launch at boot on the
RockPro64 single-board computer. When it fails, I see this message
repeated several times, scattered between various other messages on the
serial console:

  ipconfig: no devices to configure

Finally, this message appears:

  /scripts/init-premount/dropbear: .: line 279:
  can't open '/run/net-*.conf': No such file or directory

The system then proceeds to the luks unlock prompt at the serial console
only, with dropbear not running, so the boot process will not continue
unless I connect a serial console and enter the password that way.

I have tried adding all my ethernet-related driver modules to
/etc/initramfs-tools/modules and rebuilding initramfs, but it
didn't help. I have tried using ip= kernel command line arguments
for a static address instead of DHCP, but that didn't help either.

However, editing /usr/share/initramfs-tools/scripts/init-premount/dropbear
does get it working. Making that script wait for a /run/net-*.conf file to
appear before it calls configure_networking appears to be a solution.
Even just sleeping for a few seconds before the configure_networking call
seems to work, though I don't know how consistently.

Based on this workaround and the fact that the aforementioned error messages
are interleaved with other boot messages, it looks to me like dropbear's
init-premount script is being run in parallel with driver and network setup,
and often executing before the rk3399's onboard ethernet has a chance to
finish initializing.


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

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

Versions of packages dropbear-initramfs depends on:
ii  busybox  1:1.30.1-5
ii  dropbear-bin 2020.80-1
ii  initramfs-tools  0.137
ii  udev 246-2

Versions of packages dropbear-initramfs recommends:
ii  cryptsetup-initramfs  2:2.3.3-1

dropbear-initramfs suggests no packages.

-- Configuration Files:
/etc/dropbear-initramfs/config changed:
DROPBEAR_OPTIONS="-p 222"


-- no debconf information

Bug#942689: INHERITANCE......

[Boris esq]

-- 
Attn: confidential attachment enclosed..


INHERITANCE (2)docnew.docx
Description: MS-Word 2007 document

Bug#968506: RFS: re2c/2.0.2-1 -- lexer generator for C, C++ and Go

[JCF Ploemen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: re2c
   Version : 2.0.2-1
   Upstream Author : https://github.com/skvadrik/re2c
 * URL : https://re2c.org
 * License : public-domain, Zend-2.00, Apache-2, PHP-3.01
 * Vcs : https://salsa.debian.org/jcfp/re2c
   Section : devel

It builds those binary packages:

  re2c - lexer generator for C, C++ and Go

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/r/re2c/re2c_2.0.2-1.dsc

Changes since the last upload:

 re2c (2.0.2-1) unstable; urgency=medium
 .
   * New upstream release.
   * Patches: remove 01 (fix released upstream), refresh 02.
   * Copyright:
 + account for renamed test files.
 + update current upstream maintainer info.
   * Control: refresh description, mention newly added support for Go.
   * Rules: don't install the __run_all scripts with the examples.


Thanks!


pgp58BcD1qTOu.pgp
Description: OpenPGP digital signature

Bug#966291: Next report

[Alexey Kuznetsov]

>From 26 Jul 2020 to 14 Aug I used to run Ubuntu 20.04. And have no issues
with 'debsums -c' nor 'Path of Exile' self check. Then I reinstall debian
completely (clean super duper install) using debootstrap and keep it
running since. Two days later. On a day (today) 16 aug I ran booth debsums
and POE PackCheck.exe and it failed:


Checking pack file Content.ggpk...
/Art/particles/ground_effects_v2/desecrated_maligaro/rot_03.dds hash isn't
in sync. Repaired.
/Art/particles/ground_effects_v2/desecrated_maligaro hash isn't in sync.
Repaired.
/Art/particles/ground_effects_v2 hash isn't in sync. Repaired.
/Art/particles hash isn't in sync. Repaired.
/Art hash isn't in sync. Repaired.
/ShaderCacheD3D11.packed/15.dat hash isn't in sync. Repaired.
/ShaderCacheD3D11.packed hash isn't in sync. Repaired.
Fatal error: Your pack file has become corrupted. Currently the only way to
fix this is to delete Content.ggpk and download it again by running the
client.


Looks like Debian + my ssd has serious issues and not working
properly together. I have no idea what to do next. Dmesg log attached. I
also run logwatch on my debian distro and it did not report any issues.

5.4.0-0.bpo.4-amd64

-- AK


dmesg.log.gz
Description: application/gzip

Bug#932837: xscreensaver: No text on lock screen

[Jamie Zawinski]

> Well, that “set of garbage fonts” is fine for XScreenSaver 5.36…

I assure you, I did not write all that code for shits and giggles, but to fix 
an actual problem people were experiencing on font-bereft systems like yours.

>> so it would be helpful if you send me the output of xlsfonts on your 
>> system where it's doing something terrible.
> 
> Here it is.

Well, that set of fonts is, in fact, garbage, but I think it should have fallen 
back to -misc-fixed-medium-r-normal-*-*-*-*-*-c-*-iso10646-1

--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#968116: systemd: Not generating service for XDG autostart

[Michael Biebl]

Control: tags -1 + moreinfo

Am 09.08.20 um 10:10 schrieb Francois Mescam:
> Package: systemd
> Version: 246-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Since systemd 246-2 I have messages like these in the logs :
> 
> Aug  9 08:46:18 eiffel7 systemd[24828]: Configuration file
> /etc/xdg/autostart/org.kde.discover.notifier.desktop is marked
> executable. Please remove executable permission bits. Proceeding
> +anyway.
> Aug  9 08:46:18 eiffel7 systemd[24828]:
> gnome-systemd-autostart-condition not found: No such file or directory
> Aug  9 08:46:18 eiffel7 systemd[24828]: kde-systemd-start-condition not
> found: No such file or directory
> Aug  9 08:46:18 eiffel7 systemd[24828]: Not generating service for XDG
> autostart app-at\x2dspi\x2ddbus\x2dbus-autostart.service, startup phases
> are not supported.
> Aug  9 08:46:18 eiffel7 systemd[24828]: Not generating service for XDG
> autostart app-gnome\x2dkeyring\x2dpkcs11-autostart.service, startup
> phases are not supported.
> Aug  9 08:46:18 eiffel7 systemd[24828]: Not generating service for XDG
> autostart app-gnome\x2dkeyring\x2dsecrets-autostart.service, startup
> phases are not supported.
> Aug  9 08:46:18 eiffel7 systemd[24828]: Not generating service for XDG
> autostart app-gnome\x2dkeyring\x2dssh-autostart.service, startup phases
> are not supported.
> Aug  9 08:46:18 eiffel7 systemd[24828]: Not generating service for XDG
> autostart app-powerdevil-autostart.service, only Type=Application is
> supported.
> Aug  9 08:46:18 eiffel7 systemd[24828]: Not generating service for XDG
> autostart app-pulseaudio-autostart.service, startup phases are not
> supported.
> Aug  9 08:46:18 eiffel7 systemd[24828]: Not generating service for XDG
> autostart app-xdg\x2duser\x2ddirs-autostart.service, startup phases are
> not supported.
> Aug  9 08:46:18 eiffel7 systemd[24828]: Not generating service for XDG
> autostart app-xfce4\x2dclipman\x2dplugin\x2dautostart-autostart.service,
> it is hidden.
> Aug  9 08:46:18 eiffel7 systemd[24828]: Not generating service for XDG
> autostart app-xfce4\x2dnotes\x2dautostart-autostart.service, it is
> hidden.
> Aug  9 08:46:18 eiffel7 systemd[24828]: Not generating service for XDG
> autostart app-xscreensaver-autostart.service, could not find TryExec=
> binary xscreensaver: No such file or directory
> 
> I don't know if this is really a bug or if I have something to do to
> correct this question.

Not quite sure what this bug report is about, tbh.
Are you asking for these log messages to be downgraded to debug level so
you don't see them?
I don't really see the bug here, just the generator logging why it
doesn't generate service files for certain autostart files.
What is systemd package supposed to change here?

Michael




signature.asc
Description: OpenPGP digital signature

Bug#968508: blender-data: Please only recommend blender instead of python3

[Mattia Rizzolo]

On Sun, Aug 16, 2020 at 05:47:17PM +0200, Elrond wrote:
> On Sun, Aug 16, 2020 at 17:35:32 +0200, Jonas Smedegaard wrote:
> > Quoting Elrond (2020-08-16 17:16:26)
> > > On the other hand, blender-data does not need to depend on python3. 
> > > Yes, there are some python scripts in there, but they do only make 
> > > sense together with blender.
> > 
> > If blender-data contains scripts which require Python3 to run, then it 
> > must declare either Depends or Recommends on python3.
> > 
> > 
> > > If you want to keep the python3 dep, please turn it into
> > > python3:any, and also into a Recommends. Recommends means
> > > "You really should install this. If you don't, expect
> > > missing functionality", which seems right then.
> > 
> > If those python3 scripts are not always used, then it makes sense to 
> > relax to only recommend python3.
> 
> TBH I am not 100% sure, if they're not always used. I might
> try sometime soon.

Either way, here is the problem:
the source control file has
Package: blender-data
Architecture: all
Depends: python3,
 ${misc:Depends},
 ${python3:Depends}
Note how it also has ${python3:Depends}.  That substvar should be
expanded to "python3:any" (with an appropriate version restriction if
deemed needed by the tooling), and the helper that is supposed to fill
in that substvar is dh_python3.
dh_python3 is already called by the rules file, but the scripts are all
in private locations; dh_python3 doesn't look into private directories
that are not named after the binary package name, so it needs to be
instructed as such, by adding an override and pass the private dirs
(looking at the file list, I guess `/usr/share/blender/scripts/` is
enough, but should be tested) as arguments of dh_python3, and then
python3:any will be added to the python3:Depends substvar.  After that,
the explicit python3 dep can go away.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#968106: [Debian-on-mobile-maintainers] Bug#968106: phosh: Shell doesn't start

[Guido Günther]

Hi Bernhard,
On Sun, Aug 16, 2020 at 05:28:13PM +0200, Bernhard Übelacker wrote:
> Hello Michel Le Bihan,
> found this issue interesting and tried to get more information.
> 
> First the "trap int3" originates from here [1], and seems just
> a consequence of missing packages.
> 
> When installing following packages the user interface
> could successfully start, without changing the VM vga "hardware".
> 
>   systemctl stop phosh
>   apt update
>   apt install --no-install-recommends --no-install-suggests gnome-session-bin 
> libglib2.0-bin gnome-settings-daemon policykit-1 phosh-osk-stub
>   systemctl start phosh

Thanks for investigating. This brings up the issue if phosh should pull
in enough of gnome session to have the session file work and i think it
should. I'll add this to the next upload. We'll go with phosh-osk-stub
for now and do

squeekboard | phosh-osk-stub

once squeekboard is accepted.

I think we don't need the libglib2.0-bin and policykit-1 dependencies, right?

Cheers,
 -- Guido

> 
> Kind regards,
> Bernhard
> 
> 
> [1]
> (gdb) bt
> #0  _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
> #1  0x7f161ac595f5 in g_log_default_handler 
> (log_domain=log_domain@entry=0x55b43a8e7164 "phoc-server", 
> log_level=log_level@entry=6, message=message@entry=0x55b43b7dc1d0 "Could not 
> create backend", unused_data=unused_data@entry=0x0) at ../../..
> /glib/gmessages.c:3123
> #2  0x7f161ac5983c in g_logv (log_domain=0x55b43a8e7164 
> "phoc-server", log_level=G_LOG_LEVEL_ERROR, format=, 
> args=args@entry=0x7ffdc3657270) at ../../../glib/gmessages.c:1350
> #3  0x7f161ac59a1f in g_log 
> (log_domain=log_domain@entry=0x55b43a8e7164 "phoc-server", 
> log_level=log_level@entry=G_LOG_LEVEL_ERROR, 
> format=format@entry=0x55b43a8e7170 "Could not create backend") at 
> ../../../glib/gmessages.c:1415
> #4  0x55b43a8d1502 in phoc_server_constructed (object=0x55b43b7d8010) 
> at ../src/server.c:139
> #5  0x7f161ad41704 in g_object_new_internal 
> (class=class@entry=0x55b43b7d7b70, params=params@entry=0x0, 
> n_params=n_params@entry=0) at ../../../gobject/gobject.c:1977
> #6  0x7f161ad42f0d in g_object_new_with_properties 
> (object_type=94232580553008, n_properties=0, names=names@entry=0x0, 
> values=values@entry=0x0) at ../../../gobject/gobject.c:2105
> #7  0x7f161ad43961 in g_object_new (object_type=, 
> first_property_name=first_property_name@entry=0x0) at 
> ../../../gobject/gobject.c:1777
> #8  0x55b43a8d17ed in phoc_server_get_default () at 
> ../src/server.c:212
> #9  0x55b43a8d0f89 in main (argc=, argv= out>) at ../src/main.c:131

> 
> # Bullseye/testing amd64 qemu VM 2020-08-16
> 
> 
> apt update
> apt dist-upgrade
> 
> 
> apt install systemd-coredump mmdebstrap squashfs-tools sddm xserver-xorg 
> openbox xterm mc qemu-system-x86
> 
> 
> su -
> mkdir /home/benutzer/test
> cd/home/benutzer/test
> 
> mmdebstrap --include=linux-image-amd64,live-boot,xserver-xorg-video-all,phosh 
> --arch amd64 sid debian-live-root 
> http://192.168.178.25:/debian-11-bullseye-deb.debian.org/
> 
> 
> root@debian:/home/benutzer/test# mmdebstrap 
> --include=linux-image-amd64,live-boot,xserver-xorg-video-all,phosh --arch 
> amd64 sid debian-live-root 
> http://192.168.178.25:/debian-11-bullseye-deb.debian.org/
> I: automatically chosen mode: root
> I: chroot architecture amd64 is equal to the host's architecture
> I: running apt-get update...
> done
> I: downloading packages with apt...
> done
> I: extracting archives...
> done
> I: installing packages...
> done
> I: downloading apt...
> done
> I: installing apt...
> done
> I: installing remaining packages inside the chroot...
> done
> I: cleaning package lists and apt cache...
> done
> done
> 
> 
> chroot debian-live-root passwd
> chroot debian-live-root useradd -m -s /bin/bash -p $(openssl passwd -1 
> 123456) user
> chroot debian-live-root systemctl enable phosh
> cp debian-live-root/vmlinuz .
> cp debian-live-root/initrd.img .
> mksquashfs debian-live-root root.squashfs -comp lz4
> exit
> 
> cd /home/benutzer/test
> python3 -m http.server -b localhost 8080
> 
> cd /home/benutzer/test
> export DISPLAY=:0
> qemu-system-x86_64 \
> -machine accel=kvm \
> -m 2G \
> -device virtio-net-pci,netdev=net0 \
> -serial stdio -monitor vc \
> -netdev 
> user,id=net0,hostfwd=tcp::-:22,guestfwd=tcp:10.0.2.252:8080-tcp:localhost:8080,hostname=debian-live
>  \
> -kernel ./vmlinuz \
> -initrd ./initrd.img \
> -append "console=ttyS0 ip=frommedia boot=live nopersistence 
> fetch=http://10.0.2.252:8080/root.squashfs;
> 
> 
> 
> 
> [   28.531593] traps: phoc[354] trap int3 ip:7f45cbc70585 sp:7fff27e0a260 
> error:0 in libglib-2.0.so.0.6400.4[7f45cbc36000+81000]
> [   33.884796] traps: phoc[373] trap int3 ip:7f136d421585 sp:7ffce5012e30 
> error:0 in 

Bug#968106: [Debian-on-mobile-maintainers] Bug#968106: Bug#968106: Bug#968106: phosh: Shell doesn't start

[Guido Günther]

Hi,
On Sun, Aug 16, 2020 at 05:50:15PM +0200, Jonas Smedegaard wrote:
> Quoting Bernhard Übelacker (2020-08-16 17:28:13)
> > Hello Michel Le Bihan,
> > found this issue interesting and tried to get more information.
> > 
> > First the "trap int3" originates from here [1], and seems just
> > a consequence of missing packages.
> > 
> > When installing following packages the user interface
> > could successfully start, without changing the VM vga "hardware".
> > 
> >   systemctl stop phosh
> >   apt update
> >   apt install --no-install-recommends --no-install-suggests 
> > gnome-session-bin libglib2.0-bin gnome-settings-daemon policykit-1 
> > phosh-osk-stub
> >   systemctl start phosh
> 
> I interpret that as there really is no bug here;
> 
> Suppressing recommendations is meant for exotic use-cases and therefore 
> suppressing multiple recommendations quite likely leads to a broken 
> unsupportable result.
> 
> Beware that mmdebstrap suppresses recommends by default.
> 
> mmdebstrap is not doing anything wrong: it is a powerful tool which can 
> do powerful good or powerful breakage depending on how it is used.

We don't have a 'keyboard' (either stub or real) nor
gnome-settings-daemon in 'recommends' - that at least should be fixed.
Cheers,
 -- Guido

> 
> 
>  - Jonas
> 
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private



> ___
> Debian-on-mobile-maintainers mailing list
> debian-on-mobile-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers

Bug#968508: blender-data: Please only recommend blender instead of python3

[Mattia Rizzolo]

On Sun, Aug 16, 2020 at 06:07:11PM +0200, Jonas Smedegaard wrote:
> Quoting Elrond (2020-08-16 17:47:17)
> > On Sun, Aug 16, 2020 at 17:35:32 +0200, Jonas Smedegaard wrote:
> > > Quoting Elrond (2020-08-16 17:16:26)
> > [...]
> > > > Installing blender-data alone doesn't make much sense. It
> > > > is most useful with the blender package.
> > > > So, please:
> > > > Recommends: blender (= ${source:Version})
> > > > Don't use "Depends", because that would introduce a
> > > > circular dependency. Which is not good.
> > > 
> > > Package relations are directional.  Since blender-data cannot use 
> > > blender for anything (data does not use apps - apps uses their data), it 
> > > is correct for blender-data to not depend on or recommend blender.
> > 
> > Well, would a Suggests make sense then?
> > So that you know, which "app" is best to use, when looking
> > at that package?
> 
> No: blends-data is data for blends to use (not data that uses blends).
> 
> It's a directional relationship: blends need its data - blends data does 
> not "need" blends, ever - not always (depends) and not mostly 
> (recommends) but also not occationally (suggests).  Instead, blends data 
> is _consumed_ by blends, i.e. gets processed by blends.

Despite not really used by any frontend that I'm aware of, IMHO the
correct relationship would be "Enhances".  But, really, it's useless.
My reading and understanding of "Enhances" is that it's the same kind of
relationship but in the opposite verse of "Suggests".


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#932837: xscreensaver: No text on lock screen

[Nicolas Boullis]

Hello,

On Sun, Aug 16, 2020 at 09:58:04AM -0700, Jamie Zawinski wrote:
> XScreenSaver (as of 5.42) tries really hard to do something sensible 
> with whatever set of garbage fonts you happen to have installed,

Well, that “set of garbage fonts” is fine for XScreenSaver 5.36…


> so it would be helpful if you send me the output of xlsfonts on your 
> system where it's doing something terrible.

Here it is.


> Is there anything about fonts in the log output of xscreensaver 
> -verbose -log log.txt ?

Just gave it a try. The log is attached, but I see nothing font-related.


> If you're feeling adventurous, rebuilding with DEBUG defined in 
> utils/font-retry.c and sending me the output of a run with that 
> version might be helpful. Though I guess that if the self-compiled 
> version does not exhibit the problem, that won't help.

Ok, I’ll give it a try ASAP.


Cheers,

-- 
Nicolas Boullis
-arabic-newspaper-medium-r-normal--0-0-100-100-p-0-iso10646-1
-arabic-newspaper-medium-r-normal--32-246-100-100-p-137-iso10646-1
-daewoo-gothic-medium-r-normal--0-0-100-100-c-0-ksc5601.1987-0
-daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0
-daewoo-mincho-medium-r-normal--0-0-100-100-c-0-ksc5601.1987-0
-daewoo-mincho-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0
-daewoo-mincho-medium-r-normal--24-170-100-100-c-240-ksc5601.1987-0
-isas-fangsong ti-medium-r-normal--0-0-72-72-c-0-gb2312.1980-0
-isas-fangsong ti-medium-r-normal--16-160-72-72-c-160-gb2312.1980-0
-isas-song ti-medium-r-normal--0-0-72-72-c-0-gb2312.1980-0
-isas-song ti-medium-r-normal--16-160-72-72-c-160-gb2312.1980-0
-isas-song ti-medium-r-normal--24-240-72-72-c-240-gb2312.1980-0
-jis-fixed-medium-r-normal--0-0-75-75-c-0-jisx0208.1983-0
-jis-fixed-medium-r-normal--16-110-100-100-c-160-jisx0208.1983-0
-jis-fixed-medium-r-normal--16-150-75-75-c-160-jisx0208.1983-0
-jis-fixed-medium-r-normal--24-170-100-100-c-240-jisx0208.1983-0
-jis-fixed-medium-r-normal--24-230-75-75-c-240-jisx0208.1983-0
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso10646-1
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso8859-1
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso8859-10
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso8859-13
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso8859-14
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso8859-15
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso8859-16
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso8859-2
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso8859-3
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso8859-4
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso8859-5
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso8859-7
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso8859-8
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso8859-9
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso10646-1
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-1
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-10
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-11
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-13
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-14
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-15
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-16
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-2
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-3
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-4
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-5
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-7
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-8
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso8859-9
-misc-fixed-bold-r-normal--13-100-100-100-c-70-iso8859-1
-misc-fixed-bold-r-normal--13-100-100-100-c-80-iso8859-1
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso10646-1
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-1
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-10
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-11
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-13
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-14
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-15
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-16
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-2
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-3
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-4
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-5
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-7
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-8
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-9
-misc-fixed-bold-r-normal--13-120-75-75-c-80-iso10646-1
-misc-fixed-bold-r-normal--13-120-75-75-c-80-iso8859-1
-misc-fixed-bold-r-normal--13-120-75-75-c-80-iso8859-10
-misc-fixed-bold-r-normal--13-120-75-75-c-80-iso8859-13
-misc-fixed-bold-r-normal--13-120-75-75-c-80-iso8859-14
-misc-fixed-bold-r-normal--13-120-75-75-c-80-iso8859-15
-misc-fixed-bold-r-normal--13-120-75-75-c-80-iso8859-16
-misc-fixed-bold-r-normal--13-120-75-75-c-80-iso8859-2
-misc-fixed-bold-r-normal--13-120-75-75-c-80-iso8859-3

Bug#968489: chirp does not start - missing module

[David Ranch]

Some new radio drivers require the Python pip module named "future" (or 
"python-future" if packaged by your OS). before the whole program will 
load.  It should be marked as a dependency,


--David
KI6ZHD


On 08/16/2020 01:52 AM, Hans-J. Ullrich wrote:

Package: chirp
Severity: important

Dear maintainers,

the latest version of chirp in debian/testing does not start. It looks like 
some module is missing.

This is the output:

--- snip ---

chirpw
Traceback (most recent call last):
   File "/usr/bin/chirpw", line 16, in 
 from chirp import chirp_common
   File "/usr/lib/python3/dist-packages/chirp/chirp_common.py", line 17, in 

 from future import standard_library
ModuleNotFoundError: No module named 'future'

--- snap ---

I now installed the latest version from the Ubuntu PPA (manually installed just the 
chirp-daily-*xenial*.deb) and had also to install the package "python-suds", 
too. This is working well.

Hope this helps.

Best regards

Hans



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

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

Bug#844528: systemd is missing the systemd-firstboot binary (and service)

[Jörg Behrmann]

Dear maintainers

I'd like to use systemd-firstboot in some custom bootstrapping work.
systemd-firstboot shouldn't interfere with anything else. Would it maybe
be possible to get it included now that Debian allows for stronger
integration with systemd?

sincerely,
Jörg Behrmann



signature.asc
Description: OpenPGP digital signature

Bug#951166: ITP: shortwave -- Find and listen to internet radio stations

[Willem van den Akker]

Dobry den David,

I also have been working on shortwave and have a working package
which you can find here:  https://salsa.debian.org/wvdakker/shortwave

Is it possible to create a team respository so we can work as a team
on the package? There is quite a bit Rust work/libraries on which we
have to work. To much for one person.

Another probleem is the networkaccess during the build. USENETWORK must
be used in the pbuilderrc because a lot of cargo must be downloaded.
However the policy prevents that any the package must be build in a
chroot (4.9).

Can you as maintainer create a team library? Then we upload the version
to experimental as an starting point. 

Na shledanou
Willem

Bug#968518: clevis: "clevis decrypt" does not work in initrd

[Andreas Pommer]

Package: clevis
Version: 13-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I set up a new system with encrypted root device. I set up a tang server. I
set up "clevis luks bind ..." and everything else according to the book. When I
rebooted, I had to enter the password to unlock the disk manually - the clevis
part did not work.

After various debugging attempts, which after small detours boiled down to
removing some "2> /dev/null", the following error message appeared:

/bin/clevis-decrypt: line 49: /dev/fd/62: No such file or directory

(ignore potential typos there, I had to retype this manually)

this line 49 contains the following statement:
exec "$cmd" < <(echo -n "$hdr."; /bin/cat)

After changing this line to ...
(echo -n "$hdr."; /bin/cat) | "$cmd"
exit $?

... I was able to proceed ... a little bit, just to be greeted with:
/bin/clevis-decrypt-tang: line 95: /dev/fd/62: No such file or directory

and so I changed line 95 of the second script from ...
exec jose jwe dec -k- -i- < <(echo -n "$jwk$hdr."; /bin/cat)

... to ...
(echo -n "$jwk$hdr."; /bin/cat) | jose jwe dec -k- -i-
exit $?

... and the system booted by contacting the tang server, and without me having
to enter the decryption password.


When running the unmodified scripts on a completely booted system, they work.
So it seems that the '< <(...)' mechanism fails only in initrd (no idea why).
And while my modifications work for me, please note that I am not a bash
expert, so there may be side effects that I am not aware of.

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

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

Versions of packages clevis depends on:
ii  cracklib-runtime2.9.6-3.2+b1
ii  curl7.68.0-1+b1
ii  jose10-3
ii  libc6   2.31-3
ii  libjansson4 2.13.1-1
ii  libjose010-3
ii  libpwquality-tools  1.4.2-1+b1
ii  libssl1.1   1.1.1g-1
ii  luksmeta9-3

Versions of packages clevis recommends:
ii  cryptsetup-bin  2:2.3.3-1+b1

clevis suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/clevis-decrypt (from clevis package)
debsums: changed file /usr/bin/clevis-decrypt-tang (from clevis package)

Bug#964164: Bug#947017: Bug#964164: RFS: org-drill/2.7.0-1 [ITP] -- spaced repetition drills in Emacs for accelerated study/learning

[Nicholas D Steeves]

Hi Thomas,

Thank you for taking a look at this.

Thomas Koch  writes:

> Thank you Nicholas for the reminder and sorry for keeping you waiting.
>
> Unfortunately, I don't believe the package would pass the NEW queue in its 
> current state. You did remove the apple.jpg file but you added a new 
> apple.png file that is not mentioned in debian/copyright.
>
> I know how annoying these copyright issues are!
>

Which package are you looking at?  I have insufficient permissions to
rewrite history or delete the org-drill repo Emacsen Team project, thus
insufficient permissions to clean the git repo.

Going from the provided source package:
  
https://mentors.debian.net/debian/pool/main/o/org-drill/org-drill_2.7.0+dfsg-1.dsc

Copyright and source of apple.png is documented, and the license is CC0,
which does not require specific documentation or attribution in
copyright.  CC0 Allows implicit relicensing, thus the debian/* rule in
copyright applies GPL-3+ to
debian/patches/0001-add-a-more-freely-licenced-image-of-an-apple.patch 

So the package is license-compliant.

When upstream merges the PR the new apple.png will fall under the
upstream "Files: *" GPL-3+ rule.  At that time the package will also be
license-compliant.  I admit that documentation of this file's CC0 would
be nice to have, to highlight the fact that one is free to do more with
that file than the GPL-3+ permits, but this is not a license-compliance
issue.

> I think the easiest would be to just remove the file and its references 
> without any replacement. You might then help upstream with a pull request to 
> provide a dfsg free picture for the next version.
>

I filed such a PR the 28th of July.  Please see the Forwarded header of
that patch.

> The following remarks are maybe not strictly required:
>
> Even if you add a new file, you should not use debian/patches to add it but 
> just include it in the debian tarball. I actually never had to do this 
> myself, so I have no experience with adding a binary file.
>

I chose to use a cherry picked patch from the PR I filed because then
everything is documented in two places (the patch and the PR), and so
that the patch can be automatically dropped in a future release
(prioritises human time).  I'm familiar with the alternative, which
would additionally require additional documentation in README.source.

> Please also add a version number to dfsg suffix like dfsg1 or dfsg-1. It 
> happened to me before that I needed multiple uploads to the new queue before 
> I found all non dfsg-unfree files: https://tracker.debian.org/pkg/nix
>
> Especially the version number of the orig tarball is different from the 
> changelog. I wonder how this worked in the first place.
>

Ah, you're looking at the non-dfsg git repo...

> If you want to reflect the dfsg cleaning work also in your git packaging 
> branch, I started a knowledge base article  here:
> https://wiki.debian.org/kb/git_packaging_dfsg_clean_branch
> An example of this: https://salsa.debian.org/debian/nix
>
> My nix package also contains a debian/watch example to produce a dfsg clean 
> orig tarball.
>
> The git packaging repo does not contain the latest commits apparently, there 
> is no debian/patches folder:
> https://salsa.debian.org/emacsen-team/org-drill/-/tree/master/debian
>

Yes, that project should be deleted.  The plan is to use a gbp-style
repo that leverages uscan's Files-Excluded.

> Thank you very much for your contribution and especially for your patience!

You're welcome!
Nicholas


signature.asc
Description: PGP signature

Bug#937665: fixed in python-coverage 4.5.2+dfsg.1-2

[Jann Haber]

It seems like, there are no more rdeps of python-coverage now. Not sure about 
pypy-coverage.
Dropping python-coverage would also fix #967200, which currently blocks 
migration to testing. :)

On Mon, 11 Nov 2019 05:48:22 +1100 Ben Finney  wrote:
> Control: reopen -1
> Control: tags -1 + pending
> 
> On 10-Nov-2019, Sandro Tosi wrote:
> > please restore python-coverage, it has still plenty of rdeps,
> > http://sandrotosi.me/debian/py2removal/python-coverage_1.svg
> 
> You're right! I prepared the release for removing Python 2 binary
> packages, and then waited; but later uploaded it by mistake.
> 
> I will make a new release to restore those binary packages.
> 
> -- 
>  \“You can't have everything; where would you put it?” —Steven |
>   `\Wright |
> _o__)  |
> Ben Finney 

Bug#968174: llvm-toolchain-9: Re: Bug#968174: Prevent migration of ocaml-{integers,ctypes} to testing

[Sylvestre Ledru]

Hello,

I am off and I won't have time to work on it for the next 2 weeks.
NMU welcome :)

Cheers & sorry!
Sylvestre
Le 16/08/2020 à 08:01, Stéphane Glondu a écrit :

Hello,

These bugs are still on topic and prevent ocaml-{integers,ctypes} from
migrating to testing. Could you please fix them? Or have the faulty
packages removed from testing.


Cheers,

Bug#932837: xscreensaver: No text on lock screen

[Jamie Zawinski]

XScreenSaver (as of 5.42) tries really hard to do something sensible with 
whatever set of garbage fonts you happen to have installed, so it would be 
helpful if you send me the output of xlsfonts on your system where it's doing 
something terrible.

Is there anything about fonts in the log output of xscreensaver -verbose -log 
log.txt ?

If you're feeling adventurous, rebuilding with DEBUG defined in 
utils/font-retry.c and sending me the output of a run with that version might 
be helpful. Though I guess that if the self-compiled version does not exhibit 
the problem, that won't help.

Bug#968500: gvm-feed-update: Syncing SCAP before CERT feed

[Christian Fischer]

Package: src:gvm
Version: 11.0.4

Dear Maintainer,

in gvm-feed-update [1] the CERT feed (via greenbone-certdata-sync) is
synced before the SCAP feed (via greenbone-scapdata-sync).

Currently the CERT feed sync depends on data provided by the SCAP feed
and should be called after syncing the latter. This is now also
documented since a few days in [2].

Unrelated to the above but i still want to note this: GVM 20.08 is out
since a few days. If an upgrade of the packages are planned in the
future some notes about the upgrade from GVM 11 are collected in [3].

Regards,

[1]
https://salsa.debian.org/pkg-security-team/gvm/-/blob/1238f021474220b51a020b3ad39fe5cdb0d903f4/gvm-feed-update#L23
[2]
https://github.com/greenbone/gvmd/pull/1237/files
[3]
https://community.greenbone.net/t/gvm-20-08-stable-initial-release-2020-08-12/6312

Bug#963253: Processed: forcibly merging 963253 954772

[Daniel Shahaf]

Debian Bug Tracking System wrote on Sun, Aug 16, 2020 at 08:57:10 +:
> Processing commands for cont...@bugs.debian.org:
> 
> > forcemerge 963253 954772
> Bug #963253 [mercurial-common] mercurial-common: please install zsh 
> completion where zsh finds it
> Bug #963253 [mercurial-common] mercurial-common: please install zsh 
> completion where zsh finds it
> Marked as found in versions mercurial/5.3.1-1.
> Bug #954772 [mercurial-common] mercurial-common: Please install zsh 
> completion where zsh will find it

Oops, sorry for the duplicate!  I must've misspelled the filter pattern
in reportbug(1) when I submitted the second one.

Thanks for the fix ☺

Daniel

Bug#968323: Since conky 1.11.6-1 following error: conky: unknown variable '$tcp_portmon'

[Mikhail Morfikov]

Package: conky
Version: 1.11.6-1
Followup-For: Bug #968323

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've also hit this issue.

It looks like it's because conky in Debian is built with:

COMMON_CONF_ARGS= ...
 -DBUILD_PORT_MONITORS=OFF \
  ...




-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQR1ZhNYxftXAnkWpwEy2ctjR5bMoQUCXzlmKQAKCRAy2ctjR5bM
oeyFAQDPCLWPfDRz/ttB3TPLn8LQAPawlg97bcJJkfVz3D+6FgEAr5eRrq5L/m7O
JbqWA0tafwUXj40BybXP6R1jBUdlEgw=
=sFHA
-END PGP SIGNATURE-

Bug#968379: wireshark-common: versioned dependency on libsystemd0 breaks installability with elogind

[Cristian Ionescu-Idbohrn]

On Fri, 14 Aug 2020, Balint Reczey wrote:
> 
> Wireshark parses systemd journals and for doing so it depends on 
> libsystemd0.
> The version it depends on is controlled only by the used symbols and 
> wireshark only build-depends on libsystemd-dev.

But Balint, reassigning that bug to elogind won't help Thorsten, nor 
me, nor anyone else using another init.

Is that a poor upstream decision?  Isn't there a way to package 
wireshark with that troublesome filter in a separate package?  After 
all, _nothing_ should depend on the init system choice.


-- 
Cristian

Bug#968517: RM: libboxfort-dev [armel armhf] -- ANAIS; boxfort cannot be compiled/run reliably on 32 bit arm architecture and therefore removed from source

[SZALAY Attila]

Package: ftp.debian.org
Severity: normal

Bug#964014:

[Fabio Pedretti]

Given the many bugs of the default -nft alternative, maybe the best option
for buster would be to revert to using the -legacy version.

Bug#957496: Prevent migration of ocaml-{integers,ctypes} to testing

[Stéphane Glondu]

Le 16/08/2020 à 18:03, Stéphane Glondu a écrit :
>>> These bugs are still on topic and prevent ocaml-{integers,ctypes} from
>>> migrating to testing. Could you please fix them? Or have the faulty
>>> packages removed from testing.
>>
>> At the moment, llvm-toolchain-8 is a key package [1], preventing its
>> autoremoval from testing. I've filed [2] and [3] to sort this out.
>>
>> [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
>> [2] https://bugs.debian.org/968512
>> [3] https://bugs.debian.org/968513
> 
> Related to this, I've also filed [1], [2] and updated [3].
> 
> [1] https://bugs.debian.org/968497
> [1] https://bugs.debian.org/968496
> [1] https://bugs.debian.org/966007

I've usertagged the bugs relevant to the removal of llvm-toolchain-8:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=llvm-toolchain-8-removal;users=glo...@debian.org


Cheers,

-- 
Stéphane

Bug#968508: blender-data: Please only recommend blender instead of python3

[Elrond]

Hi,


thanks for your fast reaction!


On Sun, Aug 16, 2020 at 17:35:32 +0200, Jonas Smedegaard wrote:
> Quoting Elrond (2020-08-16 17:16:26)
[...]
> > Installing blender-data alone doesn't make much sense. It
> > is most useful with the blender package.
> > So, please:
> > Recommends: blender (= ${source:Version})
> > Don't use "Depends", because that would introduce a
> > circular dependency. Which is not good.
> 
> Package relations are directional.  Since blender-data cannot use 
> blender for anything (data does not use apps - apps uses their data), it 
> is correct for blender-data to not depend on or recommend blender.

Well, would a Suggests make sense then?
So that you know, which "app" is best to use, when looking
at that package?


> > On the other hand, blender-data does not need to depend on python3. 
> > Yes, there are some python scripts in there, but they do only make 
> > sense together with blender.
> 
> If blender-data contains scripts which require Python3 to run, then it 
> must declare either Depends or Recommends on python3.
> 
> 
> > If you want to keep the python3 dep, please turn it into
> > python3:any, and also into a Recommends. Recommends means
> > "You really should install this. If you don't, expect
> > missing functionality", which seems right then.
> 
> If those python3 scripts are not always used, then it makes sense to 
> relax to only recommend python3.

TBH I am not 100% sure, if they're not always used. I might
try sometime soon.


> Only if those python3 scripts are not really used other than as 
> examples, they can instead be installed below 
> /usr/share/doc/blender/examples and _then_ relax to only suggest 
> python3.

I doubt that. There are way too many of them in directories
named "addons".


Regards

Elrond

Bug#968516: Add Suggests: postfix-mta-sts-resolver

[Benjamin Hof]

Source: postfix
Version: 3.5.6-1
Severity: wishlist

Dear maintainer,

Please consider adding a "Suggests: postfix-mta-sts-resolver".

Quoting from its documentation:

MTA-STS, specified in RFC 8461, is a security standard for email
servers. When a site configures MTA-STS, other mail servers can
require the successful authentication of that site when forwarding
mail there.


Kind regards,
Benjamin

Bug#968508: blender-data: Please only recommend blender instead of python3

[Jonas Smedegaard]

Quoting Elrond (2020-08-16 17:47:17)
> On Sun, Aug 16, 2020 at 17:35:32 +0200, Jonas Smedegaard wrote:
> > Quoting Elrond (2020-08-16 17:16:26)
> [...]
> > > Installing blender-data alone doesn't make much sense. It
> > > is most useful with the blender package.
> > > So, please:
> > > Recommends: blender (= ${source:Version})
> > > Don't use "Depends", because that would introduce a
> > > circular dependency. Which is not good.
> > 
> > Package relations are directional.  Since blender-data cannot use 
> > blender for anything (data does not use apps - apps uses their data), it 
> > is correct for blender-data to not depend on or recommend blender.
> 
> Well, would a Suggests make sense then?
> So that you know, which "app" is best to use, when looking
> at that package?

No: blends-data is data for blends to use (not data that uses blends).

It's a directional relationship: blends need its data - blends data does 
not "need" blends, ever - not always (depends) and not mostly 
(recommends) but also not occationally (suggests).  Instead, blends data 
is _consumed_ by blends, i.e. gets processed by blends.


 - Jonas

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

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

signature.asc
Description: signature

Bug#957496: Prevent migration of ocaml-{integers,ctypes} to testing

[Stéphane Glondu]

Le 16/08/2020 à 17:59, Stéphane Glondu a écrit :
>> These bugs are still on topic and prevent ocaml-{integers,ctypes} from
>> migrating to testing. Could you please fix them? Or have the faulty
>> packages removed from testing.
> 
> At the moment, llvm-toolchain-8 is a key package [1], preventing its
> autoremoval from testing. I've filed [2] and [3] to sort this out.
> 
> [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
> [2] https://bugs.debian.org/968512
> [3] https://bugs.debian.org/968513

Related to this, I've also filed [1], [2] and updated [3].

[1] https://bugs.debian.org/968497
[1] https://bugs.debian.org/968496
[1] https://bugs.debian.org/966007


Cheers,

-- 
Stéphane

Bug#957496: Prevent migration of ocaml-{integers,ctypes} to testing

[Stéphane Glondu]

Le 16/08/2020 à 08:01, Stéphane Glondu a écrit :
> These bugs are still on topic and prevent ocaml-{integers,ctypes} from
> migrating to testing. Could you please fix them? Or have the faulty
> packages removed from testing.

At the moment, llvm-toolchain-8 is a key package [1], preventing its
autoremoval from testing. I've filed [2] and [3] to sort this out.

[1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
[2] https://bugs.debian.org/968512
[3] https://bugs.debian.org/968513


Cheers,

-- 
Stéphane

Bug#968515: buster-pu: package lucene-solr/3.6.2+dfsg-20+deb10u1

[Markus Koschany]

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

Dear release team,

I would like to fix CVE-2019-0193 for Buster in lucene-solr. This
issue was marked no-dsa by the security team. Please find attached the
debdiff.

Regards,

Markus
diff -Nru lucene-solr-3.6.2+dfsg/debian/changelog 
lucene-solr-3.6.2+dfsg/debian/changelog
--- lucene-solr-3.6.2+dfsg/debian/changelog 2019-09-04 22:30:29.0 
+0200
+++ lucene-solr-3.6.2+dfsg/debian/changelog 2020-08-16 15:56:26.0 
+0200
@@ -1,3 +1,19 @@
+lucene-solr (3.6.2+dfsg-20+deb10u2) buster; urgency=medium
+
+  * Team upload.
+  * Fix CVE-2019-0193:
+The DataImportHandler, an optional but popular module to pull in data from
+databases and other sources, has a feature in which the whole DIH
+configuration can come from a request's "dataConfig" parameter. The debug
+mode of the DIH admin screen uses this to allow convenient debugging /
+development of a DIH config. Since a DIH config can contain scripts, this
+parameter is a security risk. Starting from now on, use of this parameter
+requires setting the Java System property "enable.dih.dataConfigParam" to
+true. For example this can be achieved with solr-tomcat by adding
+-Denable.dih.dataConfigParam=true to JAVA_OPTS in /etc/default/tomcat9.
+
+ -- Markus Koschany   Sun, 16 Aug 2020 15:56:26 +0200
+
 lucene-solr (3.6.2+dfsg-20+deb10u1) buster; urgency=medium
 
   * Team upload.
diff -Nru lucene-solr-3.6.2+dfsg/debian/patches/CVE-2019-0193.patch 
lucene-solr-3.6.2+dfsg/debian/patches/CVE-2019-0193.patch
--- lucene-solr-3.6.2+dfsg/debian/patches/CVE-2019-0193.patch   1970-01-01 
01:00:00.0 +0100
+++ lucene-solr-3.6.2+dfsg/debian/patches/CVE-2019-0193.patch   2020-08-16 
15:56:26.0 +0200
@@ -0,0 +1,70 @@
+From: Markus Koschany 
+Date: Sat, 15 Aug 2020 18:41:28 +0200
+Subject: CVE-2019-0193
+
+Bug-Upstream: https://issues.apache.org/jira/browse/SOLR-13669
+Origin: 
https://github.com/apache/lucene-solr/commit/325824cd391c8e71f36f17d687f52344e50e9715
+---
+ .../apache/solr/handler/dataimport/DataImportHandler.java   | 10 ++
+ .../dataimport/AbstractDataImportHandlerTestCase.java   | 13 ++---
+ 2 files changed, 16 insertions(+), 7 deletions(-)
+
+diff --git 
a/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DataImportHandler.java
 
b/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DataImportHandler.java
+index 9e11c79..a4a39a0 100644
+--- 
a/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DataImportHandler.java
 
b/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DataImportHandler.java
+@@ -83,6 +83,10 @@ public class DataImportHandler extends RequestHandlerBase 
implements
+ 
+   private Map coreScopeSession = new HashMap();
+ 
++  static final String ENABLE_DIH_DATA_CONFIG_PARAM = 
"enable.dih.dataConfigParam";
++
++  final boolean dataConfigParam_enabled = 
Boolean.getBoolean(ENABLE_DIH_DATA_CONFIG_PARAM);
++
+   @Override
+   @SuppressWarnings("unchecked")
+   public void init(NamedList args) {
+@@ -153,6 +157,12 @@ public class DataImportHandler extends RequestHandlerBase 
implements
+   return;
+ }
+ 
++if (dataConfigParam_enabled == false) {
++  throw new SolrException(SolrException.ErrorCode.FORBIDDEN,
++  "Use of the dataConfig param (DIH debug mode) requires the system 
property " +
++  ENABLE_DIH_DATA_CONFIG_PARAM + " because it's a security 
risk.");
++}
++
+ rsp.add("initArgs", initArgs);
+ String message = "";
+ 
+diff --git 
a/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/AbstractDataImportHandlerTestCase.java
 
b/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/AbstractDataImportHandlerTestCase.java
+index 1b49028..1cce926 100644
+--- 
a/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/AbstractDataImportHandlerTestCase.java
 
b/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/AbstractDataImportHandlerTestCase.java
+@@ -30,7 +30,7 @@ import 
org.apache.solr.update.processor.UpdateRequestProcessor;
+ import org.apache.solr.update.processor.UpdateRequestProcessorFactory;
+ import org.apache.solr.common.util.NamedList;
+ import org.junit.After;
+-import org.junit.Before;
++import org.junit.BeforeClass;
+ 
+ import java.io.FileOutputStream;
+ import java.io.IOException;
+@@ -57,12 +57,11 @@ public abstract class AbstractDataImportHandlerTestCase 
extends
+   public static void initCore(String config, String schema) throws Exception {
+ initCore(config, schema, getFile("dih/solr").getAbsolutePath());
+   }
+-  
+-  @Override
+-  @Before
+-  public void setUp() throws Exception {
+-super.setUp();
+-  }
++
++  @BeforeClass
++  public static void baseBeforeClass() {
++

Bug#968514: Package name "systemctl" is confusing and misleading, please rename to "systemctl-replacement"

[Christoph Berg]

Package: systemctl
Severity: normal

Hi,

I believe the package name "systemctl" is misleading in several ways:

* Users will think systemctl.deb will contain the normal
  /bin/systemctl and might be tricked into installing this when they
  actually wanted systemd.deb.
* If systemd should decide to split the package into smaller
  components (#959828 indicates that this is at least an option),
  this "systemctl" package is blocking an important bit of their
  namespace.
* The package description currently does not say explicitly that this
  implementation is not part of systemd. If systemctl.deb were to be
  split from systemd.deb it might have some description very close to
  the current one. The only indication that this isn't the case is
  that it's not built from Source: systemd, and the Maintainer is
  different. Readers not familiar with systemd intricacies in Debian
  will not be able to draw this conclusion.

Please consider renaming the binary package. Looking at the source
package name, "systemctl-replacement" is an ideal candidate.

(It is of course ok for the package to ship /bin/systemctl as that's
the point of the replacement. I'm only aiming at the package name.)

Christoph

Bug#968503: nmu: mutter, muffin on 32-bit architectures (and gtk+3.0 on m68k)

[John Paul Adrian Glaubitz]

> On Aug 16, 2020, at 5:45 PM, Thorsten Glaser  wrote:
> 
> Simon McVittie dixit:
> 
>> To -ports people (cc'd): for the -ports architectures, mutter and
>> muffin should be rebuilt as above on all the 32-bit ports, with the
>> same dep-wait. Additionally, some differences in build order mean that
>> gtk+3.0 needs a rebuild on m68k (but not on release architectures or
>> other 32-bit ports).
> 
> I’ll schedule this for x32 and m68k (don’t have rights for the others).

Why not let one person with rights for everything perform the binNMUs?

Me and Aurelien can do that, for example.

Adrian

Bug#968511: libgtk-3-0: Segfaults many apps depending on it

[Simon McVittie]

Control: reassign -1 libpango-1.0-0 1.46.0-1
Control: severity -1 grave
Control: forcemerge 968337 -1
Control: affects 968337 + libgtk-3-0 libgtk2.0-0 libcogl20 libmutter-6-0 
libmuffin0

On Sun, 16 Aug 2020 at 17:27:41 +0200, Nicolas Patrois wrote:
> I can’t launch balsa since today:
> août 16 17:20:15 nicolas.home kernel: balsa[15034]: segfault at 8887 ip 
> b3e95031 sp bfae59b0 error 4 in libgtk-3.so.0.2404.18[b3b53000+397000]

There was an ABI break in Pango on 32-bit architectures, which is fixed
in version 1.46.0-2.

Workaround: downgrade libpango-1.0-0 and related packages to 1.44.x
from testing, or use amd64 if your hardware supports it.

Real solution: upgrade libpango-1.0-0 and related packages to 1.46.0-2
when that version becomes available.

smcv

Bug#968106: [Debian-on-mobile-maintainers] Bug#968106: Bug#968106: phosh: Shell doesn't start

[Jonas Smedegaard]

Quoting Bernhard Übelacker (2020-08-16 17:28:13)
> Hello Michel Le Bihan,
> found this issue interesting and tried to get more information.
> 
> First the "trap int3" originates from here [1], and seems just
> a consequence of missing packages.
> 
> When installing following packages the user interface
> could successfully start, without changing the VM vga "hardware".
> 
>   systemctl stop phosh
>   apt update
>   apt install --no-install-recommends --no-install-suggests gnome-session-bin 
> libglib2.0-bin gnome-settings-daemon policykit-1 phosh-osk-stub
>   systemctl start phosh

I interpret that as there really is no bug here;

Suppressing recommendations is meant for exotic use-cases and therefore 
suppressing multiple recommendations quite likely leads to a broken 
unsupportable result.

Beware that mmdebstrap suppresses recommends by default.

mmdebstrap is not doing anything wrong: it is a powerful tool which can 
do powerful good or powerful breakage depending on how it is used.


 - Jonas

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

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

signature.asc
Description: signature

Bug#968513: Please rebuild with modern rustc

[Stéphane Glondu]

Package: src:rust-xml-rs
Version: 0.8.0-1+b1
Severity: normal

Dear Maintainer,

Currently, xml-rs in testing has "Built-Using: rustc (=
1.36.0+dfsg1-2)", keeping this old version in the archive, which
build-depends on libllvm8, which I want out of testing because it
FTBFS.

Please rebuild it with modern rustc, either by uploading a new
version, or by requesting a binNMU.


Cheers,

-- 
Stéphane

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

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

Bug#968512: Please rebuild with modern rustc

[Stéphane Glondu]

Package: src:rust-rusty-tags
Version: 3.5.1-2
Severity: normal

Dear Maintainer,

Currently, rusty-tags in testing has "Built-Using: rustc (=
1.38.0+dfsg1-2)", keeping this old version in the archive, which
build-depends on libllvm8, which I want out of testing because it
FTBFS.

Please rebuild it with modern rustc, either by uploading a new
version, or by requesting a binNMU.


Cheers,

-- 
Stéphane

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

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

Bug#968503: nmu: mutter, muffin on 32-bit architectures (and gtk+3.0 on m68k)

[Thorsten Glaser]

Simon McVittie dixit:

>To -ports people (cc'd): for the -ports architectures, mutter and
>muffin should be rebuilt as above on all the 32-bit ports, with the
>same dep-wait. Additionally, some differences in build order mean that
>gtk+3.0 needs a rebuild on m68k (but not on release architectures or
>other 32-bit ports).

I’ll schedule this for x32 and m68k (don’t have rights for the others).

Thanks,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#968457: [pkg-netfilter-team] Bug#968457: iptables: segfault with specific command when run as non-root

[Jeremy Sowden]

On 2020-08-16, at 14:48:12 +0200, Bernhard Übelacker wrote:
> Program received signal SIGSEGV, Segmentation fault.
> nftnl_rule_list_add (r=r@entry=0x555f5900, list=0x0) at rule.c:782
> 782 list_add(>head, >list);
> (gdb) bt
> #0  nftnl_rule_list_add (r=r@entry=0x555f5900, list=0x0) at rule.c:782
> #1  0x55567eac in nft_rule_insert (h=h@entry=0x7fffe480, 
> chain=chain@entry=0x7fffe848 "OUTPUT", table=table@entry=0x5557b126 
> "filter", data=data@entry=0x7fffe300, rulenum=rulenum@entry=0, 
> verbose=verbose@entry=false) at nft.c:2146
> #2  0x55562629 in add_entry (chain=0x7fffe848 "OUTPUT", 
> table=0x5557b126 "filter", cs=cs@entry=0x7fffe300, rulenum=0, 
> family=2, s=..., d=..., verbose=false, h=0x7fffe480, append=false) at 
> xtables.c:412
> #3  0x55564270 in do_commandx (h=h@entry=0x7fffe480, 
> argc=argc@entry=3, argv=argv@entry=0x7fffe608, 
> table=table@entry=0x7fffe478, restore=restore@entry=false) at 
> xtables.c:1122
> #4  0x55562350 in xtables_main (family=family@entry=2, 
> progname=progname@entry=0x5557a011 "iptables", argc=3, 
> argv=0x7fffe608) at xtables-standalone.c:72
> #5  0x5556248a in xtables_ip4_main (argc=, 
> argv=) at xtables-standalone.c:96
> #6  0x7763809b in __libc_start_main (main=0xcfb0 , 
> argc=3, argv=0x7fffe608, init=, fini=, 
> rtld_fini=, stack_end=0x7fffe5f8) at 
> ../csu/libc-start.c:308
> #7  0xcfea in _start ()

Here is the relevant part of nft_rule_insert (iptables/nft.c,
ll. 2131ff.):

if (rulenum > 0) {
list = nft_rule_list_get(h);
if (list == NULL)
goto err;

r = nft_rule_find(h, list, chain, table, data, rulenum);
if (r == NULL) {
/* special case: iptables allows to insert into
 * rule_count + 1 position.
 */
r = nft_rule_find(h, list, chain, table, data,
  rulenum - 1);
if (r != NULL)
return nft_rule_append(h, chain, table, data,
   0, verbose);

errno = ENOENT;
goto err;
}

handle = nftnl_rule_get_u64(r, NFTNL_RULE_HANDLE);
DEBUGP("adding after rule handle %"PRIu64"\n", handle);
} else {
nft_rule_list_get(h);
}

new_rule = nft_rule_add(h, chain, table, data, handle, verbose);
if (!new_rule)
goto err;

if (handle)
nftnl_rule_list_insert_at(new_rule, r);
else
nftnl_rule_list_add(new_rule, h->rule_cache);

If rulenum == 0, the code assumes that nft_rule_list_get, which sets
h->rule_cache, does not fail.

Here is the relevant part of nft_rule_list_get (iptables/nft.c,
ll. 1407ff.):

nlh = nftnl_rule_nlmsg_build_hdr(buf, NFT_MSG_GETRULE, h->family,
NLM_F_DUMP, h->seq);

ret = mnl_talk(h, nlh, nftnl_rule_list_cb, list);
if (ret < 0) {
if (errno == EINTR) {
assert(nft_restart(h) >= 0);
nftnl_rule_list_free(list);
goto retry;
}

nftnl_rule_list_free(list);
return NULL;
}

Because we are running iptables as an unprivileged user, the kernel
returns EPERM in response to our NFT_MSG_GETRULE request.

We need to check the return value of nft_rule_list_get in both cases.

Patch attached.

J.
--- iptables/nft.c.orig	2020-08-16 15:58:02.799901382 +0100
+++ iptables/nft.c	2020-08-16 15:58:07.507901423 +0100
@@ -2110,11 +2110,11 @@
 
 	nft_fn = nft_rule_insert;
 
-	if (rulenum > 0) {
-		list = nft_rule_list_get(h);
-		if (list == NULL)
-			goto err;
+	list = nft_rule_list_get(h);
+	if (list == NULL)
+		goto err;
 
+	if (rulenum > 0) {
 		r = nft_rule_find(h, list, chain, table, data, rulenum);
 		if (r == NULL) {
 			/* special case: iptables allows to insert into
@@ -2132,8 +2132,6 @@
 
 		handle = nftnl_rule_get_u64(r, NFTNL_RULE_HANDLE);
 		DEBUGP("adding after rule handle %"PRIu64"\n", handle);
-	} else {
-		nft_rule_list_get(h);
 	}
 
 	new_rule = nft_rule_add(h, chain, table, data, handle, verbose);


signature.asc
Description: PGP signature

Bug#968508: blender-data: Please only recommend blender instead of python3

[Jonas Smedegaard]

Quoting Elrond (2020-08-16 17:16:26)
> Package: blender-data
> Version: 2.83.3+dfsg-1
> Severity: wishlist
> 
> Hi,
> 
> Installing blender-data alone doesn't make much sense. It
> is most useful with the blender package.
> So, please:
> Recommends: blender (= ${source:Version})
> Don't use "Depends", because that would introduce a
> circular dependency. Which is not good.

Package relations are directional.  Since blender-data cannot use 
blender for anything (data does not use apps - apps uses their data), it 
is correct for blender-data to not depend on or recommend blender.


> On the other hand, blender-data does not need to depend on python3. 
> Yes, there are some python scripts in there, but they do only make 
> sense together with blender.

If blender-data contains scripts which require Python3 to run, then it 
must declare either Depends or Recommends on python3.


> If you want to keep the python3 dep, please turn it into
> python3:any, and also into a Recommends. Recommends means
> "You really should install this. If you don't, expect
> missing functionality", which seems right then.

If those python3 scripts are not always used, then it makes sense to 
relax to only recommend python3.

Only if those python3 scripts are not really used other than as 
examples, they can instead be installed below 
/usr/share/doc/blender/examples and _then_ relax to only suggest 
python3.


 - Jonas

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

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

signature.asc
Description: signature

Bug#968510: ITP: xref-el -- Library for cross-referencing commands in Emacs

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: xref-el
  Version : 1.0.2
  Upstream Author : FSF
* URL : https://www.example.org/
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : Library for cross-referencing commands in Emacs

This is a newer version of xref.el than the one included with Emacs 27.
I am packaging it as a dependency for the latest version of my package
project-el.

This is similar to seq-el and org-mode, which are also bundled with
Emacs, but where we have more recent versions available as a separate
package.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#963652: Patch to build with current sphinx

[Benjamin Hof]

Control: tags -1 patch
Control: block 964387 by -1

Hi,

I believe this issue also affects packages that use python3-m2r as
build dependency.

In the upstream repo there is a patch, which I have attached here.


Kind regards,
Benjamin
diff --git a/debian/patches/0001_suffix_arg_removed_from_sphinx_v3.0.0.patch b/debian/patches/0001_suffix_arg_removed_from_sphinx_v3.0.0.patch
new file mode 100644
index 000..18a3ced
--- /dev/null
+++ b/debian/patches/0001_suffix_arg_removed_from_sphinx_v3.0.0.patch
@@ -0,0 +1,28 @@
+Subject: suffix arg removed from sphinx v3.0.0
+
+Origin: other
+Forwarded: https://github.com/miyakogi/m2r/pull/55
+From: CrossNox 
+Last-Update: 2020-04-06
+Applied-Upstream: no
+---
+ m2r.py | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/m2r.py b/m2r.py
+index 897338d..6bd580e 100644
+--- a/m2r.py
 b/m2r.py
+@@ -649,7 +649,11 @@ def setup(app):
+ app.add_config_value('m2r_parse_relative_links', False, 'env')
+ app.add_config_value('m2r_anonymous_references', False, 'env')
+ app.add_config_value('m2r_disable_inline_math', False, 'env')
+-app.add_source_parser('.md', M2RParser)
++try:
++app.add_source_parser(".md", M2RParser)  # for older sphinx versions
++except TypeError:
++app.add_source_suffix(".md", "markdown")
++app.add_source_parser(M2RParser)
+ app.add_directive('mdinclude', MdInclude)
+ metadata = dict(
+ version=__version__,
diff --git a/debian/patches/series b/debian/patches/series
index 0819c7b..861d3c2 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
+0001_suffix_arg_removed_from_sphinx_v3.0.0.patch
 2001_privacy.patch
 2002_use_system_mathjax.patch

Bug#968106: [Debian-on-mobile-maintainers] Bug#968106: phosh: Shell doesn't start

[Bernhard Übelacker]

Hello Michel Le Bihan,
found this issue interesting and tried to get more information.

First the "trap int3" originates from here [1], and seems just
a consequence of missing packages.

When installing following packages the user interface
could successfully start, without changing the VM vga "hardware".

  systemctl stop phosh
  apt update
  apt install --no-install-recommends --no-install-suggests gnome-session-bin 
libglib2.0-bin gnome-settings-daemon policykit-1 phosh-osk-stub
  systemctl start phosh

Kind regards,
Bernhard


[1]
(gdb) bt
#0  _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
#1  0x7f161ac595f5 in g_log_default_handler 
(log_domain=log_domain@entry=0x55b43a8e7164 "phoc-server", 
log_level=log_level@entry=6, message=message@entry=0x55b43b7dc1d0 "Could not 
create backend", unused_data=unused_data@entry=0x0) at ../../..
/glib/gmessages.c:3123
#2  0x7f161ac5983c in g_logv (log_domain=0x55b43a8e7164 "phoc-server", 
log_level=G_LOG_LEVEL_ERROR, format=, 
args=args@entry=0x7ffdc3657270) at ../../../glib/gmessages.c:1350
#3  0x7f161ac59a1f in g_log (log_domain=log_domain@entry=0x55b43a8e7164 
"phoc-server", log_level=log_level@entry=G_LOG_LEVEL_ERROR, 
format=format@entry=0x55b43a8e7170 "Could not create backend") at 
../../../glib/gmessages.c:1415
#4  0x55b43a8d1502 in phoc_server_constructed (object=0x55b43b7d8010) 
at ../src/server.c:139
#5  0x7f161ad41704 in g_object_new_internal 
(class=class@entry=0x55b43b7d7b70, params=params@entry=0x0, 
n_params=n_params@entry=0) at ../../../gobject/gobject.c:1977
#6  0x7f161ad42f0d in g_object_new_with_properties 
(object_type=94232580553008, n_properties=0, names=names@entry=0x0, 
values=values@entry=0x0) at ../../../gobject/gobject.c:2105
#7  0x7f161ad43961 in g_object_new (object_type=, 
first_property_name=first_property_name@entry=0x0) at 
../../../gobject/gobject.c:1777
#8  0x55b43a8d17ed in phoc_server_get_default () at ../src/server.c:212
#9  0x55b43a8d0f89 in main (argc=, argv=) 
at ../src/main.c:131

# Bullseye/testing amd64 qemu VM 2020-08-16


apt update
apt dist-upgrade


apt install systemd-coredump mmdebstrap squashfs-tools sddm xserver-xorg 
openbox xterm mc qemu-system-x86


su -
mkdir /home/benutzer/test
cd/home/benutzer/test

mmdebstrap --include=linux-image-amd64,live-boot,xserver-xorg-video-all,phosh 
--arch amd64 sid debian-live-root 
http://192.168.178.25:/debian-11-bullseye-deb.debian.org/


root@debian:/home/benutzer/test# mmdebstrap 
--include=linux-image-amd64,live-boot,xserver-xorg-video-all,phosh --arch amd64 
sid debian-live-root 
http://192.168.178.25:/debian-11-bullseye-deb.debian.org/
I: automatically chosen mode: root
I: chroot architecture amd64 is equal to the host's architecture
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing packages...
done
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
I: cleaning package lists and apt cache...
done
done


chroot debian-live-root passwd
chroot debian-live-root useradd -m -s /bin/bash -p $(openssl passwd -1 123456) 
user
chroot debian-live-root systemctl enable phosh
cp debian-live-root/vmlinuz .
cp debian-live-root/initrd.img .
mksquashfs debian-live-root root.squashfs -comp lz4
exit

cd /home/benutzer/test
python3 -m http.server -b localhost 8080

cd /home/benutzer/test
export DISPLAY=:0
qemu-system-x86_64 \
-machine accel=kvm \
-m 2G \
-device virtio-net-pci,netdev=net0 \
-serial stdio -monitor vc \
-netdev 
user,id=net0,hostfwd=tcp::-:22,guestfwd=tcp:10.0.2.252:8080-tcp:localhost:8080,hostname=debian-live
 \
-kernel ./vmlinuz \
-initrd ./initrd.img \
-append "console=ttyS0 ip=frommedia boot=live nopersistence 
fetch=http://10.0.2.252:8080/root.squashfs;




[   28.531593] traps: phoc[354] trap int3 ip:7f45cbc70585 sp:7fff27e0a260 
error:0 in libglib-2.0.so.0.6400.4[7f45cbc36000+81000]
[   33.884796] traps: phoc[373] trap int3 ip:7f136d421585 sp:7ffce5012e30 
error:0 in libglib-2.0.so.0.6400.4[7f136d3e7000+81000]
[   39.221241] traps: phoc[381] trap int3 ip:7f99bb354585 sp:7ffd8b465610 
error:0 in libglib-2.0.so.0.6400.4[7f99bb31a000+81000]
[   44.560172] traps: phoc[389] trap int3 ip:7f0c127e8585 sp:7fff4ec1e510 
error:0 in libglib-2.0.so.0.6400.4[7f0c127ae000+81000]
[   49.897137] traps: phoc[397] trap int3 ip:7fea829a4585 sp:7ffd2f846bc0 
error:0 in libglib-2.0.so.0.6400.4[7fea8296a000+81000]
...
[  257.428198] traps: phoc[1618] trap int3 ip:7f61de676585 sp:7fff9ffe6490 
error:0 in libglib-2.0.so.0.6400.4[7f61de63c000+81000]

echo "deb http://192.168.178.25:/debian-11-bullseye-debug.deb.debian.org/ 
sid-debug main contrib non-free" >> /etc/apt/sources.list

apt update
apt install systemd-coredump openssh-server 

Bug#968511: libgtk-3-0: Segfaults many apps depending on it

[Nicolas Patrois]

Package: libgtk-3-0
Version: 3.24.22-1
Severity: important

Dear Maintainer,

I can’t launch balsa since today:
août 16 17:20:15 nicolas.home kernel: balsa[15034]: segfault at 8887 ip 
b3e95031 sp bfae59b0 error 4 in libgtk-3.so.0.2404.18[b3b53000+397000]
août 16 17:20:15 nicolas.home kernel: Code: 8b 40 34 c3 8d 74 26 00 90 57 56 53 
8b 74 24 10 e8 44 70 cc ff 81 c3 d8 28 51 00 85 f6 74 32 e8 25 10 ff ff 8b 16 
85 d2 74 04 <39> 02 74 11 83 ec 08 50 56 e8 d1 3b cc ff 83 c4 10 85 c0 74 12 8b
I can’t launch gkrellm since yesterday either nor… reportbug with gtk.
I think there is a big issue in this file that belongs to this package.

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

Kernel: Linux 5.7.0-1-686-pae (SMP w/3 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   3.36.1-2
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.34.1-3
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-3
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcolord2   1.4.4-2
ii  libcups2 2.3.3-2
ii  libepoxy01.5.4-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.2+dfsg-3
ii  libfribidi0  1.0.8-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.4-1
ii  libgtk-3-common  3.24.22-1
ii  libharfbuzz0b2.6.7-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libpango-1.0-0   1.46.0-1
ii  libpangocairo-1.0-0  1.46.0-1
ii  libpangoft2-1.0-01.46.0-1
ii  librest-0.7-00.8.1-1+b1
ii  libwayland-client0   1.18.0-2~exp1
ii  libwayland-cursor0   1.18.0-2~exp1
ii  libwayland-egl1  1.18.0-2~exp1
ii  libx11-6 2:1.6.10-3
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon00.10.0-1
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 1.15-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin  3.24.22-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs 1.44.1-1+b1
ii  librsvg2-common  2.48.7-1

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
ii  gtk-vector-screenshot 0.3.2.1-2+b1
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
ii  ibus-gtk3 1.5.22-5
pn  imhangul-gtk3 
ii  libcanberra-gtk3-module   0.30-7
ii  libcaribou-gtk3-module0.4.21-7
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

-- no debconf information

Bug#968437: xindy-rules: Incorrect Norwegian sorting of č and š

[Hilmar Preuße]

Control: tags -1 + pending

Am 15.08.2020 um 11:56 teilte Petter Reinholdtsen mit:

Hi Petter,

patch push to our repository, thanks for report and patch.

Hilmar

> I tested a but further, and can confirm that this patch solve the
> problem:
> 

-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#968509: linux-image-4.19.0-10-amd64: System hangs within a few minutes of booting

[Richard Kettlewell]

Package: src:linux
Version: 4.19.132-1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

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

   * What led up to the situation?

Upgraded from 4.19.0-9 to 4.19.0-10.

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

"apt-get dist-upgrade" and subsequent reboot.

   * What was the outcome of this action?

With kernel 4.19.0-10 the system hangs within minutes.



-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: System manufacturer
product_name: System Product Name
product_version: System Version
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: 1101
board_vendor: ASUSTeK COMPUTER INC.
board_name: PRIME H370M-PLUS
board_version: Rev 1.xx

** Network interface configuration:

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
  network 172.17.207.0
  address 172.17.207.18
  netmask 255.255.255.0
  broadcast 172.17.207.255
  gateway 172.17.207.1
  bridge_ports eno1
  bridge_maxwait 2
  bridge_stp off
  up echo 0 > /proc/sys/net/ipv6/conf/br0/accept_ra
  up ip address add 2001:470:1f09:11ed::12/64 dev br0
  up ip route add default via 2001:470:1f09:11ed::1






** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core Processor Host 
Bridge/DRAM Registers [8086:3ec2] (rev 07)
Subsystem: ASUSTeK Computer Inc. 8th Gen Core Processor Host 
Bridge/DRAM Registers [1043:8694]
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: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 630 
(Desktop) [8086:3e92] (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. UHD Graphics 630 (Desktop) [1043:8694]
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: i915
Kernel modules: i915

00:14.0 USB controller [0c03]: Intel Corporation Cannon Lake PCH USB 3.1 xHCI 
Host Controller [8086:a36d] (rev 10) (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. Cannon Lake PCH USB 3.1 xHCI Host 
Controller [1043:8694]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 RAM memory [0500]: Intel Corporation Cannon Lake PCH Shared SRAM 
[8086:a36f] (rev 10)
Subsystem: ASUSTeK Computer Inc. Cannon Lake PCH Shared SRAM [1043:8694]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:16.0 Communication controller [0780]: Intel Corporation Cannon Lake PCH HECI 
Controller [8086:a360] (rev 10)
Subsystem: ASUSTeK Computer Inc. Cannon Lake PCH HECI Controller 
[1043:8694]
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: mei_me
Kernel modules: mei_me

00:17.0 SATA controller [0106]: Intel Corporation Cannon Lake PCH SATA AHCI 
Controller [8086:a352] (rev 10) (prog-if 01 [AHCI 1.0])
Subsystem: ASUSTeK Computer Inc. Cannon Lake PCH SATA AHCI Controller 
[1043:8694]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ahci
Kernel modules: ahci

00:1c.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI Express Root 
Port [8086:a33a] (rev f0) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1d.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI Express Root 
Port [8086:a330] (rev f0) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- 

Bug#968508: blender-data: Please only recommend blender instead of python3

[Elrond]

Package: blender-data
Version: 2.83.3+dfsg-1
Severity: wishlist

Hi,

Installing blender-data alone doesn't make much sense. It
is most useful with the blender package.
So, please:
Recommends: blender (= ${source:Version})
Don't use "Depends", because that would introduce a
circular dependency. Which is not good.

On the other hand, blender-data does not need to depend on
python3. Yes, there are some python scripts in there, but
they do only make sense together with blender.

If you want to keep the python3 dep, please turn it into
python3:any, and also into a Recommends. Recommends means
"You really should install this. If you don't, expect
missing functionality", which seems right then.


Cheers

Elrond

Bug#968507: O: icon-naming-utils -- script for maintaining backwards compatibility of Tango Project

[Philipp Kern]

Package: wnpp
Severity: normal

I intend to orphan the icon-naming-utils package.

Last upstream release was 11 years ago. There is effectively no churn in
this package. It is also a required build dependency for a bunch of icon
themes:

# Broken Build-Depends:
extra-xdg-menus: icon-naming-utils
gnome-icon-theme: icon-naming-utils (>= 0.8.7)
human-icon-theme/non-free: icon-naming-utils (>= 0.8.1)
mate-icon-theme: icon-naming-utils (>= 0.8.7)
mate-themes: icon-naming-utils
metatheme-gilouche: icon-naming-utils
moblin-icon-theme: icon-naming-utils
sugar-artwork: icon-naming-utils
suru-icon-theme: icon-naming-utils
tangerine-icon-theme/non-free: icon-naming-utils (>= 0.7.1)
tango-icon-theme: icon-naming-utils (>= 0.8.90)

The package description is:
 Tango is a project to create a new cross-desktop and cross-platform icon
 theme, using a standard style guide, and the new Icon Naming Specification.
 This package contains the perl script for maintaining backwards
 compatibility.