Bug#969451: coccinelle: use the system pyml library

[Pino Toscano]

Source: coccinelle
Version: 1.0.8.deb-4
Severity: wishlist
Tags: patch

Hi,

coccinelle has a bundled copy of pyml; it is used during the build
because no system pyml is found.
Adding libpyml-ocaml-dev as build dependency and libpyml-ocaml as
dependency does the job: the system version is found and used;
patch attached for this.

That said, I haven't tried checking whether the Python capabilities
still work; the build time test suite passes in the same way as before,
and the existing autopkgtest works. Maybe it would be worth extending
the autopkgtests for this...

Thanks,
-- 
Pino
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends: debhelper-compat (=12),
libmenhir-ocaml-dev (>= 20090204.dfsg),
libparmap-ocaml-dev (>= 1.0~rc4-5~),
libpcre-ocaml-dev,
+   libpyml-ocaml-dev,
   libstdcompat-ocaml-dev,
menhir (>= 20090204.dfsg),
ocaml-findlib,
@@ -31,6 +32,7 @@ Vcs-Browser: https://salsa.debian.org/oc
 Package: coccinelle
 Architecture: any
 Depends: libparmap-ocaml,
+ libpyml-ocaml,
  ocaml-findlib,
  ${misc:Depends},
  ${ocaml:Depends},

Bug#969452: RM: tuxguitar-* [armel armhf i386 mipsel] -- RoQA; libswt-gtk-4-java was removed from 32 bit arches which makes the package FTBFS and not-installable

[Paul Gevers]

Package: ftp.debian.org
Severity: normal

This is a follow-up on bug #962915: RM: swt4-gtk [armel armhf i386
mipsel] -- ROM; Upstream no longer supports 32 bits architectures

The removal of libswt-gtk-4-java on the 32 bits archs makes tuxguitar
(arch:all) not-installable on those arches. However, tuxguitar is a
dependency of the other (arch:any) packages in the same source. swt4-gtk
fails to migrate (already 65 days now) to testing because those binaries
from tuxguitar would become not-installable. Please remove the arch:any
packages from src:tuxguitar on armel, armhf, i386 and mipsel.

Thanks,
Paul



signature.asc
Description: OpenPGP digital signature

Bug#965074: Patches to make multicast proccesing on CDC NCM drivers

[Santiago Ruano Rincón]

El 02/09/20 a las 17:45, Greg KH escribió:
> On Wed, Sep 02, 2020 at 03:27:28PM +0200, Santiago Ruano Rincón wrote:
> > El 02/09/20 a las 14:05, Greg KH escribió:
> > > On Wed, Sep 02, 2020 at 01:47:18PM +0200, Santiago Ruano Rincón wrote:
> > > > El 30/07/20 a las 16:07, Oliver Neukum escribió:
> > > > > Am Donnerstag, den 30.07.2020, 15:53 +0200 schrieb Santiago Ruano
> > > > > Rincón:
…
> > > > 
> > > > It would be possible to apply/backport Miguel's patches (along with
> > > > 5fd99b5d9950d6300467ded18ff4e44af0b4ae55) to stable versions please?
> > > 
> > > I don't see that git commit id in Linus's tree, are you sure it is
> > > correct?
> > 
> > I should had mention it is found in linux-next, sorry. Please see
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969365#10
> 
> Ah, nothing I can do with patches that are not yet in Linus's tree.
> 

ACK.

> > > > FWIW, in the context of Debian, I'm personally interested in 4.19.y.
> > > 
> > > What specific list of commits are you wanting to see backported?
> > 
> > This:
> > 
> > 37a2ebdd9e597ae1a0270ac747883ea8f6f767b6
> > e10dcb1b6ba714243ad5a35a11b91cc14103a9a9
> > e506addeff844237d60545ef4f6141de21471caf
> > 0226009ce0f6089f9b31211f7a2703cf9a327a01
> 
> These do not look like bugfixes, but a new feature being added for this
> driver.  So why not just use a newer kernel version for this feature?

From my point of view as user these are bugfixes, since IPv6 NDP or any
other protocol relying on multicast do not work without them. In other
words, my computer's networking is broken.

I want to have them in linux stable releases because that would make
easier to include them in Debian stable release.

Thanks!

 -- Santiago


signature.asc
Description: PGP signature

Bug#969449: Debian 10 does not let me install VMware tools gives me a depmod error

[Paul Flaherty]

Knot is installed for some reason still it does. Or install VMware tools

Get Outlook for iOS


From: Phil Wyett 
Sent: Thursday, September 3, 2020 3:33 AM
To: Paul Flaherty; 969...@bugs.debian.org
Subject: Re: Bug#969449: Debian 10 does not let me install VMware tools gives 
me a depmod error

On Thu, 2020-09-03 at 06:34 +, Paul Flaherty wrote:
> Debian 10 does not let me install VMware tools gives me a depmod error
>
>
>
> Sent from Mail for Windows 10
>

Hi,

'depmod' is in the 'kmod' package that you need to install.

Regards

Phil

--

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B

Bug#969449: Debian 10 does not let me install VMware tools gives me a depmod error

[Paul Flaherty]

Kmod I mean

Get Outlook for iOS

From: Paul Flaherty 
Sent: Thursday, September 3, 2020 3:52:14 AM
To: philip.wy...@kathenas.org ; 
969...@bugs.debian.org <969...@bugs.debian.org>; Paul Flaherty 

Subject: Re: Bug#969449: Debian 10 does not let me install VMware tools gives 
me a depmod error

Knot is installed for some reason still it does. Or install VMware tools

Get Outlook for 
iOS


From: Phil Wyett 
Sent: Thursday, September 3, 2020 3:33 AM
To: Paul Flaherty; 969...@bugs.debian.org
Subject: Re: Bug#969449: Debian 10 does not let me install VMware tools gives 
me a depmod error

On Thu, 2020-09-03 at 06:34 +, Paul Flaherty wrote:
> Debian 10 does not let me install VMware tools gives me a depmod error
>
>
>
> Sent from Mail for Windows 10
>

Hi,

'depmod' is in the 'kmod' package that you need to install.

Regards

Phil

--

*** Playing the game for the games sake. ***

WWW: 
https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B

Bug#969449: Debian 10 does not let me install VMware tools gives me a depmod error

[Phil Wyett]

On Thu, 2020-09-03 at 06:34 +, Paul Flaherty wrote:
> Debian 10 does not let me install VMware tools gives me a depmod error
> 
> 
>  
> Sent from Mail for Windows 10
>  

Hi,

'depmod' is in the 'kmod' package that you need to install.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#969453: RFS: solo-python/0.0.26-1 [ITP] -- command line interface for SoloKeys 2FA security keys

[Philip Rinn]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "solo-python":

 * Package name: solo-python
   Version : 0.0.26-1
   Upstream Author : SoloKeys 
 * URL : https://github.com/solokeys/solo-python
 * License : Apache-2.0 or Expat
 * Vcs : https://salsa.debian.org/rinni/solo-python
   Section : utils

It builds those binary packages:

  solo-python - command line interface for SoloKeys

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

  https://mentors.debian.net/package/solo-python/

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/solo-python/solo-python_0.0.26-1.dsc

Changes for the initial release:

 solo-python (0.0.26-1) unstable; urgency=low
 .
   * Initial release (closes: #958565).


My main driver to package this is to have more support for 2FA security keys
available in Debian.

I own two of those keys and they are very nice devices for general 2FA but they
can actually do much more e.g. they will gain OpenPGP functionality in the
future.

I'm aware that the package will not build reproducible at the moment due to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969352 - I hope we will be 
able
to solve this issue before the freeze.

I also asked upstream to sign their releases and will ask them to include a 
manpage.


Best,
Philip

Bug#969454: apktool: unable to rebuild Trebuchet

[sergio]

Package: apktool
Version: 2.4.1-1
Severity: normal

Dear Maintainer,

1. Original apktool_2.4.1.jar from bitbucket / github works fine.

2. Debian version is broken:


% apktool d TrebuchetQuickStep.apk -o baz
% apktool b baz -o baz.apt

I: Using Apktool 2.4.1-dirty
I: Checking whether sources has changed...
I: Smaling smali folder into classes.dex...
I: Checking whether sources has changed...
I: Smaling smali_classes3 folder into classes3.dex...
I: Checking whether sources has changed...
I: Smaling smali_classes2 folder into classes2.dex...
I: Checking whether resources has changed...
I: Building resources...
W: aapt: brut.common.BrutException: brut.common.BrutException: Could not 
extract resource: /prebuilt/linux/aapt_64 (defaulting to $PATH binary)
W: res/drawable/$avd_hidden_lock__0.xml: Invalid file name: must contain only 
[a-z0-9_.]
W: res/drawable/$avd_hidden_lock__1.xml: Invalid file name: must contain only 
[a-z0-9_.]
W: res/drawable/$avd_hidden_lock__2.xml: Invalid file name: must contain only 
[a-z0-9_.]
W: res/drawable/$avd_hidden_unlock__0.xml: Invalid file name: must contain only 
[a-z0-9_.]
W: res/drawable/$avd_hidden_unlock__1.xml: Invalid file name: must contain only 
[a-z0-9_.]
W: res/drawable/$avd_hidden_unlock__2.xml: Invalid file name: must contain only 
[a-z0-9_.]
W: res/drawable/$avd_hide_password__0.xml: Invalid file name: must contain only 
[a-z0-9_.]
W: res/drawable/$avd_hide_password__1.xml: Invalid file name: must contain only 
[a-z0-9_.]
W: res/drawable/$avd_hide_password__2.xml: Invalid file name: must contain only 
[a-z0-9_.]
W: res/drawable/$avd_protected_lock__0.xml: Invalid file name: must contain 
only [a-z0-9_.]
W: res/drawable/$avd_protected_lock__1.xml: Invalid file name: must contain 
only [a-z0-9_.]
W: res/drawable/$avd_protected_unlock__0.xml: Invalid file name: must contain 
only [a-z0-9_.]
W: res/drawable/$avd_protected_unlock__1.xml: Invalid file name: must contain 
only [a-z0-9_.]
W: res/drawable/$avd_show_password__0.xml: Invalid file name: must contain only 
[a-z0-9_.]
W: res/drawable/$avd_show_password__1.xml: Invalid file name: must contain only 
[a-z0-9_.]
W: res/drawable/$avd_show_password__2.xml: Invalid file name: must contain only 
[a-z0-9_.]
brut.androlib.AndrolibException: brut.common.BrutException: could not exec 
(exit code = 1): [aapt, p, --min-sdk-version, 29, --target-sdk-version, 29, 
--version-code, 29, --version-name, 10, --no-version-vectors, -F, 
/tmp/APKTOOL14555950087481931025.tmp, -0, classes.dex, -0, resources.arsc, -0, 
png, -0, arsc, -I, /home/sergio/.local/share/apktool/framework/1.apk, -S, 
/tmp/t/baz/res, -M, /tmp/t/baz/AndroidManifest.xml]
zsh: exit 1 apktool b baz -o baz.apt


LineageOS 17.1 
/system/product/priv-app/TrebuchetQuickStep/TrebuchetQuickStep.apk
https://sergio.outerface.net/misc/TrebuchetQuickStep.apk

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

Bug#969449: bugs.debian.org: debian 10 does not let me install vmware tools looks for depmod and get issue in attached image

[Adam D. Barratt]

On Thu, 2020-09-03 at 02:22 -0400, Paul Flaherty wrote:
> Package: bugs.debian.org
> Severity: normal
> 
> debian 10 does not let me install vmware tools looks for depmod and
> get issue
> in attached image

The "bugs.debian.org" pseudo-package is for tracking issues in the bug
reporting / tracking system itself, not for general issues.

You already reported this in the same way a few days ago and were
advised at the time:


thanks for your interest in making Debian better and filing
this report:

However, at this time it looks more like a support request,
and the bug tracker is not well-suited for helping users
interactively.

Please try getting help first from other venues listed at
   https://www.debian.org/support - especially IRC,
the mailing lists or http://forums.debian.net/ .

Once there is a clear bug identified, please file a new report
against the package having the bug.


Have you tried this?

Regards,

Adam

Bug#955001:

[Jonas Smedegaard]

[ re-posted, now cc the bugreport ]

Quoting Michael Lustfield (2020-09-03 05:09:38)
> I'd be happy to, but it doesn't look like this will ever get 
> reviewed/included.
> 
> TBH- I actually forgot about this upload because it's been half a year. If
> it's still pending the next time I look at it, I'll probably request it's
> rejection and close this bug. :/

Please in that case (or rgardless, if you wish) hand over the package to 
me instead.


 - 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#969453: RFS: solo-python/0.0.26-1 [ITP] -- command line interface for SoloKeys 2FA security keys

[Ansgar]

Hi,

On Thu, 2020-09-03 at 10:03 +0200, Philip Rinn wrote:
> It builds those binary packages:
> 
>   solo-python - command line interface for SoloKeys

I don't have time to review the package, just one small notice:

If it is a command-line utility the choice of language for its
implementation doesn't matter to users and probably shouldn't be part
of a package's name for the same reason Policy recommends scripts in
PATH not including a `.sh` or `.py` suffix[1].

Ansgar

  [1]: https://www.debian.org/doc/debian-policy/ch-files.html#scripts

Bug#969453: RFS: solo-python/0.0.26-1 [ITP] -- command line interface for SoloKeys 2FA security keys

[Philip Rinn]

On 03.09.20 at 10:09 Ansgar wrote:
> If it is a command-line utility the choice of language for its
> implementation doesn't matter to users and probably shouldn't be part
> of a package's name for the same reason Policy recommends scripts in
> PATH not including a `.sh` or `.py` suffix[1].

Thanks, I know, but it's the name upstream chose (there is a package called 
'solo'
on pypi already) so I decides to not change it. The cli itself is called 'solo'
anyways.

Best,

Philip

Bug#969454: Acknowledgement (apktool: unable to rebuild Trebuchet)

[sergio]

https://github.com/iBotPeaches/Apktool/issues/2394

--
sergio.

Bug#969021: ITP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS

[Sudip Mukherjee]

Control: tags -1 pending
--

It is now in the NEW queue waiting for review by the ftp masters.


-- 
Regards
Sudip

Bug#969455: ITP: golang-github-rickb777-date -- Go library that provides functionality for working with dates.

[Arun Kumar Pariyar]

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

* Package name: golang-github-rickb777-date
  Version : 1.13.0-1~exp1
  Upstream Author : Rick Beton
* URL : https://github.com/rickb777/date
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go library that provides functionality for working with
dates.

This package introduces a light-weight Date type that is storage-efficient
and convenient for calendrical calculations and date parsing and
formatting (including years outside the [0,] interval).

Bug#931297: Bug #931297: Please support /usr/lib64/sane

[Colomban Wendling]

Source: sane-backends
Version: 1.0.30-1~experimental2
Followup-For: Bug #931297

I support this, and all of Gunnar's reasoning.  We have a patch
already for something almost identical, and there's still 3rd party
drivers out there that install in /usr/lib64/sane -- e.g. Samsung also
has drivers showing this, and I would guess there still are a bunch
other around.

My impression is that it would be trivial to fix the issue so that
these drivers work out of the box.  Yes, their authors should fix them
(and some are going the right direction, e.g. there are now Epson
drivers installing the the right multiarch directory), but we
unfortunately cannot reasonably expect most drivers out there getting
fixed anytime soon (especially ones for older hardware), so I think we
can make the lives of users a little easier here.

I myself patched 0125-multiarch_dll_search_path.patch to add lib64 on
my end (patch attached), and it seems to work just fine.

Thanks!
diff --git a/debian/patches/0125-multiarch_dll_search_path.patch 
b/debian/patches/0125-multiarch_dll_search_path.patch
index a213060..cebbaa3 100644
--- a/debian/patches/0125-multiarch_dll_search_path.patch
+++ b/debian/patches/0125-multiarch_dll_search_path.patch
@@ -1,7 +1,7 @@
 Description: Keep /usr/lib/sane as a fallback for SANE backends
  Make /usr/lib/arch_triplet/sane the default location for SANE backends,
- but keep /usr/lib/sane as a fallback for now.
-Author: Julien BLACHE 
+ but keep /usr/lib/sane and /usr/lib{32,64}/sane as fallbacks for now.
+Author: Julien BLACHE , Colomban Wendling 

 
 Index: trunk/backend/dll.c
 ===
@@ -39,7 +39,7 @@ Index: trunk/backend/Makefile.am
  ##  included LICENSE file for license information.
  
 -AM_CPPFLAGS += -I. -I$(srcdir) -I$(top_builddir)/include 
-I$(top_srcdir)/include $(USB_CFLAGS) -DLIBDIR="\"$(libdir)/sane\""
-+AM_CPPFLAGS += -I. -I$(srcdir) -I$(top_builddir)/include 
-I$(top_srcdir)/include $(USB_CFLAGS) -DLIBDIR="\"$(libdir)/sane\"" 
-DDEB_DLL_LIBDIR="\"$(libdir)/sane:$(prefix)/lib/sane\""
++AM_CPPFLAGS += -I. -I$(srcdir) -I$(top_builddir)/include 
-I$(top_srcdir)/include $(USB_CFLAGS) -DLIBDIR="\"$(libdir)/sane\"" 
-DDEB_DLL_LIBDIR="\"$(libdir)/sane:$(prefix)/lib/sane:$(prefix)/lib$(shell 
dpkg-architecture -q DEB_TARGET_ARCH_BITS)/sane\""
  
  AM_LDFLAGS += $(STRICT_LDFLAGS)
  # The -rpath option is added because we are creating _LTLIBRARIES based

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

[Jakob Meng]

Hello Anton,
that is great news! Keeping VTK and ParaView in sync' is not going to be
easy:

Sync'ing VTK sources and ParaView's VTK sources and allowing both to be
co-installable, increases the maintenance burden for both package
maintainers. Especially for Alastair McKinstry, because he would have to
copy and adapt all patches from (Debian's) VTK package sources to his
ParaView VTK sources.

Latest ParaView release is 5.8.1 [1] and that is using a pre-VTK9
development version of VTK [2][3] ?!? The master branch of next ParaView
release [4] has VTK 9 [5]. ParaView's release tarballs are published
without the VTK subfolder [6], but I am not sure whether that is due to
a "bug" [7] of the GitHub release process or if that means it is valid
to "mix" different ParaView and VTK releases.

ParaView CMakeLists.txt uses VTK's CMake files [8] before considering
PARAVIEW_USE_EXTERNAL_VTK [9], hence ParaView requires the VTK
subdirectory to be present anyway.

For Debian users, it would be beneficial to have VTK and ParaView
packages in sync and possibly installed at the same time, because that
enables them e.g.
1. run (i)python3 or pvpython and enter 'import vtk' without crashs
2. use find_package(VTK) and find_package(ParaView) in a single
CMakeLists.txt without tedious if-else constructs

[1] https://gitlab.kitware.com/paraview/paraview/-/tree/v5.8.1
[2]
https://gitlab.kitware.com/paraview/paraview/-/commit/ce73a508883c599927967be854ecfbf1562f032f
[3]
https://gitlab.kitware.com/vtk/vtk/-/blob/da522f73bc0639f8c995b8c89e21d604656f99e2/CMake/vtkVersion.cmake
[4] https://gitlab.kitware.com/paraview/paraview
[5]
https://gitlab.kitware.com/vtk/vtk/-/blob/ae3f586abc4032895ce05e664d4a6ad84f990ef2/CMake/vtkVersion.cmake
[6] https://github.com/Kitware/ParaView/releases
[7] https://stackoverflow.com/a/34721233/6490710
[8] https://github.com/Kitware/ParaView/blob/v5.8.1/CMakeLists.txt#L98
[9] https://github.com/Kitware/ParaView/blob/v5.8.1/CMakeLists.txt#L218

Best regards
Jakob




signature.asc
Description: OpenPGP digital signature

Bug#931297: Bug #931297: Please support /usr/lib64/sane

[Colomban Wendling]

Colomban Wendling:> I myself patched
0125-multiarch_dll_search_path.patch to add lib64 on
> my end (patch attached), and it seems to work just fine.

I didn't see Gunnar's patch before, oops.  Yet I think it's best not to
hard-code lib64 as it would not make any sense on a 32bits system.  I'm
not sure using dpkg-architecture like I did is the best solution, but it
was easy and works fine -- and in the context of a Debian patch, I'm not
worried about using that tool.

Bug#887649: cdebconf-gtk-terminal: Please don't depend on unmaintained vte

[Simon McVittie]

On Sun, 21 Jan 2018 at 21:27:47 +0100, Egmont Koblinger wrote:
> > We don't do c++ in d-i.
> 
> Unfortunately this sounds really problematic. As of version 0.42 vte
> has been using (more and more) C++. This is not like Ubuntu's PCRE2
> hack which is a matter of a few hours of work reverting and merging a
> few commits. It's reasonably impossible to revert to plain C and
> maintain that as a fork, and upstream has no intention to revert to C
> either.

One way to resolve this might be to build the vte2.91 udeb with
-static-libstdc++, which makes it about 200K larger than it would
otherwise have been, but avoids needing a 1.5M shared libstdc++. vte
exports a C ABI, and only uses C++ internally.

We need to upload a new vte2.91 to experimental anyway, so I'm going
to try this - d-i doesn't currently use that udeb anyway, so there's
nothing to lose by trying it.

smcv

Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

[Raúl Sánchez Siles]

  Hi:

El jueves, 3 de septiembre de 2020 6:54:23 (CEST) Mike Hommey escribió:
> On Thu, Sep 03, 2020 at 06:41:55AM +0200, Christoph Anton Mitterer wrote:
> > On Thu, 2020-09-03 at 10:37 +0900, Mike Hommey wrote:
[...]
> 
> Try going to about:config, switch extensions.logging.enabled to true,
> and try to reproduce, then open the browser console from the web
> developer menu and see if there's anything useful.
> 
> Mike

  As I'm experiencing the bug and I'm not sure how confidential data in the 
log is I'm sending the log privately to Mike. I got it enabling the 
extensions logging and the running firefox from the console with the --
jsconsole parameter.

  Regards,

-- 
Raúl

Bug#887649: cdebconf-gtk-terminal: Please don't depend on unmaintained vte

[Cyril Brulebois]

Hi Simon,

Simon McVittie  (2020-09-03):
> On Sun, 21 Jan 2018 at 21:27:47 +0100, Egmont Koblinger wrote:
> > > We don't do c++ in d-i.
> > 
> > Unfortunately this sounds really problematic. As of version 0.42 vte
> > has been using (more and more) C++. This is not like Ubuntu's PCRE2
> > hack which is a matter of a few hours of work reverting and merging a
> > few commits. It's reasonably impossible to revert to plain C and
> > maintain that as a fork, and upstream has no intention to revert to C
> > either.
> 
> One way to resolve this might be to build the vte2.91 udeb with
> -static-libstdc++, which makes it about 200K larger than it would
> otherwise have been, but avoids needing a 1.5M shared libstdc++. vte
> exports a C ABI, and only uses C++ internally.
> 
> We need to upload a new vte2.91 to experimental anyway, so I'm going
> to try this - d-i doesn't currently use that udeb anyway, so there's
> nothing to lose by trying it.

This looks like a nice plan, thanks for the heads-up!


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


signature.asc
Description: PGP signature

Bug#969456: kmix 20.08.0 crashes on exit

[Bernhard Übelacker]

Package: kmix
Version: 4:20.08.0-1
Severity: normal
Forwarded: https://bugs.kde.org/show_bug.cgi?id=425469
Tags: upstream fixed-upstream


Dear Maintainer,
I found several kmix cores lately and investigated a bit.

It crashes when attempting to do some cleanup on process exit.
There unfortunately the QtPaMainLoop structure got deleted,
but later still accessed.

Upstream has already a patch in git.

Kind regards,
Bernhard



==3727== Invalid read of size 8
==3727==at 0x7FBA456: pa_srbchannel_free (srbchannel.c:364)
==3727==by 0x7FB7032: check_srbpending.part.0 (pstream.c:724)
==3727==by 0x7FB9319: pa_pstream_unlink (pstream.c:1190)
==3727==by 0x7FB9319: pa_pstream_unlink (pstream.c:1181)
==3727==by 0x6E1FCB4: context_unlink (context.c:223)
==3727==by 0x6E1FCB4: context_unlink (context.c:201)
==3727==by 0x6E1FE01: context_free (context.c:244)
==3727==by 0x4A60F87: Mixer_PULSE::~Mixer_PULSE() (mixer_pulse.cpp:1073)
==3727==by 0x4A60FA8: Mixer_PULSE::~Mixer_PULSE() (mixer_pulse.cpp:1080)
==3727==by 0x4A3E0C4: Mixer::~Mixer() (mixer.cpp:115)
==3727==by 0x4A3E0D8: Mixer::~Mixer() (mixer.cpp:116)
==3727==by 0x4A37C36: MixerToolBox::deinitMixer() (mixertoolbox.cpp:356)
==3727==by 0x12D3F7: KMixWindow::~KMixWindow() (kmix.cpp:139)
==3727==by 0x12D4D8: KMixWindow::~KMixWindow() (kmix.cpp:151)
==3727==  Address 0x10704168 is 88 bytes inside a block of size 112 free'd
==3727==at 0x4839EAB: operator delete(void*) (vg_replace_malloc.c:584)
==3727==by 0x4A60F40: operator() (unique_ptr.h:85)
==3727==by 0x4A60F40: ~unique_ptr (unique_ptr.h:361)
==3727==by 0x4A60F40: Mixer_PULSE::~Mixer_PULSE() (mixer_pulse.cpp:1056)
==3727==by 0x4A60FA8: Mixer_PULSE::~Mixer_PULSE() (mixer_pulse.cpp:1080)
==3727==by 0x4A3E0C4: Mixer::~Mixer() (mixer.cpp:115)
==3727==by 0x4A3E0D8: Mixer::~Mixer() (mixer.cpp:116)
==3727==by 0x4A37C36: MixerToolBox::deinitMixer() (mixertoolbox.cpp:356)
==3727==by 0x12D3F7: KMixWindow::~KMixWindow() (kmix.cpp:139)
==3727==by 0x12D4D8: KMixWindow::~KMixWindow() (kmix.cpp:151)
==3727==by 0x136533: KMixApp::~KMixApp() (KMixApp.cpp:58)
==3727==by 0x12A527: main (main.cpp:73)
==3727==  Block was alloc'd at
==3727==at 0x4838DEF: operator new(unsigned long) (vg_replace_malloc.c:342)
==3727==by 0x4A5E538: Mixer_PULSE::connectToDaemon() (mixer_pulse.cpp:961)
==3727==by 0x4A61387: Mixer_PULSE::Mixer_PULSE(Mixer*, int) 
(mixer_pulse.cpp:1037)
==3727==by 0x4A61745: PULSE_getMixer(Mixer*, int) (mixer_pulse.cpp:947)
==3727==by 0x4A3E9F7: Mixer::Mixer(QString const&, int) (mixer.cpp:102)
==3727==by 0x4A381FE: 
MixerToolBox::initMixerInternal(MixerToolBox::MultiDriverMode, QStringList 
const&, bool) (mixertoolbox.cpp:142)
==3727==by 0x4A39602: initMixer (mixertoolbox.cpp:273)
==3727==by 0x4A39602: MixerToolBox::initMixer(bool, QStringList const&, 
bool) (mixertoolbox.cpp:284)
==3727==by 0x133724: KMixWindow::KMixWindow(bool, bool) (kmix.cpp:91)
==3727==by 0x1363AD: KMixApp::createWindowOnce(bool, bool) [clone .part.0] 
(KMixApp.cpp:69)
==3727==by 0x136B41: createWindowOnce (KMixApp.cpp:125)
==3727==by 0x136B41: KMixApp::restoreSessionIfApplicable(bool, bool) 
(KMixApp.cpp:125)
==3727==by 0x136CDE: KMixApp::newInstance(QStringList const&, QString 
const&) (KMixApp.cpp:166)
==3727==by 0x12A4F1: main (main.cpp:84)



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

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

Versions of packages kmix depends on:
ii  libasound2 1.2.3.2-1
ii  libc6  2.31-3
ii  libcanberra0   0.30-7
ii  libkf5configcore5  5.70.0-1
ii  libkf5configgui5   5.70.0-1
ii  libkf5configwidgets5   5.70.0-2
ii  libkf5coreaddons5  5.70.0-2
ii  libkf5dbusaddons5  5.70.0-1
ii  libkf5globalaccel-bin  5.70.0-1
ii  libkf5globalaccel5 5.70.0-1
ii  libkf5i18n55.70.0-1
ii  libkf5notifications5   5.70.0-1
ii  libkf5plasma5  5.70.1-1
ii  libkf5solid5   5.70.0-1
ii  libkf5widgetsaddons5   5.70.0-1
ii  libkf5windowsystem55.70.0-1
ii  libkf5xmlgui5  5.70.0-1+b1
ii  libpulse0  13.0-5
ii  libqt5core5a   5.14.2+dfsg-6
ii  libqt5dbus55.14.2+dfsg-6
ii  libqt5gui5 5.14.2+dfsg-6
ii  libqt5widgets5 5.14.2+dfsg-6
ii  libqt5xml5 5.14.2+dfsg-6
ii  libstdc++6 10.2.0-5

kmix recommends no packages.

kmix suggests no packages.

-- no debconf information

Bug#931297: Please support /usr/lib64/sane

[Gunnar Hjalmarsson]

On 2020-09-03 11:31, Colomban Wendling wrote:

I didn't see Gunnar's patch before, oops.


No problem. My patch was based on a previous version of 
0125-multiarch_dll_search_path.patch anyway, so let's consider your 
patch a refreshed and improved one. :)


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#969458: perl crash in eval command trying a failing require statement

[Raphaël Hertzog]

Package: perl
Version: 5.30.3-4
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: debian-d...@lists.debian.org
Control: found -1 5.32.0-2

In Kali, any source package build started to fail with a mysterious
error:
> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 127

After quite some investigation, I tracked this down to perl exiting with
that error code in the middle of an eval statement that should have failed:
https://sources.debian.org/src/dpkg/1.20.5/scripts/Dpkg/Vendor.pm/#L166

The $name tried is "Kali" and we don't ship any Dpkg::Vendor::Kali. The
code should fallback to Dpkg::Vendor::Debian and this works a few times
but after multiples calls, at some point it no longer works and the
require statement in the eval block just never returns, it seems to crash
the perl interpreter.

You can easily reproduce this on an up-to-date testing or unstable system
with dpkg 1.20.5 (that version is failing, the former version we had
in Kali was 1.19.7 and it was not triggering this issue):

$ sudo tee /etc/dpkg/origins/kali >/dev/null < Vendor: Kali
> Vendor-URL: https://www.kali.org/
> Parent: debian
> Bugs: https://bugs.kali.org/
> END
$ sudo ln -sf kali /etc/dpkg/origins/default
$ apt source hello
[...]
$ cd hello-*
$ dpkg-buildpackage -S
[...]
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building hello using existing ./hello_2.10.orig.tar.gz
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 127


Note that I only reproduce this with "3.0 (quilt)" source packages. Native
packages have different code paths likely involving fewer calls to
run_vendor_hook() and the problem can't be reproduced with such a source
package.

I can also reproduce the bug with version 5.32.0-2 available in
experimental.

FWIW I'm working around this issue in Kali with the attached patch but
this really smells like a bug in perl, thus I'm reporting it here.

Guillem, I believe the attached patch should be applied to dpkg in any
case as it's a small optimization that avoids running the evaled code too
often.

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

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

Versions of packages perl depends on:
ii  dpkg   1.20.5
ii  libperl5.305.30.3-4
ii  perl-base  5.30.3-4
ii  perl-modules-5.30  5.30.3-4

Versions of packages perl recommends:
ii  netbase  6.1

Versions of packages perl suggests:
pn  libtap-harness-archive-perl  
ii  libterm-readline-gnu-perl1.36-2+b1
ii  make 4.3-4
ii  perl-doc 5.30.3-4

-- no debconf information
>From 75631da697b9d2c5b3ff2c54bc225fc55d3ab9c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Thu, 3 Sep 2020 11:26:58 +0200
Subject: [PATCH] Work-around a perl crash during any package build

Somehow perl doesn't like the multiple execution of the eval code that tries
to "require Dpkg::Vendor::Kali;" and at some point perl just exits with
an error code of 127 when it tries to execute this line of code. When
it happens, the eval doesn't return.

To avoid the multiple execution of this code, we cache the result of the
lookup made on the parent vendor as the good result for the current
vendor as well.

There's likely some bug in perl here and somehow the update from
dpkg 1.19.7 to dpkg 1.20.5 started to trigger that bug.
---
 scripts/Dpkg/Vendor.pm | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/Dpkg/Vendor.pm b/scripts/Dpkg/Vendor.pm
index 196159156..5b8f66fd8 100644
--- a/scripts/Dpkg/Vendor.pm
+++ b/scripts/Dpkg/Vendor.pm
@@ -174,10 +174,12 @@ sub get_vendor_object {
 
 my $info = get_vendor_info($vendor);
 if (defined $info and defined $info->{'Parent'}) {
-return get_vendor_object($info->{'Parent'});
+$obj = get_vendor_object($info->{'Parent'});
 } else {
-return get_vendor_object('Default');
+$obj = get_vendor_object('Default');
 }
+$OBJECT_CACHE{$vendor} = $obj;
+return $obj;
 }
 
 =item run_vendor_hook($hookid, @params)
-- 
2.28.0

Bug#777410: freecdb: please make the build reproducible

[Chris Lamb]

tags 777410 - patch
thanks

Hi Sudip,

> > Friendly ping on this?
>
> This is an orphan package and anyone can make a QA upload.

Ah, I did not spot it was a QA package. (*)

> And can you please check again if it still has the problem?
> d/rules has been completely rewritten with 0.76 version and so the
> patch will not apply anymore.

Rechecking.. okay, so there is now a different set of problem or
problems that I can't immediately resolve, so I am removing the
"patch" tag for now.

Thanks for the quick reply. :)


(*) Well, actually UDD is returning me out of date "maintainer_name"
and "maintainer_email" values in the "bugs" table; the BTS
webpages are is correctly displaying this as a QA/orphaned package.


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Bug#969444: qemu-system-gui: gtk gui does not start

[Sicelo]

> 
> Please show the version number of qemu-system-x86 package you're trying to 
> run.
> 

Hi

After this question, I checked my installation, and noticed that even
though I had run `apt update` and `apt upgrade`, I had qemu-system-x86
version 1:5.0-8 as the newer 1:5.1+dfsg-4 was held back.

Having manually installed the newer version, the issue is no longer
there. Sorry for false alarm. This bug report can be closed.

Regards
Sicelo

Bug#763995: ITP: python-qutepart - Code editor component for PyQt and PySide

[Peter Ji]

Control: retitle -1 ITP: python-qutepart - Code editor component for PyQt and 
PySide
Owner: peter_...@yeah.net



Dear Maintainer,

I'm interested in this package and would like to pack and maintain it. thanks!





Regards,

Peter Ji

Bug#968148: /usr/bin/apt-key: Suggestion for manpage and Warning

[Vincent van Adrighem]

Package: apt
Followup-For: Bug #968148

Dear Maintainer,

Replacing the command is not what we want to achieve here, but a few
changes in the documentation would go a long way in resolving this.

Maybe changing the text from:
>   Warning: apt-key is deprecated.  Manage keyring files in
>   trusted.gpg.d instead (see apt-key(8)).
To:
>   Warning: apt-key is deprecated.  Keys can simply be downloaded and
>   managed separately in the trusted.gpg.d directory instead using
>   standard file management tools (see apt-key(8)).

And in the apt-key man-page:
>   Use of apt-key is deprecated, except for the use of apt-key del in 
> maintainer scripts to remove existing keys from the main
>   keyring. If such usage of apt-key is desired the additional installation of 
> the GNU Privacy Guard suite (packaged in gnupg) is
>   required.
To:
>   Use of apt-key is deprecated, except for the use of apt-key del in 
> maintainer scripts to remove existing keys from the main
>   keyring. If such usage of apt-key is desired the additional installation of 
> the GNU Privacy Guard suite (packaged in gnupg) is
>   required.
>   New keys can be managed separately in the trusted.gpg.d directory instead 
> using
>   standard file management tools (see apt-key(8)).
>   A replacement for "sudo apt-key add -" would be "sudo tee
>   /etc/apt/trusted.gpg.d/keyname.gpg"

Those last two lines are a nice addition because
apt-key add examples float around a lot on the web.

Thanks for maintaining the package. Hope this helps to resolve the
issue people have.

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

Bug#969460: curl: HTTP/2 response not shown on its own response line

[Dario Andres Susman]

Package: curl
Version: 7.64.0-4+deb10u1
Severity: minor

Dear Maintainer,

I was testing a website which responded on HTTP/2 and had trouble finding the 
HTTP response status code.
I noticed that the HTTP response status code was not on its own line. I was 
expecting it to be/have its own line.

I have tested this on testing with curl 7.72.0 - No improvements.

Here's the example, on stable:

dsusman@fgx-laptop:~$ curl -v https://www.southbeachofficial.com -o /dev/null
* Expire in 0 ms for 6 (transfer 0x55edba67bf70)
* Expire in 1 ms for 1 (transfer 0x55edba67bf70)
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
Expire in 0 ms for 1 (transfer 0x55edba67bf70)
* Expire in 2 ms for 1 (transfer 0x55edba67bf70)
* Expire in 0 ms for 1 (transfer 0x55edba67bf70)
* Expire in 0 ms for 1 (transfer 0x55edba67bf70)
* Expire in 2 ms for 1 (transfer 0x55edba67bf70)
* Expire in 0 ms for 1 (transfer 0x55edba67bf70)
* Expire in 0 ms for 1 (transfer 0x55edba67bf70)
* Expire in 2 ms for 1 (transfer 0x55edba67bf70)
* Expire in 0 ms for 1 (transfer 0x55edba67bf70)
* Expire in 0 ms for 1 (transfer 0x55edba67bf70)
* Expire in 2 ms for 1 (transfer 0x55edba67bf70)
* Expire in 1 ms for 1 (transfer 0x55edba67bf70)
* Expire in 1 ms for 1 (transfer 0x55edba67bf70)
* Expire in 2 ms for 1 (transfer 0x55edba67bf70)
* Expire in 1 ms for 1 (transfer 0x55edba67bf70)
* Expire in 1 ms for 1 (transfer 0x55edba67bf70)
* Expire in 2 ms for 1 (transfer 0x55edba67bf70)
* Expire in 1 ms for 1 (transfer 0x55edba67bf70)
* Expire in 1 ms for 1 (transfer 0x55edba67bf70)
* Expire in 2 ms for 1 (transfer 0x55edba67bf70)
* Expire in 2 ms for 1 (transfer 0x55edba67bf70)
* Expire in 2 ms for 1 (transfer 0x55edba67bf70)
* Expire in 2 ms for 1 (transfer 0x55edba67bf70)
* Expire in 2 ms for 1 (transfer 0x55edba67bf70)
* Expire in 2 ms for 1 (transfer 0x55edba67bf70)
* Expire in 3 ms for 1 (transfer 0x55edba67bf70)
*   Trying 104.26.15.56...
* TCP_NODELAY set
* Expire in 149995 ms for 3 (transfer 0x55edba67bf70)
* Expire in 200 ms for 4 (transfer 0x55edba67bf70)
* Connected to www.southbeachofficial.com (104.26.15.56) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [2238 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [79 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=San Francisco; O=Cloudflare, Inc.; 
CN=sni.cloudflaressl.com
*  start date: Jul 30 00:00:00 2020 GMT
*  expire date: Jul 30 12:00:00 2021 GMT
*  subjectAltName: host "www.southbeachofficial.com" matched cert's 
"*.southbeachofficial.com"
*  issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x55edba67bf70)
} [5 bytes data]
> GET / HTTP/2
> Host: www.southbeachofficial.com
> User-Agent: curl/7.64.0
> Accept: */*
> 
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [230 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [230 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
} [5 bytes data]
  0 00 00 0  0  0 --:--:--  0:00:01 --:--:-- 0< 
HTTP/2 200 -- The HTTP/2 response status code should have 
been below this line.
< date: Thu, 03 Sep 2020 11:41:56 GMT
< content-type: text/html; charset=UTF-8
< set-cookie: __cfduid=dd91e9ddaa9790284374020661682fc971599133314; 
expires=Sat, 03-Oct-20 11:41:54 GMT; path=/; domain=.southbeachofficial.com; 
HttpOnly; SameSite=Lax
< set-cookie: PHPSESSID=l7v652csa3g0e6mquf467kovo6; expires=Thu, 03-Sep-2020 
12:41:55 GMT; Max-Age=3600; path=/; domain=www.southbeachofficial.com; secure; 
HttpOnly
< pragma: no-cache
< cache-control: max-age=0, must-revalidate, no-cache, no-store
< expires: Tue, 03 Sep 2019 10:28:57 GMT
< content-security-policy-report-only: font-src 'self' 'unsafe-inline'; 
form-action geostag.cardinalcommerce.com geo.cardinalcommerce.com 
1eafstag.car

Bug#966846: Kernel panic (4.19.0-10): RIP __cgroup_bpf_run_filter_skb

[Sébastien NOBILI]

Hi Salvatore,

Le 2020-08-30 17:08, Salvatore Bonaccorso a écrit :
On Sun, Aug 30, 2020 at 04:49:51PM +0200, isch...@der-ball-ist-rund.net 
wrote:
But I'm still running two lxc-containers and two virtual machines 
kvm/qemu.


Yes, the issue would not be exclusively with docker.


I'm facing this bug as well on a server with LXC containers (no 
Docker/KVM/Qemu

at all).


The issue should be pending fixed, but if you can I would appreciate
if you can test (warning: temporary and unofficial build!) packages
rebased to 4.19.142 upstream:

https://people.debian.org/~carnil/tmp/linux/4.19.142-1/


I've installed it (amd64 version) and will let you know how things are 
going on.


Sébastien

Bug#964674: debian-reference: FTBFS: build-dependency not installable: libopencc2-data

[peter green]

Lucas Nussbaum  wrote:

> The following packages have unmet dependencies:
>  sbuild-build-depends-main-dummy : Depends: libopencc2-data but it is not 
installable
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.


Fixed in git.
Tagging this bug as pending


This bug was tagged as pending over a month ago, but is still not fixed in the 
archive.
Is there some blocker for uploading?

Bug#961345: cups: daemon crashes with invalid free()

[Bernhard Übelacker]

Am 02.09.20 um 10:20 schrieb Ronny Adsetts:
> Hi Bernhard,

> 
> Good news. I don't see any "invalid free" reports.
> 
> Can I thank you again for your time and energy in solving this. It really is 
> appreciated.
> 
> Let me know if there's anything I can do to help get this patch upstreamed.
> 
> Ronny


Hello Ronny,
that's great, I have opened an issue upstream,
let's see what they think.

Kind regards,
Bernhard

Bug#942965: Patch for closure-compiler rc bugs, possible NMU.

[peter green]

tags 942965 +patch
tags 961839 +pending

The attached debdiff fixes bugs 942965 and 961839, the former by changing
the build-dependency from python-docutils to python3-docutils and the latter
by adding "ant.build.javac.source=8" and "ant.build.javac.target=8" to
debian/ant.properties.

If I do not get any response to this mail I will likely NMU this later.
diff -Nru closure-compiler-20130227+dfsg1/debian/ant.properties 
closure-compiler-20130227+dfsg1/debian/ant.properties
--- closure-compiler-20130227+dfsg1/debian/ant.properties   2017-09-12 
13:12:47.0 +
+++ closure-compiler-20130227+dfsg1/debian/ant.properties   2020-09-03 
12:30:30.0 +
@@ -1,2 +1,4 @@
 build.svnVersion = 20130227
 lib.dir=/usr/share/java
+ant.build.javac.source=8
+ant.build.javac.target=8
diff -Nru closure-compiler-20130227+dfsg1/debian/changelog 
closure-compiler-20130227+dfsg1/debian/changelog
--- closure-compiler-20130227+dfsg1/debian/changelog2017-09-12 
14:18:28.0 +
+++ closure-compiler-20130227+dfsg1/debian/changelog2020-09-03 
12:32:03.0 +
@@ -1,3 +1,12 @@
+closure-compiler (20130227+dfsg1-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Set Java source and target versions to 8 (Closes: 961839)
+  * Replace build-dependency on python-docutils with python3-docutils
+(Closes: 942965)
+
+ -- Peter Michael Green   Thu, 03 Sep 2020 12:32:03 +
+
 closure-compiler (20130227+dfsg1-10) unstable; urgency=medium
 
   * Team upload.
diff -Nru closure-compiler-20130227+dfsg1/debian/control 
closure-compiler-20130227+dfsg1/debian/control
--- closure-compiler-20130227+dfsg1/debian/control  2017-09-12 
14:17:54.0 +
+++ closure-compiler-20130227+dfsg1/debian/control  2020-09-03 
12:30:44.0 +
@@ -18,7 +18,7 @@
 ant,
 libjarjar-java,
 protobuf-compiler,
-python-docutils,
+python3-docutils,
 javahelper (>= 0.25)
 Build-Depends-Indep: default-jdk-doc, libmaven-javadoc-plugin-java
 Standards-Version: 4.1.0

Bug#961345: cups: daemon crashes with invalid free()

[Ronny Adsetts]

Bernhard Übelacker wrote on 03/09/2020 13:42:
> 
> that's great, I have opened an issue upstream, let's see what they
> think.

Thanks. I'll monitor the issue.

Ronny

-- 
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com

Registered office: 85 Waldegrave Park, Twickenham, TW1 4TJ
Registered in England. Company No. 4042957




signature.asc
Description: OpenPGP digital signature

Bug#969462: elpa-pdf-tools: annotation editing broken with emacs 27.1

[David Bremner]

Package: elpa-pdf-tools
Version: 0.90-3
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The function display-buffer-split-below-and-attach in pdf-utils.el
calls the (presumably internal) function window--display-buffer with 5
arguments, when it expects 3 to 4 in emacs 27.1.

This is fixed upstream. Probably we should update to a git snapshot
(it's been about 18 months since 0.90 was tagged).

Unfortunately a simple update to the latest from upstream git failed
for me because of apparent changes to the upstream build system.

What did work for me was just replacing the definition of
display-buffer-split-below-and-attach with the one from upstream master.

Let me know if you intend to update pdf-tools to a new upstream
version. If not I (or someone) can upload a patched version of 0.90

- --
To reproduce

1) start emacs -q
(load-library "pdf-tools-autoloads")
(pdf-tools-install)
2) make an annotation (I tried text and highlight style). Try to activate it. 
Observe the error message

   display-buffer-split-below-and-attach: Wrong number of arguments: (3 . 4), 5

3) replace the definition of display-buffer-split-below-and-attach

(defun display-buffer-split-below-and-attach (buf alist)
  "Display buffer action using `pdf-util-window-attach'."
  (let ((window (selected-window))
(height (cdr (assq 'window-height alist)))
newwin)
(when height
  (when (floatp height)
(setq height (round (* height (frame-height)
  (setq height (- (max height window-min-height
(setq newwin (window--display-buffer
  buf
  (split-window-below height)
  'window alist))
(pdf-util-window-attach newwin window)
newwin))

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

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

Versions of packages elpa-pdf-tools depends on:
ii  elpa-let-alist 1.0.6-2
ii  elpa-pdf-tools-server  0.90-3+b1
ii  elpa-tablist   1.0-1
ii  emacs  1:27.1+1-1
ii  emacs-gtk [emacs]  1:27.1+1-1
ii  emacsen-common 3.0.4

elpa-pdf-tools recommends no packages.

elpa-pdf-tools suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl9Q6+EACgkQA0U5G1Wq
FSE6DQ//V1BNssr3PIKzbPdOVKyAkyAnG67fwmvUpUVo6jDcsGjg51VAHzdwXf4o
+unjqCDksZtdToJRw91AeidLAirnXvntPc834V9AG9qSRjjxPId2JdTlhaH4BMy1
A5HiFgDkhSc2Y2NLwa7RSABnGpK2kyEFDzZGnUexygcb25lZiF7xXCKDGNeaR620
psIyf+dMS6EOtW1C+SEEf9e8fAnqhsm37+beENBtlqlcEdSdapAbStAiosiWwT62
TAudI5SD6OFAAKFOpjo/nab4VzYh4xczMch+yxGmCe4833ckb9S5xOdY+NbgPEVn
rNKTYLGj3IvEbeUn7dbKZpMYvsKTiLYjzYL2ROwIV+UE3rBsv2t3l04zE6pwY8JF
+g9rXUE0GAjY4l15NLxmZ4guu9kQ6NN/jKTyKbaijQ2UCWBm13bVTW80EBecjniJ
uAkuZgvl6+kZJ/8fQ5uosDoquASPH7h+XIW1HDPvMvmJZ37C/0WkRttsvUNLCci4
9/GmT+kAotlmfOSEx9j5iGOmHwdsUaERvuljdqp++24gNMGTAczf4jzrSALYS8zP
27HHWAACMYiy8nECt6eusyjhFKsgPIG3YqRB34o0vfXdjEfDeE875rGdklfropkO
1Ufhp8TalE4El0iGEKxWJ8AcUPXB/tQ8FpV1q73H2ZnL5+Eujbw=
=Y+Dl
-END PGP SIGNATURE-

Bug#966825: transition: libcdio

[Mattia Rizzolo]

On Thu, Sep 03, 2020 at 06:49:54AM +, Vasyl Gello wrote:
> Hi Gabriel!
> 
> If I understand the info from tracker.d.o correctly, libcdio 2.1.0-2 migrated 
> to testing and transition is complete, isn't it?
> If that's true, can you please push buster backport?

That has nothing to do with the release team (i.e. this bug report), so
please ask in a different forum.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#969463: rsync: fails reproducible but unexplained on a specific volume, breaks horribly when started by BackupPC

[Andreas Feldner]

Package: rsync
Version: 3.2.3-2
Severity: important

Dear Maintainer,

   * What led up to the situation?

I believe the problem started with the latest update of the rsync package end
of 08/2020. A previously working setup of backuppc reproducibly fails for a
specific host and specific directory tree since then.

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

I repeatedly restarted the backup from BackupPC, all failing.
I conducted a test rsynch over ssh directly without BackupPC, all failing.
I checked dmesg for indications of lower level problems, there are none.

   * What was the outcome of this action?

1) With BackupPC

-- Output of
/usr/share/backuppc/bin/BackupPC_zcat 
/var/lib/backuppc/pc/localhost/XferLOG.z|grep -v -a '^  '
full backup started for directory /var/lib/lxc (baseline backup #131)
Running: /usr/bin/ssh -q -x -l root localhost /usr/bin/rsync --server --sender 
--numeric-ids \
 --perms --owner --group -D --links --hard-links --times --block-size=2048 
--recursive \
 --one-file-system --ignore-times . /var/lib/lxc/
Xfer PIDs are now 77976
Got remote protocol 31
Negotiated protocol version 28
Sent exclude: tmp
Sent exclude: temp
Sent exclude: *Trash*
Sent exclude: trash*
Sent exclude: backup*
Sent exclude: *.bak
Sent exclude: *.tmp
Xfer PIDs are now 77976,78855
Remote[-7]:
Remote[98]: <>
-- end of filtered log


-- Another run, the output looks like:
incr backup started back to 2020-08-19 22:00:03 (backup #127) for directory 
/var/lib/lxc
Running: /usr/bin/ssh -q -x -l root localhost /usr/bin/rsync --server --sender 
--numeric-ids --perms --owner --group -D --links --hard-links --times 
--block-size=2048 --recursive --one-file-system . /var/lib/lxc/
Xfer PIDs are now 23770
Got remote protocol 31
Negotiated protocol version 28
Sent exclude: tmp
Sent exclude: temp
Sent exclude: *Trash*
Sent exclude: trash*
Sent exclude: backup*
Sent exclude: *.bak
Sent exclude: *.tmp
Xfer PIDs are now 23770,24835
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[41]: 
^@^G^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
Remote[-7]:
<< thousands of identical lines>>
<<...binary garbage>>
-- 



Finally, rsync (and BackupPC_dump) just hang around each waiting for something 
to happen:

-- Output of strace on rsync's PID:
strace: Process 23781 attached
select(2, [], [1], [], {tv_sec=35, tv_usec=526085}) = 0 (Timeout)
select(2, [], [1], [], {tv_sec=60, tv_usec=0}) = 0 (Timeout)
select(2, [], [1], [], {tv_sec=60, tv_usec=0}) = 0 (Timeout)
select(2, [], [1], [], {tv_sec=60, tv_usec=0}^Cstrace: Process 23781 detached
 
--

It is required to stop the BackupPC service, or to manually kill BackupPC_dump 
and/or rsync.




2) rsync test run

-- rsync stdout
opening connection using: ssh -l root localhost rsync --server --sender 
-vvvlHogDtprxe.iLsfxCIvu -B2048 --numeric-ids . /var/lib/lxc  (12 args)
receiving incremental file list
server_sender starting pid=144226
[sender] make_file(lxc,*,0)
send_file_list done
[sender] pushing local filters for /var/lib/lxc/
<>
got file_sum
set modtime, atime of lxc/nextcloud/rootfs/var/backups/.gshadow.bak.vcUsMX to 
(1596971541) 2020/08/09 13:12:21, (1599125234) 2020/09/03 11:27:14
renaming lxc/nextcloud/rootfs/var/backups/.gshadow.bak.vcUsMX to 
lxc/nextcloud/rootfs/var/backups/gshadow.bak
recv_files(lxc/nextcloud/rootfs/var/backups/nextcloud-dir_20200119.tar)
lxc/nextcloud/rootfs/var/backups/nextcloud-dir_20200119.tar
[receiver] _exit_cleanup(code=13, file=log.c, line=245): about to call exit(13)
[generator] _exit_cleanup(code=13, file=io.c, line=1644): about to call exit(13)
-- end of stdout

-- rsync stderr
rsync error: errors with program diagnostics (code 13) at log.c(245) 
[receiver=3.2.3]
rsync: [generator] write error: Broken pipe (32)
-- end of stderr


3) tar file generation
...just worked

   * What outcome did you expect instead?

A copy of the source directory tree at the destination ;-)



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

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

Versions of p

Bug#969222: cyrus-caldav: hhtp keep 100% CPU after access with Thunderbird

[rollop...@gmail.com]

Is the same problem of bug #961600 
Seems to be a problem with http2 support, but apparently it needs to be
disabled during compilation, I have not found a way to disable it with
the package :-(

Gabriel Rolland

Bug#969464: src:r-cran-brms: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: r-cran-brms
Version: 2.12.0-2
Severity: serious
Control: close -1 2.13.3-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:r-cran-brms
in unstable has been trying to migrate for more than 70 days [2]. Hence,
I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=r-cran-brms




signature.asc
Description: OpenPGP digital signature

Bug#969465: O: libquvi-scripts -- library for parsing video download links (Lua scripts)

[Alejandro Garrido Mota]

Package: wnpp
Severity: normal

Unfortunately, I'm not using this package anymore. Also, checking at [0]
looks it is not maintained anymore.



The package description is:
 libquvi is a library to parse Adobe flash video download links. It
 supports Youtube and other similar video websites. It provides access
 to functionality and data through an API, and does not enable or
 require the use of the flash technology.
 .
 This package contains the Lua scripts used to parse documents.

[0] http://quvi.sourceforge.net/r/dev/source/repos/

Bug#961600: Workaround

[rollop...@gmail.com]

As a workaround I tried setting the "network.http.spdy.enabled.http2"
value to false in Thunderbird and it seems to work for now

Gabriel Rolland

Bug#942965: Patch for closure-compiler rc bugs, possible NMU.

[tony mancill]

Hi Peter,

If you have fixes for closure-compiler, please feel free to go ahead and
NMU.  I will pick up the changes and apply them to the packaging repo
from the NMU.

Thank you for helping with this,
tony

On Thu, Sep 03, 2020 at 02:05:03PM +0100, peter green wrote:
> tags 942965 +patch
> tags 961839 +pending
> 
> The attached debdiff fixes bugs 942965 and 961839, the former by changing
> the build-dependency from python-docutils to python3-docutils and the latter
> by adding "ant.build.javac.source=8" and "ant.build.javac.target=8" to
> debian/ant.properties.
> 
> If I do not get any response to this mail I will likely NMU this later.

> diff -Nru closure-compiler-20130227+dfsg1/debian/ant.properties 
> closure-compiler-20130227+dfsg1/debian/ant.properties
> --- closure-compiler-20130227+dfsg1/debian/ant.properties 2017-09-12 
> 13:12:47.0 +
> +++ closure-compiler-20130227+dfsg1/debian/ant.properties 2020-09-03 
> 12:30:30.0 +
> @@ -1,2 +1,4 @@
>  build.svnVersion = 20130227
>  lib.dir=/usr/share/java
> +ant.build.javac.source=8
> +ant.build.javac.target=8
> diff -Nru closure-compiler-20130227+dfsg1/debian/changelog 
> closure-compiler-20130227+dfsg1/debian/changelog
> --- closure-compiler-20130227+dfsg1/debian/changelog  2017-09-12 
> 14:18:28.0 +
> +++ closure-compiler-20130227+dfsg1/debian/changelog  2020-09-03 
> 12:32:03.0 +
> @@ -1,3 +1,12 @@
> +closure-compiler (20130227+dfsg1-10.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Set Java source and target versions to 8 (Closes: 961839)
> +  * Replace build-dependency on python-docutils with python3-docutils
> +(Closes: 942965)
> +
> + -- Peter Michael Green   Thu, 03 Sep 2020 12:32:03 
> +
> +
>  closure-compiler (20130227+dfsg1-10) unstable; urgency=medium
>  
>* Team upload.
> diff -Nru closure-compiler-20130227+dfsg1/debian/control 
> closure-compiler-20130227+dfsg1/debian/control
> --- closure-compiler-20130227+dfsg1/debian/control2017-09-12 
> 14:17:54.0 +
> +++ closure-compiler-20130227+dfsg1/debian/control2020-09-03 
> 12:30:44.0 +
> @@ -18,7 +18,7 @@
>  ant,
>  libjarjar-java,
>  protobuf-compiler,
> -python-docutils,
> +python3-docutils,
>  javahelper (>= 0.25)
>  Build-Depends-Indep: default-jdk-doc, libmaven-javadoc-plugin-java
>  Standards-Version: 4.1.0

> __
> This is the maintainer address of Debian's Java team
> .
>  Please use
> debian-j...@lists.debian.org for discussions and questions.



signature.asc
Description: PGP signature

Bug#942965: Patch for closure-compiler rc bugs, possible NMU.

[peter green]

On 03/09/2020 14:45, tony mancill wrote:

Hi Peter,

If you have fixes for closure-compiler, please feel free to go ahead and
NMU.  I will pick up the changes and apply them to the packaging repo
from the NMU.

NMU uploaded.


Thank you for helping with this,
tony

On Thu, Sep 03, 2020 at 02:05:03PM +0100, peter green wrote:

tags 942965 +patch
tags 961839 +pending

The attached debdiff fixes bugs 942965 and 961839, the former by changing
the build-dependency from python-docutils to python3-docutils and the latter
by adding "ant.build.javac.source=8" and "ant.build.javac.target=8" to
debian/ant.properties.

If I do not get any response to this mail I will likely NMU this later.



diff -Nru closure-compiler-20130227+dfsg1/debian/ant.properties 
closure-compiler-20130227+dfsg1/debian/ant.properties
--- closure-compiler-20130227+dfsg1/debian/ant.properties   2017-09-12 
13:12:47.0 +
+++ closure-compiler-20130227+dfsg1/debian/ant.properties   2020-09-03 
12:30:30.0 +
@@ -1,2 +1,4 @@
  build.svnVersion = 20130227
  lib.dir=/usr/share/java
+ant.build.javac.source=8
+ant.build.javac.target=8
diff -Nru closure-compiler-20130227+dfsg1/debian/changelog 
closure-compiler-20130227+dfsg1/debian/changelog
--- closure-compiler-20130227+dfsg1/debian/changelog2017-09-12 
14:18:28.0 +
+++ closure-compiler-20130227+dfsg1/debian/changelog2020-09-03 
12:32:03.0 +
@@ -1,3 +1,12 @@
+closure-compiler (20130227+dfsg1-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Set Java source and target versions to 8 (Closes: 961839)
+  * Replace build-dependency on python-docutils with python3-docutils
+(Closes: 942965)
+
+ -- Peter Michael Green   Thu, 03 Sep 2020 12:32:03 +
+
  closure-compiler (20130227+dfsg1-10) unstable; urgency=medium
  
* Team upload.

diff -Nru closure-compiler-20130227+dfsg1/debian/control 
closure-compiler-20130227+dfsg1/debian/control
--- closure-compiler-20130227+dfsg1/debian/control  2017-09-12 
14:17:54.0 +
+++ closure-compiler-20130227+dfsg1/debian/control  2020-09-03 
12:30:44.0 +
@@ -18,7 +18,7 @@
  ant,
  libjarjar-java,
  protobuf-compiler,
-python-docutils,
+python3-docutils,
  javahelper (>= 0.25)
  Build-Depends-Indep: default-jdk-doc, libmaven-javadoc-plugin-java
  Standards-Version: 4.1.0



__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#969457: libvirt-daemon-system: Cannot hot attach NIC

[Sander Klein]

Package: libvirt-daemon-system
Version: 5.0.0-4+deb10u1
Severity: important

Dear Maintainer,

It seems apparmor is denying the hot attach of a NIC to a VM. While trying
to attach a NIC I get:

audit: type=1400 audit(1599123343.785:152): apparmor="DENIED" 
operation="file_receive" profile="libvirt-87dd6694-43b6-4f40-a62f-fa71525467ab" 
name="/dev/vhost-net" pid=16384 comm="qemu-system-x86" requested_mask="wr" 
denied_mask="wr" fsuid=9869 ouid=0

After investigating I found that adding '/dev/vhost-net rw,' to
'/etc/apparmor.d/abstractions/libvirt-qemu' fixes the issue.

Looking at the Ubuntu version of this file it seems that more hotplugging
is not working. They have added:

  # for vhost-net/vsock/scsi hotplug (LP: #1815910)
  /dev/vhost-net rw,
  /dev/vhost-vsock rw,
  /dev/vhost-scsi rw,

Could this be added to the package?

Regards,

Sander Klein



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

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  gettext-base   0.19.8.1-9
ii  iptables   1.8.2-4
ii  libacl12.2.53-4
ii  libapparmor1   2.13.2-10
ii  libaudit1  1:2.8.4-3
ii  libblkid1  2.33.1-0.1
ii  libc6  2.28-10
ii  libcap-ng0 0.7.9-2
ii  libdbus-1-31.12.20-0+deb10u1
ii  libdevmapper1.02.1 2:1.02.155-3
ii  libgnutls303.6.7-4+deb10u5
ii  libnl-3-2003.4.0-1
ii  libnl-route-3-200  3.4.0-1
ii  libnuma1   2.0.12-1
ii  libselinux12.8-1+b1
ii  libvirt-clients5.0.0-4+deb10u1
ii  libvirt-daemon 5.0.0-4+deb10u1
ii  libvirt0   5.0.0-4+deb10u1
ii  libxml22.9.4+dfsg1-7+b3
ii  libyajl2   2.1.0-3
ii  logrotate  3.14.0-4
ii  lsb-base   10.2019051400
ii  policykit-10.105-25

Versions of packages libvirt-daemon-system recommends:
ii  dmidecode3.2-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  iproute2 4.20.0-2
ii  parted   3.2-25

Versions of packages libvirt-daemon-system suggests:
ii  apparmor2.13.2-10
pn  auditd  
ii  nfs-common  1:1.3.4-2.5+deb10u1
pn  open-iscsi  
pn  pm-utils
pn  radvd   
ii  systemd 241-7~deb10u4
pn  systemtap   
pn  zfsutils

-- Configuration Files:
/etc/libvirt/nwfilter/allow-arp.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-arp.xml'
/etc/libvirt/nwfilter/allow-dhcp-server.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-dhcp-server.xml'
/etc/libvirt/nwfilter/allow-dhcp.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-dhcp.xml'
/etc/libvirt/nwfilter/allow-incoming-ipv4.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-incoming-ipv4.xml'
/etc/libvirt/nwfilter/allow-ipv4.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-ipv4.xml'
/etc/libvirt/nwfilter/clean-traffic-gateway.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/clean-traffic-gateway.xml'
/etc/libvirt/nwfilter/clean-traffic.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/clean-traffic.xml'
/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-arp-spoofing.xml'
/etc/libvirt/nwfilter/no-ip-multicast.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-ip-multicast.xml'
/etc/libvirt/nwfilter/no-ip-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-mac-broadcast.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-mac-broadcast.xml'
/etc/libvirt/nwfilter/no-mac-spoofing.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-other-l2-traffic.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-other-l2-traffic.xml'
/etc/libvirt/nwfilter/no-other-rarp-traffic.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/no-other-rarp-traffic.xml'
/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml'
/etc/libvirt/nwfilter/qemu-announce-self.xml [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/qemu-announce-self.xml'
/etc/libvirt/qemu.conf [Errno 13] Permission denied: '/etc/libvirt/qemu.conf'
/

Bug#947979: enchant -> enchant-2 transition: Time to purge enchant(1)?

[Boyuan Yang]

X-Debbugs-CC: g...@debian.org elb...@debian.org bi...@debian.org

On Thu, 4 Jun 2020 14:08:24 +0200 Paul Gevers 
wrote:
> # We don't want to ship two enchants in bullseye. Dear maintainers,
> # you can lower the severity until December 2020 if you have a plan
to
> # fix the issue before the bullseye transition freeze, but please
> # document that in the bug in case you do.

Now, according to 
https://release.debian.org/transitions/html/enchant-2.html , package
xenur ( https://tracker.debian.org/pkg/xneur ) is the last package that
(build-)depends on enchant(1). This package has been under FTBFS status
due to GCC-10 since July and was removed in Testing.

I believe we can make some early move and remove enchant(1) from Sid
(and natually Testing) now. Alexander: if you still need enchant(1)
these months, please let me know; this removal can be postponed till
December 2020 (but will surely happen after that). Otherwise I am
looking into opening a RM bug against FTP Masters about 1 week later
and finally finish this longlasting transition.

Let me know if you have any comments.

-- 
Regards,
Boyuan Yang


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

Bug#950895: closed by Bernhard Übelacker (Re: Bug#950895: freecad: autopkgtest fails on arm64 but not on amd64)

[Lisandro Damián Nicanor Pérez Meyer]

> From: "Bernhard Übelacker" 
> To: 950895-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 3 Sep 2020 15:49:17 +0200
> Subject: Re: Bug#950895: freecad: autopkgtest fails on arm64 but not on amd64
> Dear Maintainer,
> it seems the tests started to succeed here again:
>   2020-02-10 03:43:32 UTC
>
> The logs from before seem to have been deleted.
>
> In the last two months are no failures shown for
> freecad testing at arm64.
>
> Therefore I hope it is ok then to close.

Without really knowing what was really happening? Well, at least mark
the test as flaky if if starts failing "with no reason" again.

Bug#969466: btrfs-progs: strace'ing btrfs instantly and silently breaks operation

[Marc Lehmann]

Package: btrfs-progs
Version: 5.6-1
Severity: normal

Dear Maintainer,

on at least some operations, e.g. "btrfs fi def somefile", attaching
strace to the btrfs process instantly cancels the current operation
without any error message or other indication that it has not done its
job.

obviously, I would expect that strace'ing btrfs would not affect the
correctness of its operation.

-- System Information:
Debian Release: 10.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), 
(500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 
'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

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

Versions of packages btrfs-progs depends on:
ii  libblkid12.33.1-0.1
ii  libc62.30-4
ii  libcom-err2  1.45.6-1
ii  libext2fs2   1.45.6-1
ii  liblzo2-22.10-0.1
ii  libuuid1 2.33.1-0.1
ii  libzstd1 1.4.5+dfsg-4
ii  zlib1g   1:1.2.11.dfsg-1

btrfs-progs recommends no packages.

Versions of packages btrfs-progs suggests:
pn  duperemove  

-- no debconf information

Bug#962477: artha: Please migrate away from enchant(1) to enchant-2

[Boyuan Yang]

Control: fixed 962477 1.0.5-2

Thanks for the quick fix!

-- 
Regards,
Boyuan Yang

On Thu, 3 Sep 2020 18:00:06 +0530 Nilesh  wrote:
> Hi,
> 
> On Wed, 02 Sep 2020 20:32:19 -0400 Boyuan Yang 
wrote:
> 
> > X-Debbugs-CC: npatra...@gmail.com legend...@yahoo.com
> >
> > Hi,
> >
> > On Mon, 27 Jul 2020 18:34:50 + (UTC) Sundaram
>  wrote:
> > > Hi BoyuanThanks for reporting this!
> > > Artha 1.0.5, released today, the optional dependency of
libenchant
> has been
> > bumped from 1 to 2.
> > > Regards!Sundaram
> >
> > Thanks for providing this information. I see that there was a
> artha/1.0.5-1
> > upload but the recommendation to package libenchant1c2a was still
in
> the new
> > version. Can we fix this problem soon (ideally before Debian 11
soft
> freeze)?
> 
> Thanks a lot for your investigation on this, I've fixed this with the
> next upload - hence closing the bug.
> Do let me know if there's something else you'd like to be done for
this
> package.
> 
> Kind Regards,
> Nilesh
> 
> 
> 
> 


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

Bug#969463: rsync: fails reproducible but unexplained on a specific volume, breaks horribly when started by BackupPC

[Paul Slootman]

On Thu 03 Sep 2020, Andreas Feldner wrote:

> 2) rsync test run
> 
> -- rsync stdout
> opening connection using: ssh -l root localhost rsync --server --sender 
> -vvvlHogDtprxe.iLsfxCIvu -B2048 --numeric-ids . /var/lib/lxc  (12 args)

How are you invoking rsync? Please give the exact command line,
including what you current working directory is.

Are you actually using ssh to connect to localhost and transferring the
data over that ssh link?
If so, then these lines are very strange in the case (1) text:

> Got remote protocol 31
> Negotiated protocol version 28

I would expect an rsync to negotiate the highest protocol version
possible, so this looks like it's talking to a newer version than
itself.

> receiving incremental file list
> server_sender starting pid=144226
> [sender] make_file(lxc,*,0)
> send_file_list done
> [sender] pushing local filters for /var/lib/lxc/
> <>
> got file_sum
> set modtime, atime of lxc/nextcloud/rootfs/var/backups/.gshadow.bak.vcUsMX to 
> (1596971541) 2020/08/09 13:12:21, (1599125234) 2020/09/03 11:27:14
> renaming lxc/nextcloud/rootfs/var/backups/.gshadow.bak.vcUsMX to 
> lxc/nextcloud/rootfs/var/backups/gshadow.bak
> recv_files(lxc/nextcloud/rootfs/var/backups/nextcloud-dir_20200119.tar)
> lxc/nextcloud/rootfs/var/backups/nextcloud-dir_20200119.tar
> [receiver] _exit_cleanup(code=13, file=log.c, line=245): about to call 
> exit(13)
> [generator] _exit_cleanup(code=13, file=io.c, line=1644): about to call 
> exit(13)
> -- end of stdout
> 
> -- rsync stderr
> rsync error: errors with program diagnostics (code 13) at log.c(245) 
> [receiver=3.2.3]
> rsync: [generator] write error: Broken pipe (32)
> -- end of stderr

Because of the "errors with program diagnostics" I would have expected
more messages...

It would be most helpful if you could follow the instructions on
https://rsync.samba.org/issues.html especially de second half of
question 3.


Paul

Bug#960788: ITP: alsa-sof-firmware -- Intel SOF audio firmware and topology

[Jordi Mallach]

Hi,

El dj. 03 de 09 de 2020 a les 08:11 +0200, en/na intrigeri va escriure:
> Hi Jordi,
> 
> I see you took responsibility for this ITP a few months ago.
> 
> Are you in a position to share a rough timeline?

After claiming it and looking at the source, I resolved this probably
belongs as part of linux-firmware or whatever the source name is, as
Ubuntu did. zumbi@ has been talking to the kernel people about this but
right now I'm unsure what the status is.

Jordi
-- 
Jordi Mallach 
Debian Project

Bug#969445: RFS: vguitar-2.6 [ITP] -- Play Guitar in any term window. Use with a MIDI synthesizer (qsynth).

[Boyuan Yang]

Control: close 969445
Control: tags -1 +moreinfo

Hi Nick,

Thanks for your interest in getting software into Debian. Some
comments:

* Since you submitted two duplicated RFS requests, I am closing one of
them to make sure that there are no duplications.

* I reviewed the package you provided and found that you only provided
the binary package (.deb) for amd64 architecture, which is not
acceptable at this moment. In order to make the software into Debian,
you will have to provide the source package (.dsc file and related
source tarballs) so that Debian can review the source code of such
software as well as build the binary packages for other officially-
supported architectures (i386, arm* etc.). Please follow the
instruction texts in https://mentors.debian.net/intro-maintainers/ and
prepare your Debian source package properly.

Please fix the problems mentioned above and let people know when it's
ready again by replying your RFS report at 
https://bugs.debian.org/969446 .

-- 
Thanks,
Boyuan Yang


On Thu, 03 Sep 2020 02:43:22 + Nick Strauss <
nick.stra...@rocketmail.com> wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear Mentor/Maintainer,
> 
> Package name: vguitar
> Version : 2.5
> Upstream Author : 
> URL : http://nick-strauss.com
> License : GPL
> 
> apt-key adv --keyserver keyserver.ubuntu.com --recv-keys AB406C34
> add to /etc/apt/sources.list.d
> deb [ arch=amd64 ] http://apt.nick-strauss.com/apt/debian jessie main
> apt-get install vguitar
> 
> vguitar --help
> man vguitar
> 
> -- System Information:
> Debian Release: 8.4
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'oldoldstable'),
(500, 'oldstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.4.55-1-pve (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to fr_FR.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)


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

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

[Mark Hindley]

Dmitry,

With the upload of systemctl/1.4.4181-1.1, this issue is no longer evident.

Are you happy for me to reassign #959920 to systemctl so it can be closed with
the appropriate fixed version?

Thanks

Mark

Bug#969459: RFS: python-jsbeautifier/1.13.0-1 -- JavaScript unobfuscator and beautifier

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-jsbeautifier":

 * Package name: python-jsbeautifier
   Version : 1.13.0-1
   Upstream Author : Liam Newman, Einar Lielmanis, et al.

 * URL : https://github.com/beautify-web/js-beautify
 * License : MIT
 * Vcs : https://salsa.debian.org/debian/python-jsbeautifier
   Section : python

It builds those binary packages:

  jsbeautifier - JavaScript unobfuscator and beautifier
  python3-jsbeautifier - JavaScript unobfuscator and beautifier (python3)

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

  https://mentors.debian.net/package/python-jsbeautifier/

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-jsbeautifier/python-jsbeautifier_1.13.0-1.dsc

Changes since the last upload:

 python-jsbeautifier (1.13.0-1) unstable; urgency=medium
 .
   * New upstream version 1.13.0
   * Rebase patch
   * Bump debhelper to 13

Regards,
Håvard

Bug#969467: miller: CVE-2020-15167

[Salvatore Bonaccorso]

Source: miller
Version: 5.9.0-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for miller.

CVE-2020-15167[0]:
| In Miller (command line utility) using the configuration file support
| introduced in version 5.9.0, it is possible for an attacker to cause
| Miller to run arbitrary code by placing a malicious `.mlrrc` file in
| the working directory. See linked GitHub Security Advisory for
| complete details. A fix is ready and will be released as Miller 5.9.1.


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-15167
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15167
[1] https://github.com/johnkerl/miller/security/advisories/GHSA-mw2v-4q78-j2cw

Regards,
Salvatore

Bug#969469: ITP: libtrapperkeeper-authorization-clojure -- authorization service for use with the trapperkeeper service framework

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libtrapperkeeper-authorization-clojure
  Version : 1.0.0
  Upstream Author : Puppet Labs Inc 
* URL : https://github.com/puppetlabs/trapperkeeper-authorization
* License : Apache-2.0
  Programming Lang: Clojure
  Description : authorization service for use with the trapperkeeper 
service framework

 This project provides an authorization service for use with the trapperkeeper
 service framework. It aims to port Puppet's auth.conf feature to Clojure and
 the trapperkeeper framework, with a different way to express authorization
 rules.

This is part of the dependency chain for packaging Puppet 6.

Bug#969468: lintian: Can't opendir(/dev/.lxd-mounts): Permission denied

[Julian Andres Klode]

Package: lintian
Version: 2.92.0
Severity: important


lintian 2.92.0 is broken inside a lxd container:

$ lxc exec debian -- sudo -iu jak env -C $PWD lintian apt_2.1.1.dsc 
Can't opendir(/dev/.lxd-mounts): Permission denied
 at /usr/share/perl/5.30/File/Find.pm line 387.
File::Find::_find_dir(HASH(0x55f401c79d48), "/dev", 8) called at 
/usr/share/perl/5.30/File/Find.pm line 236
File::Find::_find_opt(HASH(0x55f401c79d48), "/dev") called at 
/usr/share/perl/5.30/File/Find.pm line 760
File::Find::find(HASH(0x55f401c79d48), "/dev") called at 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Proc/ProcessTable.pm line 162

Proc::ProcessTable::_get_tty_list(Proc::ProcessTable=HASH(0x55f401c79cd0)) 
called at /usr/lib/x86_64-linux-gnu/perl5/5.30/Proc/ProcessTable.pm line 136
Proc::ProcessTable::initialize(Proc::ProcessTable=HASH(0x55f401c79cd0)) 
called at /usr/lib/x86_64-linux-gnu/perl5/5.30/Proc/ProcessTable.pm line 79
Proc::ProcessTable::new("Proc::ProcessTable") called at 
/usr/share/lintian/bin/../lib/Lintian/Pool.pm line 250
Lintian::Pool::process(Lintian::Pool=HASH(0x55f3fb8493c8), 
Lintian::Profile=HASH(0x55f3fd1cfbc0), SCALAR(0x55f3fd229fb8), 
HASH(0x55f3fd21c510), GLOB(0x55f3fabd0560), 
Lintian::Output::EWI=HASH(0x55f3fbca3388)) called at /usr/bin/lintian line 761

This makes it fail its autopkgtest test suite on Ubuntu armhf:

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/armhf/l/lintian/20200829_110043_f9a6a@/log.gz

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#947979: enchant -> enchant-2 transition: Time to purge enchant(1)?

[Alexander Gerasiov]

On Thu, 03 Sep 2020 10:25:01 -0400
Boyuan Yang  wrote:

> X-Debbugs-CC: g...@debian.org elb...@debian.org bi...@debian.org
> 
> On Thu, 4 Jun 2020 14:08:24 +0200 Paul Gevers 
> wrote:
> > # We don't want to ship two enchants in bullseye. Dear maintainers,
> > # you can lower the severity until December 2020 if you have a
> > plan  
> to
> > # fix the issue before the bullseye transition freeze, but please
> > # document that in the bug in case you do.  
> 
> Now, according to 
> https://release.debian.org/transitions/html/enchant-2.html , package
> xenur ( https://tracker.debian.org/pkg/xneur ) is the last package
> that (build-)depends on enchant(1). This package has been under FTBFS
> status due to GCC-10 since July and was removed in Testing.
> 
> I believe we can make some early move and remove enchant(1) from Sid
> (and natually Testing) now. Alexander: if you still need enchant(1)
> these months, please let me know; this removal can be postponed till
> December 2020 (but will surely happen after that). Otherwise I am
> looking into opening a RM bug against FTP Masters about 1 week later
> and finally finish this longlasting transition.
Sorry for the delay, I'll take a look on the package later, but feel
free to remove enchant.

-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: a...@gerasiov.net  WWW: https://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Bug#969462: elpa-pdf-tools: annotation editing broken with emacs 27.1

[Lev Lamberov]

Hi,

I can confirm the problem. When trying to add new annotation I'm getting
wrong-number-of-arguments error. Please, find the debug log below:

Debugger entered--Lisp error: (wrong-number-of-arguments (3 . 4) 5)
  window--display-buffer(# # window ((inhibit-same-window . t) (window-height . 
0.25)) nil)
  display-buffer-split-below-and-attach(# ((inhibit-same-window . t) (window-height . 0.25)))
  display-buffer(# 
((display-buffer-reuse-window display-buffer-split-below-and-attach) 
(inhibit-same-window . t) (window-height . 0.25)))
  pdf-annot-edit-contents(((buffer . #) (page . 8) 
(edges 0.080065 0.223485 0.19281 0.25) (type . squiggly) (id . annot-8-2) 
(flags . 0) (color . "#ffa500") (contents . "") (modified 24400 57626) (label . 
"Lev Lamberov") (subject) (opacity . 1.0) (popup-edges) (popup-is-open) 
(created) (markup-edges (0.080065 0.223485 0.19281 0.25
  pdf-annot-default-activate-handler(((buffer . #) 
(page . 8) (edges 0.080065 0.223485 0.19281 0.25) (type . squiggly) (id . 
annot-8-2) (flags . 0) (color . "#ffa500") (contents . "") (modified 24400 
57626) (label . "Lev Lamberov") (subject) (opacity . 1.0) (popup-edges) 
(popup-is-open) (created) (markup-edges (0.080065 0.223485 0.19281 0.25
  pdf-annot-activate-annotation(((buffer . #) (page . 
8) (edges 0.080065 0.223485 0.19281 0.25) (type . squiggly) (id . annot-8-2) 
(flags . 0) (color . "#ffa500") (contents . "") (modified 24400 57626) (label . 
"Lev Lamberov") (subject) (opacity . 1.0) (popup-edges) (popup-is-open) 
(created) (markup-edges (0.080065 0.223485 0.19281 0.25
  pdf-annot-add-annotation(squiggly ((0.08607594936708861 0.23679060665362034 
0.1949367088607595 0.24266144814090018)) ((color . "orange") (label . "Lev 
Lamberov")) 8)
  pdf-annot-add-markup-annotation(((0.08607594936708861 0.23679060665362034 
0.1949367088607595 0.24266144814090018)) squiggly nil nil)
  pdf-annot-add-squiggly-markup-annotation(((0.08607594936708861 
0.23679060665362034 0.1949367088607595 0.24266144814090018)))
  funcall-interactively(pdf-annot-add-squiggly-markup-annotation 
((0.08607594936708861 0.23679060665362034 0.1949367088607595 
0.24266144814090018)))
  #(pdf-annot-add-squiggly-markup-annotation nil nil)
  apply(# pdf-annot-add-squiggly-markup-annotation 
(nil nil))
  call-interactively@ido-cr+-record-current-command(# 
pdf-annot-add-squiggly-markup-annotation nil nil)
  apply(call-interactively@ido-cr+-record-current-command # (pdf-annot-add-squiggly-markup-annotation nil nil))
  call-interactively(pdf-annot-add-squiggly-markup-annotation nil nil)
  command-execute(pdf-annot-add-squiggly-markup-annotation)

Regards,
Lev

Bug#969471: cryptsetup: CVE-2020-14382

[Salvatore Bonaccorso]

Source: cryptsetup
Version: 2:2.3.3-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for cryptsetup.

CVE-2020-14382[0]:
| Out-of-bounds write when validating segments

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-14382
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14382
[1] https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/102
[2] 
https://gitlab.com/cryptsetup/cryptsetup/-/commit/52f5cb8cedf22fb3e14c744814ec8af7614146c7

Regards,
Salvatore

Bug#969470: virtualbox dkms build fails against kernel 5.8.x

[S. R. Wright]

Package: virtualbox-dkms
Version: 6.1.12-dfsg-9
Kernel: 5.8.6

The dkms build fails for the current version of virtualbox-dkms and kernel 
5.8.x sources:

Building module:
cleaning build area...
make -j8 KERNELRELEASE=5.8.6 -C /usr/src/linux-5.8.6 
M=/var/lib/dkms/virtualbox/6.1.12/build...(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.8.6 (x86_64)
Consult /var/lib/dkms/virtualbox/6.1.12/build/make.log for more information.

make.log is attached.

-- sRw

DKMS make.log for virtualbox-6.1.12 for kernel 5.8.6 (x86_64)
Thu 03 Sep 2020 10:22:24 AM CDT
make: Entering directory '/usr/src/linux-5.8.6'
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/linux/SUPDrv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvGip.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvSem.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvTracer.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPLibAll.o
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/types.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvInternal.h:38,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvGip.c:33:
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/types.h:142:12: fatal error: linux/version.h: No such file or directory
  142 | #  include 
  |^
compilation terminated.
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/types.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/linux/../SUPDrvInternal.h:38,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/linux/SUPDrv-linux.c:32:
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/types.h:142:12: fatal error: linux/version.h: No such file or directory
  142 | #  include 
  |^
compilation terminated.
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvGip.o] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/types.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvInternal.h:38,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrv.c:33:
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/types.h:142:12: fatal error: linux/version.h: No such file or directory
  142 | #  include 
  |^
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/linux/SUPDrv-linux.o] Error 1
compilation terminated.
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/alloc-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/initterm-r0drv.o
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrv.o] Error 1
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/types.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvInternal.h:38,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvSem.c:33:
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/types.h:142:12: fatal error: linux/version.h: No such file or directory
  142 | #  include 
  |^
compilation terminated.
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/types.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvInternal.h:38,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvTracer.c:33:
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/types.h:142:12: fatal error: linux/version.h: No such file or directory
  142 | #  include 
  |^
compilation terminated.
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvSem.o] Error 1
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvTracer.o] Error 1
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/types.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/sup.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPLibAll.c:31:
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/types.h:142:12: fatal error: linux/version.h: No such file or directory
  142 | #  include 
  |^
compilation terminated.
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPLibAll.o] Error 1
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/initterm.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/initterm-r0drv.c:31:
/var/lib

Bug#947979: enchant -> enchant-2 transition: Time to purge enchant(1)?

[Boyuan Yang]

Hi Alexander,

在 2020-09-03星期四的 18:17 +0300，Alexander Gerasiov写道：
> On Thu, 03 Sep 2020 10:25:01 -0400
> Boyuan Yang  wrote:
> 
> > X-Debbugs-CC: g...@debian.org elb...@debian.org bi...@debian.org
> > 
> > On Thu, 4 Jun 2020 14:08:24 +0200 Paul Gevers 
> > wrote:
> > > # We don't want to ship two enchants in bullseye. Dear
> > > maintainers,
> > > # you can lower the severity until December 2020 if you have a
> > > plan  
> > to
> > > # fix the issue before the bullseye transition freeze, but please
> > > # document that in the bug in case you do.  
> > 
> > Now, according to 
> > https://release.debian.org/transitions/html/enchant-2.html ,
> > package
> > xenur ( https://tracker.debian.org/pkg/xneur ) is the last package
> > that (build-)depends on enchant(1). This package has been under
> > FTBFS
> > status due to GCC-10 since July and was removed in Testing.
> > 
> > I believe we can make some early move and remove enchant(1) from
> > Sid
> > (and natually Testing) now. Alexander: if you still need enchant(1)
> > these months, please let me know; this removal can be postponed
> > till
> > December 2020 (but will surely happen after that). Otherwise I am
> > looking into opening a RM bug against FTP Masters about 1 week
> > later
> > and finally finish this longlasting transition.
> Sorry for the delay, I'll take a look on the package later, but feel
> free to remove enchant.


Thanks, I will go ahead with the RM bug.

-- 
Regards,
Boyuan Yang

Bug#969471: [pkg-cryptsetup-devel] Bug#969471: cryptsetup: CVE-2020-14382

[Guilhem Moulin]

On Thu, 03 Sep 2020 at 17:28:27 +0200, Salvatore Bonaccorso wrote:
> The following vulnerability was published for cryptsetup.
> 
> CVE-2020-14382[0]:
> | Out-of-bounds write when validating segments

Oh, thanks Salvatore!  Missed that somehow :-(  Will get to this
tonight.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#969473: RM: enchant -- RoQA; Superceded by v2.x series; Unmaintained

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: bi...@debian.org

Dear Debian FTP Masters,

I am working to finish the transition from enchant(1) to enchant-2 [1]
and the removal of enchant(1) is the last step. According to [1] and
the transition management bug [2], the Enchant library is now provided
by src:enchant-2 and we need to remove the old src:enchant.

As seem in [1], the only reverse (build-)dependency to src:enchant is
src:xneur. I have just talked with the maintainer of src:xneur and the
maintainer agreed to look into the problem later and have enchant
removed first.

As a result, it looks like we can now go ahead. Please remove the old
src:enchant [4] library in Sid.


[1] https://release.debian.org/transitions/html/enchant-2.html
[2] https://bugs.debian.org/947979
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947979;msg=96
[4] https://tracker.debian.org/pkg/enchant

-- 
Thanks,
Boyuan Yang




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

Bug#969472: /etc/cron.daily/dpkg backs up when missing /var/lib/dpkg/arch

[David Rayna]

Package: dpkg
Version: 1.18.25

1st loop in /etc/cron.daily/dpkg treats missing file as a reason to backup.
2nd loop does handle missing files okay.

Result is without any arch file, unchanged files are backed up daily which
can be critical when the storage medium has limited life.

Adding a line in first /etc/cron.daily/dpkg loop should fix it:
...
dbfiles="arch status diversions statoverride"
for db in $dbfiles ; do
[ -e $dbdir/$db ] || continue  <<<
...

Issue may exist elsewhere, but is observed in:

$ dpkg --version
Debian 'dpkg' package management program version 1.18.25 (armhf)

$ uname -a
Linux x 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l
GNU/Linux

Raspberry PI3+
Rasbian Stretch Lite

Bug#965370: RFS: wand/0.6.2-1 -- Python interface for ImageMagick library (Python 3)

[Håvard Flaget Aasen]

søn. 2. aug. 2020 kl. 18:45 skrev Adam Borowski :
>
> On Mon, Jul 20, 2020 at 01:17:13PM +, Håvard Flaget Aasen wrote:
> >  * Package name: wand
> >Version : 0.6.2-1
>
> > Changes since the last upload:
> >
> >* New upstream version 0.6.2
> >* Set upstream metadata fields: Bug-Submit.
> >* Update salsa CI
> >  - Watch all variations of reprotest.
> >* Use spaces rather than tabs in d/copyright
> >* Rebase patches
> >* flask sphinx theme is now in the upstream repository
> >  - Remove patch and lintian-override
>
> Alas, it fails to build; during tests:
>
> === FAILURES 
> ===
>  test_artifacts 
> 
>
> def test_artifacts():
> with Image(filename='rose:') as img:
> img.artifacts['key'] = 'value'
> assert 'date:create' in img.artifacts
> assert img.artifacts['key'] == 'value'
> assert img.artifacts['novalue'] is None
> >   assert len(img.artifacts) > 0
> E   AssertionError: assert 0 > 0
> E+  where 0 = len( 0x7f064a3ce760>)
> E+where  = 
> .artifacts
>
> tests/image_properties_test.py:51: AssertionError
> === warnings summary 
> ===
> .pybuild/cpython3_3.8_wand/build/tests/color_test.py::test_user_error
>   /<>/.pybuild/cpython3_3.8_wand/build/wand/color.py:113: 
> OptionWarning: unrecognized color `not_a_color' @ 
> warning/color.c/GetColorCompliance/1057
> self.raise_exception()
>
> -- Docs: https://docs.pytest.org/en/latest/warnings.html
> = 1 failed, 538 passed, 7 skipped, 3 deselected, 2 xfailed, 1 warnings in 
> 16.48 seconds =
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁
> ⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i.
> ⠈⠳⣄
>

Thanks for the review.
I'm not entirely sure why this test failed, it was succeeding when I
uploaded it. It also looks like the current version in Debian fails
for the same test.

I uploaded a new version, and ended up disabling the testsuite during
build. This is the same testsuite that I enabled in the last release.
When the package gets uploaded I will reopen bug [#761325]

The autopkgtest is still active and seems to be more reliable.

Håvard

[#761325] https://bugs.debian.org/761325

Bug#969471: cryptsetup: CVE-2020-14382

[Milan Broz]

FYI There will be upstream stable release in a few hours fixing this.

If you are going to only backport the fix for this CVE, these master branch
git commits should be backported (the fix with followed simplification
of the validation code).

52f5cb8cedf22fb3e14c744814ec8af7614146c7
46ee71edcd13e1dad50815ad65c28779aa6f7503
752c9a52798f11d3b765b673ebaa3058eb25316e

Milan

Bug#969474: ddclient: [INTL:fr] French debconf templates translation

[Jean-Pierre Giraud]

Package: ddclient
Severity: wishlist
Tags: patch l10n

Hi!

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

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

Kind Regards

jipege


fr.po.gz
Description: application/gzip

Bug#969475: pandoc: New release available

[Thomas Clavier]

Package: pandoc
Version: 2.9.2.1-1
Severity: normal

Dear Maintainer,

The last version of pandoc work fine with revealjs 4.0 see : 
https://github.com/jgm/pandoc/issues/6431



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

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

Versions of packages pandoc depends on:
ii  libc62.31-3
ii  libffi7  3.3-4
ii  libgmp10 2:6.2.0+dfsg-6
ii  libpcre3 2:8.39-13
ii  pandoc-data  2.9.2.1-1
ii  zlib1g   1:1.2.11.dfsg-2

pandoc recommends no packages.

Versions of packages pandoc suggests:
pn  citation-style-language-styles  
pn  context 
pn  ghc 
pn  groff   
ii  libjs-mathjax   2.7.9+dfsg-1
pn  librsvg2-bin
pn  node-katex  
ii  nodejs  12.18.3~dfsg-4
pn  pandoc-citeproc 
ii  perl5.30.3-4
pn  php 
pn  python  
pn  r-base-core 
ii  ruby1:2.7+1
pn  texlive-latex-extra 
pn  texlive-latex-recommended   
pn  texlive-luatex  
pn  texlive-xetex   
pn  wkhtmltopdf 

-- no debconf information

Bug#880507: mlocate: daily cron job should be (optionally) splayed to prevent thundering herd

[Jonathan Dowland]

If #882993 is implemented (systemd support), then the default behaviour
of the systemd timer would be to splay, and you could consider this bug
addressed, assuming everyone who wanted splay is using systemd.


--
Jonathan Dowland

Bug#969470: virtualbox dkms build fails against kernel 5.8.x

[S. R. Wright]

Submitted the wrong make.log.  Attached is the correct one.

-- sRw


DKMS make.log for virtualbox-6.1.12 for kernel 5.8.6 (x86_64)
Thu 03 Sep 2020 11:12:18 AM CDT
make: Entering directory '/usr/src/linux-5.8.6'
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/linux/SUPDrv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvGip.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvSem.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvTracer.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPLibAll.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/alloc-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/initterm-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/memobj-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/mpnotification-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/powernotification-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/assert-r0drv-linux.o
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvTracer.o: warning: objtool: .text+0x7: indirect jump found in RETPOLINE build
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvTracer.o: warning: objtool: supdrvTracerProbeFireStub() is missing an ELF size annotation
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/initterm-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/mp-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/mpnotification-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/process-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/rtStrFormatKernelAddress-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/semevent-r0drv-linux.o
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o: warning: objtool: VBoxHost_RTR0MemKernelCopyFrom()+0x13: redundant CLD
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o: warning: objtool: VBoxHost_RTR0MemKernelCopyTo()+0x13: redundant CLD
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/semeventmulti-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/semfastmutex-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/semmutex-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/spinlock-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/thread-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/thread2-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/threadctxhooks-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/time-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/timer-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/generic/semspinmutex-r0drv-generic.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/alloc/alloc.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/checksum/crc32.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/checksum/ipv4.o
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/threadctxhooks-r0drv-linux.o: warning: objtool: rtThreadCtxHooksLnxSchedOut()+0x1f: call to __x86_indirect_thunk_rax() with UACCESS enabled
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/threadctxhooks-r0drv-linux.o: warning: objtool: rtThreadCtxHooksLnxSchedIn()+0x29: call to __x86_indirect_thunk_rax() with UACCESS enabled
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/checksum/ipv6.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/err/RTErrConvertFromErrno.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/err/RTErrConvertToErrno.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/err/errinfo.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/log/log.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/log/logellipsis.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/log/logrel.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/log/logrelellipsis.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/log/logcom.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/log/logformat.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/misc/RTAssertMsg1Weak.o
  CC [M] 

Bug#969476: ITP: librbac-client-clojure -- lightweight API clients for PE services

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: librbac-client-clojure
  Version : 0.9.4
  Upstream Author : Puppet Labs Inc 
* URL : https://github.com/puppetlabs/clj-rbac-client
* License : Apache-2.0
  Programming Lang: Clojure
  Description : lightweight API clients for PE services

 A Clojure library designed to hold lightweight API clients for PE services.
 The clients are meant to provide alternate versions of the TK services.

Note: This is part of the packaging for Puppet 6.

Bug#966114: src:cyrus-imapd: Mail::JMAPTalk version 0.15 required--this is only version 0.13 at ./Cassandane/Cyrus/JMAPCore.pm

[Chris Hofstaedtler]

* Xavier  [200903 16:10]:
> > I must say I find it unacceptable that autopkgtests which are being
> > used to test migration from Debian unstable to Debian testing to rely
> > on code from random places on the Internet, which Debian Developers
> > have no control over.
> 
> I understand your point of view. We found this way to reproduce upstream
> test in this package that had no test before. What would be the best:
>  * embed test libraries in source package (like apache2) ?
>+ embed copies of dovecot and some other package that exists in
>  Debian but with a different version ?
>  -- or --
>+ try to patch upstream test to use Debian packages in test ? (I
>  tried without success)
>  * remove autopkgtest files ?
>  * render autopkgtest success "skippable" ?

CC-ed d-release@ as they probably have stronger opinions on this
question. A side question there might be: "Why does CI have access
to the Internet?"

In an ideal world I'd go with "package test libraries for Debian". 

Chris

Bug#969477: zfs-dkms fails to compile with 5.7.0-3 kernel blocking kernel upgrade

[Jordan Mendler]

Package: zfs-dkms
Version: 0.8.4-2
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: jordanmend...@gmail.com

jordan@jordan-laptop:~$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  enchant libenchant1c2a
Use 'sudo apt autoremove' to remove them.
The following packages have been kept back:
  vlc-data vlc-plugin-base
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up zfs-dkms (0.8.4-2) ...
Removing old zfs-0.8.4 DKMS files...

--
Deleting module version: 0.8.4
completely from the DKMS tree.
--
Done.
Loading new zfs-0.8.4 DKMS files...
Building for 5.7.0-2-amd64 5.7.0-3-amd64
Module build for kernel 5.7.0-2-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
Building initial module for 5.7.0-3-amd64
grep: /lib/modules/5.7.0-3-amd64/build/include/linux/miscdevice.h: No such file 
or directory
configure: error:
*** None of the expected "global page state" interfaces were detected.
*** This may be because your kernel version is newer than what is
*** supported, or you are using a patched custom kernel with
*** incompatible modifications.
***
*** ZFS Version: zfs-0.8.4-2
*** Compatible Kernels: 2.6.32 - 5.6

Error! Bad return status for module build on kernel: 5.7.0-3-amd64 (x86_64)
Consult /var/lib/dkms/zfs/0.8.4/build/make.log for more information.
dpkg: error processing package zfs-dkms (--configure):
 installed zfs-dkms package post-installation script subprocess returned error 
exit status 10
dpkg: dependency problems prevent configuration of zfs-initramfs:
 zfs-initramfs depends on zfs-modules | zfs-dkms; however:
  Package zfs-modules is not installed.
  Package zfs-dkms which provides zfs-modules is not configured yet.
  Package zfs-dkms is not configured yet.

dpkg: error processing package zfs-initramfs (--configure):
 dependency problems - leaving unconfigured
Processing triggers for initramfs-tools (0.137) ...
update-initramfs: Generating /boot/initrd.img-5.7.0-3-amd64
I: The initramfs will attempt to resume from /dev/sda6
I: (UUID=ed50f26c-a201-4381-806d-a9c6b2b4766a)
I: Set the RESUME variable to override this.
Errors were encountered while processing:
 zfs-dkms
 zfs-initramfs
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)


-- System Information:
Distributor ID: Debian Sid
Description:Debian Sid
Release:sid
Codename:   sid
Architecture: x86_64

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

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  dkms   2.8.3-4
ii  file   1:5.38-5
ii  libc6-dev [libc-dev]   2.31-3
ii  libpython3-stdlib  3.8.2-3
ii  lsb-release11.1.0
ii  perl   5.30.3-4
ii  python3-distutils  3.8.5-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  5.7.17-1
ii  zfs-zed 0.8.4-2
ii  zfsutils-linux  0.8.4-2

Versions of packages zfs-dkms suggests:
ii  debhelper  13.2

-- debconf information:
  zfs-dkms/stop-build-for-32bit-kernel: true
* zfs-dkms/note-incompatible-licenses:
  zfs-dkms/stop-build-for-unknown-kernel: true

Bug#969479: reportbug: /usr/share/zoneinfo/Etc/GMT+2 is actually GMT-2 and /usr/share/zoneinfo/Etc/GMT-2 is GMT+2

[Loïc Alberi]

Package: reportbug
Version: 7.5.3~deb10u1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I needed to be on the correct timezone on my container 
https://hub.docker.com/_/httpd?tab=description
FYI: reportbug was executed from that container.
   

   * What exactly did you do that was ineffective)?
 
 Changed the timezone to reflect mine (GMT+2) was ineffective
 
 
root@f7d91ad3ac98:/usr/local/apache2# ls -l /etc/localtime
lrwxrwxrwx. 1 root root 29 Sep  3 09:20 /etc/localtime -> 
/usr/share/zoneinfo/Etc/GMT+2
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2# ls -l /usr/share/zoneinfo/Etc/GMT+2
-rw-r--r--. 1 root root 148 Apr 27 08:46 /usr/share/zoneinfo/Etc/GMT+2
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2# ls -l /usr/share/zoneinfo/Etc/
total 104
lrwxrwxrwx. 1 root root   6 Apr 27 08:46 GMT -> ../GMT
lrwxrwxrwx. 1 root root   6 Apr 27 08:46 GMT+0 -> ../GMT
-rw-r--r--. 1 root root 148 Apr 27 08:46 GMT+1
-rw-r--r--. 1 root root 149 Apr 27 08:46 GMT+10
-rw-r--r--. 1 root root 149 Apr 27 08:46 GMT+11
-rw-r--r--. 1 root root 149 Apr 27 08:46 GMT+12
-rw-r--r--. 1 root root 148 Apr 27 08:46 GMT+2
-rw-r--r--. 1 root root 148 Apr 27 08:46 GMT+3
-rw-r--r--. 1 root root 148 Apr 27 08:46 GMT+4
-rw-r--r--. 1 root root 148 Apr 27 08:46 GMT+5
-rw-r--r--. 1 root root 148 Apr 27 08:46 GMT+6
-rw-r--r--. 1 root root 148 Apr 27 08:46 GMT+7
-rw-r--r--. 1 root root 148 Apr 27 08:46 GMT+8
-rw-r--r--. 1 root root 148 Apr 27 08:46 GMT+9
lrwxrwxrwx. 1 root root   6 Apr 27 08:46 GMT-0 -> ../GMT
-rw-r--r--. 1 root root 149 Apr 27 08:46 GMT-1
-rw-r--r--. 1 root root 150 Apr 27 08:46 GMT-10
-rw-r--r--. 1 root root 150 Apr 27 08:46 GMT-11
-rw-r--r--. 1 root root 150 Apr 27 08:46 GMT-12
-rw-r--r--. 1 root root 150 Apr 27 08:46 GMT-13
-rw-r--r--. 1 root root 150 Apr 27 08:46 GMT-14
-rw-r--r--. 1 root root 149 Apr 27 08:46 GMT-2
-rw-r--r--. 1 root root 149 Apr 27 08:46 GMT-3
-rw-r--r--. 1 root root 149 Apr 27 08:46 GMT-4
-rw-r--r--. 1 root root 149 Apr 27 08:46 GMT-5
-rw-r--r--. 1 root root 149 Apr 27 08:46 GMT-6
-rw-r--r--. 1 root root 149 Apr 27 08:46 GMT-7
-rw-r--r--. 1 root root 149 Apr 27 08:46 GMT-8
-rw-r--r--. 1 root root 149 Apr 27 08:46 GMT-9
lrwxrwxrwx. 1 root root   6 Apr 27 08:46 GMT0 -> ../GMT
lrwxrwxrwx. 1 root root   6 Apr 27 08:46 Greenwich -> ../GMT
lrwxrwxrwx. 1 root root   6 Apr 27 08:46 UCT -> ../UCT
lrwxrwxrwx. 1 root root   6 Apr 27 08:46 UTC -> ../UCT
lrwxrwxrwx. 1 root root   6 Apr 27 08:46 Universal -> ../UCT
lrwxrwxrwx. 1 root root   6 Apr 27 08:46 Zulu -> ../UCT
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2# date
Thu Sep  3 13:54:36 -02 2020
root@f7d91ad3ac98:/usr/local/apache2#



   * What was the outcome of this action?

Wrong date displayed in result of date command



   * What outcome did you expect instead?

GMT+2 date as a result of date command was expected



   * What exactly did you do that was effective?


root@f7d91ad3ac98:/usr/local/apache2# ln -sf /usr/share/zoneinfo/Etc/GMT-2 
/etc/localtime
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2# ls -l /etc/localtime
lrwxrwxrwx 1 root root 29 Sep  3 17:56 /etc/localtime -> 
/usr/share/zoneinfo/Etc/GMT-2
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2#
root@f7d91ad3ac98:/usr/local/apache2# date
Thu Sep  3 17:56:25 +02 2020
root@f7d91ad3ac98:/usr/local/apache2#

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


-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /root/.reportbugrc:
reportbug_version "7.5.3~deb10u1"
mode novice
ui text
offline
realname "supp...@cecurity.com"
email "supp...@cecurity.com"
no-check-uid
no-cc
list-cc-me
smtphost reportbug.debian.org

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

Kernel: Linux 4.18.0-193.14.3.el8_2.x86_64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages reportbug depends on:
ii  apt1.8.2.1
ii  python33.7.3-1
iu  python3-reportbug  7.5.3~deb10u1
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
pn  debconf-utils   
pn  debsums 
pn  dlocate 
pn  emacs-bin-common   

Bug#969478: knot-resolver: [INTL:fr] French debconf templates translation

[Jean-Pierre Giraud]

Package: knot-resolver
Severity: wishlist
Tags: patch l10n

Hi!

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

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

Kind Regards

Jean-Pierre Giraud


fr.po.gz
Description: application/gzip

Bug#969480: prometheus-blackbox-exporter: [INTL:fr] French debconf templates translation

[Jean-Pierre Giraud]

Package: prometheus-blackbox-exporter
Severity: wishlist
Tags: patch l10n

Hi!

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

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

Kind Regards

Jean-Pierre Giraud


fr.po.gz
Description: application/gzip

Bug#969481: ITP: libring-json-clojure -- ring middleware functions for handling JSON requests and responses

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libring-json-clojure
  Version : 0.4.0
  Upstream Author : James Reeves 
* URL : https://github.com/ring-clojure/ring-json
* License : Expat
  Programming Lang: Clojure
  Description : ring middleware functions for handling JSON requests and 
responses

 This package contains the Standard Ring middleware functions for handling JSON
 requests and responses.

Note: This is part of the dependency chain to get Puppet 6 packaged.

Bug#969477: Acknowledgement (zfs-dkms fails to compile with 5.7.0-3 kernel blocking kernel upgrade)

[Jordan Mendler]

FYI...

jordan@jordan-laptop:~$ cat /var/lib/dkms/zfs/0.8.4/build/make.log
DKMS make.log for zfs-0.8.4 for kernel 5.7.0-3-amd64 (x86_64)
Thu 03 Sep 2020 09:19:11 AM PDT
make: *** No targets specified and no makefile found.  Stop.

Jordan Mendler
[image: The Veloz Group]
The Veloz Group
President & Chief Technology Officer
jor...@thevelozgroup.com
www.thevelozgroup.com

Bug#968997: fwupdmgr: "Successfully" updates BIOS firmware, no effect on reboot

[Lee Garrett]

Package: fwupd
Followup-For: Bug #968997
X-Debbugs-Cc: deb...@rocketjump.eu

Hi again,

today I was offered an upgrade to 0.1.69, and that update ran through without
problems. So it seems as though the 0.1.68 update was faulty for some reason. If
the faulty update was rejected by the firmware, it would be at least nice to get
notified as the user. But I don't know fwupdmgr well enough to say if that's
something the running system firmware gives feedback on.

As a result I'm lowering the severity to wishlist.

Regards,
Lee

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

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

Versions of packages fwupd depends on:
ii  libc6  2.31-3
ii  libefiboot137-5
ii  libefivar1 37-5
ii  libelf10.180-1+b1
ii  libflashrom1   1.2-5
ii  libfwupd2  1.4.5-1
ii  libfwupdplugin11.4.5-1
ii  libglib2.0-0   2.64.4-1
ii  libgudev-1.0-0 233-1
ii  libgusb2   0.3.4-0.2
ii  libjcat1   0.1.3-2
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-29
ii  libsmbios-c2   2.4.3-1
ii  libsoup2.4-1   2.70.0-1
ii  libsqlite3-0   3.33.0-1
ii  libtss2-esys0  2.4.1-1+b1
ii  libxmlb1   0.1.15-2
ii  shared-mime-info   1.15-1

Versions of packages fwupd recommends:
ii  bolt  0.9-1
pn  fwupd-signed  
ii  python3   3.8.2-3

fwupd suggests no packages.

-- no debconf information

Bug#969483: ITP: glab -- An open-source GitLab command line tool

[Clement Sam]

Package: wnpp
Severity: wishlist
Owner: root 

* Package name: glab
  Version : 1.10.0-1
  Upstream Author : Clement Sam
* URL : https://github.com/profclems/glab
* License : Expat
  Programming Lang: Go
  Description : An open-source GitLab command line tool

 GLab
 .
 All Contributors (#contributors-)
 .
 .
 Go Report Card (https://goreportcard.com/report/github.com/profclems/glab)
 GitHub Workflow Status .github/workflows/build_docs.yml Gitter
 
(https://gitter.im/glabcli/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
 License (LICENSE) Twitter
 
(https://twitter.com/intent/tweet?text=Take%20Gitlab%20to%20the%20command%20line%20with%20%23glab,%20an%20open-source%20GitLab%20CLI%20tool:&url=https%3A%2F%2Fgithub.com%2Fprofclems%2Fglab)
 .
 GLab is an open source Gitlab Cli tool written in Go (golang) to help
 work seamlessly with Gitlab from the command line. Work with issues,
 merge requests, watch running pipelines directly from your CLI among
 other features.
 .
 image Usage bash
   glab   [flags]
 .
 Core Commands• glab mr [list, create, close, reopen, delete]• glab
 issue [list, create, close, reopen, delete]• glab pipeline [list,
 delete, ci status, ci view]• glab config• glab helpExamples bash
   $ glab issue create --title="This is an issue title" --description="This
   is a really long description" $ glab issue list --closed $ glab pipeline
   ci view -b master# to watch the latest pipeline on master $ glab
   pipeline status# classic ci view
 .
 Learn More Read the documentation (https://clementsam.tech/glab)
 for more information on this tool.  Installation
 Download a binary suitable for your OS at the releases page
 (https://github.com/profclems/glab/releases/latest).  Quick Install (Bash)
 You can install or update glab with: bash curl -sL https://j.mp/glab-i |
 sudo bash
 .
 or bash curl -s
 https://raw.githubusercontent.com/profclems/glab/trunk/scripts/quick_install.sh
 | sudo bash
 .
 Installs into usr/local/bin Windows Available for download
 on scoop or manually as an installable executable file or a
 Portable archived file in tar and zip formats at the releases
 page (https://github.com/profclems/glab/releases/latest).
 Download and install now at the releases page
 (https://github.com/profclems/glab/releases/latest).
 .
 The installable executable file sets the PATH
 automatically.  Scoop sh scoop bucket add profclems-bucket
 https://github.com/profclems/scoop-bucket.git scoop install glab
 .
 Linux Downloads available via linuxbrew (homebrew) and tar balls Linuxbrew
 (Homebrew) sh brew install profclems/tap/glab
 .
 Updating: sh brew upgrade glab
 .
 Arch Linux glab is available through the gitlab-glab-bin
 (https://aur.archlinux.org/packages/gitlab-glab-bin/) package on
 the AUR.  Manual Installation Download the tar ball, untar and
 install: • Download the .tar.gz file from the releases page
 (https://github.com/profclems/glab/releases/latest)• unzip
 glab-*-linux-amd64.tar.gz to unzip the downloaded file• sudo mv
 glab-*-linux-amd64/glab /usr/binMacOS glab is available via Homebrew or
 you can manually install Homebrew sh brew install profclems/tap/glab
 .
 Updating: sh brew upgrade glab
 .
 Installing manually• Download the .tar.gz or .zip file from the releases
 page (https://github.com/profclems/glab/releases/latest) and unzip or
 untar• ls /usr/local/bin/ || sudo mkdir /usr/local/bin/; to make sure
 the bin folder exists• sudo mv glab-*-darwin-amd64/glab /usr/binBuilding
 From Source If a supported binary for your OS is not found at the releases
 page (https://github.com/profclems/glab/releases/latest), you can build
 from source: • Verify that you have Go 1.13.8+ installed sh
$ go version go version go1.14
 .
 .
 If go is not installed, follow instructions on the Go website
 (https://golang.org/doc/install).  • Clone this repository sh
$ git clone https://github.com/profclems/glab.git glab-cli $
cd glab-cli
 .
 .
 or
 .
 sh
$ git clone https://gitlab.com/profclems/glab.git $ cd glab-cli
 .
 • Build the project
 .
$ make build
 .
 • Move the resulting bin/glab executable to somewhere in your PATH sh
$ sudo mv ./bin/glab /usr/local/bin/
 .
or sh $ sudo mv ./bin/glab /usr/bin/
 .
 • Run glab version to check if it worked and glab config -g to set
 upConfiguration To set configuration for current directory (must be a
 git repository) ```sh glab config  // Will be prompted for details
 .
 or
 .
 glab config --token= --url=https://gitlab.com --remote-var=origin
 .
 **To set configuration globally** sh glab config --global // Will be
 prompted for details
 .
 or
 .
 glab config --global --token= --url=https://gitlab.com
 --remote-var=origin
 .
 **For initial releases up to v1.6.1** sh glab config --token=
 --url=https://gitlab.com --pid= --repo=OWNER/REPO ``` Example sh glab
 config --token=sometoken --url=https://gitlab.com --pid=someprojectid
 --repo=profclems/glab
 .
 NB: Change gitlab.com 

Bug#969485: ITP: glab -- An open-source GitLab command line tool

[TODO]

Package: wnpp
Severity: wishlist
Owner: TODO 

* Package name: glab
  Version : 1.10.0-1
  Upstream Author : Clement Sam
* URL : https://github.com/profclems/glab
* License : Expat
  Programming Lang: Go
  Description : An open-source GitLab command line tool

 GLab
 .
 All Contributors (#contributors-)
 .
 .
 Go Report Card (https://goreportcard.com/report/github.com/profclems/glab)
 GitHub Workflow Status .github/workflows/build_docs.yml Gitter
 
(https://gitter.im/glabcli/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
 License (LICENSE) Twitter
 
(https://twitter.com/intent/tweet?text=Take%20Gitlab%20to%20the%20command%20line%20with%20%23glab,%20an%20open-source%20GitLab%20CLI%20tool:&url=https%3A%2F%2Fgithub.com%2Fprofclems%2Fglab)
 .
 GLab is an open source Gitlab Cli tool written in Go (golang) to help
 work seamlessly with Gitlab from the command line. Work with issues,
 merge requests, watch running pipelines directly from your CLI among
 other features.
 .
 image Usage bash
   glab   [flags]
 .
 Core Commands• glab mr [list, create, close, reopen, delete]• glab
 issue [list, create, close, reopen, delete]• glab pipeline [list,
 delete, ci status, ci view]• glab config• glab helpExamples bash
   $ glab issue create --title="This is an issue title" --description="This
   is a really long description" $ glab issue list --closed $ glab pipeline
   ci view -b master# to watch the latest pipeline on master $ glab
   pipeline status# classic ci view
 .
 Learn More Read the documentation (https://clementsam.tech/glab)
 for more information on this tool.  Installation
 Download a binary suitable for your OS at the releases page
 (https://github.com/profclems/glab/releases/latest).  Quick Install (Bash)
 You can install or update glab with: bash curl -sL https://j.mp/glab-i |
 sudo bash
 .
 or bash curl -s
 https://raw.githubusercontent.com/profclems/glab/trunk/scripts/quick_install.sh
 | sudo bash
 .
 Installs into usr/local/bin Windows Available for download
 on scoop or manually as an installable executable file or a
 Portable archived file in tar and zip formats at the releases
 page (https://github.com/profclems/glab/releases/latest).
 Download and install now at the releases page
 (https://github.com/profclems/glab/releases/latest).
 .
 The installable executable file sets the PATH
 automatically.  Scoop sh scoop bucket add profclems-bucket
 https://github.com/profclems/scoop-bucket.git scoop install glab
 .
 Linux Downloads available via linuxbrew (homebrew) and tar balls Linuxbrew
 (Homebrew) sh brew install profclems/tap/glab
 .
 Updating: sh brew upgrade glab
 .
 Arch Linux glab is available through the gitlab-glab-bin
 (https://aur.archlinux.org/packages/gitlab-glab-bin/) package on
 the AUR.  Manual Installation Download the tar ball, untar and
 install: • Download the .tar.gz file from the releases page
 (https://github.com/profclems/glab/releases/latest)• unzip
 glab-*-linux-amd64.tar.gz to unzip the downloaded file• sudo mv
 glab-*-linux-amd64/glab /usr/binMacOS glab is available via Homebrew or
 you can manually install Homebrew sh brew install profclems/tap/glab
 .
 Updating: sh brew upgrade glab
 .
 Installing manually• Download the .tar.gz or .zip file from the releases
 page (https://github.com/profclems/glab/releases/latest) and unzip or
 untar• ls /usr/local/bin/ || sudo mkdir /usr/local/bin/; to make sure
 the bin folder exists• sudo mv glab-*-darwin-amd64/glab /usr/binBuilding
 From Source If a supported binary for your OS is not found at the releases
 page (https://github.com/profclems/glab/releases/latest), you can build
 from source: • Verify that you have Go 1.13.8+ installed sh
$ go version go version go1.14
 .
 .
 If go is not installed, follow instructions on the Go website
 (https://golang.org/doc/install).  • Clone this repository sh
$ git clone https://github.com/profclems/glab.git glab-cli $
cd glab-cli
 .
 .
 or
 .
 sh
$ git clone https://gitlab.com/profclems/glab.git $ cd glab-cli
 .
 • Build the project
 .
$ make build
 .
 • Move the resulting bin/glab executable to somewhere in your PATH sh
$ sudo mv ./bin/glab /usr/local/bin/
 .
or sh $ sudo mv ./bin/glab /usr/bin/
 .
 • Run glab version to check if it worked and glab config -g to set
 upConfiguration To set configuration for current directory (must be a
 git repository) ```sh glab config  // Will be prompted for details
 .
 or
 .
 glab config --token= --url=https://gitlab.com --remote-var=origin
 .
 **To set configuration globally** sh glab config --global // Will be
 prompted for details
 .
 or
 .
 glab config --global --token= --url=https://gitlab.com
 --remote-var=origin
 .
 **For initial releases up to v1.6.1** sh glab config --token=
 --url=https://gitlab.com --pid= --repo=OWNER/REPO ``` Example sh glab
 config --token=sometoken --url=https://gitlab.com --pid=someprojectid
 --repo=profclems/glab
 .
 NB: Change gitlab.com 

Bug#969482: ITP: glab -- An open-source GitLab command line tool

[TODO]

Package: wnpp
Severity: wishlist
Owner: TODO 

* Package name: glab
  Version : 1.10.0-1
  Upstream Author : Clement Sam
* URL : https://github.com/profclems/glab
* License : Expat
  Programming Lang: Go
  Description : An open-source GitLab command line tool

 GLab
 .
 All Contributors (#contributors-)
 .
 .
 Go Report Card (https://goreportcard.com/report/github.com/profclems/glab)
 GitHub Workflow Status .github/workflows/build_docs.yml Gitter
 
(https://gitter.im/glabcli/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
 License (LICENSE) Twitter
 
(https://twitter.com/intent/tweet?text=Take%20Gitlab%20to%20the%20command%20line%20with%20%23glab,%20an%20open-source%20GitLab%20CLI%20tool:&url=https%3A%2F%2Fgithub.com%2Fprofclems%2Fglab)
 .
 GLab is an open source Gitlab Cli tool written in Go (golang) to help
 work seamlessly with Gitlab from the command line. Work with issues,
 merge requests, watch running pipelines directly from your CLI among
 other features.
 .
 image Usage bash
   glab   [flags]
 .
 Core Commands• glab mr [list, create, close, reopen, delete]• glab
 issue [list, create, close, reopen, delete]• glab pipeline [list,
 delete, ci status, ci view]• glab config• glab helpExamples bash
   $ glab issue create --title="This is an issue title" --description="This
   is a really long description" $ glab issue list --closed $ glab pipeline
   ci view -b master# to watch the latest pipeline on master $ glab
   pipeline status# classic ci view
 .
 Learn More Read the documentation (https://clementsam.tech/glab)
 for more information on this tool.  Installation
 Download a binary suitable for your OS at the releases page
 (https://github.com/profclems/glab/releases/latest).  Quick Install (Bash)
 You can install or update glab with: bash curl -sL https://j.mp/glab-i |
 sudo bash
 .
 or bash curl -s
 https://raw.githubusercontent.com/profclems/glab/trunk/scripts/quick_install.sh
 | sudo bash
 .
 Installs into usr/local/bin Windows Available for download
 on scoop or manually as an installable executable file or a
 Portable archived file in tar and zip formats at the releases
 page (https://github.com/profclems/glab/releases/latest).
 Download and install now at the releases page
 (https://github.com/profclems/glab/releases/latest).
 .
 The installable executable file sets the PATH
 automatically.  Scoop sh scoop bucket add profclems-bucket
 https://github.com/profclems/scoop-bucket.git scoop install glab
 .
 Linux Downloads available via linuxbrew (homebrew) and tar balls Linuxbrew
 (Homebrew) sh brew install profclems/tap/glab
 .
 Updating: sh brew upgrade glab
 .
 Arch Linux glab is available through the gitlab-glab-bin
 (https://aur.archlinux.org/packages/gitlab-glab-bin/) package on
 the AUR.  Manual Installation Download the tar ball, untar and
 install: • Download the .tar.gz file from the releases page
 (https://github.com/profclems/glab/releases/latest)• unzip
 glab-*-linux-amd64.tar.gz to unzip the downloaded file• sudo mv
 glab-*-linux-amd64/glab /usr/binMacOS glab is available via Homebrew or
 you can manually install Homebrew sh brew install profclems/tap/glab
 .
 Updating: sh brew upgrade glab
 .
 Installing manually• Download the .tar.gz or .zip file from the releases
 page (https://github.com/profclems/glab/releases/latest) and unzip or
 untar• ls /usr/local/bin/ || sudo mkdir /usr/local/bin/; to make sure
 the bin folder exists• sudo mv glab-*-darwin-amd64/glab /usr/binBuilding
 From Source If a supported binary for your OS is not found at the releases
 page (https://github.com/profclems/glab/releases/latest), you can build
 from source: • Verify that you have Go 1.13.8+ installed sh
$ go version go version go1.14
 .
 .
 If go is not installed, follow instructions on the Go website
 (https://golang.org/doc/install).  • Clone this repository sh
$ git clone https://github.com/profclems/glab.git glab-cli $
cd glab-cli
 .
 .
 or
 .
 sh
$ git clone https://gitlab.com/profclems/glab.git $ cd glab-cli
 .
 • Build the project
 .
$ make build
 .
 • Move the resulting bin/glab executable to somewhere in your PATH sh
$ sudo mv ./bin/glab /usr/local/bin/
 .
or sh $ sudo mv ./bin/glab /usr/bin/
 .
 • Run glab version to check if it worked and glab config -g to set
 upConfiguration To set configuration for current directory (must be a
 git repository) ```sh glab config  // Will be prompted for details
 .
 or
 .
 glab config --token= --url=https://gitlab.com --remote-var=origin
 .
 **To set configuration globally** sh glab config --global // Will be
 prompted for details
 .
 or
 .
 glab config --global --token= --url=https://gitlab.com
 --remote-var=origin
 .
 **For initial releases up to v1.6.1** sh glab config --token=
 --url=https://gitlab.com --pid= --repo=OWNER/REPO ``` Example sh glab
 config --token=sometoken --url=https://gitlab.com --pid=someprojectid
 --repo=profclems/glab
 .
 NB: Change gitlab.com 

Bug#969484: ITP: glab -- An open-source GitLab command line tool

[Clement Sam]

Package: wnpp
Severity: wishlist
Owner: root 

* Package name: glab
  Version : 1.10.0-1
  Upstream Author : Clement Sam
* URL : https://github.com/profclems/glab
* License : Expat
  Programming Lang: Go
  Description : An open-source GitLab command line tool

 GLab
 .
 All Contributors (#contributors-)
 .
 .
 Go Report Card (https://goreportcard.com/report/github.com/profclems/glab)
 GitHub Workflow Status .github/workflows/build_docs.yml Gitter
 
(https://gitter.im/glabcli/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
 License (LICENSE) Twitter
 
(https://twitter.com/intent/tweet?text=Take%20Gitlab%20to%20the%20command%20line%20with%20%23glab,%20an%20open-source%20GitLab%20CLI%20tool:&url=https%3A%2F%2Fgithub.com%2Fprofclems%2Fglab)
 .
 GLab is an open source Gitlab Cli tool written in Go (golang) to help
 work seamlessly with Gitlab from the command line. Work with issues,
 merge requests, watch running pipelines directly from your CLI among
 other features.
 .
 image Usage bash
   glab   [flags]
 .
 Core Commands• glab mr [list, create, close, reopen, delete]• glab
 issue [list, create, close, reopen, delete]• glab pipeline [list,
 delete, ci status, ci view]• glab config• glab helpExamples bash
   $ glab issue create --title="This is an issue title" --description="This
   is a really long description" $ glab issue list --closed $ glab pipeline
   ci view -b master# to watch the latest pipeline on master $ glab
   pipeline status# classic ci view
 .
 Learn More Read the documentation (https://clementsam.tech/glab)
 for more information on this tool.  Installation
 Download a binary suitable for your OS at the releases page
 (https://github.com/profclems/glab/releases/latest).  Quick Install (Bash)
 You can install or update glab with: bash curl -sL https://j.mp/glab-i |
 sudo bash
 .
 or bash curl -s
 https://raw.githubusercontent.com/profclems/glab/trunk/scripts/quick_install.sh
 | sudo bash
 .
 Installs into usr/local/bin Windows Available for download
 on scoop or manually as an installable executable file or a
 Portable archived file in tar and zip formats at the releases
 page (https://github.com/profclems/glab/releases/latest).
 Download and install now at the releases page
 (https://github.com/profclems/glab/releases/latest).
 .
 The installable executable file sets the PATH
 automatically.  Scoop sh scoop bucket add profclems-bucket
 https://github.com/profclems/scoop-bucket.git scoop install glab
 .
 Linux Downloads available via linuxbrew (homebrew) and tar balls Linuxbrew
 (Homebrew) sh brew install profclems/tap/glab
 .
 Updating: sh brew upgrade glab
 .
 Arch Linux glab is available through the gitlab-glab-bin
 (https://aur.archlinux.org/packages/gitlab-glab-bin/) package on
 the AUR.  Manual Installation Download the tar ball, untar and
 install: • Download the .tar.gz file from the releases page
 (https://github.com/profclems/glab/releases/latest)• unzip
 glab-*-linux-amd64.tar.gz to unzip the downloaded file• sudo mv
 glab-*-linux-amd64/glab /usr/binMacOS glab is available via Homebrew or
 you can manually install Homebrew sh brew install profclems/tap/glab
 .
 Updating: sh brew upgrade glab
 .
 Installing manually• Download the .tar.gz or .zip file from the releases
 page (https://github.com/profclems/glab/releases/latest) and unzip or
 untar• ls /usr/local/bin/ || sudo mkdir /usr/local/bin/; to make sure
 the bin folder exists• sudo mv glab-*-darwin-amd64/glab /usr/binBuilding
 From Source If a supported binary for your OS is not found at the releases
 page (https://github.com/profclems/glab/releases/latest), you can build
 from source: • Verify that you have Go 1.13.8+ installed sh
$ go version go version go1.14
 .
 .
 If go is not installed, follow instructions on the Go website
 (https://golang.org/doc/install).  • Clone this repository sh
$ git clone https://github.com/profclems/glab.git glab-cli $
cd glab-cli
 .
 .
 or
 .
 sh
$ git clone https://gitlab.com/profclems/glab.git $ cd glab-cli
 .
 • Build the project
 .
$ make build
 .
 • Move the resulting bin/glab executable to somewhere in your PATH sh
$ sudo mv ./bin/glab /usr/local/bin/
 .
or sh $ sudo mv ./bin/glab /usr/bin/
 .
 • Run glab version to check if it worked and glab config -g to set
 upConfiguration To set configuration for current directory (must be a
 git repository) ```sh glab config  // Will be prompted for details
 .
 or
 .
 glab config --token= --url=https://gitlab.com --remote-var=origin
 .
 **To set configuration globally** sh glab config --global // Will be
 prompted for details
 .
 or
 .
 glab config --global --token= --url=https://gitlab.com
 --remote-var=origin
 .
 **For initial releases up to v1.6.1** sh glab config --token=
 --url=https://gitlab.com --pid= --repo=OWNER/REPO ``` Example sh glab
 config --token=sometoken --url=https://gitlab.com --pid=someprojectid
 --repo=profclems/glab
 .
 NB: Change gitlab.com 

Bug#969463: rsync: fails reproducible but unexplained on a specific volume, breaks horribly when started by BackupPC

[Pelzi]

Hi Paul,

thanks for the fast answer!

"Paul Slootman" p...@debian.org – 3. September 2020 16:27
[...]

>> opening connection using: ssh -l root localhost rsync --server --sender 
>> -vvvlHogDtprxe.iLsfxCIvu -B2048 --numeric-ids . /var/lib/lxc (12 args)
> 
> How are you invoking rsync? Please give the exact command line,
> including what you current working directory is.


User is backuppc, working directory is /var/lib/backuppc. Command line:

sh-5.0$ rsync -vvv --rsh=ssh --numeric-ids --perms --owner --group -D --links 
--hard-links --times --block-size 48 \
--recursive --one-file-system root@localhost:/var/lib/lxc /mnt/testrsync/ 
>/mnt/testrsync/stdout.txt 2>/mnt/testrsync/stderr.txt

> Are you actually using ssh to connect to localhost and transferring the
> data over that ssh link?

In this case (2), I issued the command from within a screen session. Here, ssh 
is used internally by rsync (--rsh=ssh). The idea is to change privilege, as 
backuppc is allowed to execute rsync via authorized_keys. Also it is nice that 
the same mechanism works for all hosts to be backed up.

> If so, then these lines are very strange in the case (1) text:
> 
>> Got remote protocol 31
>> Negotiated protocol version 28
> 
> I would expect an rsync to negotiate the highest protocol version
> possible, so this looks like it's talking to a newer version than
> itself.

In contrast to case (2), this case is running from within BackupPC. AFAIK, 
BackupPC_dump directly executes ssh rsync —server —sender … and implements the 
receiving side itself. So, I would conclude that BackupPC_dump implements 
protocol version 28.

>> -- rsync stderr
>> rsync error: errors with program diagnostics (code 13) at log.c(245) 
>> [receiver=3.2.3]
>> rsync: [generator] write error: Broken pipe (32)
>> -- end of stderr
> 
> Because of the "errors with program diagnostics" I would have expected
> more messages...

So did I :-)

> It would be most helpful if you could follow the instructions on
> rsync.samba.org/issues.html especially de second half of
> question 3.

Thanks for the reference, I will try it later.

Andreas.

Bug#969468: lintian 2.92.0 is broken inside a lxd container:

[Felix Lechner]

Hi Julian,

Iñaki Malerba from the Salsa CI team was so kind to point me to the
following code right after I hit the send button on my previous
message:


https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/salsa-ci.yml#L208

Perhaps it is helpful to you.

Kind regards
Felix Lechner

Bug#969486: ITP: libsemver-clojure -- parsing, comparison, and manipulation of semantic version strings

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libsemver-clojure
  Version : 0.3.0
  Upstream Author : Deepak Giridharagopal 
* URL : https://github.com/grimradical/clj-semver
* License : Apache-2.0
  Programming Lang: Clojure
  Description : parsing, comparison, and manipulation of semantic version 
strings

 This Clojure library provides functions for parsing, comparison, and
 manipulation of semantic version strings. The intent is to implement the
 actual spec, including proper comparisons on pre-release and build fields.

Note: This is part of the Puppet 6 packaging.

Bug#969468: lintian: Can't opendir(/dev/.lxd-mounts): Permission denied

[Felix Lechner]

Hi Julian,

Iñaki Malerba also pointed out the following code:

https://salsa.debian.org/salsa-ci-team/autopkgtest-lxc/-/blob/master/.gitlab-ci.yml#L13

Perhaps you find it useful.

Kind regards
Felix Lechner

Bug#965074: Patches to make multicast proccesing on CDC NCM drivers

[Bjørn Mork]

Santiago Ruano Rincón  writes:
> El 02/09/20 a las 17:45, Greg KH escribió:
>> On Wed, Sep 02, 2020 at 03:27:28PM +0200, Santiago Ruano Rincón wrote:
>>
>> > This:
>> > 
>> > 37a2ebdd9e597ae1a0270ac747883ea8f6f767b6
>> > e10dcb1b6ba714243ad5a35a11b91cc14103a9a9
>> > e506addeff844237d60545ef4f6141de21471caf
>> > 0226009ce0f6089f9b31211f7a2703cf9a327a01
>> 
>> These do not look like bugfixes, but a new feature being added for this
>> driver.  So why not just use a newer kernel version for this feature?
>
> From my point of view as user these are bugfixes, since IPv6 NDP or any
> other protocol relying on multicast do not work without them. In other
> words, my computer's networking is broken.

I was in doubt when I submitted these, but ended up specfying net-next
instead of net+stable as the target for a reason.  This is a new feature
as Greg says. Even if the feature is essential for your use case, it is
still new. "Has never been supported" isn't really a bug.

And I am still convinced that my decision was correct.  The patches are
a bit more intrusive than I'd be comfortable submitting to stable, as
was demonstrated by the stupid build bug I added... Fixed by commit
5fd99b5d9950 ("net: cdc_ncm: Fix build error") BTW.

> I want to have them in linux stable releases because that would make
> easier to include them in Debian stable release.

This has not been an absolute requirement in the past. Distros tend to
have a more relaxed stable policy.

Using a newer kernel until Debian moves on is obviously also an option.



Bjørn

Bug#969487: ITP: glab -- An open-source GitLab command line tool

[Clement Sam]

Package: wnpp
Severity: wishlist
Owner: root 

* Package name: glab
  Version : 1.10.0-1
  Upstream Author : Clement Sam
* URL : https://github.com/profclems/glab
* License : Expat
  Programming Lang: Go
  Description : An open-source GitLab command line tool

 GLab
 .
 All Contributors (#contributors-)
 .
 .
 Go Report Card (https://goreportcard.com/report/github.com/profclems/glab)
 GitHub Workflow Status .github/workflows/build_docs.yml Gitter
 
(https://gitter.im/glabcli/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
 License (LICENSE) Twitter
 
(https://twitter.com/intent/tweet?text=Take%20Gitlab%20to%20the%20command%20line%20with%20%23glab,%20an%20open-source%20GitLab%20CLI%20tool:&url=https%3A%2F%2Fgithub.com%2Fprofclems%2Fglab)
 .
 GLab is an open source Gitlab Cli tool written in Go (golang) to help
 work seamlessly with Gitlab from the command line. Work with issues,
 merge requests, watch running pipelines directly from your CLI among
 other features.
 .
 image Usage bash
   glab   [flags]
 .
 Core Commands• glab mr [list, create, close, reopen, delete]• glab
 issue [list, create, close, reopen, delete]• glab pipeline [list,
 delete, ci status, ci view]• glab config• glab helpExamples bash
   $ glab issue create --title="This is an issue title" --description="This
   is a really long description" $ glab issue list --closed $ glab pipeline
   ci view -b master# to watch the latest pipeline on master $ glab
   pipeline status# classic ci view
 .
 Learn More Read the documentation (https://clementsam.tech/glab)
 for more information on this tool.  Installation
 Download a binary suitable for your OS at the releases page
 (https://github.com/profclems/glab/releases/latest).  Quick Install (Bash)
 You can install or update glab with: bash curl -sL https://j.mp/glab-i |
 sudo bash
 .
 or bash curl -s
 https://raw.githubusercontent.com/profclems/glab/trunk/scripts/quick_install.sh
 | sudo bash
 .
 Installs into usr/local/bin Windows Available for download
 on scoop or manually as an installable executable file or a
 Portable archived file in tar and zip formats at the releases
 page (https://github.com/profclems/glab/releases/latest).
 Download and install now at the releases page
 (https://github.com/profclems/glab/releases/latest).
 .
 The installable executable file sets the PATH
 automatically.  Scoop sh scoop bucket add profclems-bucket
 https://github.com/profclems/scoop-bucket.git scoop install glab
 .
 Linux Downloads available via linuxbrew (homebrew) and tar balls Linuxbrew
 (Homebrew) sh brew install profclems/tap/glab
 .
 Updating: sh brew upgrade glab
 .
 Arch Linux glab is available through the gitlab-glab-bin
 (https://aur.archlinux.org/packages/gitlab-glab-bin/) package on
 the AUR.  Manual Installation Download the tar ball, untar and
 install: • Download the .tar.gz file from the releases page
 (https://github.com/profclems/glab/releases/latest)• unzip
 glab-*-linux-amd64.tar.gz to unzip the downloaded file• sudo mv
 glab-*-linux-amd64/glab /usr/binMacOS glab is available via Homebrew or
 you can manually install Homebrew sh brew install profclems/tap/glab
 .
 Updating: sh brew upgrade glab
 .
 Installing manually• Download the .tar.gz or .zip file from the releases
 page (https://github.com/profclems/glab/releases/latest) and unzip or
 untar• ls /usr/local/bin/ || sudo mkdir /usr/local/bin/; to make sure
 the bin folder exists• sudo mv glab-*-darwin-amd64/glab /usr/binBuilding
 From Source If a supported binary for your OS is not found at the releases
 page (https://github.com/profclems/glab/releases/latest), you can build
 from source: • Verify that you have Go 1.13.8+ installed sh
$ go version go version go1.14
 .
 .
 If go is not installed, follow instructions on the Go website
 (https://golang.org/doc/install).  • Clone this repository sh
$ git clone https://github.com/profclems/glab.git glab-cli $
cd glab-cli
 .
 .
 or
 .
 sh
$ git clone https://gitlab.com/profclems/glab.git $ cd glab-cli
 .
 • Build the project
 .
$ make build
 .
 • Move the resulting bin/glab executable to somewhere in your PATH sh
$ sudo mv ./bin/glab /usr/local/bin/
 .
or sh $ sudo mv ./bin/glab /usr/bin/
 .
 • Run glab version to check if it worked and glab config -g to set
 upConfiguration To set configuration for current directory (must be a
 git repository) ```sh glab config  // Will be prompted for details
 .
 or
 .
 glab config --token= --url=https://gitlab.com --remote-var=origin
 .
 **To set configuration globally** sh glab config --global // Will be
 prompted for details
 .
 or
 .
 glab config --global --token= --url=https://gitlab.com
 --remote-var=origin
 .
 **For initial releases up to v1.6.1** sh glab config --token=
 --url=https://gitlab.com --pid= --repo=OWNER/REPO ``` Example sh glab
 config --token=sometoken --url=https://gitlab.com --pid=someprojectid
 --repo=profclems/glab
 .
 NB: Change gitlab.com 

Bug#969488: Assertion failed when speaking some Unicode characters

[Dennis Filder]

Package: speechd-up
Version: 0.5~20110719-9

SYMPTOMS

I ran into a failed assertion.  When pressing certain Unicode
characters like U+20AC (EURO SIGN) or U+2192 (RIGHTWARDS ARROW) on the
console via a keyboard, speechd-up exits suddenly.  The same happens
when moving the cursor over a Unicode character in a text editor or on
a readline prompt.  I first ran into this under Buster.

DIAGNOSIS

>From strace:

...
write(2, "speechd-up: speechd-up.c:457: parse_buf: Assertion `bytes <= 
BUF_SIZE' failed.\n", 79) = 79
...

WORKAROUND

The problem only manifests when speechd-up is started with the default
command line "speechd-up -l1".  Putting this into
/etc/default/speechd-up prevents the bug from being triggered:
DAEMON_OPTS="$DAEMON_OPTS -D/dev/softsynthu -cUTF-8"

ANALYSIS

The error is in speechd-up.c:main():

750 ...
751 chars_read = read(fd, buf, BUF_SIZE);
752 if (chars_read < 0) {
753 ...

chars_read is declared as size_t, but read() returns ssize_t, thus a
failed read returning -1 (errno==11/EAGAIN in my case) triggers the
assertion in parse_buf().

The patch fixes the error and also adds code to retry the read after a
short delay.
--- speechd-up-0.5~20110719/speechd-up.c	2020-09-02 21:05:47.357273940 +0200
+++ speechd-up-0.5~20110719/speechd-up.c	2020-09-02 21:07:45.929271575 +0200
@@ -631,6 +631,7 @@
 int main(int argc, char *argv[])
 {
 	size_t chars_read;
+	ssize_t chars_read_signed;
 	char buf[BUF_SIZE + 1];
 	int ret;

@@ -748,11 +749,20 @@
 			close(fd);
 			return -1;
 		}
-		chars_read = read(fd, buf, BUF_SIZE);
-		if (chars_read < 0) {
-			FATAL(5, "read() failed");
-			close(fd);
-			return -1;
+		chars_read_signed = read(fd, buf, BUF_SIZE);
+		if (chars_read_signed < 0) {
+			if (errno == EAGAIN) {
+LOG(5, "read() failed with EAGAIN, retrying");
+usleep(1000);
+continue;
+			} else {
+FATAL(5, "read() failed with %d,%s",
+  errno, strerror(errno));
+close(fd);
+return -1;
+			}
+		} else {
+			chars_read = chars_read_signed;
 		}
 		buf[chars_read] = 0;
 		LOG(5, "Main loop characters read = %d : (%s)", chars_read,

Bug#936391: Bug#905014: Short status message about dhcpy6d in Debian Unstable and the Python 2 to 3 migration

[Axel Beckert]

Hi,

Axel Beckert wrote:
> just a short update on dhcpy6d in Debian Unstable (and the Python 2 to
> 3 migration):
> 
> I'm planning to do an upload of the 1.0.1 upstream version to Debian
> Unstable soon (next few days) to fix the Python 2 to 3 migration issue
> (#936391) and get the package back in shape.

Based on Henri's (binary-only) packaging changes for Python 3, I got a
version which builds as source and as binary package at
https://salsa.debian.org/debian/dhcpy6d

But it still throws a lot of lintian warnings, so there's still a lot
of work ahead before I can upload this.

You should be able to follow my packaging improvements in that git
repository.

Moritz: I've given you write access to the above mentioned git
repository. Feel free to join and maybe later take over?

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#969488: Assertion failed when speaking some Unicode characters

[Samuel Thibault]

Hello,

Dennis Filder, le jeu. 03 sept. 2020 19:28:11 +0200, a ecrit:
> The patch fixes the error and also adds code to retry the read after a
> short delay.

? You don't want to delay. Either the file is opened in blocking mode,
and you never get EAGAIN, or you open in non-blocking mode, and the
whole loop is supposed to handle this with select, which is the case
here. So just let it go back to select. If that poses problems, it means
that there is a bug that should be fixed inside speakup, and your delay
only hides that bug, while eating batteries.

Samuel

Bug#969475: pandoc: New release available

[Jonas Smedegaard]

Control: retitle -1 pandoc: does not work with reveal.js 4.x
Control: severity -1 minor

Hi Thomas,

Quoting Thomas Clavier (2020-09-03 17:48:21)
> Package: pandoc
> Version: 2.9.2.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> The last version of pandoc work fine with revealjs 4.0 see : 
> https://github.com/jgm/pandoc/issues/6431

Thanks for your bugreport.

Since this is a bugtracker and "New release available" is not a bug, I 
have taken the liberty of reading your mind regarding what you consider 
a bug in the Debian packaging of pandoc.

If I failed at that (mind-reading is kinda brittle, especially from 
afar), then please do elaborate what was on your mind. :-)

Also, I lowered severity since RevealJS is not in Debian (please 
consider filing a so-called RFP: see 
https://www.debian.org/devel/wnpp/#l1 for details on how to that).


Kind regards,

 - 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#969488: Assertion failed when speaking some Unicode characters

[Samuel Thibault]

Samuel Thibault, le jeu. 03 sept. 2020 19:41:57 +0200, a ecrit:
> Dennis Filder, le jeu. 03 sept. 2020 19:28:11 +0200, a ecrit:
> > The patch fixes the error and also adds code to retry the read after a
> > short delay.
> 
> ? You don't want to delay. Either the file is opened in blocking mode,
> and you never get EAGAIN, or you open in non-blocking mode, and the
> whole loop is supposed to handle this with select, which is the case
> here. So just let it go back to select. If that poses problems, it means
> that there is a bug that should be fixed inside speakup, and your delay
> only hides that bug, while eating batteries.

Looking more into it: speechd-up uses softsynth rather than softsynthu.
speakup thus drops all the non-latin1 characters, but it does so by
skipping them from the read(), and thus it returns EAGAIN since in the
end it actually doesn't have anything to return. The behavior then
really is to go back to select(), select() won't return immediately
since the read() call will have consumed the non-latin1 characters, even
if not returning them.

BTW, please submit your patches to upstream
http://github.com/williamh/speechd-up as well, we do not want to carry
them in Debian only longtermwise.

And thanks for the investigation :)
Samuel

Bug#968097: transmission-daemon consumes all memory

[Moritz Mühlenhoff]

On Sat, Aug 08, 2020 at 03:01:35PM +0200, ilf wrote:
> Package: transmission-daemon
> Version: 2.94-2+deb10u1
> 
> I have been running transmission-daemon on Debian 10 buster since it was
> released, mostly without problems.
> 
> On 2020-08-01, transmission-daemon was upgraded to 2.94-2+deb10u1. Since
> then, it consumes all available memory, then all swap, ramping up the load,
> eventually rendering the system unusable.

Can you please test the updated packages at https://people.debian.org/~jmm/,
they should fix it and worked fine in my tests, but I'm using Transmission
in GUI mode, not as a daemon.

Cheers,
Moritz

Bug#969490: RM: caldav-tester -- RoQA; Depends on Python 2, dead upstream

[Moritz Muehlenhoff]

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

Please remove caldav-tester. It depends on Python 2 and upstream is
inactive. Removal has been acked by the maintainer in #936268.

Cheers,
Moritz

Bug#963669: RM: python-numpy -- ROM; python2-only; superseeded by src:numpy; no rdeps

[Moritz Mühlenhoff]

On Tue, Jul 14, 2020 at 07:36:30PM +0200, Moritz Mühlenhoff wrote:
> On Sat, Jul 11, 2020 at 11:06:20AM -0700, Sean Whitton wrote:
> > Hello,
> > 
> > On Thu 09 Jul 2020 at 05:14PM -04, Sandro Tosi wrote:
> > 
> > > Hello FTP Masters,
> > >
> > > On Wed, Jun 24, 2020 at 11:57 PM Sandro Tosi  wrote:
> > >>
> > >> Package: ftp.debian.org
> > >> Severity: normal
> > >>
> > >> cython has just been removed, and the remaining rdeps are not in testing 
> > >> as RC
> > >> for other reasons, so let's not wait on them
> > >
> > > can you please proceed with this removal? thanks!
> > 
> > Just to explain the hold up, since there are rdeps, it needs an ftp team
> > member with python2 transition-specific knowledge to process the
> > removal.  So it might take a bit longer.
> 
> See the breakdown below, TLDR: All remaining rdeps are already removed from
> testing (sometimes for > 2 years) and 9/14 are already uninstallable or
> FTBFS in unstable due to removed Py2 packages. As such, please let's go
> ahead with the removal, this is inline how we've dealt with other rdeps
> as well at this stage.

Update version below, can we please go ahead with this one?

snowballz
-> Removed from testing since 2020-04-04
-> Already uninstallable due to python-opengl gone
 
brian
-> Removed from testing since 2017-10-28
-> Already FTBFS #948040, #876920
 
code-aster-run
-> Removed from testing since 2019-12-15
 
dipy
-> Removed from testing since 2017-01-14
-> FTBFS for a long time: #851048, #896620
 
python-neuroshare
-> Removed from testing since 2019-11-07
 -> FTBFS due to python-sphinx, python-h5py gone already
 
openopt
-> Removed from testing since 2020-01-05
-> Already uninstallable due to python-setproctitle gone
 
ola
-> Removed from testing since 2019-09-07
-> Already uninstallable due to python-protobuf gone
 
unanimity
-> Removed from testing since 2019-10-21
 
pbgenomicconsensus
-> Removed from testing since 2019-09-23
-> Already uninstallable due to python-pytest gone
 
pd-py
-> Removed from testing since 2020-04-23
 
nipype
-> Removed from testing since 2019-08-20
-> Already uninstallable due to python-nibabel and several others gon
 
displaycal
-> Removed from testing since 2020-06-06
 
childsplay
-> Removed from testing since 2020-04-22
-> Already uninstallable due to python-sqlalchemy gone

Cheers,
Moritz

Bug#969491: gnome-shell: User Switcher not working in Gnome-Shell with lightdm

[Kevin Ford]

Package: gnome-shell
Version: 3.30.2-11~deb10u1
Severity: important

Dear Maintainer,

   * What led up to the situation?
Attempted to switch users from main Gnome menu and nothing happened.


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I have two users on this system.  I'm logged in with userA and want to switch
to userB, leaving userA logged in with apps running.  I clicked switch user
from main menu and nothing happened.


   * What was the outcome of this action?
Nothing apparent happened in the UI.  No response in UI to my action


   * What outcome did you expect instead?
To be presented with the lightdm greeter to select a user to login.


THIS ERROR FROM /var/log/messages
-
Sep  3 12:22:03 caladan gnome-shell[10153]: JS ERROR: Gio.DBusError: Unable to
create transient display:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.gnome.DisplayManager was not provided by any .service
files#012activateSwitchUser/<@resource:///org/gnome/shell/misc/systemActions.js:412:13



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evolution-data-server3.30.5-1+deb10u1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-freedesktop   1.58.3-2
ii  gir1.2-gcr-3 3.28.1-1
ii  gir1.2-gdesktopenums-3.0 3.28.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.2-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gnomebluetooth-1.03.28.2-4~deb10u1
ii  gir1.2-gnomedesktop-3.0  3.30.2.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gweather-3.0  3.28.2-2
ii  gir1.2-ibus-1.0  1.5.19-4+deb10u1
ii  gir1.2-mutter-3  3.30.2-9~deb10u1
ii  gir1.2-nm-1.01.14.6-2+deb10u1
ii  gir1.2-nma-1.0   1.8.20-1.1
ii  gir1.2-pango-1.0 1.42.4-8~deb10u1
ii  gir1.2-polkit-1.00.105-25
ii  gir1.2-rsvg-2.0  2.44.10-2.1
ii  gir1.2-soup-2.4  2.64.2-2
ii  gir1.2-upowerglib-1.00.99.10-1
ii  gjs  1.54.3-1
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.2-3
ii  gnome-shell-common   3.30.2-11~deb10u1
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libcroco30.6.12-3
ii  libecal-1.2-19   3.30.5-1+deb10u1
ii  libedataserver-1.2-233.30.5-1+deb10u1
ii  libgcr-base-3-1  3.28.1-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgirepository-1.0-11.58.3-2
ii  libgjs0g 1.54.3-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libglib2.0-bin   2.58.3-2+deb10u2
ii  libgstreamer1.0-01.14.4-1
ii  libgtk-3-0   3.24.5-1
ii  libical3 3.0.4-3
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-3-03.30.2-9~deb10u1
ii  libnm0   1.14.6-2+deb10u1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpolkit-agent-1-0  0.105-25
ii  libpolkit-gobject-1-00.105-25
ii  libpulse-mainloop-glib0  12.2-4+deb10u1
ii  libpulse012.2-4+deb10u1
ii  libsecret-1-00.18.7-1
ii  libstartup-notification0 0.12-6
ii  libsystemd0

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

[Dan Streetman]

On Mon, Aug 17, 2020 at 4:42 AM Michael Biebl  wrote:
>
> Control: severity -1 serious
> Control: tags -1 + patch
>
> Hi everyone,
>
> I think the effects of this issue are severe enough, that it needs to be
> fixed for bullseye. In other words, it should be RC
>
> On Sat, 08 Aug 2020 13:13:44 +0200 =?utf-8?q?Thomas_M=C3=BChlbacher?=
>  wrote:
> > I noticed that there were already two related bugreports, with Michael
> > Biebl providing a solution for the issue:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967906
> >
> > And to a lesser degree this one, I suppose:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968009
> >
> > I tried the container setup again with `PathExists=` dropped from
> > `resolvconf-pull-resolved.path` and it stops the errors from occurring,
> > however I did not verify that this way the service still does what it's
> > supposed to.
>
> #967906 and the related upstream bug report
> https://github.com/systemd/systemd/issues/16669 have more context.
>
> In short: PathExists in systemd v246 changed its behaviour to actually
> match the documentation.
> For resolvconf-pull-resolved.service that means, it's continuously
> started over and over again.
>
> Afaics, the simplest solution, is to simply drop
>
> PathExists=/run/systemd/resolve/stub-resolv.conf
>
> and instead add a
>
> [Install]
> WantedBy=systemd-resolved.service
>
>
> to resolvconf-pull-resolved.service and also add a
> After=systemd-resolved.service

It looks like resolvconf's resolvconf-pull-resolved.path has been
updated to use PathChanged instead.

That should fix the constant loop, though I'm not sure if it is
optimal, as I vaguely remember someone complaining that
systemd-resolved rewrites stub-resolv.conf often, and IIUC
PathChanged= triggers on inotify IN_CLOSE_WRITE so it would trigger
each time systemd-resolved opened (for write) and closed the file.
Although I have not actually looked into the code, so maybe it's fine.

In general I've tried to stay away from resolvconf as the integration
with resolved has been a bit painful, and I think xnox is in the
process of trying to fix that up.

I do tag any LP bugs that I notice relate to resolved/resolvconf
integration/interaction with the 'resolved-resolvconf' tag:
https://bugs.launchpad.net/bugs/+bugs?field.tag=resolved-resolvconf

>
> I've attached a prospective patch.
>
> Dan, Dimitri, would welcome your feedback here, since most of the
> resolvconf/resolved integration is seemingly coming from you.
>
>
> Regards,
> Michael

Bug#969488: Assertion failed when speaking some Unicode characters

[Dennis Filder]

Okay, I removed the delay in the attached version of the patch which I
will send upstream.  I post it here just for sake of completeness.

Regards,
Dennis.
--- speechd-up-0.5~20110719/speechd-up.c	2020-09-02 21:05:47.357273940 +0200
+++ speechd-up-0.5~20110719/speechd-up.c	2020-09-02 21:07:45.929271575 +0200
@@ -631,6 +631,7 @@
 int main(int argc, char *argv[])
 {
 	size_t chars_read;
+	ssize_t chars_read_signed;
 	char buf[BUF_SIZE + 1];
 	int ret;

@@ -748,11 +749,19 @@
 			close(fd);
 			return -1;
 		}
-		chars_read = read(fd, buf, BUF_SIZE);
-		if (chars_read < 0) {
-			FATAL(5, "read() failed");
-			close(fd);
-			return -1;
+		chars_read_signed = read(fd, buf, BUF_SIZE);
+		if (chars_read_signed < 0) {
+			if (errno == EAGAIN) {
+LOG(5, "read() failed with EAGAIN, retrying");
+continue;
+			} else {
+FATAL(5, "read() failed with %d,%s",
+  errno, strerror(errno));
+close(fd);
+return -1;
+			}
+		} else {
+			chars_read = chars_read_signed;
 		}
 		buf[chars_read] = 0;
 		LOG(5, "Main loop characters read = %d : (%s)", chars_read,