Bug#967506: guitarix: depends on deprecated GTK 2

[Hermann Meyer]

Latest guitarix release 0.41.0  use GTK 3, so it just needs to be
updated on bbuild to solve this issue.


regards

hermann

Bug#945718: Python 3 Version

[Soren Stoutner]

Does anyone know if there is a Python 3 version planned, or is this the end of 
life for ownCloud Dolphin integration?

-- 
Soren Stoutner
623-262-6169
so...@stoutner.com

Bug#540782: Please provide dwarf2-eh version of mingw-i686

[Ximin Luo]

Hi, I am digging up an old thread because it is still relevant today.

I am the maintainer of rustc in Debian. I am trying to provide cross-compiling 
libraries for windows. I have 64-bit working fine, however 32-bit is not 
working because rustc expects dw2 exceptions but Debian's mingw only provides 
sjlj.

I therefore request the maintainer to provide the dw2 version.

There were previously arguments saying this would be confusing for users; 
however I note that we *already* provide two mingw toolchains - one for the 
pthreads threading model, and one for the win32 threading model. Incidentally, 
rustc requires the latter.

I am not suggesting that we provide 4 toolchains, only 3, the 3rd one being 
win32+dw2. We could call it gcc-mingw-w64-i686-win32+dw2 for example.

For other context, Fedora in fact recently switched from sjlj to dw2, ditching 
the former completely, largely because of rust:

https://fedoraproject.org/wiki/Changes/Mingw32GccDwarf2

Best,
Ximin

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#966386: cppcheck: crashes with --clang option (.c)

[John Scott]

I saw upstream said they couldn't reproduce with the development tree, so I 
was going to try bisecting this. However when I build non-Debianized Cppcheck 
2.1 using the following default options, I can't reproduce the crash and it 
seems to work.

As you can see from the CMake log it does detect that I have clang-tidy at 
build time, which I don't think it would building the package since it doesn't 
appear to be a build-dep.

Otherwise might depend on some optional features being enabled in the Debian 
package, although I do have the package build-deps installed.

-- The C compiler identification is GNU 10.1.0
-- The CXX compiler identification is GNU 10.1.0
-- Check for working C compiler: /usr/lib/ccache/cc
-- Check for working C compiler: /usr/lib/ccache/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/lib/ccache/c++
-- Check for working CXX compiler: /usr/lib/ccache/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- -- General configuration for Cppcheck 2.1 -
-- 
-- CMake Generator =   Ninja
-- Compiler =  GNU
-- Compiler Version =  10.1.0
-- Build type =Debug
-- CMAKE_INSTALL_PREFIX =  /usr/local
-- C++ flags (General) =
-- C++ flags (Release) =   -O3 -DNDEBUG
-- C++ flags (RelWithDebInfo) = -O2 -g -DNDEBUG
-- C++ flags (Debug) = -g
-- Found Define: _GLIBCXX_DEBUG
-- Found Define: FILESDIR="/usr/lib/x86_64-linux-gnu/cppcheck"
--
-- -
-- ANALYZE_MEMORY =OFF
-- ANALYZE_ADDRESS =   OFF
-- ANALYZE_THREAD =OFF
-- ANALYZE_UNDEFINED = OFF
-- ANALYZE_DATAFLOW =  OFF
-- WARNINGS_ARE_ERRORS =   OFF
--
-- USE_MATCHCOMPILER = Auto
-- USE_MATCHCOMPILER_OPT = Off
--
-- BUILD_SHARED_LIBS = OFF
-- BUILD_TESTS =   OFF
-- ENABLE_CHECK_INTERNAL = OFF
-- ENABLE_OSS_FUZZ =   ON
--
-- BUILD_GUI = OFF
-- WITH_QCHART =   OFF
--
-- HAVE_RULES =OFF
--
-- USE_Z3 =OFF
--
-- CLANG_TIDY=/usr/bin/clang-tidy

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

Bug#968113: apt-file: -s --src --source shortcuts for -I dsc

[Paul Wise]

Package: apt-file
Version: 3.2.2
Severity: wishlist

It would be nice to have an option to enable searching source packages
that is easier to remember & type than `-I dsc` or `--index-names dsc`
such as -s --src --source.

I think the full --source option would be good to have for use in
scripts. The -s option would be good for use on the command-line for
when you remember the short option. The --src option would be good for
use on the command-line when you forgot the -s option.

I'm currently working around this using a shell alias:

alias apt-file-src='apt-file -I dsc'

Please note that in apt-file 2.x from Debian jessie and earlier the -s
option existed and did something else, but apt-file 3.x has been around
for a while now, Debian jessie is now unsupported by the Debian
security/LTS teams and it seems unlikely that the old option would be
used by any scripts.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages apt-file depends on:
ii  apt  2.1.8
ii  libapt-pkg-perl  0.1.36+b3
ii  liblist-moreutils-perl   0.416-1+b5
ii  libregexp-assemble-perl  0.36-1
ii  perl 5.30.3-4

apt-file recommends no packages.

apt-file suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#922396: [Pkg-mozext-maintainers] Bug#922396: Updated package / patch and status information

[Ximin Luo]

I was the last person to upload noscript in 2018.

The reason why I haven't updated it since 2018 is because I've moved onto using 
umatrix personally and also maintaining it in debian.

umatrix gives you more fine-grained permissions including cookies, XHR, etc, so 
you don't need to install a 2nd extension to manage your cookies. It's written 
by the same author as ublock-origin.

>From what I remember noscript maintenance in terms of Debian packaging was 
>also a pain. umatrix maintenance is pretty simple.

I encourage everyone to move to umatrix and drop noscript.

Best,
Ximin

Helge Kreutzmann:
> tags 922396 + patch
> thanks
> 
> Hello,
> this is a central package, so I had a look at it. Unfortunately,
> README.source is outdated, the following recipe works:
> 
>  * apt-get source
>  * cd mozilla-noscript-10.1.9.6
>  * uscan
>  * create appropriate directory, cd into it and tar xJvf 
> ../mozilla-noscript_….orig.tar.xz
>  * copy over debian directory from 10.1.9.6
>  * export QUILT_PATCHES=debian/patches
>  * quilt new 0002b-remove-websites-from-default-white-list.patch
>  * quilt edit common/Policy.js
>  * quilt refresh
>  * comment out 0002 (original) patch in debian/patches/series
>  * dch -i und Changelog-Eintrag vorgenommen (Note: version number)
>  * debuild
> 
> for version 11.0.34 the (new/updated) patch is as follows:
> Author: Ximin Luo , Helge Kreutzmann 
> 
> Description: remove websites from default white list
>  Original patch by
>  From: arno 
>  Date: Tue, 25 Aug 2009 23:32:30 +0200
>  Subject: remove websites from default white list
> 
> Index: mozilla-noscript-11.0.34/common/Policy.js
> ===
> --- mozilla-noscript-11.0.34.orig/common/Policy.js
> +++ mozilla-noscript-11.0.34/common/Policy.js
> @@ -294,21 +294,7 @@ var {Permissions, Policy, Sites} = (() =
>function defaultOptions() {
>  return {
>sites:{
> -trusted: `addons.mozilla.org
> -  afx.ms ajax.aspnetcdn.com
> -  ajax.googleapis.com bootstrapcdn.com
> -  code.jquery.com firstdata.com firstdata.lv gfx.ms
> -  google.com googlevideo.com gstatic.com
> -  hotmail.com live.com live.net
> -  maps.googleapis.com mozilla.net
> -  netflix.com nflxext.com nflximg.com nflxvideo.net
> -  noscript.net
> -  outlook.com passport.com passport.net passportimages.com
> -  paypal.com paypalobjects.com
> -  securecode.com securesuite.net sfx.ms tinymce.cachefly.net
> -  wlxrs.com
> -  yahoo.com yahooapis.com
> -  yimg.com youtube.com 
> ytimg.com`.split(/\s+/).map(Sites.secureDomainKey),
> +trusted: ``.split(/\s+/).map(Sites.secureDomainKey),
>  untrusted: [],
>  custom: {},
>},
> 
> Now I have to check if this updated version works …
> 
> Btw., version 10.1.9.6. still seems to work in firefox 68.10.0esr-1.
> 
> Greetings
> 
>   Helge
> 
> P.S. If someone takes over mozilla-noscript, README.source should be 
>  updated as well
> 
> 
> ___
> Pkg-mozext-maintainers mailing list
> pkg-mozext-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#959865: [Pkg-mozext-maintainers] Bug#959865: New version fixes this issue

[Ximin Luo]

Control: tags -1 + moreinfo unreproducible

Hi you two,

I am in the process of updating this package. However, the curretn verison 
3.4.7-1 works for me with firefox 79 in sid. So I don't know why it's not 
working for you. Therefore I don't feel right to close this bug when updating 
to the new version.

Can you please test the new version when I upload it (in the next few hours) 
and close this bug if it works for you.

Best,
Ximin

Martina Ferrari:
> Hi,
> 
> I was just trying this extension after moving from firefox-esr to
> firefox/sid, and noticed it did not work.
> 
> But if I install the latest version from
> https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/ it works
> again, so packaging a new version should fix this.
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#962259: Creating Webhooks fails and returns error 500

[Antoine Le Gonidec]

I think I found another issue that has the same source than the one reported 
here.

When trying to enable 2-factor authentication on a user account:

Started GET "/profile/two_factor_auth" for :::: at 
2020-08-08 22:28:29 +0200
Processing by Profiles::TwoFactorAuthsController#show as HTML
Completed 500 Internal Server Error in 419ms (ActiveRecord: 18.7ms | 
Elasticsearch: 0.0ms | Allocations: 113618)
  
NoMethodError (undefined method `set_attribute_was' for #
Did you mean?  custom_attributes):
  
app/controllers/profiles/two_factor_auths_controller.rb:8:in `show'
app/controllers/application_controller.rb:497:in `set_current_admin'
lib/gitlab/session.rb:11:in `with_session'
app/controllers/application_controller.rb:488:in `set_session_storage'
lib/gitlab/i18n.rb:55:in `with_locale'
lib/gitlab/i18n.rb:61:in `with_user_locale'
app/controllers/application_controller.rb:482:in `set_locale'
lib/gitlab/error_tracking.rb:51:in `with_context'
app/controllers/application_controller.rb:547:in `sentry_context'
app/controllers/application_controller.rb:475:in `block in set_current_context'
lib/gitlab/application_context.rb:52:in `block in use'
lib/gitlab/application_context.rb:52:in `use'
lib/gitlab/application_context.rb:20:in `with_context'
app/controllers/application_controller.rb:468:in `set_current_context'
lib/gitlab/request_profiler/middleware.rb:17:in `call'
lib/gitlab/middleware/go.rb:20:in `call'
lib/gitlab/etag_caching/middleware.rb:13:in `call'
lib/gitlab/middleware/multipart.rb:125:in `call'
lib/gitlab/middleware/read_only/controller.rb:51:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/same_site_cookies.rb:27:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call'
lib/gitlab/middleware/request_context.rb:23:in `call'
config/initializers/fix_local_cache_middleware.rb:9:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:60:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'



signature.asc
Description: OpenPGP digital signature

Bug#964839: bbswitch-dkms: Fails to re-enable graphics after suspend with kernel 5.7

[Felix Dörre]

Thanks for the hint, this are the observations:
On 5.6:

[389399.743191] PM: suspend entry (deep)
[389399.766750] Filesystems sync: 0.023 seconds
[389399.767062] (NULL device *): firmware: direct-loading firmware 
i915/kbl_dmc_ver1_04.bin
[389399.767088] (NULL device *): firmware: direct-loading firmware 
intel/ibt-12-16.ddc
[389399.767167] (NULL device *): firmware: direct-loading firmware 
regulatory.db
[389399.767170] (NULL device *): firmware: direct-loading firmware 
regulatory.db.p7s
[389399.768870] (NULL device *): firmware: direct-loading firmware 
intel/ibt-12-16.sfi
[389399.770169] (NULL device *): firmware: direct-loading firmware 
iwlwifi-8265-36.ucode
[389399.770188] bbswitch: bbswitch_pm_handler: event_type=3 
is_card_disabled=1 dis_before_suspend_disabled=0

[389399.770189] bbswitch: enabling discrete graphics
[389399.920138] Freezing user space processes ... (elapsed 0.004 
seconds) done.

[389399.924632] OOM killer disabled.
[389399.924633] Freezing remaining freezable tasks ... (elapsed 0.001 
seconds) done.
[389399.926456] printk: Suspending console(s) (use no_console_suspend to 
debug)


[389408.348659] OOM killer enabled.
[389408.348660] Restarting tasks ... done.
[389408.428103] bbswitch: bbswitch_pm_handler: event_type=4 
is_card_disabled=0 dis_before_suspend_disabled=1

[389408.428106] bbswitch: disabling discrete graphics
[389408.493000] pci :01:00.0: refused to change power state from D0 
to D3hot

[389408.495182] PM: suspend exit

On 5.7:
[   89.560733] PM: suspend entry (deep)
[   89.656060] Filesystems sync: 0.095 seconds
[   89.656623] (NULL device *): firmware: direct-loading firmware 
regulatory.db
[   89.656630] (NULL device *): firmware: direct-loading firmware 
regulatory.db.p7s
[   89.657274] (NULL device *): firmware: direct-loading firmware 
iwlwifi-8265-36.ucode
[   89.657646] (NULL device *): firmware: direct-loading firmware 
i915/kbl_dmc_ver1_04.bin
[   89.777521] Freezing user space processes ... (elapsed 0.003 seconds) 
done.

[   89.780568] OOM killer disabled.
[   89.780569] Freezing remaining freezable tasks ... (elapsed 0.001 
seconds) done.
[   89.782023] printk: Suspending console(s) (use no_console_suspend to 
debug)


[   93.238967] OOM killer enabled.
[   93.238968] Restarting tasks ... done.
[   93.304163] bbswitch: bbswitch_pm_handler: event_type=4 
is_card_disabled=1 dis_before_suspend_disabled=0

[   93.304165] PM: suspend exit

So to me, it seems that the suspend event is just missing.

Another, independent experiment has shown, that this missing 
reactivation is the cause for the problem: Enabling the card manually 
before going to suspend is a workaround for the problem.


Kind regards,
Felix

Bug#968112: xiphos: The drop down menu for the books, chapter and verse fails to scroll properly

[cora]

Source: xiphos
Version: 4.1.0
Severity: important
Tags: a11y

Dear Maintainer,

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

   * What led up to the situation? I installed the program and this behaviour
was from the beginning.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?Updating the system was not effective.
   * What was the outcome of this action?The program still did not work
properly.
   * What outcome did you expect instead?I expected for the drop down menu to
work properly.

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



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

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

Bug#968103: [pkg-go] Bug#968103: Please package stable tagged release v1.0.0

[Stephen Gelman]

control: owner -1 !

On Aug 8, 2020, at 12:01 PM, Nicholas D Steeves  wrote:
> 
> Subject: Please package stable tagged release v1.0.0
> Source: golang-github-inconshreveable-mousetrap
> Severity: normal
> 
> Hi,
> 
> While investigating alternatives to "Afterwriting", a nodejs fountain2pdf 
> converter with a nightmare dependency chain, I found "Wrap", which has much 
> more reasonable deps.  It requires mousetrap v1.0.0.  
> 
> "rkt" appears to be the only package that would be affected ( 
> https://codesearch.debian.net/search?q=golang-github-inconshreveable-mousetrap-dev=1
>  
> 
>  )
> 
> Regards,
> Nicholas

rkt FTBFS with the new package, however it also FTBFS in general 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964871 
). Additionally the 
version of this package vendored in rkt 1.0.0 so it seems safe to upload this. 
I will do so in a few minutes!

Stephen

Bug#961903: prusa-slicer: Unwanted background connections to http://files.prusa3d.com/

[Antoni Villalonga]

Please consider the attached patch.

Raw file: 
https://salsa.debian.org/friki/slic3r-prusa/-/raw/1d54f79dc7108515aeb62d2dab4918aea1ffd0e7/debian/patches/Secured-self-updates-and-disable-by-default.patch
Merge Request: 
https://salsa.debian.org/3dprinting-team/slic3r-prusa/-/merge_requests/1

-- 
Antoni Villalonga
https://friki.cat/
From: Antoni Villalonga 
Date: Sun, 09 Aug 2020 00:15:17 +0200
Subject: Secure self-updates and disable by default
Bug-Debian: http://bugs.debian.org/961903
Forwarded: not-needed

--- a/src/slic3r/GUI/AppConfig.cpp
+++ b/src/slic3r/GUI/AppConfig.cpp
@@ -57,9 +57,9 @@
 set("show_incompatible_presets", "0");
 
 if (get("version_check").empty())
-set("version_check", "1");
+set("version_check", "0");
 if (get("preset_update").empty())
-set("preset_update", "1");
+set("preset_update", "0");
 
 if (get("export_sources_full_pathnames").empty())
 set("export_sources_full_pathnames", "0");
--- a/resources/profiles/BIBO.ini
+++ b/resources/profiles/BIBO.ini
@@ -7,7 +7,7 @@
 # This means, the server may force the PrusaSlicer configuration to be downgraded.
 config_version = 0.0.1
 # Where to get the updates from?
-config_update_url = http://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/BIBO/
+config_update_url = https://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/BIBO/
 
 # The printer models will be shown by the Configuration Wizard in this order,
 # also the first model installed & the first nozzle installed will be activated after install.
--- a/resources/profiles/Creality.ini
+++ b/resources/profiles/Creality.ini
@@ -7,8 +7,8 @@
 # This means, the server may force the PrusaSlicer configuration to be downgraded.
 config_version = 0.0.2
 # Where to get the updates from?
-config_update_url = http://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/Creality/
-# changelog_url = http://files.prusa3d.com/?latest=slicer-profiles=%1%
+config_update_url = https://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/Creality/
+# changelog_url = https://files.prusa3d.com/?latest=slicer-profiles=%1%
 
 # The printer models will be shown by the Configuration Wizard in this order,
 # also the first model installed & the first nozzle installed will be activated after install.
--- a/resources/profiles/LulzBot.ini
+++ b/resources/profiles/LulzBot.ini
@@ -4,7 +4,7 @@
 # Vendor name will be shown by the Config Wizard.
 name = LulzBot
 config_version = 0.0.1
-config_update_url = http://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/LulzBot/
+config_update_url = https://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/LulzBot/
 
 [printer_model:MINI_AERO]
 name = Mini Aero
--- a/resources/profiles/PrusaResearch.ini
+++ b/resources/profiles/PrusaResearch.ini
@@ -7,8 +7,8 @@
 # This means, the server may force the PrusaSlicer configuration to be downgraded.
 config_version = 1.1.2
 # Where to get the updates from?
-config_update_url = http://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/PrusaResearch/
-changelog_url = http://files.prusa3d.com/?latest=slicer-profiles=%1%
+config_update_url = https://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/PrusaResearch/
+changelog_url = https://files.prusa3d.com/?latest=slicer-profiles=%1%
 
 # The printer models will be shown by the Configuration Wizard in this order,
 # also the first model installed & the first nozzle installed will be activated after install.
--- a/src/slic3r/GUI/UpdateDialogs.cpp
+++ b/src/slic3r/GUI/UpdateDialogs.cpp
@@ -25,7 +25,7 @@
 namespace GUI {
 
 
-static const char* URL_CHANGELOG = "http://files.prusa3d.com/?latest=slicer-stable=%1%;;
+static const char* URL_CHANGELOG = "https://files.prusa3d.com/?latest=slicer-stable=%1%;;
 static const char* URL_DOWNLOAD = "https://www.prusa3d.com/downloads=%1%;;
 static const char* URL_DEV = "https://github.com/prusa3d/PrusaSlicer/releases/tag/version_%1%;;
 
--- a/src/slic3r/Utils/PresetUpdater.cpp
+++ b/src/slic3r/Utils/PresetUpdater.cpp
@@ -301,7 +301,7 @@
 		const std::string idx_path = (cache_path / (vendor.id + ".idx")).string();
 		const std::string idx_path_temp = idx_path + "-update";
 		//check if idx_url is leading to our site 
-		if (! boost::starts_with(idx_url, "http://files.prusa3d.com/wp-content/uploads/repository/;))
+		if (! boost::starts_with(idx_url, "https://files.prusa3d.com/wp-content/uploads/repository/;))
 		{
 			BOOST_LOG_TRIVIAL(warning) << "unsafe url path for vendor \"" << vendor.name << "\" rejected: " << idx_url;
 			continue;

Bug#968080: xfburn: Bug in the "A full, but erasable disc is in the drive" dialog

[René Kjellerup]

Thank you for the report,
Unfortunately I have no RW media to verify the issue.
It does sound like incorrect behavior and I will see if we can solve
this with the next release,
or at the very least suppress the ask for blanking when opening the
blank disc dialog.

On Sat, Aug 8, 2020 at 12:30 AM Job Bautista
 wrote:
>
> Package: xfburn
> Version: 0.6.2-1
> Severity: normal
>
> Dear Maintainer,
>
> When I try to blank my CD-RW disc, a pop-up dialog saying "A full but
> erasable disc in the drive" appears. When I press yes, it will open another
> Blank Disc window and the same dialog shows up again. It seems like I am
> unable to blank the disc, but if I press no, the dialog disappears and I was
> able to blank. So the blanking works, it's just annoying having to click no
> to a dialog that wasn't supposed to appear.
>
> Attached in this report is a PNG screenshot showing the bug.
>
>
> -- System Information:
> Distributor ID: Devuan
> Description:Devuan GNU/Linux 4 (chimaera/ceres)
> Release:testing/unstable
> Codename:   n/a
> Architecture: x86_64
>
> Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_PH.UTF-8, LC_CTYPE=en_PH.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_PH:en
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> LSM: AppArmor: enabled
>
> Versions of packages xfburn depends on:
> ii  libburn41.5.2-1
> ii  libc6   2.31-2
> ii  libexo-2-0  0.12.11-1
> ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
> ii  libglib2.0-02.64.4-1
> ii  libgstreamer-plugins-base1.0-0  1.16.2-4
> ii  libgstreamer1.0-0   1.16.2-2
> ii  libgtk-3-0  3.24.20-1
> ii  libgudev-1.0-0  233-1
> ii  libisofs6   1.5.2-1
> ii  libxfce4ui-2-0  4.14.1-1+b1
> ii  libxfce4util7   4.14.0-1
>
> xfburn recommends no packages.
>
> xfburn suggests no packages.
>
> -- no debconf information



-- 
-- as life grows older, I gain experience.
-- http://www.alchemiestick.net/

Bug#968106: phosh: Shell doesn't start

[Michel Le Bihan]

Package: phosh
Version: 0.4.3-1
Severity: grave
Justification: renders package unusable

Hello,

On a freshly created Debian sid live system:
```
sudo mmdebstrap --include=linux-image-amd64,live-boot,xserver-xorg-video-
all,phosh --arch amd64 sid debian-live-root http://ftp.pl.debian.org/debian/
sudo chroot debian-live-root passwd
sudo chroot debian-live-root useradd -m -s /bin/bash -p $(openssl passwd -1
123456) user
sudo chroot debian-live-root systemctl enable phosh
cp debian-live-root/vmlinuz .; cp debian-live-root/initrd.img .
sudo mksquashfs debian-live-root root.squashfs -comp lz4
python3 -m http.server -b localhost 8080
qemu-system-x86_64 -machine accel=kvm -m 4G -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;
```
(last command is to start the test VM)

Phosh doesn't start. On the console I see:
```
traps: phoc[362] trap int3 ip:7f684a6d9585 sp:7ffccc2cfe90 error:0 in
libglib-2.0.so.0.6400.4[7f684a69f000+81000]
```

When attempting to start it manually:
```
user@debian:~$ phoc

(phoc:468): phoc-wlroots-CRITICAL **: 18:03:33.384:
[backend/session/logind.c:760] Failed to get seat id: No data available

(phoc:468): phoc-wlroots-CRITICAL **: 18:03:33.393: [backend/session/direct-
ipc.c:30] Do not have root privileges; cannot become DRM master

(phoc:468): phoc-wlroots-CRITICAL **: 18:03:33.396:
[backend/session/session.c:96] Failed to load session backend

(phoc:468): phoc-wlroots-CRITICAL **: 18:03:33.405: [backend/backend.c:286]
Failed to start a DRM session

(phoc:468): phoc-server-ERROR **: 18:03:33.407: Could not create backend
[   76.891092] traps: phoc[468] trap int3 ip:7feeea992585 sp:7ffe555d1130
error:0 in libglib-2.0.so.0.6400.4[7feeea958000+81000]
Trace/breakpoint trap
```

```
user@debian:~$ phoc -E '/usr/bin/phosh -U' -C /usr/share/phosh/phoc.ini

(phoc:517): phoc-wlroots-CRITICAL **: 18:04:01.976:
[backend/session/logind.c:760] Failed to get seat id: No data available

(phoc:517): phoc-wlroots-CRITICAL **: 18:04:01.978: [backend/session/direct-
ipc.c:30] Do not have root privileges; cannot become DRM master

(phoc:517): phoc-wlroots-CRITICAL **: 18:04:01.981:
[backend/session/session.c:96] Failed to load session backend

(phoc:517): phoc-wlroots-CRITICAL **: 18:04:01.983: [backend/backend.c:286]
Failed to start a DRM session

(phoc:517): phoc-server-ERROR **: 18:04:01.986: Could not create backend
```

Starting phosh as root doesn't help:
```
root@debian:~# phosh
/usr/bin/phosh: 12: gnome-session: not found

(phoc:558): phoc-wlroots-CRITICAL **: 18:06:37.488:
[backend/session/logind.c:760] Failed to get seat id: No data available

(phoc:558): phoc-wlroots-CRITICAL **: 18:06:37.490:
[backend/session/direct.c:176] Could not get current tty number: Inappropriate
ioctl for device

(phoc:558): phoc-wlroots-CRITICAL **: 18:06:37.494:
[backend/session/session.c:96] Failed to load session backend

(phoc:558): phoc-wlroots-CRITICAL **: 18:06:37.496: [backend/backend.c:195]
failed to start a session

(phoc:558): phoc-wlroots-CRITICAL **: 18:06:37.498: [backend/backend.c:235]
failed to start backend 'drm'

(phoc:558): phoc-server-ERROR **: 18:06:37.500: Could not create backend
```

root@debian:~# phoc -E '/usr/bin/phosh -U' -C /usr/share/phosh/phoc.ini

(phoc:611): phoc-wlroots-CRITICAL **: 18:07:10.418:
[backend/session/logind.c:760] Failed to get seat id: No data available

(phoc:611): phoc-wlroots-CRITICAL **: 18:07:10.421:
[backend/session/direct.c:176] Could not get current tty number: Inappropriate
ioctl for device

(phoc:611): phoc-wlroots-CRITICAL **: 18:07:10.425:
[backend/session/session.c:96] Failed to load session backend

(phoc:611): phoc-wlroots-CRITICAL **: 18:07:10.428: [backend/backend.c:286]
Failed to start a DRM session

(phoc:611): phoc-server-ERROR **: 18:07:10.431: Could not create backend
```

It's also possible that I missed an important step, but I couldn't find
anything related in the doc.

Michel Le Bihan



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

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 phosh depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  fonts-lato   2.0-2
ii  gsettings-desktop-schemas3.36.1-1
ii  libc62.31-2
ii  libcairo21.16.0-4
pn  libfeedback-0.0-0  

Bug#967205: No python package

[Marcos Fouces]

Hi!

I think that rfdump package is not related with Python. I think there
is a mistake.

Greetings, 
Marcos

Bug#964839: bbswitch-dkms: Fails to re-enable graphics after suspend with kernel 5.7

[Andreas Beckmann]

You could start with adding this (untested) line:

  pr_info("bbswitch_pm_handler: event_type=%ld is_card_disabled=%d
dis_before_suspend_disabled=%d\n", event_type, is_card_disabled(),
dis_before_suspend_disabled);

at the start of bbswitch_pm_handler() (right before the "switch") to get
some more output (test it on both kernels).


Andreas

Bug#968111: lintian-brush: is confused about non-existing pending changes

[Raphaël Hertzog]

Package: lintian-brush
Version: 0.74
Severity: normal

$ git clone https://salsa.debian.org/debian/cpputest.git
$ cd cpputest
$ lintian-brush
/home/rhertzog/tmp/cpputest: Please commit pending changes first.
$ LANG=C git status --ignored
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean


I have no idea why lintian-brush believes that there are pending
changes...

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.20.4
ii  python3  3.8.2-3
ii  python3-breezy   3.1.0-5
ii  python3-debian   0.1.37
ii  python3-debmutate0.4
ii  python3-distro-info  0.23
ii  python3-dulwich  0.20.2-1
ii  python3-iniparse 0.4-3
ii  python3-ruamel.yaml  0.16.10-2

Versions of packages lintian-brush recommends:
ii  decopy   0.2.4.3-0.1
ii  dos2unix 7.4.1-1
ii  gpg  2.2.20-1
ii  libdebhelper-perl13.2
ii  lintian  2.87.0
ii  python3-asyncpg  0.20.1-1+b1
ii  python3-bs4  4.9.1-1
ii  python3-levenshtein  0.12.0-5+b1
ii  python3-pyinotify0.9.6-1.3
ii  python3-toml 0.10.1-1

Versions of packages lintian-brush suggests:
ii  gnome-pkg-tools0.21.2
ii  postgresql-common  215

-- no debconf information

Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

[gregor herrmann]

On Fri, 07 Aug 2020 17:14:30 -0700, Russ Allbery wrote:

> > What I'm wondering is:
> > - depending on debian-policy would be another dependency, and the
> >   debian-policy only installs files to /usr/share/doc which is not
> >guaranteed to exist; and there's also no easily parsable file there;
> If it would be helpful for debian-policy to ship this information directly
> in the package, that should be relatively easy to do.  Feel free to open a
> bug against debian-policy.  I'm not sure if Sean would see any problems
> that I'm not seeing, but I personally have no objection to Policy starting
> to install some machine-readable information about Policy in files in
> /usr/share/debian-policy in a documented format.

I think having the data provided by debian-policy (in the package,
and maybe-for other purposes-also on the website) would be an
excellent idea, thanks for the offer.
 
I'm waiting for Dominique's thoughts before cloning/etc. this bug.


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
   `-   


signature.asc
Description: Digital Signature

Bug#968110: linux-image-5.7.0-2-amd64: USB 3 storage device not detected

[Jörg-Volker Peetz]

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

Dear Maintainer,

USB 3 storage devices (hdd and stick) are not detected. Nothing shows up in the
log files (messages, kern.log) and the command lsusb doesn't show the device.
The version 5.7.6-1 also doesn't work.

A USB 2 storage device and a USB mouse are detected and can be used.

Any ideas?
Regards,
Jörg.


** Model information
sys_vendor: Hewlett-Packard
product_name: HP ProBook 650 G1
product_version: A3008CD10003
chassis_vendor: Hewlett-Packard
chassis_version:
bios_vendor: Hewlett-Packard
bios_version: L77 Ver. 01.21
board_vendor: Hewlett-Packard
board_name: 1993
board_version: KBC Version 16.39

Bug#968109: linux-image-5.7.0-2-arm64: USB unusable on Raspberry Pi 4B 8GB

[Ryutaroh Matsumoto]

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

Dear Maintainer,

I installed an SD card image from
https://raspi.debian.net/daily/raspi_4.img.xz
to Raspberry Pi 4B 8GB (board revision 1.4).

USB is unusable and "lsusb" shows nothing.
Relevant dmesg is as follows:


[3.198861] pci :01:00.0: enabling device ( -> 0002)
[8.663493] pci :01:00.0: xHCI HW not ready after 5 sec (HC bug?) status 
= 0x801
[8.663690] pci :01:00.0: quirk_usb_early_handoff+0x0/0x890 took 5336734 
usecs

[   12.265387] xhci_hcd :01:00.0: xHCI Host Controller
[   12.268816] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[   12.278041] dwc2 fe98.usb: supply vusb_d not found, using dummy regulator
[   12.278134] dwc2 fe98.usb: supply vusb_a not found, using dummy regulator
[   12.282227] xhci_hcd :01:00.0: new USB bus registered, assigned bus 
number 1
[   22.320273] xhci_hcd :01:00.0: can't setup: -110
[   22.336521] xhci_hcd :01:00.0: USB bus 1 deregistered
[   22.353573] xhci_hcd :01:00.0: init :01:00.0 fail, -110


Best regards, Ryutaroh Matsumoto

-- Package-specific info:
** Version:
Linux version 5.7.0-2-arm64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-15), GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 
5.7.10-1 (2020-07-26)

** Command line:
video=HDMI-A-1:3840x2160M@30,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48
 dma.dmachans=0x71f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 
bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 
bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000  console=tty0 
console=ttyS1,115200 root=/dev/mmcblk1p2 rw elevator=deadline fsck.repair=yes 
net.ifnames=0  rootwait

** Tainted: C (1024)
 * staging driver was loaded

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
Device Tree model: Raspberry Pi 4 Model B Rev 1.4

** Loaded modules:
nls_ascii
nls_cp437
vfat
fat
hci_uart
btqca
btrtl
btbcm
btsdio
btintel
bcm2835_v4l2(C)
bluetooth
brcmfmac
brcmutil
videobuf2_vmalloc
videobuf2_memops
snd_bcm2835(C)
videobuf2_v4l2
jitterentropy_rng
videobuf2_common
snd_pcm
drbg
snd_timer
videodev
snd
ansi_cprng
cpufreq_dt
cfg80211
mc
soundcore
ecdh_generic
ecc
rfkill
raspberrypi_cpufreq
bcm2835_wdt
bcm2711_thermal
pwm_bcm2835
iproc_rng200
vchiq(C)
rng_core
leds_gpio
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
btrfs
blake2b_generic
xor
xor_neon
zstd_decompress
zstd_compress
raid6_pq
libcrc32c
crc32c_generic
bfq
broadcom
bcm_phy_lib
xhci_pci
dwc2
xhci_hcd
udc_core
mdio_bcm_unimac
usbcore
genet
sdhci_iproc
of_mdio
sdhci_pltfm
i2c_bcm2835
fixed_phy
libphy
sdhci
gpio_regulator
usb_common
phy_generic

** Network interface configuration:
*** /etc/network/interfaces:
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

*** /etc/network/interfaces.d/eth0:
auto eth0

# TODO: switch back to iptables-persistent once it re-enters testing
iface eth0 inet dhcp
# We don't currently support setup of firewalls here.
#   pre-up iptables-restore < /etc/iptables/rules.v4 || true
#   pre-up ip6tables-restore < /etc/iptables/rules.v6 || ture

*** /etc/network/interfaces.d/wlan0:
auto wlan0

# TODO: switch back to iptables-persistent once it re-enters testing
iface wlan0 inet dhcp
# We don't currently support setup of firewalls here.
#   pre-up iptables-restore < /etc/iptables/rules.v4 || true
#   pre-up ip6tables-restore < /etc/iptables/rules.v6 || ture

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state DOWN group 
default qlen 1000
link/ether dc:a6:32:bb:99:d9 brd ff:ff:ff:ff:ff:ff
3: wlan0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether dc:a6:32:bb:99:da brd ff:ff:ff:ff:ff:ff
inet 192.168.1.84/24 brd 192.168.1.255 scope global dynamic wlan0
   valid_lft 42924sec preferred_lft 42924sec
inet6 2400:4050:2ba1:ac00:dea6:32ff:febb:99da/64 scope global dynamic 
mngtmpaddr 
   valid_lft 14071sec preferred_lft 12271sec
inet6 fe80::dea6:32ff:febb:99da/64 scope link 
   valid_lft forever preferred_lft forever

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:   0   0000 0  0 00  
 0000 0   0  0
  eth0:   0   0000 0  0 0

Bug#968108: lintian: False positive for no-dh-sequencer, maybe due to unexpected target dependency

[Raphaël Hertzog]

Package: lintian
Version: 2.87.0
Severity: normal

In the zim package I have this in debian/rules:

# Zim build system requires those environment variables...
export USER=fake
export HOME=$(CURDIR)/debian/fake-home

$(CURDIR)/debian/fake-home:
mkdir $(CURDIR)/debian/fake-home

%: $(CURDIR)/debian/fake-home
dh $@ --with python3 --buildsystem=pybuild


And this triggers the no-dh-sequencer tag... but as you can see, I'm using
it! It's just that I have a dependency on the target to ensure some
prerequisite.

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

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

Versions of packages 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  1.20.5
ii  file  1:5.38-5
ii  gettext   0.19.8.1-10
ii  gpg   2.2.20-1
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b3
ii  libarchive-zip-perl   1.68-1
ii  libcapture-tiny-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-dpath-perl0.58-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdpkg-perl  1.20.5
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libipc-run3-perl  0.048-2
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libperlio-gzip-perl   0.19-1+b6
ii  libsereal-decoder-perl4.018+ds-1
ii  libsereal-encoder-perl4.018+ds-1
ii  libtext-levenshteinxs-perl0.03-4+b7
ii  libtext-xslate-perl   3.5.8-1
ii  libtime-duration-perl 1.21-1
ii  libtime-moment-perl   0.44-1+b2
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  lzip  1.21-7
ii  man-db2.9.3-2
ii  patchutils0.4.2-1
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#968055: journal uses an unsupported feature, ignoring file

[Michael Biebl]

Am 08.08.20 um 20:34 schrieb 積丹尼 Dan Jacobson:
>> "MB" == Michael Biebl  writes:
> 
> MB> You can either uninstall resolvconf or use the workaround I posted at
> MB> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967906#47
> 
> OK, perhaps there should be a Conflicts: resolvconf ...
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968009
> 

No, why?



signature.asc
Description: OpenPGP digital signature

Bug#957086: chordii: diff for NMU version 4.5.3+repack-0.2

[Sudip Mukherjee]

Control: tags 957086 + patch
Control: tags 957086 + pending

Dear maintainer,

I've prepared an NMU for chordii (versioned as 4.5.3+repack-0.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru chordii-4.5.3+repack/debian/changelog 
chordii-4.5.3+repack/debian/changelog
--- chordii-4.5.3+repack/debian/changelog   2017-01-03 12:27:24.0 
+
+++ chordii-4.5.3+repack/debian/changelog   2020-08-08 20:23:47.0 
+0100
@@ -1,3 +1,10 @@
+chordii (4.5.3+repack-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957086)
+
+ -- Sudip Mukherjee   Sat, 08 Aug 2020 20:23:47 
+0100
+
 chordii (4.5.3+repack-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru chordii-4.5.3+repack/debian/patches/fix_ftbfs.patch 
chordii-4.5.3+repack/debian/patches/fix_ftbfs.patch
--- chordii-4.5.3+repack/debian/patches/fix_ftbfs.patch 1970-01-01 
01:00:00.0 +0100
+++ chordii-4.5.3+repack/debian/patches/fix_ftbfs.patch 2020-08-08 
20:23:23.0 +0100
@@ -0,0 +1,38 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957086
+Forwarded: no
+
+---
+
+--- chordii-4.5.3+repack.orig/src/chordii.h
 chordii-4.5.3+repack/src/chordii.h
+@@ -74,12 +74,14 @@ struct kcs {
+   int s1,s2,s3,s4,s5,s6;
+   int origin;
+   int difficult;
+-  } dummy_kcs;
++  };
++extern struct kcs dummy_kcs;
+ 
+ struct chord_struct {
+   struct chord_struct *next;
+   struct kcs *chord;
+-  } dummy_chord_struct;
++  };
++extern struct chord_struct dummy_chord_struct;
+ 
+ struct sub_title_struct {
+   struct sub_title_struct *next_sub;
+--- chordii-4.5.3+repack.orig/src/grid.c
 chordii-4.5.3+repack/src/grid.c
+@@ -19,6 +19,8 @@
+ 
+ struct chord_struct *so_chordtab = NULL;
+ struct kcs *so_known_chords = NULL;
++struct kcs dummy_kcs;
++struct chord_struct dummy_chord_struct;
+ 
+ int   nb_chord = 0;
+ int   first_ptr = 0;
diff -Nru chordii-4.5.3+repack/debian/patches/series 
chordii-4.5.3+repack/debian/patches/series
--- chordii-4.5.3+repack/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ chordii-4.5.3+repack/debian/patches/series  2020-08-08 20:23:47.0 
+0100
@@ -0,0 +1 @@
+fix_ftbfs.patch

Bug#964611: libqtpas: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below

[Abou Al Montacir]

Hi Paul

On Fri, 2020-08-07 at 15:16 +0200, Abou Al Montacir wrote:
> I'm going to upload both FPC 3.2.0 and Lazarus 2.0.10. So maybe you can wait
> until I upload them before fixing this?
I've just pushed new sources for libqtpat 2.6+2.0.10+dfsg.
I've verified in cowbuilder that we have the very same issue, so you should not
have any particular issue when applying your patch to the new release.
Please upload to SID as soon as you are done.
-- 
Cheers,
Abou Al Montacir


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

Bug#968034: xidle: introduction of setsid() call introduces undocumented behaviour changes

[Matthieu Herrb]

On Fri, Aug 07, 2020 at 09:41:01PM +, Thorsten Glaser wrote:
> Marcel Partap dixit:
> 
> >in my user .tmux.conf, I have put following mechanism
> 
> This is a very complex setup; I cannot easily reproduce what exactly
> makes this fail for you.
> 
> >https://www.mail-archive.com/tech@openbsd.org/msg49105.html
> 
> As I said in my earlier mail, this patch combines multiple changes
> and is… tricky.
> 
> Matthieu, can you have a look at it as well as the change
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/app/xidle/xidle.c.diff?r1=1.3=1.4
> possibly introducing the problem for our user?

Hi,

I'm currently on vacation. I will look at this when I come back later
next week.


> 
> I’m seeing multiple things here:
> 
> • closing stdout and stderr: I agree with that output should go
>   to .xsession-errors (if open) and would remove that, redirecting
>   only stdin from /dev/null
> 
> • using execvp: this makes me cringe, both the change and the
>   current code also. I’d propose introducing two new ways of
>   specifying the command to run. One would take one argument,
>   like -program does, but actually run sh -c  (with
>   shell interpolation, pipes, I/O redirection, etc. possible);
>   the other (probably a double dash) would collect all remaining
>   arguments and create an argument vector from them (whitespace-
>   safe), perhaps with an -argv0 option (like exec -a in some shells)
>   and retire -program entirely (or keep it for a while but document
>   it as deprecated, to avoid breaking users right now)
> 
> • calling setsid(2): is this deliberate? What are the effects of
>   doing so vs. not doing so for the programs run?
> 
>   If this is deliberate, perhaps we can introduce a -keepsession
>   flag that would omit the call to setsid(2) only, for use cases
>   like Marcel’s.
> 
> >noticed the introduction of a setsid() call, which seem to be the source of 
> >the
> 
> Are you sure about this? That is, if you locally recompile xidle with
> just the call to setsid removed, does your scenatio work?
> 
> Thanks,
> //mirabilos
> -- 
> (gnutls can also be used, but if you are compiling lynx for your own use,
> there is no reason to consider using that package)
>   -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

-- 
Matthieu Herrb

Bug#967929: kalarm: Doen't instal properly. It nedd instalation of Akonadi, kdepin-runtime, Kderun, etc...

[Luis Duarte]

Dears
I tried to install Kalarm in Debian 10, only with the Xfce installed. To 
have a full functional Kalarm I needed to additionally install the 
packages: kdepim-runtime and kderun.

My best wishes

On 05/08/2020 07:23, Luis Duarte wrote:

Package: kalarm
Version: 4:18.08.3-1
Severity: important

Dear Maintainer,

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

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

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



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

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

Versions of packages kalarm depends on:
ii  kio  5.54.1-1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libkf5akonadicontact54:18.08.3-1
ii  libkf5akonadicore5abi2   4:18.08.3-7~deb10u1
ii  libkf5akonadimime5   4:18.08.3-1
ii  libkf5akonadiwidgets5abi14:18.08.3-7~deb10u1
ii  libkf5alarmcalendar5abi1 4:18.08.3-2
ii  libkf5auth5  5.54.0-2
ii  libkf5calendarcore5abi2  4:18.08.3-1
ii  libkf5calendarutils5 4:18.08.3-2
ii  libkf5codecs55.54.0-1
ii  libkf5completion55.54.0-1
ii  libkf5configcore55.54.0-1+deb10u1
ii  libkf5configgui5 5.54.0-1+deb10u1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5contacts5  4:18.08.3-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5globalaccel-bin5.54.0-1
ii  libkf5globalaccel5   5.54.0-1
ii  libkf5guiaddons5 5.54.0-1
ii  libkf5holidays5  1:5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5iconthemes55.54.0-1
ii  libkf5identitymanagement518.08.3-2
ii  libkf5itemmodels55.54.0-1
ii  libkf5jobwidgets55.54.0-1
ii  libkf5kdelibs4support5   5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiofilewidgets55.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5libkdepim-plugins  4:18.08.3-2
ii  libkf5libkdepim5 4:18.08.3-2
ii  libkf5mailtransport5 18.08.3-2
ii  libkf5mailtransportakonadi5  18.08.3-2
ii  libkf5mime5abi1  18.08.3-1
ii  libkf5notifications5 5.54.0-1
ii  libkf5pimcommon5abi2 4:18.08.3-2
ii  libkf5pimtextedit5abi2   18.08.3-1
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5textwidgets5   5.54.0-1
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5windowsystem5  5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libphonon4qt5-4  4:4.10.2-1
ii  libqt5core5a 5.11.3+dfsg1-1+deb10u3
ii  libqt5dbus5  5.11.3+dfsg1-1+deb10u3
ii  libqt5gui5   5.11.3+dfsg1-1+deb10u3
ii  libqt5network5   5.11.3+dfsg1-1+deb10u3
ii  libqt5widgets5   5.11.3+dfsg1-1+deb10u3
ii  libstdc++6   8.3.0-6
ii  perl 5.28.1-6+deb10u1
ii  phonon4qt5   4:4.10.2-1

kalarm recommends no packages.

kalarm suggests no packages.

-- no debconf information

Bug#968055: journal uses an unsupported feature, ignoring file

[積丹尼 Dan Jacobson]

> "MB" == Michael Biebl  writes:

MB> You can either uninstall resolvconf or use the workaround I posted at
MB> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967906#47

OK, perhaps there should be a Conflicts: resolvconf ...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968009

Bug#966816: lvm2: Patch to fix the problem

[Asher Gordon]

Michael Biebl  writes:

> As said in the initial message: a better fix is to simply drop that
> ExecStart= line altogether. It's not necessary (anymore) for
> Type=oneshot services.

Sorry, I missed that. Well although it is trivial, here is a patch to
justify the patch tag I added: ;-)
diff --git a/scripts/blk_availability_systemd_red_hat.service.in b/scripts/blk_availability_systemd_red_hat.service.in
index c556e1c8d..c7df95cc0 100644
--- a/scripts/blk_availability_systemd_red_hat.service.in
+++ b/scripts/blk_availability_systemd_red_hat.service.in
@@ -7,7 +7,6 @@ Conflicts=shutdown.target
 
 [Service]
 Type=oneshot
-ExecStart=@bindir@/true
 ExecStop=@SBINDIR@/blkdeactivate -u -l wholevg -m disablequeueing -r wait
 RemainAfterExit=yes
 
Thanks,
Asher

-- 
If you stand on your head, you will get footprints in your hair.
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature

Bug#966096: geeqie: immediate segfault

[James Van Zandt]

Sounds good. I'll check it out.

On Sat, Aug 8, 2020, 1:33 PM Andreas Ronnquist  wrote:

> I am about to upload a git snapshot of geeqie to Debian unstable, in
> which I will close 966509, since it adds a --disable-clutter option,
> which should make it possible to run with or without clutter.
>
> In this bug (966096) I track the g_strsplit segfault.
>
> -- Andreas Rönnquist
> gus...@debian.org
>

Bug#968097: transmission-daemon consumes all memory

[Sandro Tosi]

Hey Moritz,
wanna take a look at this? thanks!

On Sat, Aug 8, 2020 at 9:09 AM ilf  wrote:
>
> Package: transmission-daemon
> Version: 2.94-2+deb10u1
>
> I have been running transmission-daemon on Debian 10 buster since it
> was released, mostly without problems.
>
> On 2020-08-01, transmission-daemon was upgraded to 2.94-2+deb10u1. Since
> then, it consumes all available memory, then all swap, ramping up the
> load, eventually rendering the system unusable.
>
> Attached is a munin graph showing this.
>
> --
> ilf
>
> If you upload your address book to "the cloud", I don't want to be in it.



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

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

Bug#902121: Wishlist - Pgcli bash completion script

[Daniel Baumann]

retitle 902121 pgcli bash completion script
tag 902121 fixed-upstream
thanks

This has been merged upstream as of version 3.0.0, however, the debian
source tarball doesn't contain it (github vs pypi I guess).

Regards,
Daniel

Bug#939406: ITP: ungoogled-chromium -- Web browser that aims to build a safer, faster, and more stable internet browsing experience

[Thomas]

Package: wnpp

Severity: wishlist

Owner: Thomas 

* Package name : ungoogled-chromium

Version : 84.0.4147.105-1.1

Upstream Author : Eloston 

* URL :https://github.com/Eloston/ungoogled-chromium

* License : BSD-3-Clause

Programming Lang: Python

Description : A lightweight approach to removing Google web service dependency

I intend to maintain the package that Piccoro has pointed out here as I use 
this browser on a daily basis and I believe that it is a better alternative to 
chromium. Chromium itself is still very dependent on Google web services to 
operate making this very difficult for those who want to use Chromium without 
the Google aspect to it.

The package currently has a ungoogled-chromium-debian Github link where the 
original developer has included build files for ungoogled-chromium. I also 
intend on contacting & assisting the developer in packaging the files for 
Debian and uploading them to the official Debian archive.The 
ungoogled-chromium-debian branch contains packages for Debian sid and stable 
but is sometimes not as up-to-date as the original upstream source.

So far, I plan on maintaining the package on my own but if I do need help I 
hope that I can reach out to the Debian Chromium Team. I require a sponsor - I 
have found a developer willing to sponsor the uploads.

Bug#968107: POSIX locks not working on fuse fileystems for thunderbird

[Ángel]

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

After updating an i386 system from stretch to buster, it was found that
thunderbird no longer works, instead showing every time the message:
> Thunderbird is already running, but is not responding. To open a new
window, you must first close the existing Thunderbird process, or
restart your system.


strace showed that it is finally shown after thunderbird loops a number
of times on: 

 openat(AT_FDCWD, "<$HOME>/.thunderbird/Profiles//.parentlock", 
O_WRONLY|O_CREAT|O_TRUNC, 0666) = 7
 fcntl64(7, F_GETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0, 
l_pid=3085726144}) = 0
 fcntl64(7, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 
-1 EACCES
 close(7)= 0

this is part of nsProfileLock::Lock() at source file nsProfileLock.cpp


The issue is, another instance of thunderbird was *NOT* running. The
issue manifesting itself every time, even just after booting, also after
removing the exiting .parentlock.

Manually doing these operations from a separate test program worked,
though, so it's not that POSIX locks (even on that same file)
*sometimes* work.

Finally, it was determined that the error only happened if the profile
was in a fuse filesystem, as tested on exFAT and ntfs-3g. Even more
intriguing, on sshfs the old profile doesn't work but a new one does?!

Downgrading thunderbird from 1:68.9.0-1~deb9u1 to 1:68.8.0-1~deb9u1 made
no difference, as didn't downgrading libfuse from 2.9.9-1+deb10u1 to
2.9.7-1+deb9u2. However, going back from 4.19.0-10-686-pae to the old
stretch kernel 4.9.0-12-686-pae makes thunderbird work again. Going
forwards to 5.6.0-0.bpo.2-686-pae, it still fails.

Thus, it seems that some change in the new kernel makes POSIX locks not
work on a fuse filesystem (and fail with EACCES, as opposed to e.g.
EOPNOTSUPP) but only under certain conditions that seem to be triggered
by thunderbird but not by a simpler program.
Interestingly, firefox (which would supposedly use the same profile
locking code) did not show any issue on that same system.

Also, the number of file locks was not limited (this is only the second
F_WRLCK in the process, anyway):
file locks  (-x) unlimited


-- Package-specific info:
** Version:
Linux version 4.19.0-10-686-pae (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-686-pae root=UUID= ro quiet

** Not tainted


** Model information

** Loaded modules:
netlink_diag
speedstep_lib
cpufreq_userspace
cpufreq_powersave
cpufreq_conservative
rfkill
binfmt_misc
fuse
snd_intel8x0
snd_ac97_codec
ac97_bus
snd_pcm
joydev
snd_timer
snd
iTCO_wdt
soundcore
intel_powerclamp
iTCO_vendor_support
sg
pcspkr
serio_raw
rng_core
evdev
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
crypto_simd
cryptd
aes_i586
hid_generic
usbhid
hid
sd_mod
ata_generic
nouveau
psmouse
ata_piix
mxm_wmi
wmi
video
i2c_algo_bit
libata
ttm
drm_kms_helper
uhci_hcd
ehci_pci
i2c_i801
ehci_hcd
drm
scsi_mod
usbcore
8139too
8139cp
lpc_ich
mfd_core
mii
usb_common
thermal
fan
floppy
button


-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-10-686-pae (SMP w/2 CPU cores)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-4.19.0-10-686-pae depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133+deb10u1
ii  kmod26-1
ii  linux-base  4.6

Versions of packages linux-image-4.19.0-10-686-pae recommends:
ii  apparmor 2.13.2-10
ii  firmware-linux-free  3.4

Versions of packages linux-image-4.19.0-10-686-pae suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02+dfsg1-20+deb10u2
pn  linux-doc-4.19  

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

-- no debconf information

Bug#966857: libtpms: FTBFS: tpm2/NVDynamic.c:126:10: error: ‘nvHandle’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

[Seunghun Han]

Hi Lucas,

On Mon, Aug 3, 2020 at 5:12 PM Lucas Nussbaum  wrote:
>
> Source: libtpms
> Version: 0.8.0~dev1-1.1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200802 ftbfs-bullseye
> ... [snip] ...
> > tpm2/NVDynamic.c: In function ‘NvNextByType’:
> > tpm2/NVDynamic.c:126:10: error: ‘nvHandle’ may be used uninitialized in 
> > this function [-Werror=maybe-uninitialized]
> >   126 |  *handle = nvHandle;
> >   |  ^~

Thank you for your notification. I just fixed the FTBFS bug and will
upload the newer version 0.8.0~dev1-1.2 soon.

Best regards,

Seunghun

Bug#964768: libtpms: please make the build reproducible

[Seunghun Han]

Hi Chris,

On Fri, Jul 10, 2020 at 6:30 PM Chris Lamb  wrote:
>
> Source: libtpms
> Version: 0.8.0~dev1-1.1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> Hi,
>
> Whilst working on the Reproducible Builds effort [0] we noticed that
> libtpms could not be built reproducibly.
>
> This is because the 0003-set-man-page-date-to-last-changelog had an
> incorrect path the Debian change which was leading to:
>
> dpkg-parsechangelog: error: cannot open file changelog: No such file or 
> directory
>
> … in the logs.

Thank you for your notification and patch. I just fixed the bug and
will upload a newer version, 0.8.0~dev1-1.2 soon.

Best regards,

Seunghun

Bug#968102: new upstream release (2.16)

[Daniel Baumann]

Hi Carsten,

On 8/8/20 7:11 PM, Carsten Schoenert wrote:
> Mechtilde and myself are working on the required packaging for tbsync
> and the also required providers for TbSync. We had some difficulties to
> get the system installed packages working with Thunderbird due the API
> changes in Thunderbird but we did get it managed.

great to hear the news and thanks for sharing it :)

Regards,
Daniel

Bug#968105: chrony still not started by systemd (on Buster)

[Harald Dunkel]

Package: systemd
Version: 241-7~deb10u4

Chrony (3.4-4) is not started at boot time.

# systemctl status chrony
* chrony.service - chrony, an NTP client/server
   Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: 
enabled)
   Active: inactive (dead)
 Docs: man:chronyd(8)
   man:chronyc(1)
   man:chrony.conf(5)


systemd-timesyncd is not started, either:

root@nas1:/var/log/chrony# systemctl status systemd-timesyncd
* systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; 
vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
   `-disable-with-time-daemon.conf
   Active: inactive (dead)
Condition: start condition failed at Sat 2020-08-08 19:06:25 CEST; 9min ago
   `- ConditionFileIsExecutable=!/usr/sbin/chronyd was not met
 Docs: man:systemd-timesyncd.service(8)

Aug 08 19:06:25 nas1.afaics.de systemd[1]: Condition check resulted in Network 
Time Synchronization being skipped.


Of course I found #947936, but this doesn't help. Apparently this
"start condition" thingy is not working correctly. Would you mind
to fix for Buster?

The system is a openmediavault filer. Its supposed to run out of the
box. Not having a proper time synchronisation (even though its
configured correctly in the web GUI) is a serious problem.


Thanx very much. Keep on your good work
Harri

Bug#927397: u-boot: Very poor ethernet performance on A20 OLinuXino Lime2 Rev.G2

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2019-04-26 09:54:37)
> Quoting Sunil Mohan Adapa (2019-04-25 21:30:03)
> > > Were your Lime2 boards connected with a cross-over cable or via a 
> > > switch during those tests?
> > 
> > Lime2 was connected to a laptop via a cross-over cable (actually 
> > regular cable but the hardware actually detects cross-over setup and 
> > automatically swaps TX/RX).
> 
> Thanks.  Makes good sense to me now (sorry for being dense).

It seems wiring while testing _is_ relevant after all:

Concretely, wiring affects MDI/MDI-X, commonly emulated transparently in 
both hosts and switches nowadays (because it is an optional part of the 
standard for gigabit ethernet), with no need for actually using a 
"cross-over cable".

I do not suspect any flaws in MDI/MDI-X handling itself, but indirectly 
the _need_ for NDI-X matters anyway: The cause for the packet loss 
issues is likely a timing issue. Ethernet is tied to a clock signal fed 
from one end of the wiring - the "master". When using a switch the 
switch end of the wiring becomes master, but in "cross-over" wiring (no 
matter if a cross-over cable is used or whichever of the host PHYs 
emulate cross-over by flipping from the normal MDI to MDI-X) it is 
_undefined_ which end gets becomes master.

It can seem more reliable to setup a minimal test involving only two 
hosts and a cable, but in reality that introduces less reliable results 
than using a switch in-between.

Sunil: It would be helpful to know who from Olimex you talked to, so 
that we can try get back to them and figure out if their tests leading 
to 20% failure was done "head-to-head" (where it is undefined which end 
becomes master but perhaps just a fancier chipset at the peer end wins a 
random race 80% of the time), or they used a switch (where I cannot 
think of such obvious explanation for the 20% failure, and fall back on 
"20% of the chips are behaving differently than the rest").

What I am hoping for is to that all chips behave the same - that the 20% 
can be explained by the wiring in the test setup.


 - 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#968104: openafs-client: Upgrade of openfs-client break until reboot

[Jose M Calhariz]

Package: openafs-client
Version: 1.8.6-1~dsi10+1
Severity: normal

Hi,

I have made a "private backport" of openafs software from bullseye to
buster.  So this means is the first time for me that I am upgrading 
openafs client 1.8.x on live systems.  Where in the past this worked 
without problems for openafs 1.4 and 1.6, now the openafs client stops
working and I need to do a reboot.

What I am requesting is that if possible to do a live upgrade of the
software and the client does not stop working even if it is necessary 
to work with the old software until a reboot.

Kind regards
Jose M Calhariz


-- System Information:
Debian Release: 10.5
Architecture: amd64 (x86_64)

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

Versions of packages openafs-client depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  init-system-helpers1.56+nmu1
ii  libc6  2.28-10
ii  libcom-err21.44.5-1+deb10u3
ii  libhcrypto4-heimdal7.5.0+dfsg-3
ii  libk5crypto3   1.17-3
ii  libkrb5-26-heimdal 7.5.0+dfsg-3
ii  libkrb5support01.17-3
ii  libncurses66.1+20181013-2+deb10u2
ii  libroken18-heimdal 7.5.0+dfsg-3
ii  libtinfo6  6.1+20181013-2+deb10u2
ii  lsb-base   10.2019051400

Versions of packages openafs-client recommends:
ii  lsof  4.91+dfsg-1
ii  openafs-modules-dkms  1.8.6-1~dsi10+1

Versions of packages openafs-client suggests:
pn  openafs-doc   
ii  openafs-krb5  1.8.6-1~dsi10+1

-- debconf information:
* openafs-client/fakestat: true
* openafs-client/thiscell: ist.utl.pt
* openafs-client/crypt: true
* openafs-client/afsdb: true
* openafs-client/cachesize: 1400
* openafs-client/dynroot: No
  openafs-client/cell-info:
* openafs-client/run-client: true

Bug#966509: Bug#966096: geeqie: immediate segfault

[Andreas Ronnquist]

I am about to upload a git snapshot of geeqie to Debian unstable, in
which I will close 966509, since it adds a --disable-clutter option,
which should make it possible to run with or without clutter.

In this bug (966096) I track the g_strsplit segfault.  

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

Bug#968098: ITP: ungoogled-chromium -- A lightweight approach to removing Google web service dependency

[Thomas]

Package: wnpp
Severity: wishlist
Owner: Thomas 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name : ungoogled-chromium
Version : 84.0.4147.105-1.1
Upstream Author : Eloston 
* URL : https://github.com/Eloston/ungoogled-chromium
* License : BSD-3-Clause
Programming Lang: Python
Description : A lightweight approach to removing Google web service dependency

Chromium itself is still very dependent on Google web services to operate 
making this very difficult for those who want to use Chromium without the 
Google aspect to it. This is where ungoogled-chromium comes in and offers an 
alternative to Chromium: A transparent and more private Chromium with Google 
web services stripped from the source code.

I use ungoogled-chromium quite heavily as my main browser as I believe that it 
is a better alternative to the chromium that currently exists.

The package currently has a ungoogled-chromium-debian Github link where the 
original developer has included build files for ungoogled-chromium.
I also intend on contacting & assisting the developer in packaging the files 
for Debian and uploading them to the official Debian archive.The 
ungoogled-chromium-debian branch contains packages for Debian sid and stable 
but is sometimes not as up-to-date as the original upstream source.

So far, I plan on maintaining the package on my own but if I do need help I 
hope that I can reach out to the Debian Chromium Team. I require a sponsor - I 
have found a developer willing to sponsor the uploads.

Bug#968038: sysvinit-utils: do_restart fails when not ran from a terminal

[Trek]

you spotted a bug fixed in my patch 7 of 12 a month ago :)

http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2020-July/003306.html

may be someone will apply them, but who knows?
ciao!

Bug#968102: new upstream release (2.16)

[Carsten Schoenert]

Hello Daniel,

Am 08.08.20 um 18:51 schrieb Daniel Baumann:

Package: tbsync

Hi,

thank you for maintaining tbsync in debian. it would be nice if you
could upgrade it to the current upstream version (2.16), which will make
it work with thunderbird 78.

the current packages of tbsync in experimental install fine with tb 78,
but do not work.


Mechtilde and myself are working on the required packaging for tbsync 
and the also required providers for TbSync. We had some difficulties to 
get the system installed packages working with Thunderbird due the API 
changes in Thunderbird but we did get it managed.


I can't speak for Mechtilde but my guess would be that a upload will 
happen soon.


--
Regards
Carsten Schoenert

Bug#966832: kodi 18.8

[Vasyl Gello]

Hi Balint!

August 8, 2020 4:58:26 PM UTC, "Bálint Réczey"  
написав(-ла):
>This bug is fixed now, and kodi from Salsa builds for me in Ubuntu, so
>you can go ahead with the uploads.
>I've just uploaded new waylandpp upstream version and also libcec, but
>it waits in NEW due to SO version bump.
>I think giving a few days to libcec to be accepted and uploading new
>kodi only after libcec hit unstable would make sense to save a
>rebuild.

I have uploaded 18.8 to Salsa but again, I need you to sponsor the actual 
upload to unstable.
Please sign it when you can.

>Otherwise I see Kodi 19 alpha is out, this is a perfect opportunity to
>upload it to experimental if you feels like it.

Yes, I built and tested it and it is fine. I have prepared all the PVR addons 
in my personal space
and the new required inputstream addons so we can upload them when you approve 
my Kodi
personal repo. In the meantime I want to add the rest of binary addons to Salsa 
and upload them
to experimental too after Kodi 19.0 gets accepted from NEW. After all addons 
are there, I will do
Chorus2 related packaging.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

signature.asc
Description: PGP signature

Bug#968091: Switching to another tty then back to tty1 in 20200808-3 netinst snapshot fails install

[Job Bautista]

Okay, I was still able to install the image successfully.

Job Bautista

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20200808-00:03:03"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux sid 5.7.0-2-amd64 #1 SMP Debian 5.7.10-1 (2020-07-26) x86_64 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [8086:1904] 
(rev 08)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake 
GT2 [HD Graphics 520] [8086:1916] (rev 07)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon 
E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 
08)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP 
USB 3.0 xHCI Controller [8086:9d2f] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:201f]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:15.1 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise 
Point-LP CSME HECI #1 [8086:9d3a] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-LP 
SATA Controller [AHCI mode] [8086:9d03] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #1 [8086:9d10] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #5 [8086:9d14] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.5 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #6 [8086:9d15] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-LP LPC 
Controller [8086:9d48] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise 
Point-LP PMC [8086:9d21] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD 
Audio [8086:9d70] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel, snd_soc_skl
lspci -knn: 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus 
[8086:9d23] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL810xE PCI Express Fast Ethernet controller [10ec:8136] (rev 07)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:200f]
lspci -knn: Kernel driver in use: r8169
lspci -knn: Kernel modules: r8169
lspci -knn: 03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. 
RTL8821AE 802.11ac PCIe Wireless Network Adapter [10ec:8821]
lspci -knn: Subsystem: AzureWave Device [1a3b:2161]
lspci -knn: Kernel driver in use: rtl8821ae
lspci -knn: Kernel modules: rtl8821ae
usb-list: 

usb-list: Bus 01 Device 01: xHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 5.7.0-2-amd64 xhci-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 

usb-list: Bus 01 Device 02: 2.4G Mouse [1ea7:0064]
usb-list:Level 01 Parent 01 Port 00  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Interface 00: Class 03(HID  ) Subclass 01 Protoc

Bug#962952: azure-cli: exception when connecting to azure services

[Luca Boccassi]

On Fri, 10 Jul 2020 17:25:59 +0100 Luca Boccassi 
wrote:
> On Fri, 2020-07-10 at 16:15 +0200, Jakub Wilk wrote:
> > * Luca Boccassi , 2020-07-10, 09:54:
> > > (note that the monitor functionality is but one of the many
features
> > > and subcommands, hence the downgrade in severity).
> > 
> > It's not just the monitor functionality, whatever that is.
> > All the "az vm" commands are broken, e.g.:
> > 
> >$ az vm list
> >The command failed with an unexpected error. Here is the
traceback:
> > 
> >No module named 'antlr4'
> >Traceback (most recent call last):
> >  File "/usr/lib/python3/dist-packages/knack/cli.py", line 215,
in invoke
> >cmd_result = self.invocation.execute(args)
> >  File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/__init__.py", line 553, in execute
> >self.commands_loader.load_arguments(command)
> >  File "/usr/lib/python3/dist-
packages/azure/cli/core/__init__.py", line 345, in load_arguments
> >loader.load_arguments(command)  # this adds entries to the
argument registries
> >  File "/usr/lib/python3/dist-
packages/azure/cli/command_modules/vm/__init__.py", line 31, in
load_arguments
> >from azure.cli.command_modules.vm._params import
load_arguments
> >  File "/usr/lib/python3/dist-
packages/azure/cli/command_modules/vm/_params.py", line 31, in 
> >from azure.cli.command_modules.monitor.actions import
get_period_type
> >  File "/usr/lib/python3/dist-
packages/azure/cli/command_modules/monitor/actions.py", line 7, in

> >import antlr4
> >ModuleNotFoundError: No module named 'antlr4'
> > 
> > The "az vm" commands are so fundamental, that this bug renders the 
> > package unusable IMO.
> > 
> > As a quick work-around, I've moved the import to the function
that 
> > uses it; see the attachment.
> 
> Whether it's fundamental or not is pretty much subjective - I never
use
> it, for example. Anyway, there's a simple enough workaround as
> mentioned - install antlr4 with pip until it gets packaged. Not
ideal,
> but it will do for now. I've asked upstream if they can downgrade to
> antlr3 as well.

No answer from upstream, so applied your workaround in the latest
upload.

-- 
Kind regards,
Luca Boccassi


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

Bug#968103: Please package stable tagged release v1.0.0

[Nicholas D Steeves]

Subject: Please package stable tagged release v1.0.0
Source: golang-github-inconshreveable-mousetrap
Severity: normal

Hi,

While investigating alternatives to "Afterwriting", a nodejs fountain2pdf
converter with a nightmare dependency chain, I found "Wrap", which has much
more reasonable deps.  It requires mousetrap v1.0.0.

"rkt" appears to be the only package that would be affected (
https://codesearch.debian.net/search?q=golang-github-inconshreveable-mousetrap-dev=1
)

Regards,
Nicholas

Bug#966832: kodi 18.8

[Bálint Réczey]

Control: reassign -1 dh-python
Control: fixed -1 4.20200804

Hi Vasyl,

Vasyl Gello  ezt írta (időpont: 2020. aug. 3., H, 6:45):
>
> Dear colleagues,
>
> I confirm the issue affects kodi 18.7+. I prepared 18.8 release, but we are 
> blocked with this bug.

This bug is fixed now, and kodi from Salsa builds for me in Ubuntu, so
you can go ahead with the uploads.
I've just uploaded new waylandpp upstream version and also libcec, but
it waits in NEW due to SO version bump.
I think giving a few days to libcec to be accepted and uploading new
kodi only after libcec hit unstable would make sense to save a
rebuild.

Otherwise I see Kodi 19 alpha is out, this is a perfect opportunity to
upload it to experimental if you feels like it.

Cheers,
Balint


> Kodi 19.0 I am working on in my personal space has no such issue because it 
> already supports python3-only.
> --
> Vasyl Gello
> 
> Certified SolidWorks Expert
>
> Mob.:+380 (98) 465 66 77
>
> E-Mail: vasek.ge...@gmail.com
>
> Skype: vasek.gello
> 
> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#968102: new upstream release (2.16)

[Daniel Baumann]

Package: tbsync

Hi,

thank you for maintaining tbsync in debian. it would be nice if you
could upgrade it to the current upstream version (2.16), which will make
it work with thunderbird 78.

the current packages of tbsync in experimental install fine with tb 78,
but do not work.

Regards,
Daniel

Bug#966470: fix for #966470: biobambam2 autopkgtest failures

[Étienne Mollier]

Control: tags -1 pending

Good day,

I had a look at the autopkgtest failure affecting biobambam2,
and since these segmentation faults were showing up only in my
autopkgtest environment, and not when using the package directly
on my system, it felt like a missing dependency.  So I trapped
system calls issued by the `bamsormadup` command using `strace`
within the run-unit-test script, and it turned out the program
was searching for a libz.so library.

After appending the zlib1g-dev package to dependencies of the
biobambam2 package, the autopkgtest suite fully executes without
errors.  Changes are pushed on Salsa, available for review:

https://salsa.debian.org/med-team/biobambam2

As a side note I also updated the package to version 2.0.173, as
it has been released lately, and cleaned an informational entry
that was showing up in lintian.  This should also unblock and
resolve #966472; should it be mentioned through a "Closes"
statement in the changelog ?

Kind Regards,
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#959387: [Re] paraview-dev: missing cmake vtk modules in the dev package, cannot use

[Jakob Meng]

PS: I've uploaded a patched package based on ParaView 5.7.0-4 from
Debian Sid to

https://git.inf.h-brs.de/jmeng2m/debian-package-paraview




signature.asc
Description: OpenPGP digital signature

Bug#967150: closed by Debian FTP Masters (reply to tony mancill ) (Bug#967150: fixed in jython 2.7.2+repack1-2)

[tony mancill]

Hi Gilles,

On Wed, Aug 05, 2020 at 11:36:05PM +, Debian Bug Tracking System wrote:

> Date: Wed, 05 Aug 2020 16:01:50 -0700
> Source: jython
> Architecture: source
> Version: 2.7.2+repack1-2
> Distribution: experimental
> Urgency: medium
> Maintainer: Debian Java Maintainers 
> 
> Changed-By: tony mancill 
> Closes: 936776 967150
> Changes:
>  jython (2.7.2+repack1-2) experimental; urgency=medium
>  .
>* Team upload
>* Update build dependencies for python 3 (Closes: #936776, #967150)
>* Upload to experimental to give users a chance to test.

Regarding my recent upload of jython, do you have any concerns with me
uploading it to unstable?

I initially uploaded to experimental because it felt odd to build a
package that implements a Python2 runtime using Python3, but I realize
now that it's not odd and I was just being silly.  The build toolchain
version of Python isn't tied to the jython implementation.

The package in experimental functions as an interactive Python
interpreter - i.e., it passes a smoke test.  Do you have suggestions for
a more comprehensive set of tests before uploading?

Thank you,
tony


signature.asc
Description: PGP signature

Bug#968101: init script is broken and does not correctly shutdown squid

[Gianluigi Tiesi]

Package: squid
Severity: important

Hi,

in the initscript I see:

PIDFILE=/run/NAME.pid

it should be $NAME.pid or squid.pid

Regards


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

Kernel: Linux 4.19.0-10-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: sysvinit (via /sbin/init)

Versions of packages squid depends on:
ii  adduser  3.118
ii  libc62.31-3
ii  libcap2  1:2.42-2
ii  libcom-err2  1.45.6-1
ii  libcrypt11:4.4.16-1
ii  libdb5.3 5.3.28+dfsg1-0.6
ii  libdbi-perl  1.643-2
pn  libecap3 
ii  libexpat12.2.9-1
ii  libgcc-s110.2.0-3
ii  libgnutls30  3.6.14-2+b1
ii  libgssapi-krb5-2 1.17-10
ii  libkrb5-31.17-10
ii  libldap-2.4-22.4.50+dfsg-1+b1
ii  libltdl7 2.4.6-14
pn  libnetfilter-conntrack3  
ii  libnettle8   3.6-2
ii  libpam0g 1.3.1-5
ii  libsasl2-2   2.1.27+dfsg-2
ii  libstdc++6   10.2.0-3
ii  libsystemd0  246-2
ii  libxml2  2.9.10+dfsg-5+b1
pn  logrotate
ii  lsb-base 11.1.0
ii  netbase  6.1
pn  squid-common 

Versions of packages squid recommends:
ii  ca-certificates  20200601
ii  libcap2-bin  1:2.42-2

Versions of packages squid suggests:
pn  apparmor 
pn  resolvconf   
pn  smbclient
pn  squid-cgi
pn  squid-purge  
pn  squidclient  
pn  ufw  
pn  winbind  

Bug#964181: linux-image-4.19.0-9-amd64: Unable to get battery status

[Tino Schmidt]

As I feel no one can help me I took this to upstream:
https://bugzilla.kernel.org/show_bug.cgi?id=208729

Bug#967975: rss2email 3.12-1 error

[Justin Piszcz]

Hello,

Yes- it is 100% reproducible:

Versions:
ii  python             2.7.17-2     amd64        interactive high-level
object-$
ii  python3-bs4        4.9.1-1      all          error-tolerant HTML parser
for$
ii  python3-feedparser 5.2.1-2      all          Universal Feed Parser for
Pyth$
ii  python3-html2text  2020.1.16-1  all          Python module for
converting H$
ii  rss2email          1:3.12.1-1     all          receive RSS feeds by
email

rss2email 3.12.1-1
$ # clear out old preferences and start fresh
$ rm -f $HOME/.rss2email/feeds.dat \
>   $HOME/.config/rss2email.cfg \
>   $HOME/.local/share/rss2email.json
$ r2e new test@localhost
Traceback (most recent call last):
  File "/usr/bin/r2e", line 5, in 
rss2email.main.run()
  File "/usr/lib/python3/dist-packages/rss2email/main.py", line 186, in run
args.func(feeds=feeds, args=args)
  File "/usr/lib/python3/dist-packages/rss2email/command.py", line 46, in
new
feeds.save()
  File "/usr/lib/python3/dist-packages/rss2email/feeds.py", line 350, in
save
self._save_feeds()
  File "/usr/lib/python3/dist-packages/rss2email/feeds.py", line 365, in
_save_feeds
self.datafile.close()  # release the lock
AttributeError: 'NoneType' object has no attribute 'close'
$

rss2email 3.11-2
$ # clear out old preferences and start fresh
$ rm -f $HOME/.rss2email/feeds.dat \
>   $HOME/.config/rss2email.cfg \
>   $HOME/.local/share/rss2email.json
$ r2e new user@localhost
$

Regards,

Justin.

-Original Message-
From: gustavo panizzo  
Sent: Friday, August 7, 2020 5:09 PM
To: Justin Piszcz ; 967...@bugs.debian.org
Subject: Re: Bug#967975: rss2email 3.12-1 error


Hello Justin

I think the bug you are reporting has been reported upstream already.
https://github.com/rss2email/rss2email/issues/126

Can you provide more information about your setup?

Specifically the versions of python, python3-feedparser, python3-html2text
and python3-bs4

what operation were you doing when the error appeared? can you
reproduce the issue with a clean configuration/state?

thanks


-- 
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#968074: /usr/sbin/dkms: line 247: /dev/fd/62: No such file or directory

[Harald Dunkel]

I was told this might be a udev problem on systems without systemd.

Bug#968086: installation-reports: Successful install of 20200808-1 netinst iso on Asus X441U

[Job Bautista]

Package: installation-reports
Severity: wishlist

-- Package-specific info:

Boot method: CD
Image version: 20200808-1 netinst 
(https://cdimage.debian.org/cdimage/daily-builds/daily/20200808-1/amd64/iso-cd/debian-testing-amd64-netinst.iso)
Date: 08 August 2020, around 16:15 UTC+8

Machine: Asus X441U
Partitions:

Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs   1950608   0   1950608   0% /dev
tmpfs  tmpfs   399744 976398768   1% /run
/dev/sda4  ext4  47787756 1095500  44235016   3% /
tmpfs  tmpfs  1998716   0   1998716   0% /dev/shm
tmpfs  tmpfs 5120   0  5120   0% /run/lock
tmpfs  tmpfs 4096   0  4096   0% /sys/fs/cgroup
/dev/sda1  vfat2820565352276704   2% /boot/efi


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

I burned the ISO on a CD-RW disc. I installed the firmware-realtek (20200619-1) 
package from my
USB drive during installation. I only installed the bare minimum (which means 
while on "Select and
install software", I unchecked all items). The only complaint I have is my 
touchpad not working in
graphical install. I would also suggest adding more details on the retrieving 
items part, showing
the download speed, just like apt-get does. Other than that, all is good!


==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20200808-00:03:03"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux sid 5.7.0-2-amd64 #1 SMP Debian 5.7.10-1 (2020-07-26) x86_64 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [8086:1904] 
(rev 08)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake 
GT2 [HD Graphics 520] [8086:1916] (rev 07)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon 
E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 
08)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP 
USB 3.0 xHCI Controller [8086:9d2f] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:201f]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:15.1 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise 
Point-LP CSME HECI #1 [8086:9d3a] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-LP 
SATA Controller [AHCI mode] [8086:9d03] (rev 21)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:12a0]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #1 [8086:9d10] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #5 [8086:9d14] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.5 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #6 [8086:9d15] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-LP LPC 
Controller [8086:9d48] (rev 21)
lspci -knn: Subsystem: ASUSTeK C

Bug#968100: RM: python-cobra [s390x] -- ROM; Does not build on s390x any more

[Andreas Tille]

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

Hi,

the package does not build cleanly on s390x (as documented in bug #961224).
So please remove python3-cobra binary on s390x.

Thanks a lot

  Andreas.


Note: this was a request for a partial removal from testing, converted in one 
for unstable

Bug#911560: Tests for GMAC_TX_DELAY = ... with RevC A20 OLinuxino Lime 2

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2020-08-08 14:48:45)
> Quoting Dieter (2020-08-08 11:37:39)
> > However: I was not able to force the other partner (my old lenovo 
> > T500) of the connection to a certain mode.
> > I thought ethtool would allow me to force the T500s, but i could not 
> > find the option.
> 
> Whoa, setting master/slave mode was implemented only since Linux v5.7: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdbdac7649
> 
> Corresponding userspace support was introduced in ethtool v5.8: 
> https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/commit/?id=558f7cc33d
> 
> Ethtool v5.8 is not yet in Debian - was released upstream only 4 days 
> ago.

Request to upgrade of ethtool in debian: https://bugs.debian.org/968099


 - 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#968099: ethtool: please upgrade to v5.8 to support forcing master or slave mode

[Jonas Smedegaard]

Package: ethtool
Version: 1:5.4-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Linux 5.7 introduced support for forcing master or slave mode for
ethernet devices.

This is helpful for debugging issues like Bug#911560, #845128, #927397
suspectedly involving badly calibrated ethernet PHYs.

Interacting with theese new features require ethtool 5.8 or newer.

Therefore, please upgrade ethtool to 5.8.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl8uqhYACgkQLHwxRsGg
ASGSyg//cpQFH7EhWMLig8tFxmPI1FPjb7eQS1H60re19zC5lP+3Mru866WwkGmd
EGxWRddS4Q/Tr2LB819QE1THIm5iM9AKK8ieSF/dh/wSjllZjAywJIo7B5h+0SX1
+0MzYLZtTYG7VpHXDZwUbZKB/Ii8ikluq6Uu3PiEGNJwQyypGxY+OfnGjaDId/qh
VakUHzY5ec54iFiVTzJJx81DCA8j344Ly/UZ2q3BWTRct3Gc2oIllrayKuOI0htH
hYVIn4Q+tdB6LeatVD1nozKavp9I6jx2d2dlGV9rUWIO+lgCh4RIBjJZtW9CQyyp
mmvJw75bzS0l13UWc1jW38+KbRoFjLpU49iuFyRkt3zmK0BMl2dmyTrGvv6Iju98
9f+HffekycgQw27DA2UohpQhuC4QpD46Phxcx46C9xV71WaDF9Qoxm14veRGU6xA
mX+A6B02Uexfgnn8mZEuqJBFClsDUILAnBFRmRudPvjoa6voHEBm8Ex2XhsnJJfo
dZseAU4vADhRXc6/S4+eNw1szz9EoXwKTLsLerL+PBwwrSrzJeB45RQz7IEzbM5L
8bi/HDT6XIm63xWt/vOtMNVU51E/C5ftETo8uPq+FKPWbYRrBLm7qu9Gw5bRsCz/
6c3BCOT3TX78ZzlDkQBfPsnxUlm3QFoT0b1MXSuP/6cBjKsenuw=
=/Wc+
-END PGP SIGNATURE-

Bug#914712: Add the touchpad drivers to be able to use any compatible touchpad during the installations

[Job Bautista]

Hi, I also have the same problem. I can't use the Elan 1200 touchpad of my
Asus X441U laptop in graphical install mode for the stretch and 20200808
netinst images. I haven't tested on the buster and bullseye alpha 2 images, but
considering that my touchpad doesn't work on the latest daily snapshot of
netinst, I assume it won't work with the buster and bullseye images either.
Here are some logs from my installed system showing the touchpad I have:

Jul 10 09:53:09 job-pc kernel: [8.405265] i2c_hid i2c-ELAN1200:00: 
i2c-ELAN1200:00 supply vddl not found, using dummy regulator
Jul 10 09:53:09 job-pc kernel: [9.449019] input: ELAN1200:00 04F3:301A 
Mouse as 
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-7/i2c-ELAN1200:00/0018:04F3:301A.0001/input/input12
Jul 10 09:53:09 job-pc kernel: [9.449289] input: ELAN1200:00 04F3:301A 
Touchpad as 
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-7/i2c-ELAN1200:00/0018:04F3:301A.0001/input/input13
Jul 10 09:53:09 job-pc kernel: [9.449498] hid-generic 0018:04F3:301A.0001: 
input,hidraw0: I2C HID v1.00 Mouse [ELAN1200:00 04F3:301A] on i2c-ELAN1200:00
Jul 10 09:53:09 job-pc kernel: [9.584603] input: ELAN1200:00 04F3:301A 
Touchpad as 
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-7/i2c-ELAN1200:00/0018:04F3:301A.0001/input/input15
Jul 10 09:53:09 job-pc kernel: [9.584811] hid-multitouch 
0018:04F3:301A.0001: input,hidraw0: I2C HID v1.00 Mouse [ELAN1200:00 04F3:301A] 
on i2c-ELAN1200:00
Jul 11 10:31:01 job-pc kernel: [8.607207] i2c_hid i2c-ELAN1200:00: 
i2c-ELAN1200:00 supply vdd not found, using dummy regulator
Jul 11 10:31:01 job-pc kernel: [8.607220] i2c_hid i2c-ELAN1200:00: Linked 
as a consumer to regulator.0
Jul 11 10:31:01 job-pc kernel: [8.607222] i2c_hid i2c-ELAN1200:00: 
i2c-ELAN1200:00 supply vddl not found, using dummy regulator

I don't really mind the touchpad not working, because I could just use text
mode, or if I need graphical, I can use my wireless mouse. But others who are
installing Debian on their laptops might find it annoying.

I suggest adding this bug to the buster and bullseye erratum, like "Touchpad
not working in graphical install".

Job Bautista

signature.asc
Description: OpenPGP digital signature

Bug#968097: transmission-daemon consumes all memory

[ilf]

Package: transmission-daemon
Version: 2.94-2+deb10u1

I have been running transmission-daemon on Debian 10 buster since it 
was released, mostly without problems.


On 2020-08-01, transmission-daemon was upgraded to 2.94-2+deb10u1. Since 
then, it consumes all available memory, then all swap, ramping up the 
load, eventually rendering the system unusable.


Attached is a munin graph showing this.

--
ilf

If you upload your address book to "the cloud", I don't want to be in it.

Bug#968096: reportbug: Can't detect OpenRC as init

[Nils König]

Package: reportbug
Version: 7.7.0
Severity: normal

Dear Maintainer,

Currently reportbug does not detect openrc as init system. (The same seems to 
apply to s6, but I never used s6).
What makes this a bit more complicated is, that it is possible to use openrc 
as 
a service manager and supervisor, but something else — eg sysv-init — as the 
actual init-system.
Or use openrc as init, but leave (some or all) process supervision to s6
  https://github.com/OpenRC/openrc/blob/master/s6-guide.md
.

I've attached patches that afaik should allow OpenRC to be correctly detected 
in 
a "normal" setup and also added a patch to check the name of the actual pid 1 
process, which should work for an openrc+sysv configuration.
I'm not sure what to do with openrc+s6 (and I never used both in conjunction) 
or
if this even matters.

Regards
Nils König

(Below information generated with patched reportbug; see attached patches)

-- Package-specific info:

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

Kernel: Linux 5.7.12-pc3+fs (SMP w/16 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
set
Shell: /bin/sh linked to /usr/bin/dash
Init: openrc (via /run/openrc)
PID 1: openrc-init
LSM: AppArmor: enabled

Versions of packages reportbug depends on:
ii  apt1.8.2.1
ii  python33.7.3-1
ii  python3-reportbug  7.7.0+openrc+pid1
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
pn  debconf-utils 
ii  debsums   2.2.3
pn  default-mta | postfix | exim4 | mail-transport-agent  
pn  dlocate   
pn  emacs-bin-common  
ii  file  1:5.35-4+deb10u1
ii  gnupg 2.2.12-1+deb10u1
pn  python3-urwid 
pn  reportbug-gtk 
ii  xdg-utils 1.1.3-1+deb10u1

Versions of packages python3-reportbug depends on:
ii  apt1.8.2.1
ii  file   1:5.35-4+deb10u1
ii  python33.7.3-1
ii  python3-apt1.8.4.1
ii  python3-debian 0.1.35
ii  python3-debianbts  3.0.2
ii  python3-requests   2.21.0-1
ii  sensible-utils 0.0.12

python3-reportbug suggests no packages.

-- no debconf information


From eee54657ee872be51dcb4aced65d96d2b22818cb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Nils=20K=C3=B6nig?= 
Date: Sat, 8 Aug 2020 01:02:12 +0200
Subject: [PATCH 1/2] reportbug/utils.py: Detect OpenRC as init

OPenRC's init is shipped as /sbin/openrc-init, but its mere
prescence does not indicate if OpenRC is actually used.
Therefore attempt to detect OpenRC by checking for its run-folder.
The caveat is, that openrc may be used as the service manager, but not
as the actual pid1 init system.
---
 reportbug/utils.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/reportbug/utils.py b/reportbug/utils.py
index a1c68b3..beb4828 100644
--- a/reportbug/utils.py
+++ b/reportbug/utils.py
@@ -1207,6 +1207,8 @@ def get_init_system():
 init = 'upstart (via init_is_upstart())'
 elif os.path.isfile('/run/runit.stopit'):
 init = 'runit (via /run/runit.stopit)'
+elif os.path.isdir('/run/openrc'):
+init = 'openrc (via /run/openrc)'
 elif os.path.isfile('/sbin/init') and not os.path.islink('/sbin/init'):
 init = 'sysvinit (via /sbin/init)'
 
-- 
2.20.1

From 292891d9e85b1339c1e0364d1f83dfbaba0dba8d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Nils=20K=C3=B6nig?= 
Date: Sat, 8 Aug 2020 01:12:12 +0200
Subject: [PATCH 2/2] reportbug/bugreport.py, reportbug/utils.py: Check PID 1
 name

It is possible to create setups, in which service-management and
pid1-init are done by different programms, eg openrc with sysv-init.
To have better chances at correctly identifying these setups, check the
PID 1 command name.
---
 reportbug/bugreport.py |  3 +++
 reportbug/utils.py | 13 +
 2 files changed, 16 insertions(+)

diff --git a/reportbug/bugreport.py b/reportbug/bugreport.py
index 920e045..d334852 100644
--- a/reportbug/bugreport.py
+++ b/reportbug/bugreport.py
@@ -83,6 +83,7 @@ class bugreport(object):
 debinfo = ''
 shellpath = utils.realpath('/bin/sh')
 init = utils.get_init_system()
+pid1 = utils.get_pid1_name()
 lsminfo = utils.get_lsm_info()
 taint_flags = utils.get_kernel_taint_flags()
 
@@ -190,6 +191,8 @@ class bugreport(object):
 debinfo += 'Shell: /bin/sh linked to %s\n' % shellpath
 if init:
 debinfo += 'Init: %s\n' % init
+if 

Bug#961224: python-cobra: test failures on s390x

[Andreas Tille]

Hi,

On Sat, May 23, 2020 at 02:56:22PM +0300, Adrian Bunk wrote:
> [ debian-s390 added ]
> 
> On Thu, May 21, 2020 at 05:03:19PM +0100, peter green wrote:
> > Source: python-cobra
> > Version: 0.18.0-1
> > Severity: serious
> > 
> > Three of the last four builds of python-cobra on s390x have failed with.
> > 
> > > === FAILURES 
> > > ===
> > > ___ test_model_summary_to_frame_with_fva[optlang-glpk-0.95] 
> > > 
> > > 
> > > model = , opt_solver = 'optlang-glpk'
> > > fraction = 0.95
> > > 
> > >  @pytest.mark.parametrize("fraction", [0.95])
> > >  def test_model_summary_to_frame_with_fva(model, opt_solver, 
> > > fraction):
> > >  """Test model summary.to_frame() (using FVA)."""
> > >  if opt_solver == "optlang-gurobi":
> > >  pytest.xfail("FVA currently buggy")
> > >  # test non-fva version (these should be fixed for textbook model)
> > >  expected_in_fluxes = ['o2_e', 'glc__D_e', 'nh4_e', 'pi_e', 
> > > np.nan,
> > >np.nan, np.nan, np.nan, np.nan, np.nan, 
> > > np.nan,
> > >np.nan]
> > >  expected_out_fluxes = ['h2o_e', 'co2_e', 'h_e', 'for_e', 'ac_e', 
> > > 'acald_e',
> > > 'pyr_e', 'etoh_e', 'lac__D_e', 'succ_e', 
> > > 'akg_e',
> > > 'glu__L_e']
> > >  model.solver = opt_solver
> > >  solution = model.optimize()
> > >  out_df = model.summary(solution, fva=fraction).to_frame()
> > >  assert out_df[('IN_FLUXES', 'ID')].tolist() == expected_in_fluxes
> > > >   assert out_df[('OUT_FLUXES', 'ID')].tolist() == 
> > > > expected_out_fluxes
> > > E   AssertionError: assert ['h2o_e', 'co... 'pyr_e', ...] == 
> > > ['h2o_e', 'co2...acald_e', ...]
> > > E At index 5 diff: 'pyr_e' != 'acald_e'
> > > E Use -v to get the full diff
> > 
> 
> Can an s390x porter please have a look?

The issue remains in next upstream version.  I will exclude s390x from
the list of architectures since it seems nobody manages to care for this
issue.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#911560: Tests for GMAC_TX_DELAY = ... with RevC A20 OLinuxino Lime 2

[Jonas Smedegaard]

Quoting Dieter (2020-08-08 11:37:39)
> as we found out here
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845128#63),
> FORCE_MASTER was disabled in 2019.01+dfsg-7.
> 
> I therefore downloaded u-boot-2020.07+dfsg-1 and did some testing.
> System: debian buster
> 
> 
> Results are attached.

Thanks!  Valuable!


> u-boot without FORCE_MASTER and different TX-Delays:
> No difference can be seen i guess. I would have expected this, as the
> FORCE_MASTER switch should only work for realtek-PHYs, and the REV K
> uses the Micrel PHY.

Right. That's why I omitted above test for rev. H-L boards in my list of 
TODOs at https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks


> However: I was not able to force the other partner (my old lenovo T500)
> of the connection to a certain mode.
> I thought ethtool would allow me to force the T500s, but i could not
> find the option.

Whoa, setting master/slave mode was implemented only since Linux v5.7: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdbdac7649

Corresponding userspace support was introduced in ethtool v5.8: 
https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/commit/?id=558f7cc33d

Ethtool v5.8 is not yet in Debian - was released upstream only 4 days 
ago.

Sorry, I thought master/slave was same as MDI/MDI-X, but those are 
independent: The former is which end provides clock source, then latter 
is which wires are used: 
https://en.wikipedia.org/wiki/Gigabit_Ethernet#1000BASE-T

According to 
https://www.speedguide.net/articles/network-adapter-optimization-3449 
when auto-negotiated "multi-port devices such as switches become the 
master when connected to a single port device. If both ends are 
multi-port devices, the one with higher seed bits becomes the master."

That seems to indicate that you should reliably put the device in slave 
mode by simply plugging it into a gigabit switch.  Still not sure how to 
force master mode (other than at the other end run Linux 5.7 and compile 
and use ethtool 5.8), as the above does not tell which end "wins" when 
both are single-port devices.


> u-boot with FORCE_MASTER and TX-Delay 4:
> Same as above.
> 
> 
> u-boot with CONFIG_PHY_MICREL instead of CONFIG_PHY_REALTEK

Ohhh, good point - I totally missed that detail!

Seems more optimal to enable CONFIG_PHY_MICREL_KSZ9031.

Would be helpful if you could test...

  * CONFIG_PHY_MICREL_KSZ9031 instead of CONFIG_PHY_MICREL
  * enabling both CONFIG_PHY_REALTEK and CONFIG_PHY_MICREL_KSZ9031
  * above, with various values for TX-Delay


> Good performance with TX-Delay = [3,4].
> The results with TX-Delay = 2 could not be reproduced.
> 
> 
> Summed up: TX-delay = 3/4 seems useful for the Micrel phy.
> With TX-delay = 0, no connection was possible at all.

I would expect TX-delay = 0 to behave same as TX-delay not set at all - 
is that your experience as well?


> Do you know what the switch regarding PHY_MICREL or PHY_REALTEK does? 
> Is this possibly only used in u-boot, and therefore irrelevant as soon 
> as linux boots?

those switches enable code chunks in u-boot.  My (vague!) understanding 
is that some but not all such code chunks does some initialization of 
hardware chips, and that Linux may or may not do its own 
(re)initialization of same bits.

In other words: Possibly - it depends... :-)


> As you mentioned this commit
> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3aed3e2)
> earlier in this thread, i would guess we should re-tests this with a
> linux-image > 5.2?

Ideally we should test network quality from within u-boot, and if we 
identify some u-boot setup that fails from within u-boot but works from 
some Linux, then try identify what initialization the Linux code does 
and try figure out how that could be done in u-boot as well.

...because ideally we want u-boot to work reliably not only for 
initializing what Linux misses, but also for netbooting Linux.


Another test that would be helpful is if you test your board with u-boot 
built with A20-OLinuXino-Lime2-eMMC_defconfig (even if you do not have 
and/or use eMMC): My suspicion is that the added options enabled for 
that defconfig is harmless for non-eMMC boards, and knowing if in fact 
they are harmless is helpful to figure out how many binaries we really 
need to build in Debian, and if e.g. possible to say "use the -eMMC one 
for Micrel-based boards regardless of eMMC".


 - 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#964839: bbswitch-dkms: Fails to re-enable graphics after suspend with kernel 5.7

[Felix Dörre]

On 2020-07-31 10:50, Andreas Beckmann wrote:

I'd guess that bbswitch needs to be adusted to the corresponding kernel
changes.


I just compared the log output to the bbswitch source code and from what 
I can tell:


- There is logic to always enable the discrete graphics card just before 
standby:
> enable the device before suspend to avoid the PCI config space from 
being saved incorrectly

- This logic does not seem to be invoked:
from 5.6:
[   37.338585] Filesystems sync: 3.833 seconds
[   37.339219] (NULL device *): firmware: direct-loading firmware 
regulatory.db
[   37.339222] (NULL device *): firmware: direct-loading firmware 
regulatory.db.p7s
[   37.339918] (NULL device *): firmware: direct-loading firmware 
iwlwifi-8265-36.ucode
[   37.340208] (NULL device *): firmware: direct-loading firmware 
i915/kbl_dmc_ver1_04.bin

[   37.340311] bbswitch: enabling discrete graphics
[   37.493527] Freezing user space processes ... (elapsed 0.003 seconds) 
done.

[   37.496725] OOM killer disabled.
[   37.496727] Freezing remaining freezable tasks ... (elapsed 0.001 
seconds) done.

from 5.7:
[   42.399698] Filesystems sync: 2.100 seconds
[   42.400331] (NULL device *): firmware: direct-loading firmware 
regulatory.db.p7s
[   42.400338] (NULL device *): firmware: direct-loading firmware 
regulatory.db
[   42.401065] (NULL device *): firmware: direct-loading firmware 
iwlwifi-8265-36.ucode
[   42.401339] (NULL device *): firmware: direct-loading firmware 
i915/kbl_dmc_ver1_04.bin
[   42.523291] Freezing user space processes ... (elapsed 0.003 seconds) 
done.

[   42.526435] OOM killer disabled.
[   42.526436] Freezing remaining freezable tasks ... (elapsed 0.001 
seconds) done.


The next step would probably be to look if this 
"register_pm_notifier()" is intended to not work and there is a 
replacement, or what is happening there.


--
Kind regards,
Felix Dörre

Bug#968095: RFS: peony/3.0.0-1 [RC] -- file Manager for the UKUI desktop

[handsome_feng]

Package: sponsorship-requests
Severity: important
X-Debbugs-Cc: jianfen...@ubuntukylin.com

Dear mentors,

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

 * Package name: peony
   Version : 3.0.0-1
   Upstream Author : Yue Lan 
 * URL : https://www.ukui.org/
 * License : GPL-3.0+, LGPL-3+, Expat, GPL-3+
 * Vcs : https://github.com/ukui/peony
   Section : utils

It builds those binary packages:

  libpeony-dev - libraries for Peony components (development files)
  libpeony3 - libraries for Peony components
  peony-common - file manager for the UKUI desktop (common files)
  peony - file Manager for the UKUI desktop

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/p/peony/peony_3.0.0-1.dsc

Changes since the last upload:

 peony (3.0.0-1) unstable; urgency=medium
 .
   * New upstream release. (Closes: #957676)
   * debian:
 - libpeony2 -> libpeony3.
 - Update watch file.

Regards,
--
  handsome_feng



-- 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_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_CN:zh
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#968094: node-prismjs: CVE-2020-15138

[Salvatore Bonaccorso]

Source: node-prismjs
Version: 1.11.0+dfsg-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: Debian Security Team 

Hi,

The following vulnerability was published for node-prismjs.

CVE-2020-15138[0]:
| Prism is vulnerable to Cross-Site Scripting. The easing preview of the
| Previewers plugin has an XSS vulnerability that allows attackers to
| execute arbitrary code in Safari and Internet Explorer. This impacts
| all Safari and Internet Explorer users of Prism =v1.1.0 that use
| the _Previewers_ plugin (=v1.10.0) or the _Previewer: Easing_
| plugin (v1.1.0 to v1.9.0). This problem is fixed in version 1.21.0. To
| workaround the issue without upgrading, disable the easing preview on
| all impacted code blocks. You need Prism v1.10.0 or newer to apply
| this workaround.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-15138
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15138
[1] https://github.com/PrismJS/prism/security/advisories/GHSA-wvhm-4hhf-97x9
[2] 
https://github.com/PrismJS/prism/commit/8bba4880202ef6bd7a1e379fe9aebe69dd75f7be

Regards,
Salvatore

Bug#968093: client bug: event processing lagging behind by ..ms, your system is too slow

[積丹尼 Dan Jacobson]

Package: xserver-xorg-input-kbd
Version: 1:1.9.0-1+b2

/var/log/Xorg.0.log has
(EE) event2  - Logitech USB Keyboard: client bug: event processing lagging 
behind by 11ms, your system is too slow

So my keyboard is faster than my CPU, and it is an error, not even a warning?

Bug#968043: [Python-modules-team] Bug#968043: black: add bash-completion

[Emmanuel Arias]

Hi!

What about if you make a MR here [0]?

[0] https://salsa.debian.org/python-team/applications/black

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El vie., 7 de ago. de 2020 a la(s) 07:39, Hans-Christoph Steiner
(h...@eds.org) escribió:
>
> Package: black
> Version: 18.9b0-1-6
> Severity: minor
>
> Dear Maintainer,
>
> Please add bash-completion to this package.  Here is one that I wrote
> that is available under the same license as black itself:
>
> _have black &&
> _black()
> {
> local cur prev
>
> COMPREPLY=()
> cur=${COMP_WORDS[COMP_CWORD]}
> prev=${COMP_WORDS[COMP_CWORD-1]}
>
> case $prev in
> -l|--line-length|--include|--exclude)
> return 0;;
> esac
> if [[ "$cur" == -* ]]; then
> opts='-l -S -N -q -v -h'
> lopts='
> --check
> --config
> --diff
> --exclude
> --fast
> --include
> --line-length
> --quiet
> --safe
> --skip-numeric-underscore-normalization
> --skip-string-normalization
> --verbose
> --version
> '
> COMPREPLY=( $(compgen -W "${opts[*]} ${lopts[*]}" -- $cur) )
> else
> _filedir
> fi
> }
> complete -F _black $filenames black
>
>
>
> -- System Information:
> Debian Release: 10.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
> 'proposed-updates')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages black depends on:
> ii  python33.7.3-1
> ii  python3-appdirs1.4.3-1
> ii  python3-attr   18.2.0-1
> ii  python3-click  7.0-1
> ii  python3-pkg-resources  40.8.0-1
> ii  python3-toml   0.10.0-1
>
> black recommends no packages.
>
> Versions of packages black suggests:
> pn  python-black-doc  
>
> -- no debconf information
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#968079: [Python-modules-team] Bug#968079: libapache2-mod-wsgi: Package is not installable. Needs older Python2.

[Emmanuel Arias]

Hi,

That problem seems to be fixed on salsa, but I am
waiting for a review.

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El sáb., 8 de ago. de 2020 a la(s) 04:15, greylistd Python issue
(n...@dagami.org) escribió:
>
> Package: libapache2-mod-wsgi
> Version: 4.6.8-1+b1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> When trying to install the package, the following message is displayed:
>
> == begin 
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  python : PreDepends: python-minimal (= 2.7.17-2) but it is not going to be 
> installed
>   Depends: libpython-stdlib (= 2.7.17-2) but it is not going to be 
> installed
>   Depends: python2 (= 2.7.17-2) but 2.7.18-2 is to be installed
> E: Unable to correct problems, you have held broken packages.
> ==  end  
> The problem is that my Python2 is:
> python22.7.18-2 amd64
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to fr_FR.UTF-8), LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages libapache2-mod-wsgi depends on:
> ii  apache2-bin [apache2-api-20120211]  2.4.43-1
> ii  libc6   2.31-3
> ii  libpython2.72.7.18-1
> pn  python  
>
> libapache2-mod-wsgi recommends no packages.
>
> libapache2-mod-wsgi suggests no packages.
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#957230: Bug#966370: bsdmainutils: 12.1.3 removal of lorder breaks rdeps

[Michael Meskes]

> > I'm surprised it is actually used as it was pointed out to me that
> > the script
> > has been non-functional for quite a while.
> 
> I do recall having an issue with it at one point a few years back and
> meaning to submit a patch to bsdmainutils to fix it, but resolved it
> one way or another without that, though can't find any evidence of
> that
> nor can I remember what the problem was. But regardless, it was
> working
> well enough for the freebsd-* packages to build fine.

My guess would be that its functionality is not needed at all.

> > Anyway, it cannot easily be "restored"
> > because the old bsdmainutils package does not exist anymore. All
> > tools except
> > ncal and calendar, which are now in their own package, are now
> > build out of
> > util-linux. Would it be possible to include lorder.sh in one of the
> > affected
> > freebsd packages?
> 
> Yeah, it's possible, and that's no doubt what I'll end up doing. But
> I

I'm glad you agree, I will therefore close this bug.

> really don't appreciate all the breakage that's come about from
> bsdmainutils in the past few months. The util-linux handover was

Pas few months is a slight exaggeration but whatever.

> poorly-handled causing all kinds of problems across the archives

It is well documented that the changes caused more issues than
expected, but all packages received the necessary fixes as quickly as
possible. Having to go through NEW certainly caused some delay, too,
but again stuff like this happens, it's called unstable for a reason.

> (release and ports), and this removal of something, and thus
> *deliberately breaking* the package's "API", should have been done
> more
> carefully by checking whether anyone is actually using it (archive-
> wide
> rebuilds like is done for the new GCC versions is the
> easy-but-computationally-expensive way to do it). As it stands, I got

Come again please? Is this a joke or are you really suggesting we
should rebuild the whole archive to figure out if any package still
uses a non-functional tool in its build process?

> hit with a surprise set of RC bugs from the first archive-wide
> rebuild
> after this change landed, and I therefore have to react in a
> time-pressured way to fix it lest packages be removed from testing
> (though, arguably, testing doesn't matter so much for these given
> kfreebsd-* aren't release architectures). This really should have 

So why do you bring up this point then?

> been
> found out first, with Severity: important bugs filed a month or more
> in
> advance of making the change, that can then be upgraded to be
> release-critical further down the line. So, please, never do a
> transition like this again.

Just for the record, I do not consider removing lorder.sh a transition
of any kind. Nor do I think removing a faulty tool that apparently had
no real functionality anymore warrants the kind of lecture you're
giving me.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org

Bug#964839: bbswitch-dkms: Fails to re-enable graphics after suspend with kernel 5.7

[Felix Dörre]

On 2020-07-31 10:50, Andreas Beckmann wrote:

I'd guess that bbswitch needs to be adusted to the corresponding kernel
changes.


I am quite unfamiliar with the low-level parts of the linux kernel, so I 
probably wouldn't get far if I'd try to look at it. Should I open a 
github issue upstream? Or how would we progress to make bbswitch work again.


--
Kind regards,
Felix Dörre

Bug#968092: libroaring-dev:amd64: please provide pkg-config metadata

[Simon McVittie]

Package: libroaring-dev
Version: 0.2.66+ds-1
Severity: wishlist
Tags: patch fixed-upstream
Forwarded: https://github.com/RoaringBitmap/CRoaring/pull/235

It would be useful for libroaring to provide pkg-config metadata, which
lets Autotools- and make-based build systems discover it, and also lets
meson discover it without needing cmake installed.

This is the sort of "API" thing that should almost always be done upstream
first, so I sent a pull request upstream and it was accepted. If it
takes a while for upstream to make another release, it might be useful
to backport that change. See attached 0001-Add-pkg-config-metadata.patch.

After the upstream developers have made a release with this in, the only
part of that patch that is still necessary will be the addition to
debian/libroaring-dev.install.

It would also be good to have an autopkgtest for linking using pkg-config,
to make sure it doesn't regress. See attached
0002-Add-an-autopkgtest-for-building-with-pkg-config.patch for an example
of how to do that (based on the corresponding CMake autopkgtest that I
provided on #968063).

Thanks,
smcv

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

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

Versions of packages libroaring-dev:amd64 depends on:
ii  libroaring0  0.2.66+ds-1

libroaring-dev:amd64 recommends no packages.

libroaring-dev:amd64 suggests no packages.

-- no debconf information
>From cacd7286475f39be7d420259ebeca4947a1ae672 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 8 Aug 2020 10:21:02 +0100
Subject: [PATCH 1/2] Add pkg-config metadata

---
 debian/libroaring-dev.install |  1 +
 ...-and-install-pkg-config-metadata-235.patch | 48 +++
 debian/patches/series |  1 +
 3 files changed, 50 insertions(+)
 create mode 100644 debian/patches/Generate-and-install-pkg-config-metadata-235.patch

diff --git a/debian/libroaring-dev.install b/debian/libroaring-dev.install
index 994ef05..6ec71e3 100644
--- a/debian/libroaring-dev.install
+++ b/debian/libroaring-dev.install
@@ -1,3 +1,4 @@
 usr/include/roaring
 usr/lib/*/libroaring.so
 usr/lib/*/cmake/roaring
+usr/lib/*/pkgconfig
diff --git a/debian/patches/Generate-and-install-pkg-config-metadata-235.patch b/debian/patches/Generate-and-install-pkg-config-metadata-235.patch
new file mode 100644
index 000..784a30b
--- /dev/null
+++ b/debian/patches/Generate-and-install-pkg-config-metadata-235.patch
@@ -0,0 +1,48 @@
+From: Simon McVittie 
+Date: Fri, 7 Aug 2020 21:17:12 +0100
+Subject: Generate and install pkg-config metadata (#235)
+
+This provides a way for dependent projects with non-CMake build
+systems to locate libroaring. Multiple build systems can read these
+files, either directly (like Meson) or via the pkg-config or pkgconf
+tools (like Autotools).
+
+Signed-off-by: Simon McVittie 
+Applied-upstream: 0.2.67, commit:d7e15791d85fca9ba62591e29ef6b05fc43f5aaa
+---
+ CMakeLists.txt |  4 
+ roaring.pc.in  | 10 ++
+ 2 files changed, 14 insertions(+)
+ create mode 100644 roaring.pc.in
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 54de391..b2e91df 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -43,6 +43,10 @@ find_package(CTargets)
+ find_package(Options)
+ find_package(LTO)
+ 
++configure_file("${CMAKE_CURRENT_SOURCE_DIR}/roaring.pc.in"
++   "${CMAKE_CURRENT_BINARY_DIR}/roaring.pc" @ONLY)
++install(FILES "${CMAKE_CURRENT_BINARY_DIR}/roaring.pc" DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
++
+ ## C header files get installed to /usr/local/include/roaring typically
+ install(DIRECTORY include/${ROARING_LIB_NAME} DESTINATION include)
+ 
+diff --git a/roaring.pc.in b/roaring.pc.in
+new file mode 100644
+index 000..e3b2391
+--- /dev/null
 b/roaring.pc.in
+@@ -0,0 +1,10 @@
++prefix=@CMAKE_INSTALL_PREFIX@
++exec_prefix=${prefix}
++libdir=${prefix}/@CMAKE_INSTALL_LIBDIR@
++includedir=${prefix}/@CMAKE_INSTALL_INCLUDEDIR@
++
++Name: roaring
++Description: Roaring bitmap implementation in C
++Version: @ROARING_LIB_VERSION@
++Cflags: -I${includedir}
++Libs: -L${libdir} -lroaring
diff --git a/debian/patches/series b/debian/patches/series
index d66f89e..2b4d2f9 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 001-containerptr_roaring_bitmap_add-public.patch
+Generate-and-install-pkg-config-metadata-235.patch
-- 
2.28.0

>From 

Bug#968090: RFS: spyne/2.13.15-1~bpo10+1 -- Python library for writing and calling soap web service

[Bastian Germann]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "spyne". I want to make the
python3 version available on buster-backports:

 * Package name: spyne
   Version : 2.13.15-1~bpo10+1
   Upstream Author : Burak Arslan 
 * URL : http://spyne.io/
 * License : LGPL-2.1+
 * Vcs : https://salsa.debian.org/python-team/modules/spyne
   Section : python

It builds those binary packages:

  python3-spyne - Python library for writing and calling soap web service

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/spyne/spyne_2.13.15-1~bpo10+1.dsc

Changes since the last upload:

 spyne (2.13.15-1~bpo10+1) buster-backports; urgency=medium
 .
   * Rebuild for buster-backports.

Regards,
Bastian

Bug#967906: systemd 246 resolvconf path unit

[Thomas Mühlbacher]

Hi,

I found this bugreport after already opening one with resolvconf and
I just thought I'd link you to the one I made:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968015

Cheers,
Thomas Mühlbacher

Bug#961414:

[Nico Schlömer]

FYI, I've added an Ubuntu PPA for it.

Cheers,
Nico

[1] https://launchpad.net/~nschloe/+archive/ubuntu/waybar

Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2

[Thomas Mühlbacher]

I noticed that there were already two related bugreports, with Michael
Biebl providing a solution for the issue:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967906

And to a lesser degree this one, I suppose:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968009

I tried the container setup again with `PathExists=` dropped from
`resolvconf-pull-resolved.path` and it stops the errors from occurring,
however I did not verify that this way the service still does what it's
supposed to.

Cheers,
Thomas Mühlbacher

Bug#910000: Adopting xtables-addons

[Jeremy Sowden]

There is a RFA bug for xtables-addons (cc'ed):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=91

I was thinking about offering to adopt the package, but I'm still a bit
of a novice at maintaining packages in Debian, so although it's fairly
stable and doesn't see a lot of activity upstream, it occurred to me
that it might make more sense for it to be adopted by the Netfilter team
and to offer to help out in that context.

Does this seem like a good idea?  Shall I add it to
https://wiki.debian.org/Teams/pkg-netfilter/tasks?

J.


signature.asc
Description: PGP signature

Bug#968088: qemu-user-static: fails to start armhf Bullseye container on amd64 host

[Ryutaroh Matsumoto]

Package: qemu-user-static
Version: 1:5.0-14
Severity: normal
Tags: fixed-upstream

Dear Maintainer,

This is somewhat similar to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964289
but a different one. This is not observed with
the upstream version 5.1.0-rc3, and I attach fixed-upstream tag.

Then I built a root directory as

# mmdebstrap --components="main contrib non-free" --architectures=armhf 
--variant=important bullseye /var/lib/machines/armhf-bullseye

I fail to start the above systemd-nspawn container as
# systemd-nspawn -M armhf-bullseye -b
Spawning container armhf-bullseye on /var/lib/machines/armhf-bullseye.
Press ^] three times within 1s to kill container.
systemd 245.7-1 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)
Detected virtualization systemd-nspawn.
Detected architecture arm.

Welcome to Debian GNU/Linux bullseye/sid!

Set hostname to .
Caught , core dump failed (child 3, code=killed, status=11/SEGV).
Exiting PID 1...
Container armhf-bullseye failed with error code 255.

Best regards, Ryutaroh Matsumoto


-- 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/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.2.1-1

Versions of packages qemu-user-static suggests:
pn  sudo  

-- no debconf information

Bug#964611: [Pkg-pascal-devel] Bug#964611: libqtpas: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below

[Abou Al Montacir]

Hi Paul,

On Fri, 2020-08-07 at 19:55 +0200, Paul Gevers wrote:
> Hi,
> I am preparing an upload with the symbols file removed as there seems tobe
> consensus that using symbols files for C++ projects in Debian isn'tworth the
> effort.

It will probably require to use 2.0.10 based libQtPas, as I' uploaded both FPC
and Lazarus. So 2.0.8 based one will not build anymore.
-- 
Cheers,
Abou Al Montacir


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

Bug#878875: [Pkg-javascript-devel] Packaging twemoji

[Jonas Smedegaard]

Hi Felix,

Quoting Felix Natter (2020-08-08 10:41:53)
> hello Debian-js,
> 
> I would like to package twemoji (SVGs for unicode emojis) [1], and I
> think debian-js is the right team for this.
> 
> However, I consider packaging only the SVGs and not the javascript code,
> because that's all I need for the freeplane package, and the RFP author
> Dominik (CC:) did not reply to my query (see #878875).
> 
> What do you think, is Debian-js the right place for this, and do you
> need the javascript code?

You are most welcome to maintain twemoji in the JavaScript team and I 
agree that seems a good place to do it, given that upstream build 
framework seem tied to Node.js.  Other options you might consider are 
the fonts team and DebianArt (if the latter is a team, not sure about 
that: Maybe ask Valessio Brito directly).

When packaging it, then yes, please package it reusable for other 
projects as well - that's an important attitude of Debian packaging.  
This (from a quick look) indeed seems to mean include the javascript, 
not only SVGs.  But maybe consult the fonts teams on that - they 
maintain several fonts where upstream ship Javascript stuff as well.

Speaking of SVGs, are you sure this is the real source of those SVG 
files? It seems amchine-generated to me, and I suspect there is real 
concern as to freedom aspects of distributing only as provided here.  
Even if you choose to use the JavaScript team as platform for your 
package maintenance, I recommend that you discuss the issue of source of 
fonts with the font team, as there is collected quite some knowledge and 
experience in that team.

Hmm, maybe the fonts team would be a better place after all.  Not 
sure...

Good luck with the project - seems a great resource to have in Debian!


 - 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#967945: systemd is way too aggressive in deleting journals of yesterday

[Michael Biebl]

What's the output of
journalctl -b -u systemd-journald.service



signature.asc
Description: OpenPGP digital signature

Bug#967945: systemd is way too aggressive in deleting journals of yesterday

[Harald Dunkel]

On 8/5/20 4:46 PM, Chris Hofstaedtler wrote:


More important: how large is your journal directory now?

Chris



Sorry, my bad.

Currently its

# du -ksh /var/log/journal/
913M/var/log/journal/

# ls -al /var/log/journal/
total 56
drwxr-sr-x+  3 root systemd-journal  4096 Jan 13  2016 .
drwxr-xr-x  20 root root12288 Aug  6 00:00 ..
drwxr-sr-x+  2 root systemd-journal 36864 Aug  6 16:48 
42b7d4373eff9fb16ebd59084afbff3f

# ls -al /var/log/journal/42b7d4373eff9fb16ebd59084afbff3f
total 933936
drwxr-sr-x+ 2 root systemd-journal36864 Aug  6 16:48 .
drwxr-sr-x+ 3 root systemd-journal 4096 Jan 13  2016 ..
-rw-r-+ 1 root systemd-journal 25165824 Aug  6 17:33 system.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1002.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1014.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1021.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1022.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 17:25 user-1032.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1045.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 17:25 user-1046.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:15 user-1051.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1053.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:40 user-1055.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1056.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:50 user-1061.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1064.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1065.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1066.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1067.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1069.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1071.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1075.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1076.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1077.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1079.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1080.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1086.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1092.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:30 user-1109.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1123.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:40 user-1127.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1128.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1130.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1132.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:30 user-1133.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1135.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1138.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1139.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1158.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1159.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1168.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1175.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1179.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1188.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1189.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:30 user-1190.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1192.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1193.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1199.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1200.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1201.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1202.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1203.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1204.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1206.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1207.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1210.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1211.journal
-rw-r-+ 1 root systemd-journal  8388608 Aug  6 16:00 user-1225.journal
-rw-r-+ 1 root 

Bug#946046: not fixed

[Vincent Lefevre]

On 2020-08-08 10:04:10 +0200, Stéphane Glondu wrote:
> I still think it is useful to have a unison 2.48 compiled with OCaml
> 4.08.1 around.

Perhaps, but you should make sure that this version cannot be used
together with buster's unison 2.48, because there are not compatible
and can corrupt archive files.

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

Bug#911560: Tests for GMAC_TX_DELAY = ... with RevC A20 OLinuxino Lime 2

[Dieter]

Hi Jonas,

as we found out here
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845128#63),
FORCE_MASTER was disabled in 2019.01+dfsg-7.

I therefore downloaded u-boot-2020.07+dfsg-1 and did some testing.
System: debian buster


Results are attached.

What i did:

u-boot without FORCE_MASTER and different TX-Delays:
No difference can be seen i guess. I would have expected this, as the
FORCE_MASTER switch should only work for realtek-PHYs, and the REV K
uses the Micrel PHY.

However: I was not able to force the other partner (my old lenovo T500)
of the connection to a certain mode.
I thought ethtool would allow me to force the T500s, but i could not
find the option.

u-boot with FORCE_MASTER and TX-Delay 4:
Same as above.


u-boot with CONFIG_PHY_MICREL instead of CONFIG_PHY_REALTEK
Good performance with TX-Delay = [3,4].
The results with TX-Delay = 2 could not be reproduced.


Summed up: TX-delay = 3/4 seems useful for the Micrel phy.
With TX-delay = 0, no connection was possible at all.


Do you know what the switch regarding PHY_MICREL or PHY_REALTEK does? Is
this possibly only used in u-boot, and therefore irrelevant as soon as
linux boots?


As you mentioned this commit
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3aed3e2)
earlier in this thread, i would guess we should re-tests this with a
linux-image > 5.2?

Best regards,
Dieter



u-boot-2020.07+dfsg-1.7z
Description: application/7z-compressed

Bug#946046: not fixed

[Vincent Lefevre]

On 2020-08-08 09:53:21 +0200, Stéphane Glondu wrote:
> Le 08/08/2020 à 03:25, Vincent Lefevre a écrit :
> > The wontfix does not make any sense. The unison-all package is
> > described as follows:
> > 
> > Description: file synchronization tool (all console versions)
> >  This is a metapackage that depends on all supported console versions
> >  of Unison, a file synchronization tool.
> >  .
> >  Each of the supported versions uses a different protocol version;
> >  installing this metapackage ensures the ability to synchronize with
> >  old systems.
> > 
> > See the latest sentence. That's the *only* purpose of the unison-all
> > metapackage.
> 
> Ah right, the "ability to synchronize with old systems" is not correct
> and never will be.

This was correct in the past and really allowed me to have old unison
versions automatically installed. I suppose that either the unison
data formats in the protocol did not depend on the OCaml version at
that time, or it was not needed to rebuild the package after the
Debian release, so this was working in practice.

> For me, the purpose of unison-all is just to have all supported
> versions. For now, there is only one, but there could be many.

I think that this is of little interest if you can't guarantee
synchronization with the previous stable release at least (I
mean between 2 stable releases, or between the current stable
and unstable/testing).

> I accept this bug as an error in the description. Severity serious
> for this seems overreacted, don't you think?

I don't see this as an error in the description in the sense that
users probably installed unison-all to do synchronization between
2 releases, and starting with bullseye (currently unstable), this
is failing. This makes using this package useless, which is RC.

And note that worse than that, only the fact that trying to
synchronize with buster may currently corrupt the archive files
(as I could see). This requires the user to remove these files,
and though unison will not lose any data (in some sense) from a
state with no archive files, fixing the mess needs to be done
manually, and this can be difficult and take much time.

> > So, either you are able to fix the issue in some way via unison-all
> > (I can see only a rather ugly solution, though the end user would
> > not see the ugly part), or the issue cannot be fixed in a clean way,
> > and the unison-all package should just be removed from Debian as
> > being broken by design (co-instability of the stable versions and the
> > unstable version should be sufficient, without needing unison-all),
> > which is probably the easiest was to fix this bug.
> 
> So you think that having a metapackage just to install all supported
> versions is useless? Or even misleading? Then, I will remove unison-all
> and unison-all-gtk.

Yes, this is really misleading. While "ensures the ability to
synchronize with old systems" is clear enough (if it works), the
notion of "supported versions" is confusing, because the user will
have to ask himself whether this means he can synchronize with
older systems. It is better to document in the default package for
the current distribution that if the user wishes to synchronize
with an older distribution, he will have to install the version
from this distribution if it is different (the version being
composed of the version of the unison source and the version of
OCaml used to build unison).

Note: This applies between 2 Debian distributions, which is rather
easy via /etc/apt/sources.list, and with a non-Debian distribution,
the user will have to find a working pair of binaries anyway.

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

Bug#957066: catimg: ftbfs with GCC-10

[Étienne Mollier]

Control: tags -1 fixed-upstream
Control: tags -1 patch

Greetings,

The "master" branch of the upstream repository has a change that
includes a fix for the failure to build from source with Gcc 10:


https://github.com/posva/catimg/commit/05b946cc5cb96ffc36aea41dfcdac9ddbce2cb33

The patch in attachment applies against the existing catimg
version 2.6.0 available in Debian Sid to fix that very specific
bug, but I suppose updating the software to version 2.7.0 would
be a more appropriate approach.

Kind Regards,
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/6, please excuse my verbosity.
Description: fix ftbfs with gcc 10
Author: Étienne Mollier 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957066
Forwarded: not-needed
Applied-Upstream: https://github.com/posva/catimg/commit/05b946cc5cb96ffc36aea41dfcdac9ddbce2cb33
Last-Update: 2020-08-08
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- catimg-2.6.0.orig/src/sh_color.h
+++ catimg-2.6.0/src/sh_color.h
@@ -36,9 +36,9 @@
 } color_yuv_t;
 
 #define N_COLORS 247 ///< Number of colors in terminal
-uint32_t color_map[N_COLORS]; ///< palette of the terminal colors in RGB 0x00RRGGBB
+extern uint32_t color_map[N_COLORS]; ///< palette of the terminal colors in RGB 0x00RRGGBB
 // yuv equivalents
-color_yuv_t yuv_color_map[N_COLORS]; ///< palette of the terminal colors in YUV format
+__attribute__((__common__)) color_yuv_t yuv_color_map[N_COLORS]; ///< palette of the terminal colors in YUV format
 
 
 /**


signature.asc
Description: PGP signature

Bug#966816: lvm2: Patch to fix the problem

[Michael Biebl]

On Thu, 06 Aug 2020 23:59:54 -0400 Asher Gordon  wrote:
> Package: lvm2
> Version: 2.03.09-2
> Followup-For: Bug #966816
> 
> Dear Maintainer,
> 
> I noticed this bug as well, when I was upgrading lvm2. Here is a patch
> to fix the problem:

As said in the initial message: a better fix is to simply drop that
ExecStart= line altogether. It's not necessary (anymore) for
Type=oneshot services.



signature.asc
Description: OpenPGP digital signature

Bug#968081: systemd: Unit blk-availability.service has a bad unit file setting.

[Michael Biebl]

Control: reassign -1 lvm2
Control: forcemerge 966816 -1

Am 08.08.20 um 09:28 schrieb xiscu:
> Package: systemd
> Version: 246-2
> Severity: normal
> 
> Dear Maintainer,
> 
> after lastest apt-get (dist-)upgrade I'm getting on the logs the message:
> 
> ...
> Aug 08  systemd[1]: blk-availability.service: Cannot add dependency job, 
> ignoring:
> Unit blk-availability.service has a bad unit file setting.
> ...
> 
> Let me if you need more info.
> 
> Thanks in advance,

Since this file is shipped by lvm2, you filed this against the wrong
package. Reassigning (and merging) with the existing bug report.

Mcihael




signature.asc
Description: OpenPGP digital signature

Bug#948655: mpi4py: FTBFS on all ppc arches: tests fail: testCreateF90{Complex,Real}Double

[Drew Parsons]

Source: mpi4py
Followup-For: Bug #948655

Patch skip_ppc_failing_tests.patch was created for mpi4py 3.0.3-4 to
skip these failing tests, so builds are now "succeeding", not holding
up the system.

Can assume the failures are still there (if the patch is disabled),
until proven otherwise on a ppc chroot.

Bug#968085: mirrors: Debian mirror ftp.utexas.edu has apparently been discontinued

[Matt Roberds]

Package: mirrors
Severity: normal

Dear Maintainer,

The Debian mirror ftp.utexas.edu is online, but is responding "Not found"
to anything under ftp.utexas.edu/debian .

Looking at

https://mirror-master.debian.org/status/mirror-info/ftp.utexas.edu.html

, the last time this site was available was about 2020-08-05, 03:05 UTC.

The top level at

http://ftp.utexas.edu/

currently has the following notice:


**
  NOTICE: The ftp.utexas.edu service will be discontinued as of August 5,
  2020. All mirrored content will be removed from this server as of
  that date, and the server itself will be shut down on November 5,
  2020.
*


I don't work for or attend the University of Texas.  I noticed this
because I had ftp.utexas.edu in my sources.list .

Thanks for your help!

Matt Roberds

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

Kernel: Linux 4.9.0-12-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#878875: Packaging twemoji

[Felix Natter]

hello Debian-js,

I would like to package twemoji (SVGs for unicode emojis) [1], and I
think debian-js is the right team for this.

However, I consider packaging only the SVGs and not the javascript code,
because that's all I need for the freeplane package, and the RFP author
Dominik (CC:) did not reply to my query (see #878875).

What do you think, is Debian-js the right place for this, and do you
need the javascript code?

[1] https://github.com/twitter/twemoji

Cheers and Best Regards,
--
Felix Natter

Bug#968084: RM: haskell-cborg [armhf] -- ROM; unbuildable

[Ilias Tsitsimpis]

Package: ftp.debian.org
Severity: normal

Hi,

The latest version of haskell-cborg FTBFS on armhf (tests fail with
SIGBUS, probably due to unaligned memory access).

Please remove haskell-cborg and haskell-cborg-json (rev-dependency) from
armhf.

Thanks,

-- 
Ilias

Bug#946046: not fixed

[Stéphane Glondu]

Le 08/08/2020 à 02:41, Vincent Lefevre a écrit :
> unison-2.48 should have never been created: buster has a unison
> package with version number 2.48.4-1, thus one has the impression
> that this is compatible with unison-2.48, while this is not the
> case. The package should have been named unison-2.48+4.08.1 right
> now to avoid this confusion.

I agree with you, retrospectively.

Note that there will never be a unison-2.48+X.XX.X for X.XX.X <> 4.08.1
since unison 2.48.x does not compile with recent versions of OCaml (and
the fix looks too invasive).

> Moreover, unison-2.48 provides /usr/bin/unison-2.48; this is not fine
> since buster also has /usr/bin/unison-2.48, which is not compatible.
> As the client will start a server with the same version number on
> the remote machine (by using the recommended "addversionno = true"),
> this means that one will likely get an archive corruption (which
> happened to me). The OCaml version must be part of the version and
> attached to the name of the unison executable.

Yes, I realized that too late. My hope is to release bullseye with
unison-2.51+X.XX.X and without unison-2.48 at all.

I still think it is useful to have a unison 2.48 compiled with OCaml
4.08.1 around.


Cheers,

-- 
Stéphane

Bug#946046: not fixed

[Stéphane Glondu]

Le 08/08/2020 à 03:25, Vincent Lefevre a écrit :
> The wontfix does not make any sense. The unison-all package is
> described as follows:
> 
> Description: file synchronization tool (all console versions)
>  This is a metapackage that depends on all supported console versions
>  of Unison, a file synchronization tool.
>  .
>  Each of the supported versions uses a different protocol version;
>  installing this metapackage ensures the ability to synchronize with
>  old systems.
> 
> See the latest sentence. That's the *only* purpose of the unison-all
> metapackage.

Ah right, the "ability to synchronize with old systems" is not correct
and never will be. For me, the purpose of unison-all is just to have all
supported versions. For now, there is only one, but there could be many.

I accept this bug as an error in the description. Severity serious for
this seems overreacted, don't you think?

> So, either you are able to fix the issue in some way via unison-all
> (I can see only a rather ugly solution, though the end user would
> not see the ugly part), or the issue cannot be fixed in a clean way,
> and the unison-all package should just be removed from Debian as
> being broken by design (co-instability of the stable versions and the
> unstable version should be sufficient, without needing unison-all),
> which is probably the easiest was to fix this bug.

So you think that having a metapackage just to install all supported
versions is useless? Or even misleading? Then, I will remove unison-all
and unison-all-gtk.

Thank you for your feedback!


Cheers,

-- 
Stéphane

Bug#968082: zathura: adjust-open width setting in zathura results in black screen

[David Purton]

Package: zathura
Version: 0.4.6-1
Severity: normal

Dear Maintainer,

When ~/.config/zathura/zathurarc contains:

set adjust-open width

to make the default zoom when opening a PDF for the first time zoom to
width, PDFs open as a black screen. It's not possible to set the zoom to
width by pressing 's'. But it is possible to press '-' to zoom in a bit
and then press 's' to get the document fitting to width.

If zathura is closed and then the PDF reopened, the PDF opens OK, but
the zoom is at maximum. The PDF can then be zoomed to width OK by
pressing 's'. This zoom is then remembered for that PDF, so subsequent
behaviour is OK (until a new PDF is opened for the first time).

Inspecting ~/.local/share/zathura/history shows that the zoom for the
previously opened PDF is set to 'inf'.

This started happening with zathura 0.4.6-1. Before this new PDFs were
opened with fit to width as default without problems.

Thanks,

David

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

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

Versions of packages zathura depends on:
ii  libc62.31-2
ii  libcairo21.16.0-4
ii  libgirara-gtk3-3 0.3.5-1
ii  libglib2.0-0 2.64.4-1
ii  libgtk-3-0   3.24.20-1
ii  libmagic11:5.38-5
ii  libpango-1.0-0   1.44.7-4
ii  libseccomp2  2.4.3-1+b1
ii  libsqlite3-0 3.32.3-1
ii  libsynctex2  2020.20200327.54578-4+b1
ii  zathura-pdf-poppler  0.3.0-1

zathura recommends no packages.

Versions of packages zathura suggests:
ii  chromium [www-browser]  83.0.4103.116-3+b1
ii  firefox-esr [www-browser]   68.11.0esr-1
ii  google-chrome-stable [www-browser]  84.0.4147.105-1
ii  links [www-browser] 2.20.2-1+b1
ii  w3m [www-browser]   0.5.3-38
pn  zathura-cb  
pn  zathura-djvu
ii  zathura-ps  0.2.6-1

-- no debconf information

Bug#968079: libapache2-mod-wsgi: Package is not installable. Needs older Python2.

[greylistd Python issue]

Package: libapache2-mod-wsgi
Version: 4.6.8-1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When trying to install the package, the following message is displayed:

== begin 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python : PreDepends: python-minimal (= 2.7.17-2) but it is not going to be 
installed
  Depends: libpython-stdlib (= 2.7.17-2) but it is not going to be 
installed
  Depends: python2 (= 2.7.17-2) but 2.7.18-2 is to be installed
E: Unable to correct problems, you have held broken packages.
==  end  
The problem is that my Python2 is:
python22.7.18-2 amd64


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

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

Versions of packages libapache2-mod-wsgi depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.43-1
ii  libc6   2.31-3
ii  libpython2.72.7.18-1
pn  python  

libapache2-mod-wsgi recommends no packages.

libapache2-mod-wsgi suggests no packages.

Bug#968078: gcompris-qt: no images displayed without libqt5svg5

[ahmad haris]

Source: gcompris-qt
Severity: important
Tags: upstream

Dear Maintainer,

* What led up to the situation?

In Armbian/raspbian/armhf/aarch64, installing gcompris-qt without having
libqt5svg5 installed makes it unusable because no images are displayed.

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

Installing the package

* What was the outcome of this action?

Images displayed as expected



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

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

Bug#968077: RFS: davfs2/1.6.0-1 [RC] -- mount a WebDAV resource as a regular file system

[Hsieh-Tseng Shen]

Package: sponsorship-requests
Severity: important
Tags: upstream

Dear mentors,

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

 * Package name: davfs2
   Version : 1.6.0-1
   Upstream Author : Werner Baumann 
 * URL : http://savannah.nongnu.org/projects/davfs2
 * License : GPL-2.0+
 * Vcs : https://salsa.debian.org/debian/davfs2
   Section : utils

It builds those binary packages:

  davfs2 - mount a WebDAV resource as a regular file system

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/davfs2/davfs2_1.6.0-1.dsc

Changes since the last upload:

 davfs2 (1.6.0-1) unstable; urgency=medium
 .
   * New upstream version.
 - Fixed FTBFS with gcc-10. (Closes: #957122)
 - Drop coda module. But the fuse kernel file system is better suited 
anyway.
 - The neon library from version 0.31 on has a workaround for SharePoint's 
href-bug.
   * d/control: update debhelper-compat to 12 and remove d/compat.
   * d/control: add Rules-Requires-Root: no.
   * d/control: add Uploaders to be co-maintainer.
   * d/copyright: update to follow DEP5 format.
   * Add default gbp.conf.
   * Remove the patch for adding neon library version.
   * Remove the patch for doc-data.

Regards,

-- 
Woodrow Shen (Hsieh-Tseng Shen)
4FA0 D159 803F F8B6 34E9  5A38 3970 FE24 7CB6 9685
woodrow.s...@gmail.com


signature.asc
Description: PGP signature