Bug#979551: node-babel7: update-alternatives set up fails

[Paolo Greppi]

Package: node-babel7
Version: 7.12.11+~cs150.141.84-3
Severity: important

Dear Maintainer,

installing node-babel7 on official debian "bullseye-slim" docker image fails 
like this:

docker pull debian:bullseye-slim
docker run --rm -it debian:bullseye-slim
apt update && apt install -y --no-install-recommends yarnpkg
...
Setting up node-babel7 (7.12.11+~cs150.141.84-3) ...
update-alternatives: using /usr/bin/babeljs-7 to provide /usr/bin/babeljs 
(babeljs) in auto mode
update-alternatives: using /usr/bin/babeljs-7-external-helpers to provide 
/usr/bin/babeljs-external-helpers (babeljs-external-helpers) in auto mode
update-alternatives: using /usr/bin/babeljs-7-node to provide 
/usr/bin/babeljs-node (babeljs-node) in auto mode
update-alternatives: using /usr/bin/babeljs-7-parser to provide 
/usr/bin/babeljs-parser (babeljs-parser) in auto mode
update-alternatives: error: alternative path /usr/share/man/man1/babeljs-7.1.gz 
doesn't exist
dpkg: error processing package node-babel7 (--configure):
 installed node-babel7 package post-installation script subprocess returned 
error exit status 2
dpkg: dependency problems prevent configuration of yarnpkg:
 yarnpkg depends on node-babel7; however:
  Package node-babel7 is not configured yet.

dpkg: error processing package yarnpkg (--configure):
 dependency problems - leaving unconfigured

I guess that's because the bullseye-slim image lacks the manpages.

BTW, why is node-babel7 a run-time dependency of yarnpkg ?
Should it not just be a build-dep ?

Paolo

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages node-babel7 depends on:
ii  node-browserslist   4.16.0+~cs5.4.69-1
ii  node-chalk  4.1.0-1
ii  node-commander  6.2.1-2
ii  node-convert-source-map 1.7.0+~1.5.1-1
ii  node-core-js3.8.1-1
ii  node-debug  4.3.1+~cs4.1.5-1
ii  node-esutils2.0.3-1
ii  node-find-cache-dir 3.3.1-1
ii  node-fs-readdir-recursive   1.1.0-1
ii  node-glob   7.1.6+~7.1.3-1
ii  node-globals13.5.0-1
ii  node-js-tokens  6.0.0-1
ii  node-jsesc  3.0.2-1
ii  node-json5  2.1.3-2
ii  node-lodash 4.17.20+dfsg+~cs8.31.170-1
ii  node-make-dir   3.0.2-1
ii  node-quick-lru  1.1.0-2
ii  node-regenerator-runtime0.13.7-1
ii  node-regenerator-transform  0.14.5-4
ii  node-regexpu-core   4.7.1-1
ii  node-resolve1.19.0+~cs5.20.8-2
ii  node-semver 7.3.4-1
ii  node-slash  3.0.0-1
ii  node-source-map 0.7.0++dfsg2+really.0.6.1-4
ii  node-source-map-support 0.5.19+ds+~0.5.3-1
ii  node-to-fast-properties 3.0.1-1
ii  node-v8flags3.2.0-1
ii  nodejs  12.19.0~dfsg-1

node-babel7 recommends no packages.

node-babel7 suggests no packages.

-- no debconf information

Bug#979548: u-boot: Package Xen build

[Vagrant Cascadian]

Control: tags 979548 moreinfo

On 2021-01-07, Elliott Mitchell wrote:
> Might it be possible to get a u-boot-xen-arm64 package built?  While
> "PyGRUB" is great for Linux, it isn't so good for booting other OSes.

Do you mean:

  
https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/board/xen/xenguest_arm64.rst

This doesn't describe how to use it or, importantly, what files we would
need to ship in the package. If you could help clarify that (possibly
provide a patch), and ideally get it clarified in the upstream
documentation, then I would think we would be able to ship such a
package.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#979550: ITP: deepin-artwork -- Deepin Artwork

[Hu Feng]

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


* Package name    : deepin-artwork
  Version : 2018.10.9
  Upstream Author : deepinzhangshuang 
* URL : https://github.com/linuxdeepin/deepin-artwork
  License : LGPL-3+
  Programming Lang: Makefile
  Description : Meta package to install all deepin artwork

This metapackage merely depends on the deepin-icon-theme and 
deepin-gtk-theme

packages available in Deepin. Use this if you want fonts for every theme
.
The following metapackages will be pulled down as dependency which
will inturn pull down real font packages.
   *  deepin-icon-theme
   *  deepin-gtk-theme
.
I intend to co-maintain this package inside pkg-deepin group.

Bug#977934: pydantic: please upgrade to the latest upstream release

[Sandro Tosi]

rdeps rebuild result

2021/01/08 02:07:50 Building package 1 of 5: gammapy
2021/01/08 02:09:57 Building package 2 of 5: hypothesis-auto
2021/01/08 02:10:35 Building package 3 of 5: qcelemental
2021/01/08 02:11:22 Building package 4 of 5: qcengine
2021/01/08 02:12:11 Building package 5 of 5: psi4
2021/01/08 02:29:43 Build results:
2021/01/08 02:29:43 PASSED: psi4
2021/01/08 02:29:43 PASSED: gammapy
2021/01/08 02:29:43 PASSED: hypothesis-auto
2021/01/08 02:29:43 PASSED: qcelemental
2021/01/08 02:29:43 PASSED: qcengine

Bug#976358: [bts] failed to open SMTP connection to reportbug.debian.org

[Shengjing Zhu]

Package: devscripts
Version: 2.20.5
Followup-For: Bug #976358
X-Debbugs-Cc: z...@debian.org, pi...@debian.org

> bts: failed to open SMTP connection to reportbug.debian.org
> (SSL connect attempt failed error:1416F086:SSL 
> routines:tls_process_server_certificate:certificate verify failed)

Same problem here, a quick dirty hack is:

@@ -2718,6 +2718,7 @@
 if (have_smtps) {
 $smtp = Net::SMTPS->new(
 $host,
+SSL_verify_mode => 0,
 Port  => $port,
 Hello => $smtphelo,
 doSSL => 'starttls'

Bug#979411: resize2fs: no percentage completion bars displayed with -p

[Andrei POPESCU]

[forgot to Cc: the bug, sorry for the duplicate]

On Jo, 07 ian 21, 11:33:42, Theodore Ts'o wrote:
> On Wed, Jan 06, 2021 at 02:31:46PM +0200, Andrei POPESCU wrote:
> > Package: e2fsprogs
> > Version: 1.44.5-1+deb10u3
> > Severity: normal
> > Tags: upstream
> > 
> > According to the man page the -p option should print out "percentage 
> > completion bars", though this was not done on a recent operation 
> > (offline shrink).
> 
> If the resize operation doesn't require anything complex --- for
> example, merely adjusting the number of blocks in the superblock,
> without needing to relocate any blocks or inodes, we end up not doing
> anything time-consuming enough to trigger a progress bar.
 
Whether the operation is time-consuming probably depends a lot on the 
underlying hardware. I was resizing a 2TB partition connected via USB2 
to a PINE A64+ device, i.e. max theoretical throughput 480 Mbit/s, 
shared with another drive ;)

> I suppose we could add a pointless progress bar which shows up for a
> few milliseconds, but it would be a "even if you don't blink, you
> still might miss it".  For example:

Ok, it that is probably less useful :)

> Probably the best thing to do is to change the man page to say that
> progress bars will be displayed for non-trivial resize operations, or
> some such.

Would it be possible for resize2fs to print some advance information on 
whether relocating data will be needed and how much of it (e.g. "will 
need to relocate X nr of data blocks and Y inodes") and be slightly more 
verbose about the specific operation it is doing (e.g. "adjusting the 
number of blocks in the superblock", etc.)?

Thank you for reading and considering.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#777291: gpm should provides systemd services

[Axel Beckert]

Control: tag -1 - pending patch

Hi Moritz,

Moritz Mühlenhoff wrote:
> > Thanks! Committed to git and pushed.
> > 
> > Will probably do an upload tomorrow. To tired now and still some other
> > things to fix.
> 
> Mmhh, actually, please hold back an upload.

Didn't upload anyway. Upon closer inspection I remembered why I was
(and again still are) reluctant to providing a (trivial) .service
file:

At least the trivial case with a static commandline as in your patch
doesn't resepct /etc/gpm.conf.

Actually your patch even hardcodes a protocol (and other settings),
which is my main reason for not having provided a .service file. Then
again it hardcodes the nowadays most common mouse protocol and device
path.

Reverted that commit for now with a commit message refering to mt
concerns and pointing to your mail.

> I just ran into an issue where it failed to start, I need to poke at
> this some more and see if I can reproduce thisa. I'll update the bug
> with more information.

Thanks for that effort anyways!

Will dig into how I can make a .service file respect /etc/gpm.conf
settings.

Currently thinking about using "ExecStartPre=" to call a script that
generates a file for use with "EnvironmentFile=" — if the execution
order of those two allows it. Haven't found a hint on the order in the
man pages so I'll probably just try out. Would probably use
/run/gpm/gpm.env or so for that file.

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

Bug#979549: ingerman: Problems during ispell-autobuild

[Thorsten G.]

Package: ingerman
Version: 20161207-8
Severity: normal

Dear Maintainer,

during dist-upgrade I've got the following messeges

ispell-autobuildhash: Processing 'ngerman' dict.
/usr/lib/ispell/ngerman.aff line 157: No such string character
/usr/lib/ispell/ngerman.aff line 214: No such string character
/usr/lib/ispell/ngerman.aff line 214: No such string character
/usr/lib/ispell/ngerman.aff line 217: No such string character
/usr/lib/ispell/ngerman.aff line 218: No such string character
/usr/lib/ispell/ngerman.aff line 219: No such string character
/usr/lib/ispell/ngerman.aff line 220: No such string character
/usr/lib/ispell/ngerman.aff line 224: No such string character
/usr/lib/ispell/ngerman.aff line 240: No such string character
/usr/lib/ispell/ngerman.aff line 255: No such string character
/usr/lib/ispell/ngerman.aff line 256: No such string character
/usr/lib/ispell/ngerman.aff line 271: No such string character
/usr/lib/ispell/ngerman.aff line 272: No such string character
/usr/lib/ispell/ngerman.aff line 462: Single characters must be separated by a b
lank
/usr/lib/ispell/ngerman.aff line 463: Single characters must be separated by a b
lank
/usr/lib/ispell/ngerman.aff line 464: Single characters must be separated by a b
lank
/usr/lib/ispell/ngerman.aff line 465: Single characters must be separated by a b
lank
/usr/lib/ispell/ngerman.aff line 466: Single characters must be separated by a b
lank
/usr/lib/ispell/ngerman.aff line 467: Single characters must be separated by a b
lank
/usr/lib/ispell/ngerman.aff line 695: Single characters must be separated by a b
lank
/usr/lib/ispell/ngerman.aff line 696: Single characters must be separated by a b
lank
/usr/lib/ispell/ngerman.aff line 697: Single characters must be separated by a b
lank
/usr/lib/ispell/ngerman.aff line 698: Single characters must be separated by a b
lank
/usr/lib/ispell/ngerman.aff line 949: Single characters must be separated by a b
lank

Word 'Attach�' contains illegal characters

Word 'Boucl�' contains illegal characters

Word 'Bourr�e' contains illegal characters

Word 'B�chamel' contains illegal characters

Word 'Caf�' contains illegal characters

Word 'Chicor�e' contains illegal characters

Word 'Ch�teau' contains illegal characters

Word 'Cr�pe' contains illegal characters

Word 'Dekollet�' contains illegal characters

Word 'Drag�e' contains illegal characters

Word 'Expos�' contains illegal characters

Word 'Familiencaf�' contains illegal characters

Word 'Glac�handschuh' contains illegal characters

Word 'Kommuniqu�' contains illegal characters

Word 'Lam�' contains illegal characters

Word 'Linn�' contains illegal characters

Word 'Marineattach�' contains illegal characters

Word 'Milita"rattach�' contains illegal characters

Word 'Moir�' contains illegal characters

Word 'Napol�on' contains illegal characters

Word 'Neglig�' contains illegal characters

Word 'Nestl�' contains illegal characters

Word 'Pappmach�' contains illegal characters

Word 'pass�' contains illegal characters

Word 'Romm�' contains illegal characters

Word 'Souffl�' contains illegal characters

Word 'S�par�e' contains illegal characters

Word 'Variet�' contains illegal characters


Seems to be a problem with accent signs. I don't know if this is a problem
by ingerman or ispell itself


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'testing'), (600, 'stable'), (500, 
'oldoldstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.5-towo.1-siduction-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ingerman depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  dictionaries-common1.28.3
ii  ispell 3.4.01-1

ingerman recommends no packages.

Versions of packages ingerman suggests:
ii  wngerman  20161207-8

-- debconf information:
  shared/packages-ispell:
  ingerman/languages: deutsch (New German -tex mode-), deutsch (New German 8 
bit)

Bug#979500: dh-apparmor: please support local includes of abstractions like "abstraction/name"

[intrigeri]

Control: tag -1 + moreinfo

Hi,

Christian Boltz (2021-01-07):
> I'd argue that this is a problem that is already solved ;-)
>
> Starting with AppArmor 3.0, all[1] upstream abstractions come with a 
> rule like (example taken from abstractions/base):
>
> include if exists 
>
> so if you create that directory and place a file there, it will be 
> included by the abstraction.

> [...]

> For abstractions shipped by individual package (like libvirt), it would 
> also make sense to add an   include if exists
> rule to make it easy to add something to an abstraction.

I like what Christian Boltz is proposing (thanks!): as far as
I understand, it can happen in libvirt upstream, will benefit even
non-Debian distros, and does not require modifying dh-apparmor.

Christian Ehrhardt, how does it sound? Any reason why the approach you
initially suggested on this bug report is better?

Cheers!

Bug#976113: Closing Hydrogen RFS

[Ross Gammon]

Hi Nicholas,

On 07.01.2021 23.44, Nicholas D Steeves wrote:

Have you created the release tag on your local master branch, or shall
I, and would you like to push the tag when the package is accepted, or
would you like me to remember to do so?


I normally wait until it is accepted by the ftp-masters. Feel free to 
ping me on private mail.

Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye

[Christian Ehrhardt]

On Thu, Jan 7, 2021 at 5:04 PM Stokes, Ian  wrote:
>
> > On Thu, Nov 19, 2020 at 5:12 PM Stokes, Ian  wrote:
> > >
> > > > > I proposed an earlier upload from git as a temporary measure to ease
> > > > > the ABI transition. I worry that an ABI transition 2 months after the
> > > > > transition freeze is too much to ask, even if it only affects
> > > > > src:openvswitch (and src:collectd, but that's a straightforward
> > > > > rebuild, no changes needed).
> > > > > Nonetheless, let's see if the release team considers this acceptable.
> > > >
> > > > Two things worth mentioning:
> > > > 1. We will have support for DPDK 20.11 in OVS by next week by Ian Stokes
> > > > This was already validated vs 20.11-rc4
> > >
> > > Hi Christian,
> > >
> > > Just to clarify this, I think we will have  an RFC patch to support DPDK 
> > > 20.11
> > with OVS master by either tomorrow or early next week. We are just waiting
> > on review of the patch below
> > >
> > >
> > http://patchwork.ozlabs.org/project/openvswitch/patch/20201119123554.44
> > 684-1-sunil.pa...@intel.com/
> > >
> > > But just to clarify, once I release the RFC patch that does not mean it 
> > > will be
> > up streamed immediately to OVS master, just that it will be available for
> > review by the community at that stage.
> > >
> > > Support for DPDK 20.11 in OVS master will not be available until the
> > community has signed off on the patch itself (which may require patch
> > revisions), this may take longer than next week.
> >
> > Hi,
> > as an FYI Ubuntu moved to recent commit def6eb1ea and for us it seems
> > to work fine so far.
> > See the package at:
> > https://launchpad.net/ubuntu/+source/openvswitch/2.15.0~git20210104.de
> > f6eb1ea-0ubuntu3
> >
> > With that confirmed and the feature freeze coming soon. Would you mind
> > doing a similar upload to Debian-experimental soon'ish?
> >
>
> Hi Christian, not sure if that was targeted to myself?

Hi Ian o/,
it was mostly for the discussion about when/how to carve out a first
OVS 2.15 to be in time for the Debian Feature Freeze.
Ubuntu is in the same situation every spring (overlapping release
dates) - so I shared before that this worked well
for us in the past - and also this time seems to work well.

> As an FYI OVS master now supports DPDK 20.11 as of the following commit.
>
> 252e1e576443 ("dpdk: Update to use DPDK v20.11.")

Yeah I know, we've taken a slightly later commit (in case there would
have been follow up fixes) and things seem fine for now.
We will (as usual) before the final release then update to the latest
and then final 2.15.

> Regards
> Ian
>
> > > Regards
> > > Ian
> > >
> > >
> >
> >
> > --
> > Christian Ehrhardt
> > Staff Engineer, Ubuntu Server
> > Canonical Ltd



-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#892275: Working redshift setup

[James Tocknell]

I have redshift working on both my desktop and laptop, here's how I
have things set up:
* If you don't have "normal" desktop environment like GNOME, then you
need to start the geoclue agent manually (note that the path to it
recently changed, which may be way people have having problems again
recently). Make sure you're running the latest geoclue, as there was
an issue for systems without wifi.
* Ensure redshift and the agent are allowed to access geoclue in
/etc/geoclue/geoclue.conf (again, this is for people who aren't
running GNOME, which includes me).
* I have disabled the user service, mostly because I start things
manually. That may help if people find that redshift keeps restarting
(check your user journal also).
* I don't have a xdg-autostart service running, so I'm not affected by
redshift adding itself there automatically. Not sure if others are
being affected by this though.

I don't think this is grave, important at best, for redshift (I'd say
this is due to geoclue changes, so the bug should be assigned there).
It might be worth seeing though if some kind of autopackagetest could
be added so regressions due to geoclue changes get flagged though.

James

-- 
Don't send me files in proprietary formats (.doc(x), .xls, .ppt etc.).
It isn't good enough for Tim Berners-Lee, and it isn't good enough for
me either. For more information visit
http://www.gnu.org/philosophy/no-word-attachments.html.

Truly great madness cannot be achieved without significant intelligence.
 - Henrik Tikkanen

If you're not messing with your sanity, you're not having fun.
 - James Tocknell

In theory, there is no difference between theory and practice; In
practice, there is.

Bug#979518: [Debian-zh-dev] RFS: unicon/3.0.4+dfsg1-2 [ITA] -- Chinese Input Method Library

[肖盛文]

Hi,

    Thanks for your reviews.

在 2021/1/8 上午12:05, Boyuan Yang 写道:

Control: tags -1 +moreinfo

Hi,
* It looks like there is hardcoded x86_64-linux-gnu arch triplet in
debian/rules file. This is unacceptable and will cause FTBFS on
architectures other than amd64.

Fixed in debian/rules.

* Please explain why there are new iconv calls in debian/rules file.


Those files use old gb2312 or ISO8859 character encoding, so use iconv 
calls to transfer to UTF-8.


If not to do so, the lintian will report "national-encoding" warning.


I'd uploaded the new unicon package to mentors.d.n


Thanks!

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



OpenPGP_0x00186602339240CB.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#976696: smartmontools: install drivedb.h to /usr and copy into /var in postinst when missing/outdated

[Paul Wise]

On Fri, 2021-01-08 at 01:24 +1100, Dmitry Smirnov wrote:

> As you wish. I've left a TODO note in postinst regarding version
> check and upstream needs to know about $Id value. I guess both bugs
> could be of some use but mostly one about $Id value, especially if
> filed upstream.

I ended up combining them both into one upstream bug:

https://www.smartmontools.org/ticket/1424

As you can see what I wrote there, it is probably best to solve most of
this issue upstream and then re-use that for the Debian postinst.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#979547: smartmontools: Homepage redirects to www.smartmontools.org

[Paul Wise]

Package: smartmontools
Version: 7.2-1
Severity: minor

I noticed that the smartmontools SourceForge page redirects to a
different site and so I suggest updating the Homepage field in the
Debian package to the new site:

https://www.smartmontools.org/

   $ wget -O /dev/null $(apt-cache show smartmontools | sed -n 's/Homepage: 
//p' | sort -u)
   --2021-01-08 12:53:12--  http://smartmontools.sourceforge.net/
   Resolving smartmontools.sourceforge.net (smartmontools.sourceforge.net)... 
216.105.38.10
   Connecting to smartmontools.sourceforge.net 
(smartmontools.sourceforge.net)|216.105.38.10|:80... connected.
   HTTP request sent, awaiting response... 302 Found
   Location: http://www.smartmontools.org/ [following]
   URL transformed to HTTPS due to an HSTS policy
   --2021-01-08 12:53:13--  https://www.smartmontools.org/
   Resolving www.smartmontools.org (www.smartmontools.org)... 185.82.212.181, 
2a03:6920:0:10::101
   Connecting to www.smartmontools.org 
(www.smartmontools.org)|185.82.212.181|:443... connected.
   HTTP request sent, awaiting response... 200 Ok
   Length: 21952 (21K) [text/html]
   Saving to: ‘/dev/null’
   
   /dev/null   100%[=>] 
 21.44K  57.9KB/sin 0.4s
   
   2021-01-08 12:53:15 (57.9 KB/s) - ‘/dev/null’ saved [21952/21952]

-- 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.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 smartmontools depends on:
ii  debianutils  4.11.2
ii  libc62.31-9
ii  libcap-ng0   0.7.9-2.2+b1
ii  libgcc-s110.2.1-3
ii  libselinux1  3.1-2+b2
ii  libstdc++6   10.2.1-3
ii  libsystemd0  247.2-4
ii  lsb-base 11.1.0

smartmontools recommends no packages.

Versions of packages smartmontools suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-2
ii  curl   7.74.0-1
ii  gpg2.2.20-1
pn  gsmartcontrol  
ii  lynx   2.9.0dev.6-1
ii  smart-notifier 0.28-6
ii  wget   1.20.3-1+b3

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#979546: docker.io: version in Bullseye does not support "rootless mode", makes privilege escalation trivial

[El boulangero]

Hi Chris,

I believe what you refer to is a well-known issue with docker. I have this
reference from Apr. 2015:
https://fosterelli.co/privilege-escalation-via-docker.html

This is how docker works. The most easy mitigation is NOT to add a user to
the docker group. This way, you will always invoke docker with 'sudo
docker', and then it's explicit that you're running something as root.
Explicit better than implicit maybe, at least no more "accidental".

Second thing, as you noted, docker can access a directory on the host only
if you share it with '--volume' or '--mount' or something. So it's not
really accidental if then the process in the container writes to the host
directory. It's something that you authorized explicitly. And the fact that
it's a root access is due to the fact that the container is run as root, as
you correctly noted.

If you download and run a containerized app as root, and share your /home
with the container, then you'd better trust this app 100%.

> a search for "docker" on backports.debian.org returned no results

Indeed, docker sits on top of 100+ dependencies, backporting would mean
backporting all those dependencies. Plus maybe the go compiler and the go
library. It would be such a huge work that it's not realistic.

Since Go is a statically compiled language, there's little value in
backporting anyway. You can just try your luck and install the docker from
Debian unstable into your Debian stable. It might work. Maybe some bugs
would be lurking here and there in the dark, maybe not, I just don't know.

As for rootless mode, it should be indeed supported in the 20.10 version. I
myself never tested it. If I'm not mistaken, everything is present in the
20.10 package provided in Debian unstable to run the rootless mode. You can
give it a try :)

All the best,

  Arnaud






On Fri, Jan 8, 2021 at 10:48 AM Chris  wrote:

> Package: docker.io
> Version: 18.09.1+dfsg1-7.1+deb10u2
> Severity: critical
> Tags: security
> Justification: root security hole
>
> Dear Maintainer,
>
> Unless I'm missing something, any program running in a Docker container
> using the Docker version currently available in Debian stable has a
> trivial-to-exploit path to full, persistent, root privilege escalation.
>
> Docker v18 only works when it's SUID root. Processes running as root
> *inside* the container accessing the *host* filesystem do so as root *on
> the host system* unless they are internally configured to map to a
> regular user on the host system. (According to my rough and inexpert
> understanding of the situation.)
>
> I installed docker.io from the official Debian stable repos, added a
> user to group "docker" in order to be able to use it, downloaded and
> ran a containerized program, and noticed that the program in the
> container was creating files and directories with root ownership in my
> home directory on the host system.
>
> A quick search of the web turned up a tutorial showing how easy it is
> to exploit this situation:
> https://medium.com/@Affix/privilege-escallation-with-docker-56dc682a6e17
> ...as well as tutorials on how not to *accidentally* create root-owned
> files on the host system when setting up Docker containers, eg:
> https://vsupalov.com/docker-shared-permissions/
>
> I discovered that newer versions of Docker have a "rootless mode" that
> doesn't require the main Docker executable to run SUID root (though it
> does rely on a couple of narrow-scope SUID helper utilities), which
> should hopefully mitigate this situation to a considerable extent:
> https://docs.docker.com/engine/security/rootless
> This capability was introduced as experimental in v19.03 and "graduated
> from experimental" in v20.10. Unsurprisingly, it requires that
> unprivileged_userns_clone be enabled.
>
> The version of docker.io in the Buster repos is 18.09 at the time of
> this writing, and a search for "docker" on backports.debian.org returned
> no results. While I am aware of the controversy around
> unprivileged_userns_clone, I gather that it will be enabled by default
> in Bullseye (starting with kernel 5.10, I believe) because at this point
> it presents the lesser evil.
>
> Unless I'm gravely mistaken about the situation, I'd much rather enable
> that potentially-exploitable kernel feature and run Docker in "rootless
> mode" than continue running Docker in a configuration that's so easily
> exploitable there are tutorials on how to prevent accidentally creating
> files as root when using Docker containers as a regular user.
>
> Accidental. Root. Filesystem access. As a regular user.
>
> I propose that — as a minimum — backporting the version of Docker in
> Bullseye (currently v20.10) to Buster be treated as an urgent security
> priority, so that users at least have the option to install Docker from
> an official Debian source and use it in the less-dangerous "rootless
> mode".
>
> Further, Docker is widespread and gaining popularity fast, it's already
> in the Debian stable repositories, and 

Bug#979546: docker.io: version in Bullseye does not support "rootless mode", makes privilege escalation trivial

[Shengjing Zhu]

Control: retitle -1 docker.io: version in Buster does not support
"rootless mode"
Control: fixed -1 20.10.0~rc1+dfsg2-1
Control: severity -1 wishlist

On Fri, Jan 8, 2021 at 11:55 AM Chris  wrote:
>
> Package: docker.io
> Version: 18.09.1+dfsg1-7.1+deb10u2
> Severity: critical
> Tags: security
> Justification: root security hole
>
> Dear Maintainer,
>
> Unless I'm missing something, any program running in a Docker container
> using the Docker version currently available in Debian stable has a
> trivial-to-exploit path to full, persistent, root privilege escalation.
>
> Docker v18 only works when it's SUID root. Processes running as root
> *inside* the container accessing the *host* filesystem do so as root *on
> the host system* unless they are internally configured to map to a
> regular user on the host system. (According to my rough and inexpert
> understanding of the situation.)
>
> I installed docker.io from the official Debian stable repos, added a
> user to group "docker" in order to be able to use it, downloaded and
> ran a containerized program, and noticed that the program in the
> container was creating files and directories with root ownership in my
> home directory on the host system.
>
> A quick search of the web turned up a tutorial showing how easy it is
> to exploit this situation:
> https://medium.com/@Affix/privilege-escallation-with-docker-56dc682a6e17
> ...as well as tutorials on how not to *accidentally* create root-owned
> files on the host system when setting up Docker containers, eg:
> https://vsupalov.com/docker-shared-permissions/
>
> I discovered that newer versions of Docker have a "rootless mode" that
> doesn't require the main Docker executable to run SUID root (though it
> does rely on a couple of narrow-scope SUID helper utilities), which
> should hopefully mitigate this situation to a considerable extent:
> https://docs.docker.com/engine/security/rootless
> This capability was introduced as experimental in v19.03 and "graduated
> from experimental" in v20.10. Unsurprisingly, it requires that
> unprivileged_userns_clone be enabled.
>
> The version of docker.io in the Buster repos is 18.09 at the time of
> this writing, and a search for "docker" on backports.debian.org returned
> no results. While I am aware of the controversy around
> unprivileged_userns_clone, I gather that it will be enabled by default
> in Bullseye (starting with kernel 5.10, I believe) because at this point
> it presents the lesser evil.
>
> Unless I'm gravely mistaken about the situation, I'd much rather enable
> that potentially-exploitable kernel feature and run Docker in "rootless
> mode" than continue running Docker in a configuration that's so easily
> exploitable there are tutorials on how to prevent accidentally creating
> files as root when using Docker containers as a regular user.
>
> Accidental. Root. Filesystem access. As a regular user.
>
> I propose that — as a minimum — backporting the version of Docker in
> Bullseye (currently v20.10) to Buster be treated as an urgent security
> priority, so that users at least have the option to install Docker from
> an official Debian source and use it in the less-dangerous "rootless
> mode".
>
> Further, Docker is widespread and gaining popularity fast, it's already
> in the Debian stable repositories, and the only way the version
> currently in stable can be used is *shockingly* dangerous. Given all
> that, I'm inclined to suggest that pushing Docker v20.10 to
> buster-security along with configuration that enables
> unpriv_userns_clone and sets Docker up to run in "rootless mode" should
> be seriously considered.
>
> Or my understanding of the situation could be profoundly wrong. I'm
> pushing the edge of my technical understanding here, and I would be
> thoroughly pleased to be wrong about this whole thing.
>

This is how docker designed. If you give someone the permission to use
docker daemon, then it means you give out the root permission.
Rootless is a new feature, so this bug is a feature request, not a security bug.
docker is written in Go, you can install the 20.10 version from
unstable even if you are on buster. But it's not recommended anyway.

-- 
Shengjing Zhu

Bug#768073: ITP: lxd - The Linux Container Daemon

[peylight]

Hi Dear Debian Developers,
Can you check the 331th message of LXD packaging please:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768073#311

--
Best Regards,
peylight

Bug#979546: docker.io: version in Bullseye does not support "rootless mode", makes privilege escalation trivial

[Chris]

Package: docker.io
Version: 18.09.1+dfsg1-7.1+deb10u2
Severity: critical
Tags: security
Justification: root security hole

Dear Maintainer,

Unless I'm missing something, any program running in a Docker container
using the Docker version currently available in Debian stable has a
trivial-to-exploit path to full, persistent, root privilege escalation.

Docker v18 only works when it's SUID root. Processes running as root
*inside* the container accessing the *host* filesystem do so as root *on
the host system* unless they are internally configured to map to a
regular user on the host system. (According to my rough and inexpert
understanding of the situation.)

I installed docker.io from the official Debian stable repos, added a 
user to group "docker" in order to be able to use it, downloaded and 
ran a containerized program, and noticed that the program in the 
container was creating files and directories with root ownership in my
home directory on the host system.

A quick search of the web turned up a tutorial showing how easy it is
to exploit this situation:
https://medium.com/@Affix/privilege-escallation-with-docker-56dc682a6e17
...as well as tutorials on how not to *accidentally* create root-owned
files on the host system when setting up Docker containers, eg:
https://vsupalov.com/docker-shared-permissions/

I discovered that newer versions of Docker have a "rootless mode" that
doesn't require the main Docker executable to run SUID root (though it
does rely on a couple of narrow-scope SUID helper utilities), which 
should hopefully mitigate this situation to a considerable extent:
https://docs.docker.com/engine/security/rootless
This capability was introduced as experimental in v19.03 and "graduated
from experimental" in v20.10. Unsurprisingly, it requires that
unprivileged_userns_clone be enabled.

The version of docker.io in the Buster repos is 18.09 at the time of
this writing, and a search for "docker" on backports.debian.org returned
no results. While I am aware of the controversy around 
unprivileged_userns_clone, I gather that it will be enabled by default
in Bullseye (starting with kernel 5.10, I believe) because at this point
it presents the lesser evil.

Unless I'm gravely mistaken about the situation, I'd much rather enable
that potentially-exploitable kernel feature and run Docker in "rootless
mode" than continue running Docker in a configuration that's so easily
exploitable there are tutorials on how to prevent accidentally creating
files as root when using Docker containers as a regular user.

Accidental. Root. Filesystem access. As a regular user.

I propose that — as a minimum — backporting the version of Docker in 
Bullseye (currently v20.10) to Buster be treated as an urgent security
priority, so that users at least have the option to install Docker from
an official Debian source and use it in the less-dangerous "rootless 
mode".

Further, Docker is widespread and gaining popularity fast, it's already
in the Debian stable repositories, and the only way the version 
currently in stable can be used is *shockingly* dangerous. Given all 
that, I'm inclined to suggest that pushing Docker v20.10 to
buster-security along with configuration that enables 
unpriv_userns_clone and sets Docker up to run in "rootless mode" should
be seriously considered.

Or my understanding of the situation could be profoundly wrong. I'm 
pushing the edge of my technical understanding here, and I would be
thoroughly pleased to be wrong about this whole thing.

Cheers!
 -Chris


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

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

Versions of packages docker.io depends on:
ii  adduser 3.118
ii  iptables1.8.2-4
ii  libc6   2.28-10
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libltdl72.4.6-9
ii  libnspr42:4.20-1
ii  libnss3 2:3.42.1-1+deb10u3
ii  libseccomp2 2.3.3-4
ii  libsystemd0 241-7~deb10u5
ii  lsb-base10.2019051400
ii  runc1.0.0~rc6+dfsg1-3
ii  tini0.18.0-1

Versions of packages docker.io recommends:
ii  ca-certificates  20200601~deb10u1
ii  cgroupfs-mount   1.4
ii  git  1:2.20.1-2+deb10u3
ii  needrestart  3.4-5
ii  xz-utils 5.2.4-1

Versions of packages docker.io suggests:
pn  aufs-tools   
pn  btrfs-progs  
pn  debootstrap  
pn  docker-doc   
ii  e2fsprogs1.44.5-1+deb10u3
pn  rinse
pn  xfsprogs 
pn  zfs-fuse | zfsutils  

-- no debconf information

Bug#956958: simple-cdd on Bullseye gives reprepro error

[Ambrose Andrews]

That issue does seem fixed in git.  Ideally it'd be good to have this fix in 
time to test simple-cdd with debian-installer bullseye release candidates.  
(Although using the files from git is an available option as you say, but less 
convenient in automated flows)

  -AA.

On 8 January 2021 12:14:06 pm AEDT, Vagrant Cascadian  
wrote:
>Control: severity 956958 serious
>
>On 2021-01-06, Jose Marinho wrote:
>> jose@bullseye:~$ cd simple-cdd/
>> jose@bullseye:~/simple-cdd$ build-simple-cdd
>> gpg: /home/jose/.gnupg/trustdb.gpg: creouse a base de datos de
>confianza
>> 2021-01-06 20:26:25 ERROR reprepro: updating package lists exited
>with code 255
>> 2021-01-06 20:26:25 ERROR Last 5 lines of standard error:
>> 2021-01-06 20:26:25 ERROR reprepro: updating package lists: aptmethod
>error receiving
>'http://security.debian.org/dists/bullseye/updates/Release.gpg':
>> 2021-01-06 20:26:25 ERROR reprepro: updating package lists: '404  Not
>Found [IP: 151.101.134.132 80]'
>> 2021-01-06 20:26:25 ERROR reprepro: updating package lists: aptmethod
>error receiving
>'http://security.debian.org/dists/bullseye/updates/Release.gpg':
>> 2021-01-06 20:26:25 ERROR reprepro: updating package lists: '404  Not
>Found [IP: 151.101.134.132 80]'
>> 2021-01-06 20:26:25 ERROR reprepro: updating package lists: There
>have been errors!
>> 2021-01-06 20:26:25 ERROR reprepro failed with exit code: 255
>
>Bumped the severity to make sure this gets dealt with one way or
>another
>before the bullseye release.
>
>I intend upload in the coming weeks. It should be fixed in git; you
>could try using git in the meantime.
>
>
>live well,
>  vagrant

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#957923: webalizer: ftbfs with GCC-10

[Logan Rosen]

Package: webalizer
Version: 2.23.08-3.1
Followup-For: Bug #957923
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/gcc-10.patch: Fix compilation with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru webalizer-2.23.08/debian/patches/gcc-10.patch 
webalizer-2.23.08/debian/patches/gcc-10.patch
--- webalizer-2.23.08/debian/patches/gcc-10.patch   1969-12-31 
19:00:00.0 -0500
+++ webalizer-2.23.08/debian/patches/gcc-10.patch   2021-01-07 
22:26:24.0 -0500
@@ -0,0 +1,18 @@
+--- a/dns_resolv.c
 b/dns_resolv.c
+@@ -78,11 +78,11 @@
+ 
+ struct   dns_child child[MAXCHILD];/* DNS child pipe data  */
+ 
+-DNODEPTR host_table[MAXHASH];  /* hostname/ip hash table   */
++extern DNODEPTR host_table[MAXHASH];   /* hostname/ip hash table   */
+ 
+-char buffer[BUFSIZE];  /* log file record buffer   */
+-char tmp_buf[BUFSIZE]; /* used to temp save above  */
+-struct   utsname system_info;  /* system info structure*/
++extern char buffer[BUFSIZE];   /* log file record buffer   */
++extern char tmp_buf[BUFSIZE];  /* used to temp save above  */
++extern struct   utsname system_info;   /* system info structure*/
+ 
+ int  raiseSigChild = 1;
+ 
diff -Nru webalizer-2.23.08/debian/patches/series 
webalizer-2.23.08/debian/patches/series
--- webalizer-2.23.08/debian/patches/series 2018-10-15 11:03:02.0 
-0400
+++ webalizer-2.23.08/debian/patches/series 2021-01-07 22:24:40.0 
-0500
@@ -15,3 +15,4 @@
 24_gettext_generated.diff
 25_add_convertlang2po.diff
 26_gettext_po_files.diff
+gcc-10.patch

Bug#974779: [Pkg-julia-devel] Bug#974779: severity - Julia: Please upgrade to llvm-toolchain-11

[Norbert Preining]

Hi Sebastian,

coming back to the llvm-9 vs -10 vs -11 issue.

So, julia fails to build on ppc64el with llvm-9 because llvm-9 has bugs
there, and we cannot use llvm-11 since this is not supported in the
current version of julia.

There are thus the following options:
- keep llvm-10
- drop julia on ppc64el
- fix llvm-9

The necessary fixes for llvm-9 are described here:
https://github.com/JuliaLang/julia/pull/35477
in particular in the two patches that are included in the PR

* deps/patches/llvm9-D71443-PPC-MC-redef-symbol.patch **
>From 5cd52dbfa9c60cfd12676924bed97701ee9bc4ef Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Thu, 12 Dec 2019 16:18:57 -0800
Subject: [PATCH] [MC][PowerPC] Fix a crash when redefining a symbol after .set

Fix PR44284. This is probably not valid assembly but we should not crash.

Reviewed By: luporl, #powerpc, steven.zhang

Differential Revision: https://reviews.llvm.org/D71443

(cherry picked from commit f99eedeb72644671cd584f48e4c136d47f6b0020)
---
 llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp | 3 ++-
 llvm/test/MC/PowerPC/ppc64-localentry-symbols.s  | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp 
llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp
index 90c3c8d20ed..71f926c265e 100644
--- llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp
+++ llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp
@@ -196,7 +196,8 @@ public:

   void finish() override {
 for (auto *Sym : UpdateOther)
-  copyLocalEntry(Sym, Sym->getVariableValue());
+  if (Sym->isVariable())
+copyLocalEntry(Sym, Sym->getVariableValue());
   }

 private:
diff --git llvm/test/MC/PowerPC/ppc64-localentry-symbols.s 
llvm/test/MC/PowerPC/ppc64-localentry-symbols.s
index f1d5c5d0ab1..a663af57ad4 100644
--- llvm/test/MC/PowerPC/ppc64-localentry-symbols.s
+++ llvm/test/MC/PowerPC/ppc64-localentry-symbols.s
@@ -32,3 +32,8 @@ func:
   nop
   nop
   .localentry func, 8
+
+## PR44284 Don't crash if err is redefined after .set
+.set err, _err
+.globl err
+err:
--
2.26.0
**




*** deps/patches/llvm-9.0-D78196.patch 
diff --git a/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp 
b/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp
--- a/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp
+++ b/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp
@@ -210,6 +210,10 @@
 for (auto *Sym : UpdateOther)
   if (Sym->isVariable())
 copyLocalEntry(Sym, Sym->getVariableValue());
+
+// Clear the set of symbols that needs to be updated so the streamer can
+// be reused without issues.
+UpdateOther.clear();
   }

 private:



I cannot guarantee that Julia will build with these fixes applied to the
LLVM-9 sources, but at least that is what I read out of the above PR.

In particular looking at the list of other patches applied to LLVM-9:
ifeq ($(LLVM_VER_SHORT),9.0)
$(eval $(call LLVM_PATCH,llvm-D27629-AArch64-large_model_6.0.1))
$(eval $(call LLVM_PATCH,llvm8-D34078-vectorize-fdiv))
$(eval $(call LLVM_PATCH,llvm-6.0-NVPTX-addrspaces)) # NVPTX -- warning: this 
fails check-llvm-codegen-nvptx
$(eval $(call LLVM_PATCH,llvm-7.0-D44650)) # mingw32 build fix
$(eval $(call LLVM_PATCH,llvm9-D50010-VNCoercion-ni))
$(eval $(call LLVM_PATCH,llvm8-WASM-addrspaces)) # WebAssembly
$(eval $(call LLVM_PATCH,llvm-exegesis-mingw)) # mingw build
$(eval $(call LLVM_PATCH,llvm-test-plugin-mingw)) # mingw build
$(eval $(call LLVM_PATCH,llvm7-revert-D44485))
$(eval $(call LLVM_PATCH,llvm-8.0-D66657-codegen-degenerate)) # remove for 10.0
$(eval $(call LLVM_PATCH,llvm-8.0-D71495-vectorize-freduce)) # remove for 10.0
$(eval $(call LLVM_PATCH,llvm-D75072-SCEV-add-type))
$(eval $(call LLVM_PATCH,llvm-9.0-D65174-limit-merge-stores)) # remove for 10.0

)


I guess you prefer that we drop julia for ppc64el, which would of course
be the easiest way. But I still would like to hear your opinion,
especially since llvm-10-dev is still present as of now, in both testing
and unstable.

Best

Norbert

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

Bug#957954: wmwave: ftbfs with GCC-10

[Logan Rosen]

Package: wmwave
Version: 0.4-11
Followup-For: Bug #957954
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/gcc-10.patch: Fix compilation with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru wmwave-0.4/debian/patches/gcc-10.patch 
wmwave-0.4/debian/patches/gcc-10.patch
--- wmwave-0.4/debian/patches/gcc-10.patch  1969-12-31 19:00:00.0 
-0500
+++ wmwave-0.4/debian/patches/gcc-10.patch  2021-01-07 22:03:15.0 
-0500
@@ -0,0 +1,22 @@
+--- a/wmgeneral.h
 b/wmgeneral.h
+@@ -36,7 +36,7 @@
+  /* Global variable */
+ /***/
+ 
+-Display   *display;
++extern Display*display;
+ 
+   /***/
+  /* Function Prototypes */
+--- a/wmwave.c
 b/wmwave.c
+@@ -79,6 +79,8 @@
+ 
+ int mode = 0;// default: no card detected
+ 
++Display *display;
++
+ void usage(void);
+ void printversion(void);
+ void BlitString(char *name, int x, int y);
diff -Nru wmwave-0.4/debian/patches/series wmwave-0.4/debian/patches/series
--- wmwave-0.4/debian/patches/series2019-10-25 17:28:57.0 -0400
+++ wmwave-0.4/debian/patches/series2021-01-07 22:02:43.0 -0500
@@ -1,2 +1,3 @@
 Debian-delta.patch
 Move-libraries-to-the-end.patch
+gcc-10.patch

Bug#979180: ALSA now working

[ael]

I now have twinkle working again with ALSA.

A quick-and-dirty patch is to change "plughw:0,0" to  "default:" in
audio_device.cpp:-

$ diff -u audio_device.cpp audio_device.cpp_original
--- audio_device.cpp2021-01-07 22:35:15.862448988 +
+++ audio_device.cpp_original   2021-01-07 21:57:51.119873744 +
@@ -887,12 +887,9 @@
if ((err = snd_ctl_pcm_info(handle, pcminfo)) < 
0) continue;

t_audio_device dev;
-   /*dev.device = string("plughw:") + 
int2str(card) +
-*/
-   dev.device = string("default:");
-  /*   + int2str(card) +
+   //dev.device = string("plughw:") + 
int2str(card) +
+   dev.device = string("default:") + int2str(card) 
+
string(",") + int2str(device);
-   */
dev.name = string(card_name) + " (";
dev.name += snd_pcm_info_get_name(pcminfo);
dev.name += ")";

The previous audio device is also stored in ~/.twinkle/twinkle.sys, so
it is very likely that will need editing as well. No doubt that can
be done from the twinkle gui as well, but I have not explored that as
well.

Bug#957991: xneur: ftbfs with GCC-10

[Logan Rosen]

Package: xneur
Version: 0.20.0-2
Followup-For: Bug #957991
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/gcc-10.patch: Fix compilation with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru xneur-0.20.0/debian/patches/gcc-10.patch 
xneur-0.20.0/debian/patches/gcc-10.patch
--- xneur-0.20.0/debian/patches/gcc-10.patch1969-12-31 19:00:00.0 
-0500
+++ xneur-0.20.0/debian/patches/gcc-10.patch2021-01-07 21:50:23.0 
-0500
@@ -0,0 +1,40 @@
+--- a/lib/main/program.c
 b/lib/main/program.c
+@@ -315,7 +315,7 @@
+ 
+   p->buffer->save_and_clear(p->buffer, p->last_window);
+   p->correction_buffer->clear(p->correction_buffer);
+-  p->correction_action = ACTION_NONE;
++  p->correction_action = CORRECTION_NONE;
+ 
+   if (status == FOCUS_NONE)
+   return;
+@@ -426,7 +426,7 @@
+   p->correction_buffer = 
buffer_init(xconfig->handle, main_window->keymap);
+   p->correction_buffer->handle = xconfig->handle;
+   p->correction_buffer->keymap = 
main_window->keymap;
+-  p->correction_action = ACTION_NONE;
++  p->correction_action = CORRECTION_NONE;
+ 
+   //log_message (DEBUG, _("Now layouts count 
%d"), xconfig->handle->total_languages);
+   log_message(LOG, _("Keyboard layouts present in 
system:"));
+@@ -609,7 +609,7 @@
+   //{
+   
p->buffer->save_and_clear(p->buffer, p->focus->owner_window);
+   
p->correction_buffer->clear(p->correction_buffer);
+-  p->correction_action = 
ACTION_NONE;
++  p->correction_action = 
CORRECTION_NONE;
+   if 
((Window)p->focus->get_focused_window(p->focus) != 
(Window)p->focus->owner_window)
+   {
+   p->update(p);
+--- a/lib/lib/xneur.h
 b/lib/lib/xneur.h
+@@ -32,7 +32,7 @@
+ # include 
+ #endif
+ 
+-struct _window *main_window;
++extern struct _window *main_window;
+ 
+ struct _xneur_language
+ {
diff -Nru xneur-0.20.0/debian/patches/series xneur-0.20.0/debian/patches/series
--- xneur-0.20.0/debian/patches/series  2016-12-03 19:51:50.0 -0500
+++ xneur-0.20.0/debian/patches/series  2021-01-07 21:49:26.0 -0500
@@ -1 +1,2 @@
 01-fix-arg-parsing.patch
+gcc-10.patch

Bug#957326: gwc: ftbfs with GCC-10

[Logan Rosen]

Package: gwc
Version: 0.22.04-1
Followup-For: Bug #957326
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/gcc-10.patch: Fix compilation with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru gwc-0.22.04/debian/patches/gcc-10.patch 
gwc-0.22.04/debian/patches/gcc-10.patch
--- gwc-0.22.04/debian/patches/gcc-10.patch 1969-12-31 19:00:00.0 
-0500
+++ gwc-0.22.04/debian/patches/gcc-10.patch 2021-01-07 20:00:50.0 
-0500
@@ -0,0 +1,50 @@
+--- a/gwc.h
 b/gwc.h
+@@ -185,12 +185,12 @@
+ int ready ;
+ } DENOISE_DATA ;
+ 
+-gchar *tmpdir;
+-gchar *CLIPBOARD_FILE ;
++extern gchar *tmpdir;
++extern gchar *CLIPBOARD_FILE ;
+ 
+ void print_denoise(char *header, struct denoise_prefs *pDnprefs) ;
+ 
+-GtkWidget *main_window;
++extern GtkWidget *main_window;
+ 
+ GtkWidget *add_number_entry_with_label(char *entry_text, char *label_text, 
GtkWidget *table, int row) ;
+ GtkWidget *add_number_entry_with_label_int(int value, char *label_text, 
GtkWidget *table, int row) ;
+--- a/gwc.c
 b/gwc.c
+@@ -84,6 +84,7 @@
+ GtkWidget *hscrollbar;
+ GtkWidget *detect_only_widget;
+ GtkWidget *leave_click_marks_widget;
++GtkWidget *main_window;
+ 
+ GtkWidget *l_file_time;
+ GtkWidget *l_file_samples;
+@@ -147,6 +148,8 @@
+ gchar wave_filename[PATH_MAX+1];
+ gchar last_filename[PATH_MAX+1];
+ gchar *file_extension;
++gchar *tmpdir;
++gchar *CLIPBOARD_FILE;
+ 
+ long markers[MAX_MARKERS];
+ long n_markers = 0;
+--- a/markers.c
 b/markers.c
+@@ -39,8 +39,8 @@
+ 
+ /* The file selection widget and the string to store the chosen filename */
+ 
+-GtkWidget *file_selector;
+-gchar *selected_filename;
++extern GtkWidget *file_selector;
++extern gchar *selected_filename;
+ gchar save_cdrdao_toc_filename[PATH_MAX+1];
+ extern long num_song_markers, song_markers[] ;
+ extern gchar wave_filename[] ;
diff -Nru gwc-0.22.04/debian/patches/series gwc-0.22.04/debian/patches/series
--- gwc-0.22.04/debian/patches/series   2019-09-15 12:47:29.0 -0400
+++ gwc-0.22.04/debian/patches/series   2021-01-07 19:57:21.0 -0500
@@ -1 +1,2 @@
 02-no_extra_docs.patch
+gcc-10.patch

Bug#979524: debian-reference: build-depends on libopencc2-data, which no longer exists

[肖盛文]

Hi,

    libopencc2-data had change name to libopencc-data in bullseye sid.

As the opencc upstream had changed the version number, SONAME, etc.

Update debian-reference build-depends on libopencc-data should fix this bug.


Thanks for your bugreport!


在 2021/1/8 上午12:55, Ivo De Decker 写道:

package: src:debian-reference
version: 2.76
tags: bullseye sid ftbfs
severity: serious

Hi,

It seems debian-reference build-depends on libopencc2-data, which no longer
exists.

Cheers,

Ivo


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



OpenPGP_0x00186602339240CB.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#979323: src:gcc-11: please provide cross-compiler for or1k

[Vagrant Cascadian]

On 2021-01-05, Jonas Smedegaard wrote:
> recent releases of u-boot support integrating on 64bit ARM targets with
> a firmware for the System Control Processor (SCP) - a microprocessor
> similar to the Management Engine on amd64.  On Allwinner SoC the SCP is
> an AR100 processor and a free licensed firmware - Crust - exists which
> requires gcc targeting OpenRISC 1000 (or1k).

FWIW, I should also note that, while recent versions of u-boot
(~2020.01) work without this SCP firmware, it fails to build without
specifying the SCP firmware with the upstream defaults; long-term the
codepaths without it may bitrot... so I would definitely appreciate
getting this or1k cross-compilers enabled in Debian!

Thanks for considering.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#979545: the stretch-pu: package courier/0.76.3-5+deb9u1 still are broken

[PICCORO McKAY Lenz]

Package: courier-mlm
Version: 0.76.3-5+deb9u1
Severity: grave
Justification: renders package unusable

the upload of Andreas from #875696 that  backported the "fix" to
stretch, is still broken cos package still are unusable..

it never finishes to install cos lists directories missing from
configuration never are pre-made.. cos to make a list we need to set
up too many things at post install -.-. by example a debostrap always
will be broken even if shistemd are used by default and not only
sysvinit, check bug  #979161

so an urgent backport of the commit
https://salsa.debian.org/debian/courier/-/commit/be22539626fcefbcadcfa377454d0e42d6009ade
must be done

also the shistemd unit file must be installed disabled because of the
lists directories missing from configuration

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

Bug#979326: ITP: crust -- SCP firmware for sunxi SoCs

[Vagrant Cascadian]

On 2021-01-07, Jonas Smedegaard wrote:
> Quoting Arnaud Ferraris (2021-01-07 00:17:49)
>> Le 05/01/2021 à 12:35, Jonas Smedegaard a écrit :
>> > * Package name: crust
> [...]
>> > Personally I own an Olimex TERES-I DIY laptop
>> > and several Olimex arm64 boards,
>> > but would prefer to maintain this package as a team-effort
>> > with owners of other Allwinner boards involved as well.
>> 
>> As I own (and develop for) a PinePhone and PineTab, I'll gladly 
>> co-maintain this package with you.
>
> Great!

Also very interested; thanks for intiating the ITP process!

I have a pinebook (14), two pinebook 1080p, a few pine64+, and it would
be nice to add support for them.


> I propose that we use the Tinker team as platform for this - if fine 
> with you then please subscribe to the mailinglist and join the irc 
> channel as listed at https://wiki.debian.org/Teams/Tinker :-)

Would you be amenable to maintaining it in the Debian group, along with
u-boot and arm-trusted-firmware? The Tinker team sounds interesting,
though. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#956958: simple-cdd on Bullseye gives reprepro error

[Vagrant Cascadian]

Control: severity 956958 serious

On 2021-01-06, Jose Marinho wrote:
> jose@bullseye:~$ cd simple-cdd/
> jose@bullseye:~/simple-cdd$ build-simple-cdd
> gpg: /home/jose/.gnupg/trustdb.gpg: creouse a base de datos de confianza
> 2021-01-06 20:26:25 ERROR reprepro: updating package lists exited with code 
> 255
> 2021-01-06 20:26:25 ERROR Last 5 lines of standard error:
> 2021-01-06 20:26:25 ERROR reprepro: updating package lists: aptmethod error 
> receiving 'http://security.debian.org/dists/bullseye/updates/Release.gpg':
> 2021-01-06 20:26:25 ERROR reprepro: updating package lists: '404  Not Found 
> [IP: 151.101.134.132 80]'
> 2021-01-06 20:26:25 ERROR reprepro: updating package lists: aptmethod error 
> receiving 'http://security.debian.org/dists/bullseye/updates/Release.gpg':
> 2021-01-06 20:26:25 ERROR reprepro: updating package lists: '404  Not Found 
> [IP: 151.101.134.132 80]'
> 2021-01-06 20:26:25 ERROR reprepro: updating package lists: There have been 
> errors!
> 2021-01-06 20:26:25 ERROR reprepro failed with exit code: 255

Bumped the severity to make sure this gets dealt with one way or another
before the bullseye release.

I intend upload in the coming weeks. It should be fixed in git; you
could try using git in the meantime.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#943676: Re: Sponsor request for 'Open Surge'

[Carlos Donizete Froes]

Hi Bruno,

> I need to correct myself and unfortunately lower expectations: opensurge will
> be a package newly introduced to Debian, so it has to successfully go through
> the NEW queue [1] procedure which takes additional time. I.e., chances are low
> Open Surge may make it into bullseye, we need to see how slow or fast things
> will work out. My bad, I'm not used to upload to the NEW queue.

Okay, at least we tried if it weren't for these license questions. :(

But I am waiting for the upstream to launch OpenSurge. In case it takes too
long, we leave it to Debian 12, unfortunately.

> @Carlos: I further cleaned up packaging and documented lintian infos/warnings
> + according overrides. To save disk space in the archive, I split opensurge
> into a small architecture dependent package opensurge and an architecture
> independent package opensurge-data. This should make ftpmasters' lives easier
> for a smooth NEW queue transition. Please check the changes for any mistakes.

Thanks Bruno, it will help me a lot. As soon as the upstream releases the new
version. I will make these changes to the package.

See you later!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780


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

Bug#979441: More information

[R. Lemos]

> [...]  After the rebuild for -2, I do NOT get a missing symbol error.
> However, scanning my database for faces does crash after some time (not
> immediately as in -1+b1), but with a null pointer error that doesn't seem to
> be related to opencv.  [...]
> [...]  So I'm
> not clear what is going on and would be interested to hear (a) if -2 still
> crashes for you; and (b) if so, what is the stack trace?

I've installed -2 (had to download the packages manually though, as
these updates are not yet available in my regional mirror).

No crash so far.

I've already had my whole library (ca. 4000 pix) scanned for face
detection. No crash (neither missing symbol, nor null pointer).
I've tagged some faces, then scanned for face recognition. No crash so far.

Thanks for your support,
Rodrigo Lemos.

Bug#979541: sylpheed: [regression] spell check no longer recognizes some correct Italian words

[Ricardo Mones]

control: tags -1 moreinfo

Hi Francesco,

On Thu, Jan 07, 2021 at 11:49:04PM +0100, Francesco Poli wrote:
> On Thu, 07 Jan 2021 23:33:09 +0100 Francesco Poli (wintermute) wrote:
> 
> [...]
> > For example, if I compose a message with the following text:
> > 
> >   """
> >   Questa è una prova che mi interessa poiché c'è qualcosa che non va.
> >   """
> > 
> > and select "it" spell language, I see the following red-underlined
> > words or expressions: "è", "poiché", "c'è".
> 
> I forgot to add that even "mi" is red-underlined, despite being pure
> ASCII.
> 
> [...]
> > Hence, I do not understand what exactly broke during the last days
> > of package upgrades.
> > Maybe the way Sylpheed communicates the text to aspell?
> 
> I tried to downgrade the following packages:
> 
>   libaspell15:amd64 from 0.60.8-2 to 0.60.8-1
>   aspell from 0.60.8-2 to 0.60.8-1
>   aspell-it from 2.4-20070901-0-3.1 to 2.4-20070901-0-3
> 
> but this didn't help.
> 
> I am more and more puzzled...

Current version was not a very fortunate upload, though in theory should
not have side effects like the ones you're describing here. Anyway, can
you try to downgrade sylpheed itself to 3.7.0-7 and check?

thanks in advance,
-- 
  Ricardo Mones 
  ~
  Physics is like sex: sure, it may give some practical results, but 
  that's not why we do it.Richard Feynman



signature.asc
Description: PGP signature

Bug#957161: echoping: ftbfs with GCC-10

[Logan Rosen]

Package: echoping
Version: 6.0.2-10
Followup-For: Bug #957161
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/gcc-10.patch: Fix FTBFS with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru echoping-6.0.2/debian/patches/gcc-10.patch 
echoping-6.0.2/debian/patches/gcc-10.patch
--- echoping-6.0.2/debian/patches/gcc-10.patch  1969-12-31 19:00:00.0 
-0500
+++ echoping-6.0.2/debian/patches/gcc-10.patch  2021-01-07 19:08:48.0 
-0500
@@ -0,0 +1,112 @@
+--- a/echoping.h
 b/echoping.h
+@@ -121,7 +121,7 @@
+   struct timeval timevalue;
+ };
+ 
+-boolean timeout_flag;
++extern boolean timeout_flag;
+ struct echoping_struct
+ {
+   boolean udp;/* Use the UDP protocol (TCP is the 
default) */
+@@ -136,21 +136,21 @@
+ /* Initializes the plugin with its arguments. Returns the port name or number 
or NULL if the plugin wants to use the raw interface. */
+ typedef char *(*init_f) (const int argc, const char **argv,
+const echoping_options global_options);
+-init_f plugin_init;
++extern init_f plugin_init;
+ typedef void (*start_f) (struct addrinfo *);
+-start_f plugin_start;
++extern start_f plugin_start;
+ typedef void (*start_raw_f) ();
+-start_raw_f plugin_raw_start;
++extern start_raw_f plugin_raw_start;
+ typedef int (*execute_f) ();
+-execute_f plugin_execute;
++extern execute_f plugin_execute;
+ typedef void (*terminate_f) ();
+-terminate_f plugin_terminate;
++extern terminate_f plugin_terminate;
+ #endif
+ 
+ #endif
+ 
+-struct timeval null_timeval;
+-struct timeval max_timeval;
++extern struct timeval null_timeval;
++extern struct timeval max_timeval;
+ 
+ #define   ECHO_TCP_PORT   "echo"
+ #define   DISCARD_TCP_PORT"discard"
+@@ -173,9 +173,9 @@
+ 
+ #define CHARGENERATED " 
!\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefg";
+ 
+-char *server;
++extern char *server;
+ #ifdef LIBIDN
+-char *locale_server, *ace_server, *utf8_server;
++extern char *locale_server, *ace_server, *utf8_server;
+ #endif
+ 
+ /* My functions */
+@@ -233,6 +233,8 @@
+ 
+ extern boolean timeout_flag;
+ 
++extern char big_recvline[MAXTOREAD];
++
+ #include "compilation.h"
+ 
+ #ifndef HEADER_INCLUDED
+--- a/echoping.c
 b/echoping.c
+@@ -38,6 +38,26 @@
+ struct timeval  good_results[MAX_ITERATIONS];
+ extern int  tvcmp();
+ 
++boolean timeout_flag;
++
++#ifndef IN_PLUGIN
++init_f  plugin_init;
++start_f plugin_start;
++start_raw_f plugin_raw_start;
++execute_f   plugin_execute;
++terminate_f plugin_terminate;
++#endif
++
++struct timeval  null_timeval;
++struct timeval  max_timeval;
++
++char*server;
++#ifdef LIBIDN
++char*locale_server, *ace_server, *utf8_server;
++#endif
++
++charbig_recvline[MAXTOREAD];
++
+ int
+ main(argc, argv)
+   int argc;
+--- a/http.c
 b/http.c
+@@ -6,8 +6,6 @@
+ #include "HTParse.h"
+ 
+ 
+-charbig_recvline[MAXTOREAD];
+-
+ char   *
+ make_http_sendline(char *url, char *host, int port, int nocache)
+ {
+--- a/smtp.c
 b/smtp.c
+@@ -8,8 +8,6 @@
+ 
+ #ifdef SMTP
+ 
+-charbig_recvline[MAXTOREAD];
+-
+ int
+ smtp_read_response_from_server(FILE * fs)
+ {
diff -Nru echoping-6.0.2/debian/patches/series 
echoping-6.0.2/debian/patches/series
--- echoping-6.0.2/debian/patches/series2018-10-14 16:24:57.0 
-0400
+++ echoping-6.0.2/debian/patches/series2021-01-07 19:08:48.0 
-0500
@@ -1,3 +1,4 @@
+gcc-10.patch
 006_reproducible-build.diff
 005_gnutls34.diff
 004-only-append-port-number-if-port-is-not-80.diff

Bug#890343: linux: make fq_codel default for default_qdisc

[Noah Meyerhans]

On Thu, Apr 23, 2020 at 03:34:06PM -0700, Matt Taggart wrote:
> #890343 was originally opened against systemd asking to install the upstream
> systemd sysctl.d/50-default.conf file that sets:
> 
> net.core.default_qdisc = fq_codel
> 
> As explained in #950701 (and the systemd debian changelog) the debian
> systemd maintainers felt that systemd in debian should not be changing
> kernel policies (and I agree).
> So #890343 was reassigned to linux to consider changing the default.
> 
> fq_codel is better in every way than pfifo_fast and I am unaware of any
> reason why it would not be a better default. (but don't trust me, ask the
> kernel networking experts)
> 
> Can we change it?

I strongly agree that we should make this change for the bullseye
release.

I'm looking into provding a patch to implement the switch to fq_codel by
default, but it appears to require something more than just a kernel
config change.  I have tried the following with the 5.10 kernel from the
current sid branch:

CONFIG_NET_SCH_FQ_CODEL=m
CONFIG_DEFAULT_FQ_CODEL=y
CONFIG_DEFAULT_NET_SCH="fq_codel"

Then we don't see any change at all to the qdisc in use:

admin@ip-10-0-0-162:~$ grep -i fq_codel /boot/config-$(uname -r)
CONFIG_NET_SCH_FQ_CODEL=m
CONFIG_DEFAULT_FQ_CODEL=y
CONFIG_DEFAULT_NET_SCH="fq_codel"
admin@ip-10-0-0-162:~$ /sbin/sysctl net.core.default_qdisc
net.core.default_qdisc = pfifo_fast
admin@ip-10-0-0-162:~$ tc qdisc show dev ens5
qdisc mq 0: root
qdisc pfifo_fast 0: parent :2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
admin@ip-10-0-0-162:~$ ip link show dev ens5
2: ens5:  mtu 9001 qdisc mq state UP mode 
DEFAULT group default qlen 1000
link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff
altname enp0s5

If we statically link the fq_codel module into the kernel, then we see:

admin@ip-10-0-0-162:~$ grep -i fq_codel /boot/config-$(uname -r)
CONFIG_NET_SCH_FQ_CODEL=y
CONFIG_DEFAULT_FQ_CODEL=y
CONFIG_DEFAULT_NET_SCH="fq_codel"
admin@ip-10-0-0-162:~$ /sbin/sysctl net.core.default_qdisc
net.core.default_qdisc = fq_codel
admin@ip-10-0-0-162:~$ /sbin/tc qdisc show dev ens5
qdisc mq 0: root
qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5ms 
interval 100ms memory_limit 32Mb ecn drop_batch 64
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5ms 
interval 100ms memory_limit 32Mb ecn drop_batch 64
admin@ip-10-0-0-162:~$ ip link show dev ens5
2: ens5:  mtu 9001 qdisc mq state UP mode 
DEFAULT group default qlen 1000
link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff
altname enp0s5

So in this case, we have fq_codel configured, but not as the root
qdisc for the interface.  If we manually set it:

admin@ip-10-0-0-162:~$ sudo /sbin/tc qdisc add root dev ens5 fq_codel

Then we get the following configuration:

admin@ip-10-0-0-162:~$ /sbin/tc qdisc show dev ens5
qdisc fq_codel 8001: root refcnt 3 limit 10240p flows 1024 quantum 9015 target 
5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
admin@ip-10-0-0-162:~$ ip link show dev ens5
2: ens5:  mtu 9001 qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff
altname enp0s5

I believe that this is what we want.  Is that accurate?

The recent thread at 
https://www.mail-archive.com/netdev@vger.kernel.org/msg380410.html
also seems relevant.

noah

Bug#979306: QVTKOpenGLWidget.h: No such file or directory

[Drew Parsons]

On 2021-01-08 05:48, Anton Gladky wrote:

Hi Drew,

this header is according to documentation deprecated.
I tried to use the proposed header, but some more changes
in the code are needed.

Please verify it and close the bug, if nothing more can be done
on vtk9 side.



Thanks for checking it, Anton.  I'll work with the avogadrolibs 
developers to get the code updated in that case.
I'll inspect more closely and then close the bug (or transfer it to 
avogadrolibs)



Drew

Bug#928603: libdebian-installer - parser_rfc822: remove limitation on line length

[Diederik de Haas]

On Tue, 7 May 2019 12:07:31 + Asbjørn Sloth Tønnesen  
wrote:
> Package: libdebian-installer
> Severity: wishlist
> 
> As debated in #55 and #904699, the READSIZE limit is arbitrary,
> parser_rfc822 should be rewritten to remove READSIZE, so that it
> does't have to be increased again.

+1 as I just ran into https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971946 
which is the same problem as mentioned above, but now for bullseye.

I feel inclined to raise the severity as the original problem was reported in 
2009 and in 2021 the problem still exists, just with a different value.
So close to the freeze, I'm guessing a 'quick fix' will probably have to do, 
but a permanent fix would really be welcome.
But I'll leave it up to the maintainer(s) to raise the severity.

Cheers,
  Diederik

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

Bug#971946: libdebian-installer: READSIZE size insufficient for cdebootstrap to build sid/unstable from buster/stable environment

[Diederik de Haas]

Control: severity -1 grave

On Sat, 10 Oct 2020 14:57:28 +0400 Jonathan Stanley  
wrote:
> Package: libdebian-installer
> Version: 0.119
> 
> When using cdebootstrap from within buster/stable to create a rootfs for
> sid/unstable, it will fail with:
> 
> W: parser_rfc822: Iek! Don't find end of value!
> E: Internal error: download
> 
> Seems "64k ought to be enough for everyone" strikes again as this is
> functionally a dupe of Bug#55 though it is now that a READSIZE of 65536
> in libdebian-installer/src/parser_rfc822.c is now insufficient. I
> downloaded the deb-src, updated READSIZE to 262144, debuild'ed it and
> installed it, cdebootstrap would then complete successfully for
> sid/unstable. My diff is:

I just ran into this issue as well and it's indeed the  same problem as bug 
#55 which means that it is unable to install a Bullseye system.

Ran ~ the same script as mentioned in that bug:
$ curl -Ls https://deb.debian.org/debian/dists/bullseye/main/binary-amd64/
Packages.xz | xzcat | awk '{if($1=="Package:")pkg=$2;print length,pkg,$1;}'|
sort -nr|head -10
65652 librust-winapi-dev Provides:
11203 libc6-dbg Build-Ids:
9900 mono-devel Replaces:
9786 mono-devel Breaks:
9261 node-babel7 Provides:
8520 gstreamer1.0-libav Gstreamer-Elements:
7494 libmono-cil-dev Depends:
7180 nomad Built-Using:
6646 docker.io Built-Using:
6359 parl-desktop-world Depends:


It's just a couple of bytes (116 to be exact and it is yet again the same 
package that's causing the problem), but enough to make it fail.

As bug #55 was set to severity grave, I've done it with this bug as well. 

Cheers,
   Diederik

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

Bug#979544: error: failed to parse manifest

[Francois Marier]

Package: cargo-outdated
Version: 0.9.9-1+b1
Severity: important

This is what I get when I use cargo-outdated 0.9.9 on the safe-rm repo:


  $ git clone https://git.launchpad.net/safe-rm
  $ cd safe-rm
  $ cargo outdated
  error: failed to parse manifest at 
`/tmp/user/1000/cargo-outdatedeMctiN/Cargo.toml`
  
  Caused by:
no targets specified in the manifest
either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be 
present

whereas it works fine if I use the latest version (0.9.13) from crates.io.

Francois

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

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

Versions of packages cargo-outdated depends on:
ii  libc62.31-9
ii  libcurl3-gnutls  7.74.0-1
ii  libgcc-s110.2.1-3
ii  libgit2-1.0  1.0.1+dfsg.1-3
ii  libssh2-11.9.0-2
ii  libssl1.11.1.1i-1
ii  zlib1g   1:1.2.11.dfsg-2

cargo-outdated recommends no packages.

cargo-outdated suggests no packages.

-- no debconf information

-- 
https://fmarier.org/

Bug#977248: FTBFS against opencv 4.5.0

[peter green]

tags 977248 +patch
thanks

The issue is a change in opencv4.pc, 4.2 has

includedir_old=${prefix}/include/opencv4/opencv
includedir_new=${prefix}/include/opencv4

But 4.5 has

includedir=${prefix}/include/opencv4

I whipped up a patch for this, soon after doing so I noticed that upstream
had also patched it. I tried to make my patch retain compatibility with previous
versions, upstream did not seem to bother with that.

Anyway upstreams patch can be found at 
https://github.com/infusion/PHP-Facedetect/commit/e2d7613993e69c660f417194843773a33dfd31ae

Mine has been uploaded to raspbian and should appear soon at 
https://debdiffs.raspbian.org/main/p/php-facedetect

No intent to NMU in Debian.

Bug#978556: [ftpmas...@ftp-master.debian.org: Processing of rust-netr_0.1.4-1_amd64.changes]

[Geert Stappers]

Upload did happen

- Forwarded message from Debian FTP Masters 
 -

Date: Thu, 07 Jan 2021 22:20:32 +
From: Debian FTP Masters 
To: stapp...@debian.org
Subject: Processing of rust-netr_0.1.4-1_amd64.changes

rust-netr_0.1.4-1_amd64.changes uploaded successfully to localhost
along with the files:
  netr-dbgsym_0.1.4-1_amd64.deb
  netr_0.1.4-1_amd64.deb
  rust-netr_0.1.4-1_amd64.buildinfo
  rust-netr_0.1.4-1.dsc
  rust-netr_0.1.4.orig.tar.gz
  rust-netr_0.1.4-1.debian.tar.xz

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

- End forwarded message -


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#979487: src:u-boot: renaming install-sunxi64 to -sunxi

[Nicolas Boulenguez]

Package: src:u-boot
Followup-For: Bug #979487

The attachment is the same,
rebased on your changes and
 with a manual page for the compatibility symbolic link.
>From 8822349b18c26b929486bf3886cdf5e118450ac1 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 7 Jan 2021 21:12:43 +0100
Subject: Update references to renamed u-boot-install-sunxi64

This follows 81c170865d89c2e60136d795b0f3de78a1e516bd.

The policy requires a manual page for each executable under /usr/bin,
including symbolic links.

diff --git a/debian/u-boot-sunxi.README.Debian 
b/debian/u-boot-sunxi.README.Debian
index b8899836df..9732affeb2 100644
--- a/debian/u-boot-sunxi.README.Debian
+++ b/debian/u-boot-sunxi.README.Debian
@@ -6,4 +6,4 @@ Many sunxi boards (Bananapi, Cubieboard) can be written to SD 
directly:
 
  dd conv=fsync,notrunc if=/usr/lib/u-boot/BOARD/u-boot-sunxi-with-spl.bin 
of=/dev/mmcblkX bs=1024 seek=8
 
-Pine64 plus can be installed using the u-boot-install-sunxi64 utility.
+Pine64 plus can be installed using the u-boot-install-sunxi utility.
diff --git a/debian/u-boot-sunxi.install b/debian/u-boot-sunxi.install
index e0b6edecf5..ad5a39aa6f 100755
--- a/debian/u-boot-sunxi.install
+++ b/debian/u-boot-sunxi.install
@@ -1,4 +1,4 @@
 #!/bin/sh
 debian/bin/u-boot-install-targets sunxi
 
-echo debian/bin/u-boot-install-sunxi64 /usr/bin/
+echo debian/bin/u-boot-install-sunxi /usr/bin/
diff --git a/debian/u-boot-sunxi.links b/debian/u-boot-sunxi.links
index bee110eb53..eac1f5e469 100644
--- a/debian/u-boot-sunxi.links
+++ b/debian/u-boot-sunxi.links
@@ -1 +1,2 @@
 usr/bin/u-boot-install-sunxi usr/bin/u-boot-install-sunxi64
+usr/share/man/man8/u-boot-install-sunxi.8.gz 
usr/share/man/man8/u-boot-install-sunxi64.8.gz
diff --git a/debian/u-boot-sunxi.manpages b/debian/u-boot-sunxi.manpages
index f72604d63f..f9c42c1d24 100644
--- a/debian/u-boot-sunxi.manpages
+++ b/debian/u-boot-sunxi.manpages
@@ -1 +1 @@
-debian/manpages/u-boot-install-sunxi64.8
+debian/manpages/u-boot-install-sunxi.8

Bug#979541: sylpheed: [regression] spell check no longer recognizes some correct Italian words

[Francesco Poli]

On Thu, 07 Jan 2021 23:33:09 +0100 Francesco Poli (wintermute) wrote:

[...]
> For example, if I compose a message with the following text:
> 
>   """
>   Questa è una prova che mi interessa poiché c'è qualcosa che non va.
>   """
> 
> and select "it" spell language, I see the following red-underlined
> words or expressions: "è", "poiché", "c'è".

I forgot to add that even "mi" is red-underlined, despite being pure
ASCII.

[...]
> Hence, I do not understand what exactly broke during the last days
> of package upgrades.
> Maybe the way Sylpheed communicates the text to aspell?

I tried to downgrade the following packages:

  libaspell15:amd64 from 0.60.8-2 to 0.60.8-1
  aspell from 0.60.8-2 to 0.60.8-1
  aspell-it from 2.4-20070901-0-3.1 to 2.4-20070901-0-3

but this didn't help.

I am more and more puzzled...

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp2V1PMpjLLc.pgp
Description: PGP signature

Bug#979543: chromium: watch file

[Bastian Germann]

Package: chromium
Severity: normal
Tags: patch

Enclosed is a patch including a watch file. It should be used only in 
modes skipping mk-origtargz. The file exclusion via tar --delete in 
mk-origtargz's current implementation is too inefficient for chromium. 
For downloading incl. repacking, use the existing make target which the 
patch modifies to use uscan.
From: Bastian Germann 
Date: Thu, 7 Jan 2021 23:39:33 +0100
Subject: [PATCH] Download via uscan
---
 debian/rules | 3 +--
 debian/watch | 4 
 2 files changed, 5 insertions(+), 2 deletions(-)
 create mode 100644 debian/watch

diff --git a/debian/rules b/debian/rules
index db85893..8774d5d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -147,7 +147,6 @@ override_dh_auto_clean:
 
 ## upstream source downloading 
 
-url=https://gsdview.appspot.com/chromium-browser-official
 version=$(shell dpkg-parsechangelog -S Version | sed s/-.*//)
 extract=chromium-$(version)
 tarfile=$(extract)-lite.tar
@@ -158,7 +157,7 @@ removed=$(debvers).files-removed
 seconds=$(debvers).seconds
 
 get-orig-source:
-	wget -nv --show-progress -c $(url)/$(tarball) -O ../$(tarball)
+	uscan --noconf --download-current-version --no-exclusion
 	cp /usr/share/perl5/Devscripts/MkOrigtargz.pm debian/scripts/mk-origtargz
 	patch -p1 < debian/scripts/mk-origtargz.patch
 	date +%s > $(seconds)
diff --git a/debian/watch b/debian/watch
new file mode 100644
index 000..448ebcd
--- /dev/null
+++ b/debian/watch
@@ -0,0 +1,4 @@
+version=4
+opts="pgpmode=none, searchmode=plain, filenamemangle=s%linux.stable.@ANY_VERSION@.%chromium-$1-lite.tar.xz%, \
+  downloadurlmangle=s%linux.stable.@ANY_VERSION@.%https://gsdview.appspot.com/chromium-browser-official/chromium-$1-lite.tar.xz%; \
+https://omahaproxy.appspot.com/history linux,stable,@ANY_VERSION@,

Bug#979542: gcc-riscv64-unknown-elf: Unable to use stdint.h

[Joel Stanley]

Package: gcc-riscv64-unknown-elf
Version: 8.3.0.2019.08+dfsg-1
Severity: normal

Dear Maintainer,

I am trying to use the riscv toolchain to build a bare metal
application. It appears to have a broken stdint.h:

$ cat test.c
#include 
$ riscv64-unknown-elf-gcc -E   -march=rv32i  -mabi=ilp32  -c test.c
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
# 1 "/usr/lib/gcc/riscv64-unknown-elf/8.3.0/include/stdint.h" 1 3 4
In file included from test.c:1:
/usr/lib/gcc/riscv64-unknown-elf/8.3.0/include/stdint.h:9:16: fatal error: 
stdint.h: No such file or directory
 # include_next 
^~

$ cat /usr/lib/gcc/riscv64-unknown-elf/8.3.0/include/stdint.h
#ifndef _GCC_WRAP_STDINT_H
#if __STDC_HOSTED__
# if defined __cplusplus && __cplusplus >= 201103L
#  undef __STDC_LIMIT_MACROS
#  define __STDC_LIMIT_MACROS
#  undef __STDC_CONSTANT_MACROS
#  define __STDC_CONSTANT_MACROS
# endif
# include_next 
#else
# include "stdint-gcc.h"
#endif
#define _GCC_WRAP_STDINT_H
#endif

$ riscv64-unknown-elf-gcc -E   -march=rv32i  -mabi=ilp32 -dM -nostdlib - < 
/dev/null |grep STDC_HOSTED
#define __STDC_HOSTED__ 1

stdint-gcc.h is a "real" stdint.h, containing the definitions I want.
I'm not sure how a user is supposed to tell the toolchain to use that
instead, if they can at all.

Comparing it to Debian's arm bare metal toolchain:

$ dpkg -L gcc-arm-none-eabi |grep stdint
/usr/lib/gcc/arm-none-eabi/8.3.1/include/stdint.h
/usr/lib/gcc/arm-none-eabi/8.3.1/plugin/include/config/newlib-stdint.h

The stdint.h here is equivalent to the riscv stdint-gcc.h, so the test
program compiles in that case.

Is this something that can be fixed with the riscv toolchain? Or is it
user error on my part?

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

Kernel: Linux 5.10.0-1-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 /bin/bash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages gcc-riscv64-unknown-elf depends on:
ii  binutils-riscv64-unknown-elf  2.32.2020.04+dfsg-2
ii  libc6 2.31-6
ii  libgcc-s1 [libgcc1]   10.2.1-3
ii  libgmp10  2:6.2.1+dfsg-1
ii  libmpc3   1.2.0-1
ii  libmpfr6  4.1.0-3
ii  libstdc++610.2.1-3
ii  zlib1g1:1.2.11.dfsg-2

gcc-riscv64-unknown-elf recommends no packages.

gcc-riscv64-unknown-elf suggests no packages.

-- no debconf information

Bug#975608: Patch to fix cgi.escape issue

[peter]

Please find attached a patch for the problem.
With this patch applied, libapache2-mod-python works with python 3.9.

diff --git a/lib/python/mod_python/apache.py b/lib/python/mod_python/apache.py
index 7748108..4e5c1d8 100644
--- a/lib/python/mod_python/apache.py
+++ b/lib/python/mod_python/apache.py
@@ -26,7 +26,7 @@ import pdb
 import stat
 import imp
 import types
-import cgi
+import html
 import _apache
 
 try:
@@ -549,7 +549,7 @@ class CallBack:
 
 s = '\n\nMod_python error: "%s %s"\n\n' % (phase, 
hname)
 for e in traceback.format_exception(etype, evalue, etb):
-s = s + cgi.escape(e) + '\n'
+s = s + html.escape(e) + '\n'
 s = s + "\n"
 
 if filter:
diff --git a/lib/python/mod_python/psp.py b/lib/python/mod_python/psp.py
index f994847..cae778c 100644
--- a/lib/python/mod_python/psp.py
+++ b/lib/python/mod_python/psp.py
@@ -25,7 +25,7 @@ import sys
 import os
 import marshal
 import types
-from cgi import escape
+from html import escape
 import dbm, dbm
 import tempfile
 

Bug#954823: hydrogen: Qt5 version available

[Nicholas D Steeves]

Jonas Smedegaard  writes:

> Quoting Nicholas D Steeves (2020-12-29 16:54:14)
>> 
>> Thank you for replying, and for the good wishes.  I won't bother you 
>> with RFS in the future.  'hopefully won't need them soon anymore 
>> either, as I'm somewhere in the middle of my DD process :-)
>
> That is _great_ news!
>
> I am happy you made that move, and happy for us all to get you deeper 
> entrenched :-)
>

Haha, thank you Jonas :-)

Take care!
Nicholas


signature.asc
Description: PGP signature

Bug#979540: kde-config-gtk-style: Configuring gtk theme on KDE result in abnormal output on stdout

[Norbert Preining]

Hi Eric,

> This seems to upset Gtk somehow, but it (=gtk) should not issue anything
> to stdout in this case I guess.

I was wrong, that is in our code base. Fixed and uploaded.
There was a debug statement leftover in the upstream code.

Best

Norbert

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

Bug#976113: Closing Hydrogen RFS

[Nicholas D Steeves]

>
> Hi Nicholas,
>
> Uploaded! Thanks for all the hard work getting hydrogen reintroduced
> through several beta releases etc.
>

Thank you on both accounts!

> I am closing the RFS bug manually as the package could sit in the NEW
> queue for a while.
>

I hope it's accepted in less than ~34 days so the package will make it
into bullseye! :-)

> I have also merged your changes and my last minute tweak into the salsa
> repository.
>

Thanks!  I've gone ahead and deleted the now-uneeded rfs-976113-rebase
branch and also the master-next branch that I had created for Dennis to
work from for things he wanted to see in -2.  If for some reason you'd
like me to resurrect one of both of them, I can do this within a
week--after that, my backups will rotate them into oblivion.

Have you created the release tag on your local master branch, or shall
I, and would you like to push the tag when the package is accepted, or
would you like me to remember to do so?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#979541: sylpheed: [regression] spell check no longer recognizes some correct Italian words

[Francesco Poli (wintermute)]

Package: sylpheed
Version: 3.7.0-8
Severity: normal

Hello!

A few days ago, I began experiencing a strange regression in Italian
spell check within Sylpheed.
Some correct Italian words are no longer recognized as valid.
Especially words with accented vowels (which include non-ASCII UTF-8
characters), but not only.

For example, if I compose a message with the following text:

  """
  Questa è una prova che mi interessa poiché c'è qualcosa che non va.
  """

and select "it" spell language, I see the following red-underlined
words or expressions: "è", "poiché", "c'è".

For the record, the above text is the Italian for:

  """
  This is a test I am interested in, since there's something wrong.
  """

and all the Italian words are correct (I am an Italian native speaker).

The strange thing is that aspell (the program) does not seem to
have issues with the text:

  $ cat test.txt
  Questa è una prova che mi interessa poiché c'è qualcosa che non va.
  $ aspell -l it check test.txt 

Hence, I do not understand what exactly broke during the last days
of package upgrades.
Maybe the way Sylpheed communicates the text to aspell?

Please investigate the bug and fix it and/or forward my bug report
upstream, as appropriate.

Thanks for your time.
Bye!



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

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

Versions of packages sylpheed depends on:
ii  libc62.31-6
ii  libcairo21.16.0-5
ii  libcompfaceg11:1.5.2-5+b2
ii  libenchant-2-2   2.2.12-1
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.4-1
ii  libgpgme11   1.14.0-1+b2
ii  libgtk2.0-0  2.24.33-1
ii  libgtkspell0 2.0.16-1.3
ii  libldap-2.4-22.4.56+dfsg-1
ii  libonig5 6.9.5-2
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libssl1.11.1.1i-1
ii  pinentry-gtk21.1.0-4
ii  sensible-utils   0.0.12+nmu1

Versions of packages sylpheed recommends:
ii  aspell-de [aspell-dictionary]  20161207-8
ii  aspell-en [aspell-dictionary]  2018.04.16-0-1
ii  aspell-it [aspell-dictionary]  2.4-20070901-0-3.1
ii  ca-certificates20200601
pn  sylfilter | bogofilter | bsfilter  
ii  sylpheed-i18n  3.7.0-8

Versions of packages sylpheed suggests:
pn  claws-mail-tools  
ii  curl  7.74.0-1
pn  sylpheed-doc  
pn  sylpheed-plugins  

-- no debconf information

Bug#979540: kde-config-gtk-style: Configuring gtk theme on KDE result in abnormal output on stdout

[Norbert Preining]

Severity 979540 important
thanks

> supposed to be either "ext" or "int" it used "WINDOW DECORATIONS RELOADED".

That is a message from Gtk I guess.

> Any application using gtk windows and using stdout to provide usefull data to 
> file
> storage/pipes,  may be broken.

What the version of the package uploaded does is removing a line
@import 'window_decorations.css';
from gtk-3.0.css, if it is present.

This seems to upset Gtk somehow, but it (=gtk) should not issue anything
to stdout in this case I guess.

I will discuss with the rest of the Team how to deal with it.

Thanks for the report

Norbert

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

Bug#975023: (no subject)

[Ryutaroh Matsumoto]

Control: tags -1 + upstream

The upstream author is aware of this issue as
http://git.liw.fi/vmdb2/commit/arm64-uefi.vmdb?id=8317f3f19d1a9a749fe80232bf3729325fc4c6f2

Bug#979540: kde-config-gtk-style: Configuring gtk theme on KDE result in abnormal output on stdout

[Eric Valette]

Package: kde-config-gtk-style
Version: 4:5.20.5-1
Severity: critical
Justification: breaks unrelated software

I have been  hunting a bug that after this morning update it took me the day 
long
and one of the visible effect was that it broke my vpn application that is 
using yad
to display some simple windows and get some inputs.

At some point I discovered that  insead of using some parameter who were
supposed to be either "ext" or "int" it used "WINDOW DECORATIONS RELOADED".

As the pacakge was using yad to display some simple input/input i tried to 
launch
yad and discovered that for one user I had on the konsole

prompt> yad
WINDOW DECORATIONS RELOADED

I then discivered that any gtk3 application did write this message on stdout 
(emacs
in partciular).

By chance I discovered that another user on the same machine did not suffer 
this problem.
and finally found that removing rm -rf ~/.config/gtk* file did fix the problem.

prompt> yad

was then not showing any WINDOW DECORATIONS RELOADED message on output.

But as soon as I use systemsetting to configure application style, and in 
particular
the bottom buton to configure GNOME/GTK applications, it
re-creates  ~/.config/gtk* files and I start having the wrong behavior (e.g 
select
breeze style), save

and again

prompt> yad
WINDOW DECORATIONS RELOADED

I started to see this behavior after this moring installation with  4:5.20.5-1 
new pacakges.

Any application using gtk windows and using stdout to provide usefull data to 
file
storage/pipes,  may be broken.

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

Kernel: Linux 5.10.4 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages kde-config-gtk-style depends on:
ii  libc6 2.31-9
ii  libglib2.0-0  2.67.1-1
ii  libgtk-3-03.24.24-1
ii  libkdecorations2-5v5  4:5.20.5-1
ii  libkdecorations2private7  4:5.20.5-1
ii  libkf5configcore5 5.77.0-2
ii  libkf5configwidgets5  5.77.0-3
ii  libkf5coreaddons5 5.77.0-2
ii  libkf5dbusaddons5 5.77.0-2
ii  libkf5guiaddons5  5.77.0-4
ii  libqt5core5a  5.15.2+dfsg-2
ii  libqt5dbus5   5.15.2+dfsg-2
ii  libqt5gui55.15.2+dfsg-2
ii  libqt5svg55.15.2-2
ii  libstdc++610.2.1-3

Versions of packages kde-config-gtk-style recommends:
ii  xsettings-kde  0.9-2+b2

Versions of packages kde-config-gtk-style suggests:
pn  kde-config-gtk-style-preview  

-- no debconf information

Bug#979482: u-boot: Pass BL31 to puma-rk3399

[Vagrant Cascadian]

On 2021-01-07, Nicolas Boulenguez wrote:
> The option was missing in debian/targets, so the build system is
> seeing BL31=...rk3328 set in the environment by previous platform.
> This is probably not deliberate.

> In order to prevent such issues, it may make sense to unset the
> variable after each use.

Indeed, nice catch!


> From 1424680924e85a02cfac20cd40ace45f9a1d1eff Mon Sep 17 00:00:00 2001
> From: Nicolas Boulenguez 
> Date: Wed, 6 Jan 2021 23:01:16 +0100
> Subject: [PATCH 03/11] Pass BL31 to puma-rk3399
>
> The option was missing in debian/targets, so the build system is
> seeing BL31=...rk3328 set in the environment by previous platform.
> This is probably not deliberate.
...
>  # Vagrant Cascadian 
> -arm64  rockchippuma-rk3399  u-boot.img u-boot.bin u-boot-nodtb.bin 
> spl/u-boot-spl.bin arch/arm/dts/rk3399-puma-haikou.dtb idbloader.img
> +arm64  rockchippuma-rk3399 
> /usr/lib/arm-trusted-firmware/rk3399/bl31.elf u-boot.img u-boot.bin 
> u-boot-nodtb.bin spl/u-boot-spl.bin arch/arm/dts/rk3399-puma-haikou.dtb 
> idbloader.img

At least in the past, this platform required a non-mainline u-boot at
different offsets, which was not packaged in Debian. In this case, it
may have just not made use of the BL31 variable...

I do recall there maybe were some changes relevent to this in recent
u-boot versions that I need to look into. This is a good reminder to do
that, thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#979483: u-boot: Stop installing rockchip_make_fit_atf on armhf)

[Vagrant Cascadian]

On 2021-01-07, Nicolas Boulenguez wrote:
> From 2bf162f77c3c392a7a0d1b3d250b6ea0c0b1d17f Mon Sep 17 00:00:00 2001
> From: Nicolas Boulenguez 
> Date: Thu, 7 Jan 2021 22:25:02 +0100
> Subject: Stop installing rockchip_make_fit_atf on armhf

There are 32-bit rockchip u-boot platforms that support ATF where this
script could be useful, though none are currently packaged; I don't
think it is worth the extra complication in the packaging to avoid
installing on armhf.

On the other hand, none of the supported platforms on any architecture
use this script from the package (some may use it during the build
process)... but it has been included in the last stable release, and I
do not see the harm in including it in another release.

I have in the past used it with custom platforms, or before platforms
had support fully integrated in upstream u-boot.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#957971: xblast-tnt: diff for NMU version 2.10.4-4.1

[Sudip Mukherjee]

Control: tags 957971 + pending
--

Dear maintainer,

I've prepared an NMU for xblast-tnt (versioned as 2.10.4-4.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru xblast-tnt-2.10.4/debian/changelog xblast-tnt-2.10.4/debian/changelog
--- xblast-tnt-2.10.4/debian/changelog  2016-01-13 11:25:27.0 +
+++ xblast-tnt-2.10.4/debian/changelog  2021-01-07 21:50:26.0 +
@@ -1,3 +1,11 @@
+xblast-tnt (2.10.4-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with GCC-10. (Closes: #957971)
+- Thanks to Luis Paulo Linares.
+
+ -- Sudip Mukherjee   Thu, 07 Jan 2021 21:50:26 
+
+
 xblast-tnt (2.10.4-4) unstable; urgency=medium
 
   * Update my name/email address.
diff -Nru xblast-tnt-2.10.4/debian/patches/020_fix-ftbfs-with-gcc-10.patch 
xblast-tnt-2.10.4/debian/patches/020_fix-ftbfs-with-gcc-10.patch
--- xblast-tnt-2.10.4/debian/patches/020_fix-ftbfs-with-gcc-10.patch
1970-01-01 01:00:00.0 +0100
+++ xblast-tnt-2.10.4/debian/patches/020_fix-ftbfs-with-gcc-10.patch
2021-01-07 20:21:02.0 +
@@ -0,0 +1,26 @@
+Description: Fix FTBFS with GCC-10.
+Author: Luis Paulo Linares 
+Bug-Debian: https://bugs.debian.org/957971
+
+--- xblast-tnt-2.10.4.orig/cfg_control.h
 xblast-tnt-2.10.4/cfg_control.h
+@@ -29,7 +29,7 @@
+ #define NUM_KEYB_CONTROLS  2
+ 
+ /* constant assignment of control to event type */
+-const XBEventCode keyEventType[NUM_KEYB_CONTROLS];
++extern const XBEventCode keyEventType[NUM_KEYB_CONTROLS];
+ 
+ /* ingame controls for editing*/
+ typedef struct
+--- xblast-tnt-2.10.4.orig/network.h
 xblast-tnt-2.10.4/network.h
+@@ -105,7 +105,7 @@ typedef enum
+ #define TEAM_UNDEF 252
+ 
+ /* team color assignment */
+-const XBColor teamColors[NUM_XBTS];
++extern const XBColor teamColors[NUM_XBTS];
+ 
+ /* results of game config receive/create */
+ typedef enum
diff -Nru xblast-tnt-2.10.4/debian/patches/series 
xblast-tnt-2.10.4/debian/patches/series
--- xblast-tnt-2.10.4/debian/patches/series 2016-01-13 08:40:36.0 
+
+++ xblast-tnt-2.10.4/debian/patches/series 2021-01-07 20:21:02.0 
+
@@ -1 +1,2 @@
 fix-manpage
+020_fix-ftbfs-with-gcc-10.patch

Bug#777291: gpm should provides systemd services

[Moritz Mühlenhoff]

Am Tue, Jan 05, 2021 at 11:38:54PM +0100 schrieb Axel Beckert:
> Control: tag -1 + pending
> 
> Hi Moritz,
> 
> Moritz Mühlenhoff wrote:
> > Attached is a patch against current sid which adds a systemd unit
> > for gpm. I've been using it for a few days on my system without
> > any issues.
> 
> Thanks! Committed to git and pushed.
> 
> Will probably do an upload tomorrow. To tired now and still some other
> things to fix.

Mmhh, actually, please hold back an upload. I just ran into an issue where it
failed to start, I need to poke at this some more and see if I can reproduce
this. I'll update the bug with more information.

Cheers,
Moritz

Bug#979539: youtube-dl: fails to find youtube automatic captions

[Thorsten Glaser]

Package: youtube-dl
Version: 2020.11.29-1
Severity: normal
Tags: fixed-upstream
X-Debbugs-Cc: t...@mirbsd.de

youtube-dl fails to find youtube automatic captions;
the upstream binary 2021.01.03 succeeds, so an update
will most likely fix this.


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

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

Versions of packages youtube-dl depends on:
ii  python33.9.1-1
ii  python3-pkg-resources  51.1.0-1

Versions of packages youtube-dl recommends:
ii  ca-bundle [ca-certificates]  20190604
ii  curl 7.74.0-1
ii  ffmpeg   7:4.3.1-5
ii  mplayer  2:1.4+ds1-1
pn  python3-pyxattr  
pn  rtmpdump 
ii  wget 1.21-1

Versions of packages youtube-dl suggests:
ii  libfribidi-bin  1.0.8-2
pn  phantomjs   

-- no debconf information

Bug#978146: geary: Geary segfaults on startup after upgrade to 3.38.1-1

[Henry-Nicolas Tourneur]

X-Debbugs-CC: jbi...@debian.org,bi...@debian.org

Adding the geary uploaders directly in CC since they might not have received
emails from the BTS for this bug as the maintainer is set to Debian GNOME
Maintainers.


Best regards,


-- 
Henry-Nicolas Tourneur
mxid: @hntourne:matrix.nilux.be
irc: hntourne on oftc


 

Bug#892275: redshift: Unable to connect to GeoClue.

[Gabriel Kerneis]

Le Thu, Jan 07, 2021 at 09:14:46PM +, Mike Gabriel a écrit :
> I can confirm this. After upgrading geoclue-2.0 from 2.5.6-1 to 2.5.7-2,
> gtk-redshift is broken (again).

I can confirm as well.

> user@host#:~ kill -9 `ps aux | grep redshift | grep -v grep | awk '{ print
> $2 }'`

Also in my case I found useful to remove
~/.config/autostart/redshift-gtk.desktop and to disable the service in
systemd which (according to pstree) was responsible for launching it:
$ systemctl --user disable redshift
$ systemctl --user disable redshift-gtk

Gabriel

Bug#979538: limesuite-udev: /usr/lib/udev/rules.d/64-limesuite.rules:5 Invalid value for OPTIONS key, ignoring: 'last_rule'

[Francois Marier]

Package: limesuite-udev
Version: 20.10.0+dfsg-2
Severity: normal

I'm seeing the following in my logs:

  Jan  7 06:01:54 hostname systemd-udevd[1116442]: 
/usr/lib/udev/rules.d/64-limesuite.rules:5 Invalid value for OPTIONS key, 
ignoring: 'last_rule'

It's related to the following line in /lib/udev/rules.d/64-limesuite.rules:

  SUBSYSTEM=="xillybus", MODE="666", OPTIONS="last_rule"

though I'm not sure what that option is supposed to be or whether it's
really needed.

Francois

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

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

-- no debconf information

-- 
https://fmarier.org/

Bug#979483: u-boot: Stop installing rockchip_make_fit_atf on armhf)

[Nicolas Boulenguez]

Control: reopen 979483

> The u-boot-install-rockchip script just installs built images,
Right, thanks!

Please forget the buggy previous diff.

The attached commit removes *rockchip_make_fit_atf*, as announced in
the original bug and commit titles.
>From 2bf162f77c3c392a7a0d1b3d250b6ea0c0b1d17f Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 7 Jan 2021 22:25:02 +0100
Subject: Stop installing rockchip_make_fit_atf on armhf


diff --git a/debian/u-boot-rockchip.install b/debian/u-boot-rockchip.install
deleted file mode 100755
index 89856b7c6c..00
--- a/debian/u-boot-rockchip.install
+++ /dev/null
@@ -1,6 +0,0 @@
-#!/bin/sh
-debian/bin/u-boot-install-targets rockchip
-cp arch/arm/mach-rockchip/make_fit_atf.py debian/build/rockchip_make_fit_atf
-sed -i -e 's,/usr/bin/env python.*,/usr/bin/python3,g' 
debian/build/rockchip_make_fit_atf
-echo debian/build/rockchip_make_fit_atf /usr/bin/
-echo debian/bin/u-boot-install-rockchip /usr/bin/
diff --git a/debian/u-boot-rockchip.install.arm64 
b/debian/u-boot-rockchip.install.arm64
new file mode 100755
index 00..89856b7c6c
--- /dev/null
+++ b/debian/u-boot-rockchip.install.arm64
@@ -0,0 +1,6 @@
+#!/bin/sh
+debian/bin/u-boot-install-targets rockchip
+cp arch/arm/mach-rockchip/make_fit_atf.py debian/build/rockchip_make_fit_atf
+sed -i -e 's,/usr/bin/env python.*,/usr/bin/python3,g' 
debian/build/rockchip_make_fit_atf
+echo debian/build/rockchip_make_fit_atf /usr/bin/
+echo debian/bin/u-boot-install-rockchip /usr/bin/
diff --git a/debian/u-boot-rockchip.install.armhf 
b/debian/u-boot-rockchip.install.armhf
new file mode 100755
index 00..8142144146
--- /dev/null
+++ b/debian/u-boot-rockchip.install.armhf
@@ -0,0 +1,3 @@
+#!/bin/sh
+debian/bin/u-boot-install-targets rockchip
+echo debian/bin/u-boot-install-rockchip /usr/bin/

Bug#976651: protobuf-compiler-grpc: Multi-arch protobuf-compiler-grpc

[Andreas Henriksson]

Hello again,

On Sun, Dec 06, 2020 at 03:14:56PM +0100, Andreas Henriksson wrote:
> Package: protobuf-compiler-grpc
> Version: 1.16.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I'm having a problem with grpc_cpp_plugin in my cross-build environment.
[...]
> 
> If I'm not mistaken the protobuf-compiler-grpc package should be marked
> `Multi-Arch: foreign` just like for example protobuf-compiler package is.
[...]

I just discussed with Helmut on IRC where we collaborately tried to
figure out how protoc and grpc_cpp_plugin interacts. Helmut said
he'd write a more detailed report soon and post here, but the
conclusion was that using `Multi-Arch: foreign` is likely correct
for both protobuf-compiler and protobuf-compiler-grpc (as I previously
suggested in my initial bug report).

I would be happy to see this fix uploaded soon so it has a chance
to go into testing before freeze! As there has been no feedback
so far I'm preparing to NMU it soon. Please tell me if I can go
ahead directly, if you have any objections, etc.

Regards,
Andreas Henriksson

Bug#979527: RFS: libxau/1:1.0.9-1 [QA] -- X11 authorisation library (development headers)

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libxau
   Version : 1:1.0.9-1
   Upstream Author : https://xorg.freedesktop.org/wiki/XorgMailingLists/
 * URL : https://xorg.freedesktop.org/wiki/
 * License : ISC
   Section : x11

It builds those binary packages:

  libxau-dev - X11 authorisation library (development headers)
  libxau6-udeb - X11 authorisation library
  libxau6 - X11 authorisation library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libx/libxau/libxau_1.0.9-1.dsc

Changes since the last upload:

 libxau (1:1.0.9-1) unstable; urgency=medium
 .
   * QA upload.
   * New upstream version 1.0.9
   * d/rules: rewrite using dh sequencer in debhelper compat 13
   * d/symbols: add symbols file
   * d/copyright: convert to DEP5 format
   * d/control: add homepage
   * d/watch: use https and bump to version 4

Regards,
Christian Göttsche

Bug#979537: pipewire occupies devices preventing driver unbinding

[Thomas Schmidt]

Package: pipewire
Version: 0.3.15-1
Severity: serious
Tags: upstream patch
Justification: makes unrelated software on the system break
X-Debbugs-Cc: schmid...@gmx.de

Dear Maintainer,

Im suffering from the same Upstream Bug 
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/369 (fixed)

> I have a VM where I tend to assign/bind a graphics card using VFIO/OVMF and 
> it stopped working after the move (completely freezes libvirtd when I tried 
> booting). After fair amount of debugging I realized that stopping pipewire 
> fixes this problem. 

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

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

Versions of packages pipewire depends on:
ii  init-system-helpers  1.60
ii  libpipewire-0.3-modules  0.3.15-1
ii  pipewire-bin 0.3.15-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#977243: Still not fixed

[Casey Bodley]

On Tue, Jan 5, 2021 at 2:46 AM Thomas Goirand  wrote:
>
> On 1/4/21 4:40 PM, Casey Bodley wrote:
> > you probably need the first commit from 
> > https://github.com/ceph/ceph/pull/38263
>
> I have included it in debian/patches, but that's not enough. :/
>
> Cheers,
>
> Thomas Goirand (zigo)
>

following discussion in the nautilus backport [1] of that PR, it looks
like that definition was needed under src/librbd/ as well, and the
backport was updated accordingly

[1] https://github.com/ceph/ceph/pull/38760

Bug#892275: redshift: Unable to connect to GeoClue.

[Mike Gabriel]

Control: severity -1 grave

Hi Nicolas, dear maintainer(s) of redshift in Debian,

On  Do 07 Jan 2021 22:03:11 CET, Debian Bug Tracking System wrote:


Package: redshift-gtk
Version: 1.12-4
Followup-For: Bug #892275

Dear Maintainer,

It seems that I have the same bug since today's reboot.
See the attached screenshot.
Moreover, I can't stop redshift. I close the window and it comes back.
I can't stop it, even killing it makes the fatal window come back again.
redshift uses 100% of a processor.

Yours,
n.


I can confirm this. After upgrading geoclue-2.0 from 2.5.6-1 to  
2.5.7-2, gtk-redshift is broken (again).


For some days now, redshift is unusable, thus bumping severity to  
grave again. Also, the upstream activity of redshift is suboptimal.  
Many open PRs, last activity dates back to summer 2020. :-(


@Nicolas: with this bash one liner you can kill the redshift process,  
if it stubbornly relaunches all the time:


user@host#:~ kill -9 `ps aux | grep redshift | grep -v grep | awk '{  
print $2 }'`


Greets,
Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpDQBrk098yw.pgp
Description: Digitale PGP-Signatur

Bug#979487: [979...@bugs.debian.org: Re: u-boot: Stop installing sunxi/u-boot-install-sunxi64 on armhf]

[Nicolas Boulenguez]

With the attachment…
>From 85b1a011ce5f362cb363d9c6ce44946f2f4be754 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 7 Jan 2021 21:12:43 +0100
Subject: Remove 64 suffix from u-boot-install-sunxi64

The tool can be used with custom targets.

diff --git a/debian/bin/u-boot-install-sunxi b/debian/bin/u-boot-install-sunxi
new file mode 100755
index 00..2d29eed598
--- /dev/null
+++ b/debian/bin/u-boot-install-sunxi
@@ -0,0 +1,101 @@
+#!/bin/sh
+set -e
+
+dtmodel="/sys/firmware/devicetree/base/model"
+atf="/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin"
+if [ -z "$TARGET" ] && [ -f "${dtmodel}" ]; then
+   dtmodelname=$(cat $dtmodel)
+   case "$dtmodelname" in
+   Pinebook) TARGET="/usr/lib/u-boot/pinebook" ;;
+   "Pine64 PinePhone (1.2)") TARGET='/usr/lib/u-boot/pinephone' ;;
+   Pine64+) TARGET="/usr/lib/u-boot/pine64_plus" ;;
+   "Pine64 LTS") TARGET="/usr/lib/u-boot/pine64-lts" ;;
+   "Olimex A64-Olinuxino") TARGET="/usr/lib/u-boot/a64-olinuxino/" 
;;
+   "Olimex A64-Olinuxino-eMMC") 
TARGET="/usr/lib/u-boot/a64-olinuxino-emmc" ;;
+   "Olimex A64 Teres-I") TARGET="/usr/lib/u-boot/teres_i/" ;;
+   "OrangePi Zero Plus2") 
TARGET="/usr/lib/u-boot/orangepi_zero_plus2/" ;;
+   "OrangePi One Plus") TARGET="/usr/lib/u-boot/orangepi_one_plus/"
+   atf="/usr/lib/arm-trusted-firmware/sun50i_h6/bl31.bin" 
;;
+   "FriendlyARM NanoPi NEO 2") 
TARGET="/usr/lib/u-boot/nanopi_neo2/" ;;
+   "FriendlyARM NanoPi NEO Plus2") 
TARGET="/usr/lib/u-boot/nanopi_neo_plus2/" ;;
+   *)
+   echo >&2 "ERROR: Unknown system: ${dtmodelname}"
+   echo >&2 "Specify target: TARGET=/usr/lib/u-boot/UBOOT"
+   exit 1
+   ;;
+   esac
+fi
+
+if [ -z "$BL31" ] && [ -f "${atf}" ]; then
+   BL31="${atf}"
+fi
+
+BL31=${BL31:-"/usr/lib/atf/sun50iw1p1/bl31.bin"}
+
+case "$1" in
+-f|--force)
+   FORCE=y
+   shift;;
+-*)
+   echo >&2 "$0: unknown option '$1'"
+   exit 1;;
+esac
+
+if [ -z "$(which mkimage)" ]; then
+   echo >&2 "$0: mkimage: command not found. Please install u-boot-tools."
+   exit 1
+fi
+
+DEV="$1"
+if [ -z "$DEV" ] || ! shift || [ -n "$*" ]; then
+echo >&2 "Usage: $0 /dev/your-sd-or-mmc-or-image"
+exit 1
+fi
+
+if [ ! -w "$DEV" ] && [ -z "$FORCE" ]; then
+echo >&2 "$0: device/image ($DEV) must be writable"
+exit 1
+fi
+DEV="$(readlink -f "$DEV")"
+
+if [ ! -w "$DEV" ] && [ -z "$FORCE" ]; then
+echo >&2 "$0: device/image ($DEV) not accessible via abs path?!?"
+exit 1
+fi
+
+if [ -z "$FORCE" ]; then
+# A very simple sanity check.  GPT mandates a "protective MBR" so this 
works
+# even with GPT partitioning.
+printf '%b' '\0125\0252' >mbr-sign
+if ! cmp -s -i 0:510 -n 2 mbr-sign "$DEV"; then
+   echo >&2 "$0: device/image ($DEV) has no MBR partition table"
+   exit 1
+fi
+
+# But, on sunxi64, spl will trample upon GPT.
+printf "EFI PART" >gpt-sign
+if cmp -s -i 0:512 -n 8 gpt-sign "$DEV"; then
+   echo >&2 "$0: device/image ($DEV) uses GPT partition table, unusable on 
sunxi64"
+   exit 1
+fi
+fi
+
+itbfiles="u-boot.itb u-boot-sunxi-with-spl.fit.itb"
+itb=
+for i in $itbfiles ; do
+   i=${TARGET}/$i
+   if [ -f "$i" ]; then
+   itb=$i
+   fi
+done
+
+if [ -z "$itb" ]; then
+   echo >&2 "$0: no known .itb file in ${TARGET}"
+   exit 1
+fi
+
+echo "Writing sunxi-spl"
+dd conv=notrunc if=${TARGET}/sunxi-spl.bin of="$DEV" bs=8k seek=1
+echo "Writing u-boot FIT image"
+dd conv=notrunc if=${itb} of="$DEV" bs=8k seek=5
+sync "$DEV"
diff --git a/debian/bin/u-boot-install-sunxi64 
b/debian/bin/u-boot-install-sunxi64
deleted file mode 100755
index 2d29eed598..00
--- a/debian/bin/u-boot-install-sunxi64
+++ /dev/null
@@ -1,101 +0,0 @@
-#!/bin/sh
-set -e
-
-dtmodel="/sys/firmware/devicetree/base/model"
-atf="/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin"
-if [ -z "$TARGET" ] && [ -f "${dtmodel}" ]; then
-   dtmodelname=$(cat $dtmodel)
-   case "$dtmodelname" in
-   Pinebook) TARGET="/usr/lib/u-boot/pinebook" ;;
-   "Pine64 PinePhone (1.2)") TARGET='/usr/lib/u-boot/pinephone' ;;
-   Pine64+) TARGET="/usr/lib/u-boot/pine64_plus" ;;
-   "Pine64 LTS") TARGET="/usr/lib/u-boot/pine64-lts" ;;
-   "Olimex A64-Olinuxino") TARGET="/usr/lib/u-boot/a64-olinuxino/" 
;;
-   "Olimex A64-Olinuxino-eMMC") 
TARGET="/usr/lib/u-boot/a64-olinuxino-emmc" ;;
-   "Olimex A64 Teres-I") TARGET="/usr/lib/u-boot/teres_i/" ;;
-   "OrangePi Zero Plus2") 
TARGET="/usr/lib/u-boot/orangepi_zero_plus2/" ;;
-   "OrangePi One Plus") TARGET="/usr/lib/u-boot/orangepi_one_plus/"
-   

Bug#979487: u-boot: Stop installing sunxi/u-boot-install-sunxi64 on armhf

[Nicolas Boulenguez]

Package: src:u-boot
Followup-For: Bug #979487

The attachment implements:
> It might be worth renaming to drop the "64" part and

For me, this bug can be closed, unless you want to keep a reminder of:
> adding support known 32-bit targets as well, as is done on rockchip
> platforms.

> Also, to keep the u-boot-sunxi packages "Multi-Arch: same", I believe
> all the variants need to ship the same files in non-multiarch paths.
This alone would not be a problem.  The exact quote is "for any pair
of architectures, the common files have equal content".

Bug#979104: installation-reports: Intel Wireless 8265 / 8275 has no firmware in nonfree iso

[Ben Hutchings]

On Sun, 2021-01-03 at 14:30 +0100, Holger Wansing wrote:
> Hi,
> 
> liangyue  wrote:
> >   My wifi can not connect. The installer told me that I missing
> > firmware files are
> > regulatory.db, and I solved it by add package named wireless-regdb.
> > I think the package
> > wireless-regdb should be add to nonfree iso.
> >   By the way, my amd gpu rx590 also need firmware, because I can't
> > enter desktop 
> > environment until I install the package firmware-amd-graphics. I
> > think the two firmware
> > should included in nonfree iso for everyone like my haardware.
> 
> Two different issues here:
> 
> 1. regulatory.db from wireless-regdb package is not included in non-free 
> firmware-including d-i images.
[...]

regulatory.db is free, and is packaged in wireless-regdb-udeb which
should be included in most installer builds since 20201202.  So I don't
know why it's not being found.

Ben.


-- 
Ben Hutchings
A free society is one where it is safe to be unpopular.
  - Adlai Stevenson


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

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

[Marek Rusinowski]

Christoph Biedl wrote:

> In case you haven't noticed yet, that was fixed in clevis 15-3 a few
> days ago. There's alreaddy 15-4 which should reach testing in two days.

I've updated the system with clevis tpm2 setup today and all works
fine end to end with 15-4.

Thank you!
Marek

Bug#979533: chromium: New 87.0.4280.141 (CVE-2020-15995 CVE-2020-16043 CVE-2021-21106 CVE-2021-21107 CVE-2021-21108 CVE-2021-21109 CVE-2021-21110 CVE-2021-21111 CVE-2021-21112 CVE-2021-21113 CVE-2021-

[Jan Luca Naumann]

Michel is preparing an new version and I update the buster branch as
soon as the unstable version is uploaded.

Best,
Jan

On Thu, 07 Jan 2021 21:01:43 +0100 Salvatore Bonaccorso
 wrote:
> Source: chromium
> Version: 87.0.4280.88-0.4
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: found -1 87.0.4280.88-0.4~deb10u1
> 
> Hi
> 
> Please see
> https://chromereleases.googleblog.com/2021/01/stable-channel-update-for-desktop.html
> here is a new round of CVE fixes for chromium accordingly.
> 
> CVE-2020-15995 seems a bit unclear, it was previously marked to affect
> only Chrome on Android, but now appears to affect as well us.
> 
> Regards,
> Salvatore
> 
> 



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979180: AlSA problems remain

[ael]

Sadly the new twinkle still has ALSA problems. I will try to
investigate.

Bug#718272: Processed: reopening 718272

[Luke Dashjr]

FWIW, I brought this up at our weekly developer meeting, and there was also 
another concern about apt upgrades across softforks: It could be problematic 
to not deploy a softfork, and problematic to deploy one without the user's 
consent.

I think I recall Debian has a way for packages to interactively prompt the 
user during upgrade. Maybe if softforks were turned into a runtime option, 
that could resolve that issue. What do you think?

For reference, the meeting log:

https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-01-07-19.00.moin.txt

Luke


On Thursday 07 January 2021 18:24:39 Jonas Smedegaard wrote:
> Quoting Luke Dashjr (2021-01-07 18:26:43)
>
> > We (upstream) already elaborated many years ago, copied here:
> >
> > http://luke.dashjr.org/tmp/code/20130723-linux-distribution-packaging-and
> >-bitcoin.md.asc
> >
> > At a minimum, to be safe, Debian would need to:
> >
> > 1) Either:
> > 1a) Build with the bundled LevelDB statically linked.
> > 1b) Guarantee LevelDB package remains consensus-compatible, including NOT
> > fixing any bugs without a proper consensus-compatibility audit.
> > 2) Backport (at least) security fixes for Debian's security support
> > period. Upstream, we generally only maintain releases for a year or so at
> > most.
>
> Thanks for your input on upstream position on this matter, Luke, and in
> particular this condensed summary.  It is helpful for Debian to make its
> decision.
>
>
>  - Jonas

Bug#979536: openconnect: Assertion on connection to GlobalProtect

[Matt]

Package: openconnect
Version: 8.10-2+b1
Severity: important
X-Debbugs-Cc: tardarsa...@gmail.com

Dear Maintainer,

After upgrading openconnect from 8.10-1 to 8.10-2+b1, I can no longer connect 
to a GlobalProtect VPN.

This is the output from a connection attempt (with identifying information 
removed):

$ sudo openconnect --protocol gp -u   
POST 
https:///global-protect/prelogin.esp?tmp=tmp=4100=Linux
Connected to :443
SSL negotiation with 
openconnect: ../../../lib/x509/common.c:1794: _gnutls_sort_clist: Assertion `k 
== clist_size' failed.
Aborted

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.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 openconnect depends on:
ii  libc62.31-6
ii  libgnutls30  3.7.0-5
ii  libopenconnect5  8.10-2+b1
ii  libproxy1v5  0.4.16-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  vpnc-scripts 0.1~git20200930-1

Versions of packages openconnect recommends:
ii  python3 3.9.1-1
ii  python3-asn1crypto  1.4.0-1
ii  python3-mechanize   1:0.4.5-2
ii  python3-netifaces   0.10.9-0.2+b3

Versions of packages openconnect suggests:
ii  bash-completion  1:2.11-2

-- no debconf information

Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye

[Luca Boccassi]

On Thu, 7 Jan 2021 at 19:53, Thomas Goirand  wrote:
>
> On 1/7/21 4:54 PM, Christian Ehrhardt wrote:
> > Hi,
> > as an FYI Ubuntu moved to recent commit def6eb1ea and for us it seems
> > to work fine so far.
> > See the package at:
> > https://launchpad.net/ubuntu/+source/openvswitch/2.15.0~git20210104.def6eb1ea-0ubuntu3
> >
> > With that confirmed and the feature freeze coming soon. Would you mind
> > doing a similar upload to Debian-experimental soon'ish?
>
> So, basically, you wish that I package the tip of master in
> Experimental? I'll see if I find the time to do it. However, I very much
> would prefer if upstream OVS could cut a (alpha / beta) tag.
>
> Cheers,
>
> Thomas Goirand (zigo)

Yes, given time is running out we need to get the transition starting
ASAP, unfortunately. The upstream OVS timeline for RCs and releases
unfortunately doesn't quite align and would be too late. I asked the
release team for an exception but I had no answer, so at this point it
seems to me the safest course of action is to assume we're not getting
one.

There has been extensive testing of that commit id by Canonical, so it
should be safe to use in unstable/testing for a month, until the
proper release.

Thank you!

Kind regards,
Luca Boccassi

Bug#979535: Please package latest upstream release

[Eric Dorland]

Source: golang-github-miekg-dns
Severity: wishlist

There have been several new upstream releases and the newest dnscrypt-proxy 
package requires a newer version.


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

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

Bug#979534: wolfssl: CVE-2020-36177

[Salvatore Bonaccorso]

Source: wolfssl
Version: 4.5.0+dfsg-4
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/wolfSSL/wolfssl/pull/3426
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for wolfssl.

CVE-2020-36177[0]:
| RsaPad_PSS in wolfcrypt/src/rsa.c in wolfSSL before 4.6.0 has an out-
| of-bounds write for certain relationships between key size and digest
| size.


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-36177
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-36177
[1] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26567
[2] https://github.com/wolfSSL/wolfssl/pull/3426

Regards,
Salvatore

Bug#979184: rust-lazycell: newly introduced binary packages uninstallable.

[Paul Gevers]

Hi Peter,

On Mon, 4 Jan 2021 00:20:17 + plugwash 
wrote:
> If noone objects I will make an upload dropping these features in a week 
> or so.

I thank you for caring.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979533: chromium: New 87.0.4280.141 (CVE-2020-15995 CVE-2020-16043 CVE-2021-21106 CVE-2021-21107 CVE-2021-21108 CVE-2021-21109 CVE-2021-21110 CVE-2021-21111 CVE-2021-21112 CVE-2021-21113 CVE-2021-

[Salvatore Bonaccorso]

Source: chromium
Version: 87.0.4280.88-0.4
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 87.0.4280.88-0.4~deb10u1

Hi

Please see
https://chromereleases.googleblog.com/2021/01/stable-channel-update-for-desktop.html
here is a new round of CVE fixes for chromium accordingly.

CVE-2020-15995 seems a bit unclear, it was previously marked to affect
only Chrome on Android, but now appears to affect as well us.

Regards,
Salvatore

Bug#973922: New upstream (2.19)

[Geert Stappers]

On Thu, Jan 07, 2021 at 08:19:21PM +0100, Geert Stappers wrote:
> On Thu, Jan 07, 2021 at 07:00:42PM +0100, Fabio Pedretti wrote:
> > 2.18 was uploaded to Debian
> > while 2.19 is already available upstream?
> 
> Something between  yes and no.
> 
> 
> The 2.19 version lacks a signature from upstream.
> 2.18 has a signature from upstream.
> 
> In other words: radvd 2.18 is complete in Debian,
> v2.19 of radvd waits on signature from upstream ...
 
At https://github.com/reubenhwk/radvd/issues/129#issuecomment-728848196
is expressed what we are waiting on.

 
Regards
Geert Stappers
Maintainer of radvd in Debian
-- 
Silence is hard to parse

Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye

[Thomas Goirand]

On 1/7/21 4:54 PM, Christian Ehrhardt wrote:
> Hi,
> as an FYI Ubuntu moved to recent commit def6eb1ea and for us it seems
> to work fine so far.
> See the package at:
> https://launchpad.net/ubuntu/+source/openvswitch/2.15.0~git20210104.def6eb1ea-0ubuntu3
> 
> With that confirmed and the feature freeze coming soon. Would you mind
> doing a similar upload to Debian-experimental soon'ish?

So, basically, you wish that I package the tip of master in
Experimental? I'll see if I find the time to do it. However, I very much
would prefer if upstream OVS could cut a (alpha / beta) tag.

Cheers,

Thomas Goirand (zigo)

Bug#971754: ABI breakage from 1.4.1 to 1.4.2

[Paul Gevers]

Hi Federico,

On Tue, 06 Oct 2020 16:38:49 +0300 =?utf-8?q?Sebastian_Dr=C3=B6ge?=
 wrote:
> 1.4.2 broke ABI by adding some fields to the CBytePerfMon structure.
> See https://github.com/Haivision/srt/issues/1592 for details.

Any progress on this? The freeze for bullseye is around the corner, and
this bug is already impacting other packages that fail to migrate to
testing due to srt not migrating.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#957166: efingerd: diff for NMU version 1.6.5+nmu1

[Sudip Mukherjee]

Control: tags 957166 + patch
Control: tags 957166 + pending
--

Dear maintainer,

I've prepared an NMU for efingerd (versioned as 1.6.5+nmu1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru efingerd-1.6.5/CHANGES efingerd-1.6.5+nmu1/CHANGES
--- efingerd-1.6.5/CHANGES  2013-10-15 08:48:59.0 +0100
+++ efingerd-1.6.5+nmu1/CHANGES 2021-01-07 19:41:15.0 +
@@ -1,3 +1,10 @@
+efingerd (1.6.5+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957166)
+
+ -- Sudip Mukherjee   Thu, 07 Jan 2021 19:41:15 
+
+
 efingerd (1.6.5) unstable; urgency=low
 
   * Sanitize DNS response, ident response and username before passing them
diff -Nru efingerd-1.6.5/debian/changelog efingerd-1.6.5+nmu1/debian/changelog
--- efingerd-1.6.5/debian/changelog 2013-10-15 08:48:59.0 +0100
+++ efingerd-1.6.5+nmu1/debian/changelog2021-01-07 19:41:15.0 
+
@@ -1,3 +1,10 @@
+efingerd (1.6.5+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957166)
+
+ -- Sudip Mukherjee   Thu, 07 Jan 2021 19:41:15 
+
+
 efingerd (1.6.5) unstable; urgency=low
 
   * Sanitize DNS response, ident response and username before passing them
diff -Nru efingerd-1.6.5/debian/po/cs.po efingerd-1.6.5+nmu1/debian/po/cs.po
--- efingerd-1.6.5/debian/po/cs.po  2013-10-15 08:48:39.0 +0100
+++ efingerd-1.6.5+nmu1/debian/po/cs.po 2021-01-07 19:41:15.0 +
@@ -19,10 +19,10 @@
 "PO-Revision-Date: 2005-04-02 10:44+0200\n"
 "Last-Translator: Miroslav Kure \n"
 "Language-Team: Czech \n"
+"Language: cs\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=utf-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"Language: cs\n"
 
 #. Type: boolean
 #. Description
diff -Nru efingerd-1.6.5/debian/po/da.po efingerd-1.6.5+nmu1/debian/po/da.po
--- efingerd-1.6.5/debian/po/da.po  2013-10-15 08:48:39.0 +0100
+++ efingerd-1.6.5+nmu1/debian/po/da.po 2021-01-07 19:41:15.0 +
@@ -11,10 +11,10 @@
 "PO-Revision-Date: 2012-02-02 12:42+\n"
 "Last-Translator: Joe Hansen \n"
 "Language-Team: Danish \n"
+"Language: da\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"Language: da\n"
 
 #. Type: boolean
 #. Description
diff -Nru efingerd-1.6.5/debian/po/de.po efingerd-1.6.5+nmu1/debian/po/de.po
--- efingerd-1.6.5/debian/po/de.po  2013-10-15 08:48:39.0 +0100
+++ efingerd-1.6.5+nmu1/debian/po/de.po 2021-01-07 19:41:15.0 +
@@ -19,10 +19,10 @@
 "PO-Revision-Date: 2006-10-16 08:30+\n"
 "Last-Translator: Jens Seidel \n"
 "Language-Team: german \n"
+"Language: \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"Language: \n"
 
 #. Type: boolean
 #. Description
diff -Nru efingerd-1.6.5/debian/po/es.po efingerd-1.6.5+nmu1/debian/po/es.po
--- efingerd-1.6.5/debian/po/es.po  2013-10-15 08:48:39.0 +0100
+++ efingerd-1.6.5+nmu1/debian/po/es.po 2021-01-07 19:41:15.0 +
@@ -31,10 +31,10 @@
 "PO-Revision-Date: 2005-09-27 17:01+0100\n"
 "Last-Translator: César Gómez Martín \n"
 "Language-Team: Debian l10n spanish \n"
+"Language: \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=utf-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"Language: \n"
 "X-Poedit-Language: Spanish\n"
 "X-Poedit-Country: SPAIN\n"
 "X-Poedit-SourceCharset: utf-8\n"
diff -Nru efingerd-1.6.5/debian/po/fr.po efingerd-1.6.5+nmu1/debian/po/fr.po
--- efingerd-1.6.5/debian/po/fr.po  2013-10-15 08:48:39.0 +0100
+++ efingerd-1.6.5+nmu1/debian/po/fr.po 2021-01-07 19:41:15.0 +
@@ -19,10 +19,10 @@
 "PO-Revision-Date: 2005-03-29 21:22+0100\n"
 "Last-Translator: Steve Petruzzello \n"
 "Language-Team: French \n"
+"Language: fr\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=iso-8859-15\n"
 "Content-Transfer-Encoding: 8bit\n"
-"Language: fr\n"
 "X-Poedit-Language: French\n"
 "X-Poedit-Country: SWITZERLAND\n"
 
@@ -124,8 +124,8 @@
 "Par d�faut, efingerd affiche les vrais noms des utilisateurs (d'apr�s le "
 "fichier passwd) sur la premi�re ligne de la r�ponse. Vous pouvez choisir de "
 "supprimer cette option. Cependant, si vous autorisez simultan�ment "
-"l'utilisation de ��~/.efingerd��, les utilisateurs pourront quand m�me cacher 
"
-"leur identit� au d�mon finger."
+"l'utilisation de ��~/.efingerd��, les utilisateurs pourront quand m�me "
+"cacher leur identit� au d�mon finger."
 
 #. Type: boolean
 #. Description
diff -Nru efingerd-1.6.5/debian/po/it.po efingerd-1.6.5+nmu1/debian/po/it.po
--- efingerd-1.6.5/debian/po/it.po  2013-10-15 08:48:39.0 +0100
+++ efingerd-1.6.5+nmu1/debian/po/it.po 2021-01-07 19:41:15.0 +
@@ -10,10 +10,10 @@
 "PO-Revision-Date: 2012-08-27 16:08+0200\n"
 "Last-Translator: Beatrice Torracca \n"
 "Language-Team: Italian \n"
+"Language: 

Bug#979180: Adding ZRTP

[ael]

Although the rtp library is missing from testing,
https://github.com/wernerd/ZRTPCPP provides the file(s).
So

cmake .. -DWITH_ALSA=On -DWITH_SPEEX=On -DWITH_ILBC=Off -DWITH_ZRTP=On 
-DWITH_G729=Off -DWITH_QT5=On

now works.

Bug#979532: Wrong man page installed for gdm(8)

[Phillip Susi]

Package: gdm3
Version: 3.38.2.1-1

/usr/share/man/man8/gdm3.8.gz actually contains a copy of of the man
page for gdm-screenshot(1) rather than gdm3.

Bug#979177: cups-filters-core-drivers: Adding a printer impossible because "driverless" is too slow

[Till Kamppeter]

I have released cups-filters 1.28.7 with the fix now.

https://github.com/OpenPrinting/cups-filters/releases/tag/1.28.7

Bug#973922: New upstream (2.19)

[Geert Stappers]

On Thu, Jan 07, 2021 at 07:00:42PM +0100, Fabio Pedretti wrote:
> 2.18 was uploaded to Debian
> while 2.19 is already available upstream?

Something between  yes and no.


The 2.19 version lacks a signature from upstream.
2.18 has a signature from upstream.

In other words: radvd 2.18 is complete in Debian,
v2.19 of radvd waits on signature from upstream ...


Regards
Geert Stappers
DD,  maintainer of radvd
-- 
Silence is hard to parse

Bug#979120: qa.debian.org: Salsa CI results oddly up to date?

[Samuel Thibault]

Hello,

Samuel Thibault, le dim. 03 janv. 2021 02:18:56 +0100, a ecrit:
> The VCS CI tick is super useful, but it seems it's not always correctly up
> to date. As of now, on line ccsm of
> 
> https://qa.debian.org/developer.php?email=sthibault%40debian.org
> 
> there is a "failed" word in the VCS column, while 
> 
> https://salsa.debian.org/compiz-team/ccsm/-/pipelines
> 
> shows that this has been fixed 3 days ago already.

The ccsm package does not have the "failed" word any more, but the vmg
package still has it while

https://salsa.debian.org/a11y-team/vmg/-/pipelines

is fixed since a week.

Samuel

Bug#957068: cavezofphear: diff for NMU version 0.5.1-1.1

[Sudip Mukherjee]

Control: tags 957068 + pending
--

Dear maintainer,

I've prepared an NMU for cavezofphear (versioned as 0.5.1-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru cavezofphear-0.5.1/debian/changelog 
cavezofphear-0.5.1/debian/changelog
--- cavezofphear-0.5.1/debian/changelog 2012-01-19 11:39:31.0 +
+++ cavezofphear-0.5.1/debian/changelog 2021-01-07 19:03:02.0 +
@@ -1,3 +1,11 @@
+cavezofphear (0.5.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with GCC 10. (Closes: #957068)
+- Thanks to Reiner Herrmann.
+
+ -- Sudip Mukherjee   Thu, 07 Jan 2021 19:03:02 
+
+
 cavezofphear (0.5.1-1) unstable; urgency=low
 
   * Initial release (Closes: #650690)
diff -Nru cavezofphear-0.5.1/debian/patches/gcc10.patch 
cavezofphear-0.5.1/debian/patches/gcc10.patch
--- cavezofphear-0.5.1/debian/patches/gcc10.patch   1970-01-01 
01:00:00.0 +0100
+++ cavezofphear-0.5.1/debian/patches/gcc10.patch   2021-01-07 
18:59:24.0 +
@@ -0,0 +1,26 @@
+Author: Reiner Herrmann 
+Description: Fix FTBFS with GCC 10
+Bug-Debian: https://bugs.debian.org/957068
+
+--- a/src/frame.c
 b/src/frame.c
+@@ -26,7 +26,7 @@
+ void sigint_handler();
+ void sigwinch_handler();
+ 
+-int need_refresh;
++extern int need_refresh;
+ 
+ void curses_start(void)
+ {
+--- a/src/editor.c
 b/src/editor.c
+@@ -24,7 +24,7 @@
+ #include "common.h"
+ #include "proto.h"
+ 
+-char map[MAP_YSIZE][MAP_XSIZE];
++extern char map[MAP_YSIZE][MAP_XSIZE];
+ int lock;
+ int last_obj;
+ 
diff -Nru cavezofphear-0.5.1/debian/patches/series 
cavezofphear-0.5.1/debian/patches/series
--- cavezofphear-0.5.1/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ cavezofphear-0.5.1/debian/patches/series2021-01-07 18:59:24.0 
+
@@ -0,0 +1 @@
+gcc10.patch

Bug#979531: lodash/fp does not have all the files shipped by npm dist.tarball

[Pirate Praveen]

Package: node-lodash
Version: 4.17.20+dfsg+~cs8.31.172-1
Severity: important
Control: affects -1 gitlab
Control: tags -1 help

gitlab package from salsa master-13.5 branch fails with this error 
during installation.


ERROR in 
/environments/components/environments_table.vue?vue=script=js& 
(/usr/share/nodejs/babel-loader/lib??ref--1!/var/lib/gitlab/node_modules/vue-loader/lib??vue-loader-options!./environments/components/environments_table.vue?vue=script=js&)

Module build failed (from /usr/share/nodejs/babel-loader/lib/index.js):
SyntaxError: 
/usr/share/gitlab/app/assets/javascripts/environments/components/environments_table.vue: 
The 'lodash' method `flow` is not a known module.
Please report bugs to 
https://github.com/lodash/babel-plugin-lodash/issues.

 132 | * 5. Put folders first.
 133 | */
> 134 | return flow(
 | 
 135 | sortBy(env => (env.isFolder ? env.folderName : env.name)),
 136 | reverse,
 137 | sortBy(env => (env.last_deployment ? 
env.last_deployment.created_at : '')),
   at File.buildCodeFrameError 
(/usr/share/nodejs/@babel/core/lib/transformation/file/file.js:250:12)
   at NodePath.buildCodeFrameError 
(/usr/share/nodejs/@babel/traverse/lib/path/index.js:138:21)
   at resolvePath 
(/usr/share/nodejs/babel-plugin-lodash/lib/importModule.js:28:18)
   at importModule 
(/usr/share/nodejs/babel-plugin-lodash/lib/importModule.js:36:53)

   at memoized (/usr/share/nodejs/lodash/memoize.js:65:23)
   at /usr/share/nodejs/babel-plugin-lodash/lib/index.js:187:62
   at arrayEach (/usr/share/nodejs/lodash/_arrayEach.js:18:9)
   at forEach (/usr/share/nodejs/lodash/forEach.js:41:10)
   at /usr/share/nodejs/babel-plugin-lodash/lib/index.js:177:30
   at arrayEach (/usr/share/nodejs/lodash/_arrayEach.js:18:9)
   at forEach (/usr/share/nodejs/lodash/forEach.js:41:10)
   at /usr/share/nodejs/babel-plugin-lodash/lib/index.js:165:28
   at arrayEach (/usr/share/nodejs/lodash/_arrayEach.js:18:9)
   at forEach (/usr/share/nodejs/lodash/forEach.js:41:10)
   at PluginPass.Program 
(/usr/share/nodejs/babel-plugin-lodash/lib/index.js:154:26)

   at newFn (/usr/share/nodejs/@babel/traverse/lib/visitors.js:175:21)
   at NodePath._call 
(/usr/share/nodejs/@babel/traverse/lib/path/context.js:55:20)
   at NodePath.call 
(/usr/share/nodejs/@babel/traverse/lib/path/context.js:42:17)
   at NodePath.visit 
(/usr/share/nodejs/@babel/traverse/lib/path/context.js:92:31)
   at TraversalContext.visitQueue 
(/usr/share/nodejs/@babel/traverse/lib/context.js:115:16)
   at TraversalContext.visitSingle 
(/usr/share/nodejs/@babel/traverse/lib/context.js:84:19)
   at TraversalContext.visit 
(/usr/share/nodejs/@babel/traverse/lib/context.js:143:19)
   at Function.traverse.node 
(/usr/share/nodejs/@babel/traverse/lib/index.js:82:17)

   at traverse (/usr/share/nodejs/@babel/traverse/lib/index.js:64:12)
   at transformFile 
(/usr/share/nodejs/@babel/core/lib/transformation/index.js:107:29)

   at transformFile.next ()
   at run 
(/usr/share/nodejs/@babel/core/lib/transformation/index.js:35:12)

   at run.next ()
   at Function.transform 
(/usr/share/nodejs/@babel/core/lib/transform.js:27:41)

   at transform.next ()
   at step (/usr/share/nodejs/gensync/index.js:254:32)
   at /usr/share/nodejs/gensync/index.js:266:13
   at async.call.result.err.err 
(/usr/share/nodejs/gensync/index.js:216:11)
@ 
/environments/components/environments_table.vue?vue=script=js& 
1:0-225 1:241-244 1:246-468 1:246-468

@ ./environments/components/environments_table.vue
@ ./environments/mixins/environments_mixin.js
@ ./environments/mount_show.js
@ ./pages/projects/environments/show/index.js
@ multi ./main ./pages/projects/index.js 
/pages/projects/environments/show/index.js


When 451 files are shipped with npmjs.com dist tarball of lodash in 
lodash/fp, only 101 files are shipped in debian package. And indeed 
flow.js is missing from the debian package.

Bug#976696: smartmontools: install drivedb.h to /usr and copy into /var in postinst when missing/outdated

[bouteville pierre-noel]

Could you remove my email of your list? 
I already try normal procedure in past but it doesn’t work ! 

May be due to ‘_´ in my email? 

Envoyé de mon iPhone

> Le 7 janv. 2021 à 15:27, Dmitry Smirnov  a écrit :
> 
> On Friday, 8 January 2021 12:29:06 AM AEDT Paul Wise wrote:
>>> On Thu, 2021-01-07 at 21:33 +1100, Dmitry Smirnov wrote:
>>> Makes sense, thanks. I'll probably implement unconditional
>>> replacement of "drivedb.h" at first, then think of version detection,
>>> if time allows.
>> 
>> I noticed that the file downloaded by update-smart-drivedb still does
>> not contain a valid version number in the $Id value, would you like a
>> separate bug for that and one for the version check on updates?
> 
> As you wish. I've left a TODO note in postinst regarding version check
> and upstream needs to know about $Id value. I guess both bugs could be
> of some use but mostly one about $Id value, especially if filed upstream.
> 
> Thank you.
> 
> -- 
> Kind regards,
> Dmitry Smirnov
> GPG key : 4096R/52B6BBD953968D1B
> 
> ---
> 
> The strongest argument for socialism is that it sounds good. The strongest
> argument against socialism is that it doesn't work. But those who live by
> words will always have a soft spot in their hearts for socialism because it
> sounds so good.
>-- Thomas Sowell
> 
> ---
> 
> The Seven-Step Path from Pandemic to Totalitarianism There are just seven
> steps from pandemic declaration to permanent totalitarianism – and many
> jurisdictions are about to start Step 5.
>-- 
> https://off-guardian.org/2020/04/23/the-seven-step-path-from-pandemic-to-totalitarianism

Bug#979438: gnome-passwordsafe: many SyntaxError messages during installation

[Patrice Duroux]

Hi,

I think that my system is consistent with the current Debian unstable system,
which has the following python3 default version:

$ python3 --version
Python 3.9.1

And if I am not wrong, the python3 default is also 3.9.1 in Debian Bullseye.

Many thanks!
Patrice

Le jeudi 07 janvier 2021 à 14:06 +0100, deb...@nilux.be a écrit :
> 
> Hello Patrice,
> 
> Thanks for the report.
> I checked with upstream and we are wondering, what is the actual 
> version of your default python3 interpreter ? (python3 --version)
> 
> We cannot reproduce the error you described, neither on my system nor 
> on upstream's author ones. It seems this could be because the python3 
> interpreter that you are using is older than 3.7 (that's why I asked 
> for the version above).
> 
> Regards,
> 
> Henry-Nicolas Tourneur
> 
> 

Bug#974586:

[Fabio Pedretti]

According to upstream changelog:
https://github.com/rsyslog/loganalyzer/blob/master/ChangeLog
multiple php 7.x issues are also fixed in 4.1.7 and 4.1.8.

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956621

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 

Bug#979306: QVTKOpenGLWidget.h: No such file or directory

[Anton Gladky]

Hi Drew,

this header is according to documentation deprecated.
I tried to use the proposed header, but some more changes
in the code are needed.

Please verify it and close the bug, if nothing more can be done
on vtk9 side.

Regards

Anton

Am Di., 5. Jan. 2021 um 23:49 Uhr schrieb Drew Parsons :
>
> Hi Anton, I've pushed avogadrolibs to salsa master,
> https://salsa.debian.org/debichem-team/avogadrolibs

Bug#954823: Hydrogen is NEW

[Ross Gammon]

tag 954823 + pending
tag 960539 + pending
thanks

Tagging these bugs as pending as Hydrogen has been uploaded and is
sitting in the NEW queue.

-- 
Regards,

Ross Gammon
FBEE 0190 904F 1EA0 BA6A  300E 53FE 7BBD A689 10FC



signature.asc
Description: OpenPGP digital signature

Bug#718272: Processed: reopening 718272

[Jonas Smedegaard]

Quoting Luke Dashjr (2021-01-07 18:26:43)
> We (upstream) already elaborated many years ago, copied here:
> 
> http://luke.dashjr.org/tmp/code/20130723-linux-distribution-packaging-and-bitcoin.md.asc
> 
> At a minimum, to be safe, Debian would need to:
> 
> 1) Either:
> 1a) Build with the bundled LevelDB statically linked.
> 1b) Guarantee LevelDB package remains consensus-compatible, including NOT
> fixing any bugs without a proper consensus-compatibility audit.
> 2) Backport (at least) security fixes for Debian's security support period.
>Upstream, we generally only maintain releases for a year or so at most.

Thanks for your input on upstream position on this matter, Luke, and in 
particular this condensed summary.  It is helpful for Debian to make its 
decision.


 - 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#978983: dpkg{,-trigger} manpage refers to %PKGDOCDIR%

[Guillem Jover]

Control: tag -1 pending

Hi!

On Fri, 2021-01-01 at 18:19:52 +0100, Christoph Biedl wrote:
> Package: dpkg
> Version: 1.20.5
> Severity: minor

> the manpages for dpkg and dpkg-trigger contin a substitution
> variable %PKGDOCDIR% - possibly this should have been replaced with
> /usr/share/doc/dpkg during build but this didn't happen.

Yes, this had already been reported on IRC by Niels Thykier, and fixed
on git. :)

  


I've now included the bug closure as a git note.

Thanks,
Guillem

Bug#973922: New upstream (2.19)

[Fabio Pedretti]

2.18 was uploaded to Debian while 2.19 is already available upstream?

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155