Bug#943931: [Python-modules-team] Bug#943931: cloudpickle: autopkgtests still run python 2 tests

[Diane Trout]

Thank you for trying to resolve the bug, and I'm sorry we collided.

I ended up removing your change log entry from debian/changelog but
left it in the git history.

The debian/changelog now matches what I released, and has what I think
is an easier to read debian/tests/control file.

Diane



On Fri, 2019-11-01 at 09:26 -0300, Emmanuel Arias wrote:
> Hi,
> 
> I believe that the fixed package uploaded is not the same of salsa.
> https://salsa.debian.org/python-team/modules/cloudpickle
> 
> 
> Cheers,
> Arias Emmanuel
> @eamanu
> http://eamanu.com
> 
> El vie., 1 de nov. de 2019 a la(s) 00:30, Diane Trout (di...@ghic.org
> ) escribió:
> > Thanks for noticing and telling me.
> > 
> > Just uploaded a fixed package.
> > 
> > Diane
> > 
> > On Fri, 2019-11-01 at 12:54 +1300, Michael Hudson-Doyle wrote:
> > > Source: cloudpickle
> > > Version: 1.2.1-1
> > > Severity: normal
> > > Tags: patch
> > > 
> > > Dear Maintainer,
> > > 
> > > As subject. Best not to test packages that are no longer
> > > built.  Patch
> > > attached but really, it's trivial :)
> > > 
> > > Cheers,
> > > mwh
> > > 
> > > -- System Information:
> > > Debian Release: buster/sid
> > >   APT prefers eoan-updates
> > >   APT policy: (500, 'eoan-updates'), (500, 'eoan'), (400, 'eoan-
> > > proposed'), (100, 'eoan-backports')
> > > Architecture: amd64 (x86_64)
> > > 
> > > Kernel: Linux 5.3.0-19-generic (SMP w/8 CPU cores)
> > > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN,
> > > TAINT_OOT_MODULE
> > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> > > LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> > > Shell: /bin/sh linked to /usr/bin/dash
> > > Init: systemd (via /run/systemd/system)
> > > LSM: AppArmor: enabled
> > 
> > ___
> > Python-modules-team mailing list
> > python-modules-t...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#943959: mailscripts: add decryption capability for email-print-mime-structure

[Daniel Kahn Gillmor]

On Sat 2019-11-02 00:15:43 -0400, Daniel Kahn Gillmor wrote:
> On Fri 2019-11-01 20:37:34 -0700, Sean Whitton wrote:
>> I've applied your first patch to my master.
>
> hm, i don't see this merge when i "git remote update origin" (where
> "origin" is https://git.spwhitton.name/mailscripts).  Could you push?
>
>> The second patch is quite hard for me to review because your
>> refactoring of the basic structure of the script is in the same commit
>> as adding the new feature.  Could you split that into two or more
>> commits, please?
>
> yes, i'll do that and send the updated patches here.

OK, done with a series of 8 patches.  (plus one trailing 9th patch that
updates the manpage).

you can also find them in my salsa repo where you might expect them.

Thanks for considering them!

   --dkg

Bug#943959: [PATCH 9/8] email-print-mime-structure.1.pod: update LIMITATIONS about OpenPGP decryption

[Daniel Kahn Gillmor]

Signed-off-by: Daniel Kahn Gillmor 
---
 email-print-mime-structure.1.pod | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/email-print-mime-structure.1.pod b/email-print-mime-structure.1.pod
index 209c725..b846d87 100644
--- a/email-print-mime-structure.1.pod
+++ b/email-print-mime-structure.1.pod
@@ -49,9 +49,10 @@ Show usage instructions.
 
 =head1 LIMITATIONS
 
-B currently does not try to decrypt
-encrypted e-mails, so it cannot display the MIME structure that is
-inside the message's cryptographic envelope.
+B only decrypts encrypted e-mails using
+raw, non-password-protected OpenPGP secret keys (see B<--pgpkey>,
+above).  If it is unable to decrypt an encrypted part with the
+supplied keys, it will warn on stderr.
 
 B's output is not stable, and is not
 intended to be interpreted by machines, so please do not depend on it
-- 
2.24.0.rc1

Bug#943959: [PATCH 8/8] email-print-mime-structure: add decryption capability

[Daniel Kahn Gillmor]

Add simple decryption capability for email-print-mime-structure, so
that it can do stuff like this:

$ email-print-mime-structure --pgpkey al...@openpgp.example.sec.asc < msg.eml
└┬╴multipart/encrypted 2190 bytes
 ├─╴application/pgp-encrypted 11 bytes
 └─╴application/octet-stream 1613 bytes
  ↧ (decrypts to)
  └─╴text/plain 425 bytes
$

At the moment, it only works with keys that can be found in the
filesystem, and when the pgpy module is installed.

Possible future work:

  - try using gpg to do the decryption from whatever gpg's system
capabilities are

I've added python3-pgpy to the list of Recommends, since it is not a
hard dependency.

Signed-off-by: Daniel Kahn Gillmor 
---
 debian/control   |  1 +
 email-print-mime-structure   | 34 
 email-print-mime-structure.1.pod |  8 
 3 files changed, 43 insertions(+)

diff --git a/debian/control b/debian/control
index 6d3a54f..fc2bccc 100644
--- a/debian/control
+++ b/debian/control
@@ -39,6 +39,7 @@ Recommends:
  devscripts,
  git,
  notmuch,
+ python3-pgpy,
 Architecture: all
 Description: collection of scripts for manipulating e-mail on Debian
  This package provides a collection of scripts for manipulating e-mail
diff --git a/email-print-mime-structure b/email-print-mime-structure
index 33579a7..eb513b3 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -38,6 +38,11 @@ from typing import Optional, Union, List, Tuple, Any
 from email.charset import Charset
 from email.message import Message
 
+try:
+import pgpy #type: ignore
+except ImportError:
+pgpy = None
+
 class MimePrinter(object):
 def __init__(self, args:Namespace):
 self.args = args
@@ -66,6 +71,33 @@ class MimePrinter(object):
 
 print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname} 
{nbytes:d} bytes')
 
+if self.args.pgpkey and \
+   (parent is not None) and \
+   (parent.get_content_type().lower() == 'multipart/encrypted') and \
+   (str(parent.get_param('protocol')).lower() == 
'application/pgp-encrypted') and \
+   (num == 2):
+if pgpy is None:
+logging.warning(f'Python module pgpy is not available, not 
decrypting (try "apt install python3-pgpy")')
+else:
+cryptopayload:Optional[Message] = None
+keyname:str
+for keyname in self.args.pgpkey:
+try:
+key:pgpy.PGPKey
+key, _ = pgpy.PGPKey.from_file(keyname)
+msg:pgpy.PGPMessage = 
pgpy.PGPMessage.from_blob(z.get_payload())
+msg = key.decrypt(msg)
+cryptopayload = email.message_from_bytes(msg.message)
+break
+except:
+pass
+if cryptopayload is None:
+logging.warning(f'Unable to decrypt')
+else:
+newprefix = prefix[:-3] + ' '
+print(f'{newprefix}↧ (decrypts to)')
+self.print_tree(cryptopayload, newprefix + '└', z, 0)
+
 def print_tree(self, z:Message, prefix:str, parent:Optional[Message], 
num:int) -> None:
 if (z.is_multipart()):
 self.print_part(z, prefix+'┬╴', parent, num)
@@ -88,6 +120,8 @@ class MimePrinter(object):
 def main() -> None:
 parser:ArgumentParser = ArgumentParser(description='Read RFC2822 MIME 
message from stdin and emit a tree diagram to stdout.',
epilog="Example: 
email-print-mime-structure < message.eml")
+parser.add_argument('--pgpkey', metavar='KEYFILE', action='append',
+help='OpenPGP Transferable Secret Key for decrypting')
 args:Namespace = parser.parse_args()
 msg:Union[Message, str, int, Any] = email.message_from_file(sys.stdin)
 
diff --git a/email-print-mime-structure.1.pod b/email-print-mime-structure.1.pod
index 03a8e29..209c725 100644
--- a/email-print-mime-structure.1.pod
+++ b/email-print-mime-structure.1.pod
@@ -21,6 +21,14 @@ something like "cat -n".
 
 =over 4
 
+=item B<--pgpkey=>I
+
+I should name an OpenPGP transferable secret key that is not
+password-protected.  If a PGP/MIME-encrypted message is found on
+standard input, this key will be tried for decryption.  May be used
+multiple times if you want to try decrypting with more than one secret
+key.
+
 =item B<--help>, B<-h>
 
 Show usage instructions.
-- 
2.24.0.rc1

Bug#943959: [PATCH 7/8] email-print-mime-structure: renamed MimePrinter.test() to print_tree()

[Daniel Kahn Gillmor]

No functional changes.  This is just a more readable function name.

Signed-off-by: Daniel Kahn Gillmor 
---
 email-print-mime-structure | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/email-print-mime-structure b/email-print-mime-structure
index c1476d2..33579a7 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -66,7 +66,7 @@ class MimePrinter(object):
 
 print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname} 
{nbytes:d} bytes')
 
-def test(self, z:Message, prefix:str, parent:Optional[Message], num:int) 
-> None:
+def print_tree(self, z:Message, prefix:str, parent:Optional[Message], 
num:int) -> None:
 if (z.is_multipart()):
 self.print_part(z, prefix+'┬╴', parent, num)
 if prefix.endswith('└'):
@@ -78,9 +78,9 @@ class MimePrinter(object):
 raise TypeError(f'parts was {type(parts)}, expected 
List[Message]')
 i = 0
 while (i < len(parts)-1):
-self.test(parts[i], prefix + '├', z, i+1)
+self.print_tree(parts[i], prefix + '├', z, i+1)
 i += 1
-self.test(parts[i], prefix + '└', z, i+1)
+self.print_tree(parts[i], prefix + '└', z, i+1)
 # FIXME: show epilogue?
 else:
 self.print_part(z, prefix+'─╴', parent, num)
@@ -93,7 +93,7 @@ def main() -> None:
 
 if isinstance(msg, Message):
 printer:MimePrinter = MimePrinter(args)
-printer.test(msg, '└', None, 0)
+printer.print_tree(msg, '└', None, 0)
 else:
 logging.error('Input was not an e-mail message')
 
-- 
2.24.0.rc1

Bug#943959: [PATCH 6/8] email-print-mime-structure: add another FIXME about bytecounting

[Daniel Kahn Gillmor]

Signed-off-by: Daniel Kahn Gillmor 
---
 email-print-mime-structure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/email-print-mime-structure b/email-print-mime-structure
index 98b35fe..c1476d2 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -61,6 +61,7 @@ class MimePrinter(object):
 payload:Union[List[Message], str, bytes, None] = z.get_payload()
 if not isinstance(payload, (str,bytes)):
 raise TypeError(f'expected payload to be either str or bytes, 
got {type(payload)}')
+# FIXME: it looks like we are counting chars here, not bytes:
 nbytes = len(payload)
 
 print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname} 
{nbytes:d} bytes')
-- 
2.24.0.rc1

Bug#943959: [PATCH 4/8] email-print-mime-structure: nbytes should show as a decimal integer

[Daniel Kahn Gillmor]

No functional changes.

Signed-off-by: Daniel Kahn Gillmor 
---
 email-print-mime-structure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/email-print-mime-structure b/email-print-mime-structure
index 38dc8d9..8fc8774 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -63,7 +63,7 @@ class MimePrinter(object):
 raise TypeError(f'expected payload to be either str or bytes, 
got {type(payload)}')
 nbytes = len(payload)
 
-print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname} 
{nbytes} bytes')
+print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname} 
{nbytes:d} bytes')
 
 def test(self, z:Message, prefix:str='') -> None:
 if (z.is_multipart()):
-- 
2.24.0.rc1

Bug#943959: [PATCH 5/8] email-print-mime-structure: Pass parent and nth child info during walk

[Daniel Kahn Gillmor]

No functional change.

This is preparatory work to be able to consider the structure of each
part and determine whether we should consider trying to decrypt it.

Signed-off-by: Daniel Kahn Gillmor 
---
 email-print-mime-structure | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/email-print-mime-structure b/email-print-mime-structure
index 8fc8774..98b35fe 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -42,7 +42,7 @@ class MimePrinter(object):
 def __init__(self, args:Namespace):
 self.args = args
 
-def print_part(self, z:Message, prefix:str) -> None:
+def print_part(self, z:Message, prefix:str, parent:Optional[Message], 
num:int) -> None:
 ofname:Optional[str] = z.get_filename()
 fname:str = '' if ofname is None else f' [{ofname}]'
 ocharset:Union[Charset, str, None] = z.get_charset()
@@ -65,9 +65,9 @@ class MimePrinter(object):
 
 print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname} 
{nbytes:d} bytes')
 
-def test(self, z:Message, prefix:str='') -> None:
+def test(self, z:Message, prefix:str, parent:Optional[Message], num:int) 
-> None:
 if (z.is_multipart()):
-self.print_part(z, prefix+'┬╴')
+self.print_part(z, prefix+'┬╴', parent, num)
 if prefix.endswith('└'):
 prefix = prefix.rpartition('└')[0] + ' '
 if prefix.endswith('├'):
@@ -77,12 +77,12 @@ class MimePrinter(object):
 raise TypeError(f'parts was {type(parts)}, expected 
List[Message]')
 i = 0
 while (i < len(parts)-1):
-self.test(parts[i], prefix + '├')
+self.test(parts[i], prefix + '├', z, i+1)
 i += 1
-self.test(parts[i], prefix + '└')
+self.test(parts[i], prefix + '└', z, i+1)
 # FIXME: show epilogue?
 else:
-self.print_part(z, prefix+'─╴')
+self.print_part(z, prefix+'─╴', parent, num)
 
 def main() -> None:
 parser:ArgumentParser = ArgumentParser(description='Read RFC2822 MIME 
message from stdin and emit a tree diagram to stdout.',
@@ -92,7 +92,7 @@ def main() -> None:
 
 if isinstance(msg, Message):
 printer:MimePrinter = MimePrinter(args)
-printer.test(msg, '└')
+printer.test(msg, '└', None, 0)
 else:
 logging.error('Input was not an e-mail message')
 
-- 
2.24.0.rc1

Bug#943959: [PATCH 1/8] email-print-mime-structure: refactor to a class

[Daniel Kahn Gillmor]

We will need to send arguments to the printer, so it's handy to wrap
the functionality in a class.

No functional changes.

This diff is probably best reviewed with whitespace changes ignored.

Signed-off-by: Daniel Kahn Gillmor 
---
 email-print-mime-structure | 82 +++---
 1 file changed, 42 insertions(+), 40 deletions(-)

diff --git a/email-print-mime-structure b/email-print-mime-structure
index 185173f..b78ae91 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -37,51 +37,53 @@ from typing import Optional, Union, List, Tuple, Any
 from email.charset import Charset
 from email.message import Message
 
-def print_part(z:Message, prefix:str) -> None:
-ofname:Optional[str] = z.get_filename()
-fname:str = '' if ofname is None else f' [{ofname}]'
-ocharset:Union[Charset, str, None] = z.get_charset()
-cset:str = '' if ocharset is None else f' ({ocharset})'
-disp:Union[List[Tuple[str,str]], List[str], None] = z.get_params(None, 
header='Content-Disposition')
-disposition:str = ''
-if (disp is not None):
-for d in disp:
-if d[0] in [ 'attachment', 'inline' ]:
-disposition = ' ' + d[0]
-nbytes:int
-if z.is_multipart():
-# FIXME: it looks like we are counting chars here, not bytes:
-nbytes = len(z.as_string())
-else:
-payload:Union[List[Message], str, bytes, None] = z.get_payload()
-if not isinstance(payload, (str,bytes)):
-raise TypeError(f'expected payload to be either str or bytes, got 
{type(payload)}')
-nbytes = len(payload)
+class MimePrinter(object):
+def print_part(self, z:Message, prefix:str) -> None:
+ofname:Optional[str] = z.get_filename()
+fname:str = '' if ofname is None else f' [{ofname}]'
+ocharset:Union[Charset, str, None] = z.get_charset()
+cset:str = '' if ocharset is None else f' ({ocharset})'
+disp:Union[List[Tuple[str,str]], List[str], None] = z.get_params(None, 
header='Content-Disposition')
+disposition:str = ''
+if (disp is not None):
+for d in disp:
+if d[0] in [ 'attachment', 'inline' ]:
+disposition = ' ' + d[0]
+nbytes:int
+if z.is_multipart():
+# FIXME: it looks like we are counting chars here, not bytes:
+nbytes = len(z.as_string())
+else:
+payload:Union[List[Message], str, bytes, None] = z.get_payload()
+if not isinstance(payload, (str,bytes)):
+raise TypeError(f'expected payload to be either str or bytes, 
got {type(payload)}')
+nbytes = len(payload)
 
-print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname} {nbytes} 
bytes')
+print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname} 
{nbytes} bytes')
 
-def test(z:Message, prefix:str='') -> None:
-if (z.is_multipart()):
-print_part(z, prefix+'┬╴')
-if prefix.endswith('└'):
-prefix = prefix.rpartition('└')[0] + ' '
-if prefix.endswith('├'):
-prefix = prefix.rpartition('├')[0] + '│'
-parts:Union[List[Message], str, bytes, None] = z.get_payload()
-if not isinstance(parts, list):
-raise TypeError(f'parts was {type(parts)}, expected List[Message]')
-i = 0
-while (i < len(parts)-1):
-test(parts[i], prefix + '├')
-i += 1
-test(parts[i], prefix + '└')
-# FIXME: show epilogue?
-else:
-print_part(z, prefix+'─╴')
+def test(self, z:Message, prefix:str='') -> None:
+if (z.is_multipart()):
+self.print_part(z, prefix+'┬╴')
+if prefix.endswith('└'):
+prefix = prefix.rpartition('└')[0] + ' '
+if prefix.endswith('├'):
+prefix = prefix.rpartition('├')[0] + '│'
+parts:Union[List[Message], str, bytes, None] = z.get_payload()
+if not isinstance(parts, list):
+raise TypeError(f'parts was {type(parts)}, expected 
List[Message]')
+i = 0
+while (i < len(parts)-1):
+self.test(parts[i], prefix + '├')
+i += 1
+self.test(parts[i], prefix + '└')
+# FIXME: show epilogue?
+else:
+self.print_part(z, prefix+'─╴')
 
 msg:Union[Message, str, int, Any] = email.message_from_file(sys.stdin)
 
 if isinstance(msg, Message):
-test(msg, '└')
+printer:MimePrinter = MimePrinter()
+printer.test(msg, '└')
 else:
 logging.error('Input was not an e-mail message')
-- 
2.24.0.rc1

Bug#943959: [PATCH 3/8] email-print-mime-structure: parse argments

[Daniel Kahn Gillmor]

This adds a -h and --help option, which is currently pretty useless.

But the argparse will become useful shortly.

Signed-off-by: Daniel Kahn Gillmor 
---
 email-print-mime-structure   | 9 -
 email-print-mime-structure.1.pod | 9 -
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/email-print-mime-structure b/email-print-mime-structure
index 5eb94e0..38dc8d9 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -33,11 +33,15 @@ import sys
 import email
 import logging
 
+from argparse import ArgumentParser, Namespace
 from typing import Optional, Union, List, Tuple, Any
 from email.charset import Charset
 from email.message import Message
 
 class MimePrinter(object):
+def __init__(self, args:Namespace):
+self.args = args
+
 def print_part(self, z:Message, prefix:str) -> None:
 ofname:Optional[str] = z.get_filename()
 fname:str = '' if ofname is None else f' [{ofname}]'
@@ -81,10 +85,13 @@ class MimePrinter(object):
 self.print_part(z, prefix+'─╴')
 
 def main() -> None:
+parser:ArgumentParser = ArgumentParser(description='Read RFC2822 MIME 
message from stdin and emit a tree diagram to stdout.',
+   epilog="Example: 
email-print-mime-structure < message.eml")
+args:Namespace = parser.parse_args()
 msg:Union[Message, str, int, Any] = email.message_from_file(sys.stdin)
 
 if isinstance(msg, Message):
-printer:MimePrinter = MimePrinter()
+printer:MimePrinter = MimePrinter(args)
 printer.test(msg, '└')
 else:
 logging.error('Input was not an e-mail message')
diff --git a/email-print-mime-structure.1.pod b/email-print-mime-structure.1.pod
index ab1ec05..03a8e29 100644
--- a/email-print-mime-structure.1.pod
+++ b/email-print-mime-structure.1.pod
@@ -19,7 +19,14 @@ something like "cat -n".
 
 =head1 OPTIONS
 
-None.
+=over 4
+
+=item B<--help>, B<-h>
+
+Show usage instructions.
+
+=back
+
 
 =head1 EXAMPLE
 
-- 
2.24.0.rc1

Bug#943959: [PATCH 2/8] email-print-mime-structure: put main() into its own function

[Daniel Kahn Gillmor]

No functional changes.  This is a refactoring commit to provide some
non-global scoping and easier readability.

Signed-off-by: Daniel Kahn Gillmor 
---
 email-print-mime-structure | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/email-print-mime-structure b/email-print-mime-structure
index b78ae91..5eb94e0 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -80,10 +80,14 @@ class MimePrinter(object):
 else:
 self.print_part(z, prefix+'─╴')
 
-msg:Union[Message, str, int, Any] = email.message_from_file(sys.stdin)
+def main() -> None:
+msg:Union[Message, str, int, Any] = email.message_from_file(sys.stdin)
 
-if isinstance(msg, Message):
-printer:MimePrinter = MimePrinter()
-printer.test(msg, '└')
-else:
-logging.error('Input was not an e-mail message')
+if isinstance(msg, Message):
+printer:MimePrinter = MimePrinter()
+printer.test(msg, '└')
+else:
+logging.error('Input was not an e-mail message')
+
+if __name__ == '__main__':
+main()
-- 
2.24.0.rc1

Bug#943959: mailscripts: add decryption capability for email-print-mime-structure

[Sean Whitton]

Hello,

On Sat 02 Nov 2019 at 12:15AM -04, Daniel Kahn Gillmor wrote:

> On Fri 2019-11-01 20:37:34 -0700, Sean Whitton wrote:
>> I've applied your first patch to my master.
>
> hm, i don't see this merge when i "git remote update origin" (where
> "origin" is https://git.spwhitton.name/mailscripts).  Could you push?

Sure, done.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#943991: behave: failing tests with python3.8

[Steve Langasek]

Package: behave
Version: 1.2.5-3
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Vincent,

The behave package fails to build from source in Ubuntu focal, because
Ubuntu has begun the transition to python3.8 and behave is not
source-compatible with python3.8:

[...]
ERROR: test_loads_hooks_and_step_definitions (test.test_runner.TestRunWithPaths)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.8_behave/build/test/test_runner.py", line 
597, in test_loads_hooks_and_step_definitions
self.runner.run_with_paths()
  File "/<>/.pybuild/cpython3_3.8_behave/build/behave/runner.py", 
line 693, in run_with_paths
return self.run_model()
  File "/<>/.pybuild/cpython3_3.8_behave/build/behave/runner.py", 
line 470, in run_model
self.setup_capture()
  File "/<>/.pybuild/cpython3_3.8_behave/build/behave/runner.py", 
line 424, in setup_capture
self.log_capture = LoggingCapture(self.config)
  File 
"/<>/.pybuild/cpython3_3.8_behave/build/behave/log_capture.py", 
line 74, in __init__
fmt = logging.Formatter(fmt, datefmt)
  File "/usr/lib/python3.8/logging/__init__.py", line 576, in __init__
self._style.validate()
  File "/usr/lib/python3.8/logging/__init__.py", line 428, in validate
if not self.validation_pattern.search(self._fmt):
TypeError: expected string or bytes-like object

[...]

  (https://launchpad.net/ubuntu/+source/behave/1.2.5-3/+build/17964504)

Debian has not yet started the transition to python3.8 - the version of
python3-defaults that adds python3.8 as supported is currently in
experimental - but this will eventually become a serious bug in Debian as
well once that transition begins.

For the moment I have worked around the failure in Ubuntu by changing the
packaging to test only against the current version of python3 and not
against all supported versions, but this is a very short-term fix given that
python3.8 will become the default in the next 6 months.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru behave-1.2.5/debian/control behave-1.2.5/debian/control
--- behave-1.2.5/debian/control 2019-09-13 05:45:20.0 -0700
+++ behave-1.2.5/debian/control 2019-11-01 22:03:19.0 -0700
@@ -5,7 +5,7 @@
 Uploaders: Debian Python Modules Team 

 Build-Depends: debhelper-compat (= 12),
dh-python,
-   python3-all,
+   python3,
python3-hamcrest,
python3-mock,
python3-nose,

Bug#943724: lintian: internal error in Lintian::files::empty_package::_set_is_dummy

[Felix Lechner]

Hi everyone,

On Wed, Oct 30, 2019 at 2:55 PM Thorsten Glaser  wrote:
>
> indeed, ... [my] script uses -o APT::Install-Recommends=true

Starting with the next release, your build experience will match ours.
Lintian now depends on libclass-xsaccessor-perl.

Thank you for your goodwill.

Kind regards,
Felix Lechner

Bug#943959: mailscripts: add decryption capability for email-print-mime-structure

[Daniel Kahn Gillmor]

On Fri 2019-11-01 20:37:34 -0700, Sean Whitton wrote:
> I've applied your first patch to my master.

hm, i don't see this merge when i "git remote update origin" (where
"origin" is https://git.spwhitton.name/mailscripts).  Could you push?

> The second patch is quite hard for me to review because your
> refactoring of the basic structure of the script is in the same commit
> as adding the new feature.  Could you split that into two or more
> commits, please?

yes, i'll do that and send the updated patches here.

thanks for the prompt review.

 --dkg


signature.asc
Description: PGP signature

Bug#943990: Fails to upgrade

[David Prévot]

Package: openvswitch-common
Version: 2.11.0+2019.06.25+git.9ebe795035+ds1-6
Severity: serious

Hi,

Recent packaging changes makes the package fails to upgrade:

$ LC_ALL=C sudo apt upgrade
[sudo] password for taffit: 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 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] 
Setting up openvswitch-common (2.11.0+2019.06.25+git.9ebe795035+ds1-6) ...
update-alternatives: error: alternative path 
/usr/lib/openvswitch-common/ovs-vswitchd doesn't exist
dpkg: error processing package openvswitch-common (--configure):
 installed openvswitch-common package post-installation script subprocess 
returned error exit status 2
dpkg: dependency problems prevent configuration of openvswitch-switch:
 openvswitch-switch depends on openvswitch-common (= 
2.11.0+2019.06.25+git.9ebe795035+ds1-6); however:
  Package openvswitch-common is not configured yet.

dpkg: error processing package openvswitch-switch (--configure):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.29-3) ...
Errors were encountered while processing:
 openvswitch-common
 openvswitch-switch
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Regards

David

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

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

Versions of packages openvswitch-common depends on:
ii  iproute2 5.3.0-1
ii  libc62.29-3
ii  libcap-ng0   0.7.9-2.1
ii  libssl1.11.1.1d-2
ii  libunbound8  1.9.4-2
ii  openssl  1.1.1d-2
ii  python3  3.7.5-1
ii  python3-six  1.12.0-2

openvswitch-common recommends no packages.

Versions of packages openvswitch-common suggests:
ii  ethtool  1:4.19-1

-- no debconf information


signature.asc
Description: PGP signature

Bug#943968: closed by gregor herrmann (Bug#943968: fixed in libipc-run-perl 20180523.0-2)

[gregor herrmann]

On Sat, 02 Nov 2019 00:15:06 +0100, Elrond wrote:

> Wow!
> Thanks for this really, really quick fix!

You're welcome, and it was quite easy :)

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Wir sind Helden: (Ode) An die Arbeit


signature.asc
Description: Digital Signature

Bug#943959: mailscripts: add decryption capability for email-print-mime-structure

[Sean Whitton]

Hello dkg,

On Fri 01 Nov 2019 at 03:36PM -04, Daniel Kahn Gillmor wrote:

> Attached are two patches for mailscripts that in combination permit
> decryption using OpenPGP Transferable Secret Keys that are found in the
> filesystem.
>
> I'm finding this particularly useful when i'm working on writing
> specifications and documentation that use (for example) the OpenPGP
> Sample Keys [0].

This is a cool feature.

I've applied your first patch to my master.  The second patch is quite
hard for me to review because your refactoring of the basic structure of
the script is in the same commit as adding the new feature.  Could you
split that into two or more commits, please?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#717595: Please check for update-rc.d "start" and "stop" argument usage

[Paul Wise]

Control: tags -1 - moreinfo

Since this problem is still an issue with packages in the archive (like
x11-common), it would be nice to have lintian warn about the issues.

On Tue, 17 Dec 2013 10:10:58 +0100 Bastien ROUCARIES wrote:

> I am willing to implement this test but could you please provide a description

A reasonable description was already provided in the mail:

   The update-rc.d "start" and "stop" arguments are obsoleted and
   replaced by the "defaults" argument.  It is no longer possible to
   specify start and stop runlevel and sequence numbers; these must be
   provided by the LSB header of every init script.  If start and/or
   stop arguments are provided, these now act as if "defaults" had been
   used instead, and the extra runlevel and sequence information is
   discarded, and a warning will be issued.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#936043: ITP: gitbatch -- Manage git repositories in one place

[anarcat]

On Thu, Aug 29, 2019 at 01:28:57PM +0200, Dawid Dziurla wrote:
>  Managing multiple git repositories is easier than ever. Often one would end
>  up working on many directories and manually pulling updates etc. To make
>  this routine faster, gitbatch was created, a simple tool to handle this job.
>  Although the focus is batch jobs, one can still do de facto micro management 
> of
>  git repositories (e.g add/reset, stash, commit etc.)
> 
> Useful tool for managing multiple git repositiories at once.
> Does not need additional dependencies, only those already in archive.

Oh. My. God. This looks gorgeous. Do you need any help?

On Thu, Aug 29, 2019 at 03:23:23PM +, Dmitry Bogatov wrote:
> Sounds like `myrepos'. What `gitbatch' does that is not possible with
> `myrepos'?

On Thu, Aug 29, 2019 at 09:36:01AM -0700, Don Armstrong wrote:
> It would be interesting to know how gitbatch compares to myrepos, as
> they seem to be operating in the same or similar spaces.

On Fri, Aug 30, 2019 at 12:54:43AM +0100, Ben Hutchings wrote:
> We already have "mr", which can do this for git and several other
> version control systems.  Does gitbatch offer anything new?

Did you look at the website? Did you look at the demo?

Just look at it!

https://asciinema.org/a/lxoZT6Z8fSliIEebWSPVIY8ct

This thing looks AWESOME! Don't get me wrong: I've been using myrepos
for years now and I'm a fan. But gitbatch just blew my mind: it does all
that mr does, but interactively, and with a new TUI!

Can't wait to see that land.

A.

-- 
Ou bien Dieu voudrait supprimer le mal, mais il ne le peut pas
Ou bien Dieu pourrait supprimer le mal, mais il ne le veut pas.
- Sébastien Faure


signature.asc
Description: PGP signature

Bug#943988: Usage message jumbled

[積丹尼 Dan Jacobson]

Package: iw
Version: 5.3-1
Severity: minor

$ iw
prints a usage message, but it should be more sorted, not jumbled.

Bug#943910: lintian: FTBFS in stretch-bpo: Cannot parse line Argument "1/8" isn't numeric in numeric eq (==) at /build/lintian-2.31.0/lib/Lintian/Processable/Pool.pm line 348.

[Felix Lechner]

Hi Andreas,

On Fri, Nov 1, 2019 at 2:47 PM Andreas Beckmann  wrote:
>
> ./lib/Lintian/Processable/Pool.pm:347:return scalar %{$self->groups} == 0;

I introduced the expression in commit fb7c6165. (The other line did
not break stretch.) Sorry about the massive inconvenience I caused
you.

Kind regards
Felix Lechner

Bug#941480: mediathekview: Please package the new version of mediathekview

[Markus Koschany]

On Wed, 2 Oct 2019 15:55:20 +0200 Markus Koschany  wrote:
> Hello,
> 
> Am 02.10.19 um 11:37 schrieb Eike Fokken:
> > Dear Markus,
> > 
> > thanks for the explanation, sounds tedious to package, thanks for your 
> > trouble!
> > For the workaround: I can find no such setting, can you direct me to it in 
> > detail?
> > 
> > Best
> > 
> > Eike
> 
> You can disable the search for new versions if you goto
> Datei->Einstellungen->Allgemein->einmal am Tag nach einer neuen
> Programmversion suchen.

I have just noticed that this setting was removed in 13.2.1. At the
moment the update check cannot be disabled. This should be fixed as well
when a newer version is packaged for Debian.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#940203: faudio: Update faudio to latest upstream version

[Jens Reyer]

On 02.11.19 00:55, Alistair Leslie-Hughes wrote:
> Is there any chance you could use version 19.11 that was just release?

Definitely, I'll prepare that upload shortly.
But I still lack the permissions to upload the package (working on it).

Greets
jre

Bug#943987: non-free file in "debian/missing-sources"

[Dmitry Smirnov]

Package: gitlab
Version: 12.2.9-1
Severity: serious
Usertags: dfsg


In most recent upload Utkarsh Gupta circumvented legitimate Lintian error


E: gitlab source: source-is-missing vendor/assets/javascripts/snowplow/sp.js 
line length is 32154 characters (>512)


by adding source-less pre-minified non-DFSG-compliant "sp.js" to "debian/
missing-sources".

-- 
Regards,
 Dmitry Smirnov

---


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

Bug#943860: munin-plugins-core: ntp_states plugin is broken in current package release

[devel]

Hello Jo-Jo,


Am Wed, 30 Oct 2019 22:11:46 +0100
schrieb Jo-Jo :

> Could you please ensure to have this fix in the package as soon as possible?

hehe - this plugin was broken for five years - no need to hurry :)
Anyway: I (being upstream) will publish another release in the next days. Thus
the fix should land in unstable quite soon.


> Thanks for the great work your doing!

Appreciated!
Thank you for your report!

Cheers,
Lars

Bug#940203: faudio: Update faudio to latest upstream version

[Alistair Leslie-Hughes]

Is there any chance you could use version 19.11 that was just release?

Bug#943986: wrong shared linkage position of mv's library dependency

[David Frey]

Package: coreutils
Version: 8.30-3
Severity: serious

cp and mv have a runtime linkage to libacl and libattr which are
installed in /usr/lib/x86_64-linux-gnu/.

This means that a single-user booted system without mounted /usr,
is not able to cp or mv files!

Either the dependancy should be dropped, or the libacl and libattr
shared libraries should be moved into /lib.

Thanks,
  David

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=english (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libc62.28-10
ii  libselinux1  2.8-1+b1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information
Mit freundlichen Grüssen,
  David Frey
-- 

Bug#943968: closed by gregor herrmann (Bug#943968: fixed in libipc-run-perl 20180523.0-2)

[Elrond]

Wow!


Thanks for this really, really quick fix!


Cheers

Elrond

Bug#943577: munin-plugins-core: sensors_ plugin unable to parse millivolt

[devel]

Control: tags -1 +fixed-upstream

Hello Andreas,


Am Fri, 1 Nov 2019 08:37:42 +0100
schrieb Andreas Pommer :

> > Please test, whether the changed plugin works for you.  
> 
> I tested the attached script. First, it resulted in several error messages. I
> realized that in the first line of the script the '!' was missing, [..]

oh - that was my manual mistake with the attachment :(
The plugins in the repository use a substitution pattern. It is correct, there.


> The 'volt1' line stayed there, it reported values below 1, and the output from
> 'config' stayed stable as well. Fixed!

great - thank you for testing!
I just merged the change upstream.

Cheers,
Lars

Bug#943985: Depends on volti, which is scheduled for removal

[Moritz Muehlenhoff]

Package: parl-desktop
Severity: serious

volti is scheduled for removal from the archive, the dependency needs to be
removed.

Bug#943984: rust-nix: Please include patch to add missing VMIN and VTIME on sparc64

[John Paul Adrian Glaubitz]

Source: rust-nix
Severity: normal
Tags: patch upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

On sparc64, the definitions for VMIN and VTIME in sys:termios are missing
making rust-rustyline failing to build from source. The attached patch
fixes that by creating the aliases for VEOF<=>VMIN and VEOL<=>VTIME, I have
already included the patch in a manual build of rust-nix in Debian Ports
which is why the rust-rustyline package currently builds fine but will
break again the moment rust-nix would be updated again without the fix.

Thus, it would be nice if the patch could be included until the next fixed
version of nix is released upstream which includes the fixes:

> https://github.com/nix-rust/nix/pull/1151
> https://github.com/nix-rust/nix/pull/1150

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Add missing alias definitions for VMIN and VTIME on sparc64
 On sparc and sparc64, VMIN and VTIME in termios are defined as
 aliases of VEOF and VTIME respectively. Thus, in order to be able
 to use VMIN and VTIME in other packages like rustyline, we need to
 add this alias definitions in nix as well. Since enums cannot have
 the same numerical value defined twice, we use associated constants
 to define the aliases for VEOF and VEOL in SpecialCharacterIndices.
 .
Author: John Paul Adrian Glaubitz 

---

Forwarded: https://github.com/nix-rust/nix/pull/1151
Forwarded: https://github.com/nix-rust/nix/pull/1150
Last-Update: 2019-11-01

Index: rust-nix-0.15.0/src/sys/termios.rs
===
--- rust-nix-0.15.0.orig/src/sys/termios.rs
+++ rust-nix-0.15.0/src/sys/termios.rs
@@ -583,6 +583,13 @@ libc_enum! {
 }
 }
 
+impl SpecialCharacterIndices {
+#[cfg(all(target_os = "linux", target_arch = "sparc64"))]
+pub const VMIN: SpecialCharacterIndices = SpecialCharacterIndices::VEOF;
+#[cfg(all(target_os = "linux", target_arch = "sparc64"))]
+pub const VTIME: SpecialCharacterIndices = SpecialCharacterIndices::VEOL;
+}
+
 pub use libc::NCCS;
 #[cfg(any(target_os = "dragonfly",
   target_os = "freebsd",

Bug#943962: [debian-mysql] Bug#943962: mariadb-server-10.3: mysqld crashes and hangs, no longer processing requests

[Richard van den Berg]

On 01/11/2019 22:18, Otto Kekäläinen wrote:
> Did you report this bug upstream (as the output said "To report this
> bug, see https://mariadb.com/kb/en/reporting-bugs;). This is unlikely
> related to the packaging done in Debian.

I did not report this upstream yet. The proper thing to do with these
type of crashes is to provide a gdb trace. Unfortunately I am not able
to find dbg versions of the mariadb-server-10.3 and
mariadb-server-core-10.3 debian packages. Are they available somewhere?

Kind regards,

Richard

Bug#943983: RM: gtk-recordmydesktop -- RoQA; dead upstream, unmaintained, depends on legacy libs

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove gtk-recordmydesktop. It's dead upstream (no activity after 2010), 
depends
on legacy libs (pygtk, Python 2) and is unmaintained (last upload in 2011).

Cheers,
Moritz

Bug#943870: Fix

[JanKusanagi]

This started happening with some change to Qt, maybe by... 5.12? where
having "phonon4qt5" in the QT += line stopped generating the Makefile
correctly.

The workaround, assuming they don't re-enable that behavior in Qt, is to
add the line:

LIBS += -lphonon4qt5

somewhere in Auralquiz.pro; right after the other LIBS line, or at the
end, would work.



--
Development blog: https://jancoding.wordpress.com

Bug#943982: RM: prey -- RoQA; Depends on obsolete libs

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove prey, it depends on pygtk/Python 2 and is unmaintained
(no upload since almost six years).

Cheers,
Moritz

Bug#942114: ganeti-instance-debootstrap: diff for NMU version 0.16-6.1

[anarcat]

Control: tags 942114 + pending

Dear maintainer,

I've prepared an NMU for ganeti-instance-debootstrap (versioned as 0.16-6.1) and
uploaded it to DELAYED/02. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru ganeti-instance-debootstrap-0.16/debian/changelog ganeti-instance-debootstrap-0.16/debian/changelog
--- ganeti-instance-debootstrap-0.16/debian/changelog	2018-06-20 06:57:18.0 -0400
+++ ganeti-instance-debootstrap-0.16/debian/changelog	2019-11-01 19:01:50.0 -0400
@@ -1,3 +1,10 @@
+ganeti-instance-debootstrap (0.16-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * add patch to respect linux caps (Closes: #942114)
+
+ -- Antoine Beaupré   Fri, 01 Nov 2019 19:01:50 -0400
+
 ganeti-instance-debootstrap (0.16-6) unstable; urgency=medium
 
   * Bump Standards-Version to 4.1.4; no changes needed
diff -Nru ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch
--- ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch	1969-12-31 19:00:00.0 -0500
+++ ganeti-instance-debootstrap-0.16/debian/patches/respect-Linux-capabilities-7-in-cache.patch	2019-11-01 19:01:50.0 -0400
@@ -0,0 +1,48 @@
+From cd34bcc48a2af92f484535b81fba2d46dad1dbb6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Thu, 10 Oct 2019 11:07:51 -0400
+Subject: [PATCH] respect Linux capabilities(7) in cache
+
+The default GNU tar configuration does not carry fancy extended
+attributes and that is where, among other things, stuff like Linux
+capabilities(7) are stored. This is kind of important because that's
+how ping(8) works for regular users.
+
+We shove --selinux and --acls in there while we're at it, because why
+not. We never know what the future might bring, and it seems
+silly *not* to create a complete archive.
+
+Note that --xattrs-include='*' is important because, by default, GNU
+tar will not include capabilities /even/ if --xattrs is specified on
+the commandline, see this bug report for details:
+
+https://bugzilla.redhat.com/show_bug.cgi?id=771927
+---
+ create | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/create b/create
+index 607bab2..7526e71 100755
+--- a/create
 b/create
+@@ -83,7 +83,7 @@ if [ "$CLEAN_CACHE" -a -d "$CACHE_DIR" ]; then
+ fi
+ 
+ if [ -f "$CACHE_FILE" ]; then
+-  tar xf "$CACHE_FILE" -C $TMPDIR
++  tar --acls --selinux --xattrs --xattrs-include='*' -x -f "$CACHE_FILE" -C $TMPDIR
+ else
+   if [ "$PROXY" ]; then
+ export http_proxy="$PROXY"
+@@ -109,7 +109,7 @@ else
+ 
+   if [ "$GENERATE_CACHE" = "yes" ]; then
+ TMP_CACHE=`mktemp "${CACHE_FILE}.XX"`
+-tar cf "$TMP_CACHE" -C $TMPDIR .
++tar --acls --selinux --xattrs --xattrs-include='*' -c -f "$TMP_CACHE" -C $TMPDIR .
+ mv -f "$TMP_CACHE" "$CACHE_FILE"
+   fi
+ fi
+-- 
+2.20.1
+
diff -Nru ganeti-instance-debootstrap-0.16/debian/patches/series ganeti-instance-debootstrap-0.16/debian/patches/series
--- ganeti-instance-debootstrap-0.16/debian/patches/series	2018-06-20 06:57:18.0 -0400
+++ ganeti-instance-debootstrap-0.16/debian/patches/series	2019-11-01 19:01:50.0 -0400
@@ -1 +1,2 @@
+respect-Linux-capabilities-7-in-cache.patch
 fix-sfdisk-BLKRRPART.patch


signature.asc
Description: PGP signature

Bug#943981: Proposal: Switch to cgroupv2 by default

[Noah Meyerhans]

Package: systemd
Severity: wishlist
Version: 242-7
Tags: patch

I'd like to propose that we switch to cgroupv2 as the default
configuration for the bullseye release.  This has the potential to
impact quite a few packages (notably, it breaks Docker today), so I
don't think it can be done without engaging with a broader subsection of
the developer community, but this seems like a reasonable place to
start.  By making this transition soon, I expect that we can iron out
the issues well in advance of the bullseye release.

Detailed documentation of cgroupv2 can be found at
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html, with
rationales and comparison against v1 documented under the "Issues with
v1 and Rationales for v2" heading.

>From systemd's perspective, the switch may be as simple as adding
"-Ddefault-hierarchy=unified" to the configuration options in
debian/rules.  A minimal patch to implement this change is attached.

Thanks
noah

diff -ur systemd-242/debian/rules systemd-242-8~cgroupv2/debian/rules
--- systemd-242/debian/rules	2019-09-04 17:34:17.0 +
+++ systemd-242-8~cgroupv2/debian/rules	2019-11-01 22:31:54.575052213 +
@@ -74,7 +74,8 @@
 	-Dnobody-group=nogroup \
 	-Dbump-proc-sys-fs-nr-open=false \
 	-Ddev-kvm-mode=0660 \
-	-Dgroup-render-mode=0660
+	-Dgroup-render-mode=0660 \
+	-Ddefault-hierarchy=unified
 
 # resolved's DNSSEC support is still not mature enough, don't enable it by
 # default on stable Debian or any Ubuntu releases

Bug#943980: RM: pythoncad -- RoQA; unmaintained, dead upstream, depends on legacy libs

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pythoncad. It depends on legacy code bases (pygtk, Python 2, 
python-gobject)
and is dead upstream. It's also unmaintained (last upload in 2011 and the last 
uploader
is asked to be removed from the MIA team, #866917)

Cheers,
Moritz

Bug#938816: webtest: Python2 removal in sid/bullseye

[Steve Langasek]

Package: webtest
Followup-For: Bug #938816
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hello,

Here is a patch, based on webtest 2.0.28-1, that drops python2 support. 
This has been verified to build successfully, and has been uploaded to
Ubuntu on account of the removal of python-waitress.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru webtest-2.0.28/debian/control webtest-2.0.28/debian/control
--- webtest-2.0.28/debian/control   2017-09-29 03:52:31.0 -0700
+++ webtest-2.0.28/debian/control   2019-11-01 13:43:27.0 -0700
@@ -4,33 +4,17 @@
 Maintainer: Debian Python Modules Team 

 Uploaders: Piotr Ożarowski 
 Build-Depends: debhelper (>= 9)
-Build-Depends-Indep: dh-python, python-all, python3-all,
- python-setuptools, python-webob,
+Build-Depends-Indep: dh-python, python3-all,
  python3-setuptools, python3-webob,
 # docs & tests
  python3-sphinx, python3-six, python3-bs4, python3-waitress,
 # tests
 # python-unittest2, python-pyquery
 Standards-Version: 4.1.1
-X-Python-Version: >=2.6
 Homepage: http://pythonpaste.org/webtest/
 Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/webtest.git
 Vcs-Browser: 
https://anonscm.debian.org/cgit/python-modules/packages/webtest.git
 
-Package: python-webtest
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}, python-webob (>= 1.2),
- python-six, python-waitress (>= 0.8.5), python-bs4,
- python-paste (>= 1.7.1), python-pastedeploy
-Recommends: python-lxml, python-pyquery
-Suggests: python-webtest-doc
-Description: wraps any WSGI application and makes it easy to test
- WebTest helps you test your WSGI-based web applications. This can be any
- application that has a WSGI (Web Server Gateway Interface) interface,
- including an application written in a framework that supports WSGI (which
- includes most actively developed Python web frameworks – almost anything
- that even nominally supports WSGI should be testable).
-
 Package: python3-webtest
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}, python3-webob,
diff -Nru webtest-2.0.28/debian/python-webtest-doc.links 
webtest-2.0.28/debian/python-webtest-doc.links
--- webtest-2.0.28/debian/python-webtest-doc.links  2017-09-29 
03:52:16.0 -0700
+++ webtest-2.0.28/debian/python-webtest-doc.links  2019-11-01 
13:43:27.0 -0700
@@ -1,4 +1,2 @@
-/usr/share/doc/python-webtest-doc/ /usr/share/doc/python-webtest/html
-/usr/share/doc/python-webtest-doc/_sources /usr/share/doc/python-webtest/rst
 /usr/share/doc/python-webtest-doc/ /usr/share/doc/python3-webtest/html
 /usr/share/doc/python-webtest-doc/_sources /usr/share/doc/python3-webtest/rst
diff -Nru webtest-2.0.28/debian/rules webtest-2.0.28/debian/rules
--- webtest-2.0.28/debian/rules 2017-09-29 03:52:31.0 -0700
+++ webtest-2.0.28/debian/rules 2019-11-01 13:43:27.0 -0700
@@ -5,7 +5,7 @@
 export PYBUILD_DISABLE=test
 
 %:
-   dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+   dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_install:
dh_auto_install --buildsystem=pybuild

Bug#943979: postgresql-12-pg-checksums: Shouldn't it upgrade to this version when upgrading to postgresql.*-12?

[Diederik de Haas]

Package: postgresql-12-pg-checksums
Version: 1.0-2
Severity: minor

I just upgraded my postgresql packages from version 11 to 12, but this
package wasn't upgraded with it, I had to manually install it.
Not a problem in itself, but it makes sense to me if it was upgraded
alongside the other postgresql packages.

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

Kernel: Linux 5.3.0-1-amd64 (SMP w/16 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages postgresql-12-pg-checksums depends on:
ii  libc6  2.29-3
ii  postgresql-12  12.0-1+b1

Versions of packages postgresql-12-pg-checksums recommends:
ii  pg-checksums-doc  1.0-2

postgresql-12-pg-checksums suggests no packages.

-- no debconf information

Bug#941018: ibus 1.5.21-1 does not work with qt5 applications

[Gunnar Hjalmarsson]

On 2019-10-30 16:04, Simon McVittie wrote:

I was hoping to let glib2.0 get some testing in unstable before
backporting anything.


That makes sense, of course. OTOH backporting takes time, so preparing 
for that in the meantime can't hurt.


Want to mention that we have started the backporting work on the Ubuntu 
side. We chose to include 
gcredentialsprivate-Document-the-various-private-macros.patch. As 
regards Add-a-test-for-GDBusServer-authentication.patch we failed, at 
least so far, to apply it on glib 2.48 (Ubuntu 16.04), but it's included 
in proposed uploads for more recent Ubuntu releases.


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

Bug#943977: RM: kiwi -- RoQA; unmaintained, dead upstream, depends on legacy libs

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove kiwi. It depends on Python 2 and pygtk, there are no reverse 
dependencies
left, it's unmaintained (last maintainer upload in 2008) and the upstream 
website
vanished from the net.

Cheers,
Moritz

Bug#943978: Obsolete Suggests: on python-kiwi

[Moritz Muehlenhoff]

Package: python3-ns3
Severity: normal

python3-ns3 was switched to Python 3, but still Suggests: python-kiwi (which is
going away, so simply remove it entirely)

Cheers,
Moritz

Bug#943976: Should smart be removed?

[Moritz Muehlenhoff]

Source: smart
Severity: serious

Should smart be removed? It depends on Python 2 and pygtk, which are going away,
and it's dead upstream (last release from 2011).

Cheers,
Moritz

Bug#943975: RM: tictactoe-ng -- RoQA; dead upstream, unmaintained, depends on legacy libs

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove tictactoe-ng. It depends on legacy code bases (pygtk, 
python-gobject,
Python 2), is dead upstream and hasn't seen a maintainer upload in a decade.

Cheers,
Moritz

Bug#943974: mariadb-server-10.3: as "service mysql stop" fails, system refuse to shut down

[valette]

Package: mariadb-server-10.3
Version: 1:10.3.18-1
Severity: critical
Justification: breaks the whole system

after upgrade, each time I want to shut down, I get stuck in the shutdown
of mariadb database, that hangs forever.

Manually calling service stop for this service also hangs, as well as removal
propcedure as it aslo contains a service stop.

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

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

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.73
pn  galera-3  
ii  gawk  1:4.2.1+dfsg-1.1
ii  iproute2  5.3.0-1
ii  libc6 2.29-3
ii  libdbi-perl   1.642-1+b2
ii  libgnutls30   3.6.10-3
ii  libpam0g  1.3.1-5
ii  libstdc++69.2.1-16
ii  lsb-base  11.1.0
ii  lsof  4.93.2+dfsg-1
pn  mariadb-client-10.3   
ii  mariadb-common1:10.3.18-1
pn  mariadb-server-core-10.3  
ii  passwd1:4.7-2
ii  perl  5.30.1~rc1-1
ii  psmisc23.2-1+b1
ii  rsync 3.1.3-8
ii  socat 2.0.0~beta9-1
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages mariadb-server-10.3 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.3 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1+b1
ii  mailutils [mailx]  1:3.7-2
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

Bug#943956: snakemake: please make the build reproducible

[Chris Lamb]

forwarded 943956 https://github.com/snakemake/snakemake/pull/80
thanks

I've forwarded this upstream here:

  https://github.com/snakemake/snakemake/pull/80


Regards,

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

Bug#943973: RM: directoryassistant -- RoQA; dead upstream, depends on legacy libs, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove directoryassistant. It's dead upstream (last release/activity 
from 2011),
depends on legacy codebases (pygtk, Python 2) and hasn't seen a maintainer 
upload since 2005.

Cheers,
Moritz

Bug#942238: installer: update apt sources for security

[Holger Wansing]

Control: tags -1 + pending

Holger Wansing  wrote:
> Control: tags -1 + patch
> 
> Holger Wansing  wrote:
> > 
> > Pavel Kosina  wrote:
> > > Package: installation-guide-amd64
> > > Severity: normal
> > > 
> > > Dear Maintainer,
> > > 
> > > *** Reporter, please consider answering these questions, where 
> > > appropriate ***
> > > 
> > >* What led up to the situation?
> > > In installation of debian 10, testing, there is bad entry to
> > > /etc/apt/sources.list - installation procedure reports error when trying
> > > contact old security repository (up to 9).
> > > 
> > > The instalation procedure should use the new one:
> > > deb http://security.debian.org testing-security main contrib non-free
> > > deb-src http://security.debian.org testing-security main contrib non-free
> > 
> > Despite being reported against the installation-guide, the reported problem
> > is in the installer/the installed system and thus 'apt-setup'. 
> > The installation-guide also needs an update though.
> > 
> > So clone, retitle and assigning to apt-setup.
> 
> Also, I created a patch for apt-setup (attached).

Just committed. 
Tagging this bug as pending.

Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#855151: #855151: tasksel: should not be Priority: important

[Holger Wansing]

Control: tags -1 + pending

Holger Levsen  wrote:
> On Wed, Oct 23, 2019 at 11:52:22PM +0200, Holger Wansing wrote:
> > > > tasksel is currently at Priority: important and thus installed in every
> > > > installation, including chroots installed via debootstrap.  It doesn't
> > > > seem a useful package to install in chroots though.
> > > > 
> > > > It would be nice if d-i would install tasksel (and maybe remove it at
> > > > the end of the installation again?) so the priority of the tasksel and
> > > > tasksel-data packages could be downgraded.
> > > I think that's indeed a fair topic for the buster release cycle.
> > Should we downgrade tasksel to something like optional now?
> 
> now indeed seems to be a good moment for this. (and I'd appreciate this
> change for the reasons Ansgar pointed out.)

Just committed, thanks.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#943972: akonadi-backend-sqlite: expermental version impossible to install due to old qt dependency

[valette]

Package: akonadi-backend-sqlite
Version: 4:18.08.3-10
Severity: grave
Justification: renders package unusable

apt-get -t experimental install akonadi-backend-sqlite
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances   
Lecture des informations d'état... Fait
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation : 

Les paquets suivants contiennent des dépendances non satisfaites :
 akonadi-backend-sqlite : Dépend: qtbase-abi-5-11-3 mais il n'est pas 
installable



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

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

Versions of packages akonadi-backend-sqlite depends on:
ii  libc6 2.29-3
ii  libgcc1   1:9.2.1-16
ii  libqt5core5a [qtbase-abi-5-12-5]  5.12.5+dfsg-2
ii  libqt5sql55.12.5+dfsg-2
ii  libqt5sql5-sqlite 5.12.5+dfsg-2
ii  libsqlite3-0  3.30.1-1
ii  libstdc++69.2.1-16

Versions of packages akonadi-backend-sqlite recommends:
ii  akonadi-server  4:18.08.3-7+b1

akonadi-backend-sqlite suggests no packages.

-- no debconf information

Bug#943971: RM: virtualbricks -- RoQA; depends on legacy libs, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove virtualbricks. It depends on legacy libs (gksu, python-imaging,
python2, pygtk) and is unmaintained (last upload in 2015, dropped from testing
since almost two years)

Cheers,
Moritz

Bug#943970: debmirror: Debmirror fails to verify valid, signed InRelease files

[John Bazik]

Package: debmirror
Version: 1:2.32
Severity: important

Dear Maintainer,

When debmirror splits InRelease files using split_clearsigned_file, it can 
produce text and signature files that gpgv reports as having a "BAD signature." 
 Yet gpgv reports "Good signature" for the original InRelease file, by itself.  
What I found is that most files work but some do not.  Attached is a standalone 
split command, using the code from debmirror.  This is what I see when I test 
the debian-archive wheezy-backports InRelease file:

# md5sum wheezy-inrelease
a3f7caeef19f3e3797ec08748409d413  wheezy-inrelease
# head -n 20 wheezy-inrelease
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Origin: Debian Backports
Label: Debian Backports
Suite: wheezy-backports
Version: 
Codename: wheezy-backports
Date: Wed, 24 Jan 2018 08:51:34 UTC
NotAutomatic: yes
ButAutomaticUpgrades: yes
Architectures: amd64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips 
mipsel powerpc s390 s390x sparc
Components: main contrib non-free
Description: Backports for the Wheezy Distribution
MD5Sum:
 21206181d8c101b785f51c82820acef7   118763 contrib/Contents-amd64
 85c8255dffc0437f45d71e2e0d27401b 2704 contrib/Contents-amd64.diff/Index
 01c60695e6465dc1a3f2035d7060de5710211 contrib/Contents-amd64.gz
 01d265b9bcabbad6969c560a6955089072100 contrib/Contents-armel
 e03cee735398401fedf5b505fdc0cdbc 1720 contrib/Contents-armel.diff/Index
# gpgv --keyring /usr/share/keyrings/debian-archive-keyring.gpg --keyring 
/usr/share/keyrings/debian-archive-removed-keys.gpg -v wheezy-inrelease
gpgv: armor header: Hash: SHA256
gpgv: original file name=''
gpgv: Signature made Wed 24 Jan 2018 03:51:53 AM EST
gpgv:using RSA key A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553
gpgv: Good signature from "Debian Archive Automatic Signing Key (7.0/wheezy) 
"
gpgv: textmode signature, digest algorithm SHA256, key algorithm rsa4096
gpgv: Signature made Wed 24 Jan 2018 03:51:53 AM EST
gpgv:using RSA key 126C0D24BD8A2942CC7DF8AC7638D0442B90D010
gpgv: Good signature from "Debian Archive Automatic Signing Key (8/jessie) 
"
gpgv: textmode signature, digest algorithm SHA256, key algorithm rsa4096
# ./split_clearsigned_file wheezy-inrelease 
# gpgv --keyring /usr/share/keyrings/debian-archive-keyring.gpg --keyring 
/usr/share/keyrings/debian-archive-removed-keys.gpg -v wheezy-inrelease-sig 
wheezy-inrelease-txt 
gpgv: Signature made Wed 24 Jan 2018 03:51:53 AM EST
gpgv:using RSA key A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553
gpgv: BAD signature from "Debian Archive Automatic Signing Key (7.0/wheezy) 
"
gpgv: textmode signature, digest algorithm SHA256, key algorithm rsa4096

It does not always fail in this way.  The jessie-backports InRelease file works 
fine.

Here's the source I used for split_clearsigned_file:

#!/usr/bin/perl -w
# isolate split_clearsigned_file from debmirror

my $infile = $ARGV[0];
open my $sfd, '>', "$infile-sig" or die "$infile-sig\n";
open my $tfd, '>', "$infile-txt" or die "$infile-txt\n";

split_clearsigned_file($infile, $tfd, $sfd) or die "split failed\n";

# Split a clearsigned message into data and signature.
# Based on the similar SplitClearSignedFile in APT.
sub split_clearsigned_file {
  my ($filename, $content_fh, $signature_fh) = @_;
  my $found_message_start = '';
  my $found_message_end = '';
  my $skip_until_empty_line = '';
  my $found_signature = '';
  my $first_line = 1;
  my $signed_message_not_on_first_line = '';
  my $found_garbage = '';
  open my $handle, "<", $filename or die "can't open $filename: $1";
  while (my $line = <$handle>) {
$line =~ s/[\n\r]+$//;
if (not $found_message_start) {
  if ($line eq '-BEGIN PGP SIGNED MESSAGE-') {
$found_message_start = 1;
$skip_until_empty_line = 1;
  } else {
$signed_message_not_on_first_line = 1;
$found_garbage = 1;
  }
} elsif ($skip_until_empty_line) {
  if ($line eq '') {
$skip_until_empty_line = '';
  }
} elsif (not $found_signature) {
  if ($line eq '-BEGIN PGP SIGNATURE-') {
$found_signature = 1;
$found_message_end = 1;
print $signature_fh "$line\n";
  } elsif (not $found_message_end) {  # we are in the message block
# We don't have any fields that need to be dash-escaped, but
# implementations are free to encode all lines.
$line =~ s/^- //;
if ($first_line) {  # first line does not need a newline
  $first_line = '';
} else {
  print $content_fh "\n";
}
print $content_fh $line;
  } else {
$found_garbage = 1;
  }
} else {
  print $signature_fh "$line\n";
  if ($line eq '-END PGP SIGNATURE-') {
$found_signature = '';
  }
}
  }

  $content_fh->flush;
  $signature_fh->flush;

  if ($found_message_start) {
if ($signed_message_not_on_first_line) {
  die "Clearsigned file '$filename' does not 

Bug#943842: RFS: notepadqq/2.0.0~beta1-1 [ITP] -- Notepad++-like editor for Linux

[Adam Borowski]

On Wed, Oct 30, 2019 at 06:09:12PM +0100, Alessandro Grassi wrote:
>  * Package name: notepadqq
>Version : 2.0.0~beta1-1
>  * URL : http://notepadqq.altervista.org
>  * Vcs : https://github.com/notepadqq/notepadqq

> It builds those binary packages:

> Changes since the last upload:
> 
+ notepadqq (2.0.0~beta1-1) unstable; urgency=low
+
>[ Alessandro Grassi ]
>* Initial release. Closes: #740809
+
+ -- Alessandro Grassi   Fri, 18 Oct 2019 22:23:25 +0200

That bracketed part is redundant.


The package seems to work, but I'm afraid that the copyright file needs
work.  (Yeah, I hate hate hate that, but we're too small fish to ignore
nonsensical laws.)  For example:
* icons are LGPL 2014 Uri Herrera  and others
* "codemirror mode D" is BSL 2007-2009 Digital Mars
and probably more.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#943910: lintian: FTBFS in stretch-bpo: Cannot parse line Argument "1/8" isn't numeric in numeric eq (==) at /build/lintian-2.31.0/lib/Lintian/Processable/Pool.pm line 348.

[Felix Lechner]

Hi Andreas,

On Fri, Nov 1, 2019 at 2:47 PM Andreas Beckmann  wrote:
>
> ./lib/Lintian/DepMap.pm:162:unless ($parents || scalar 
> %{$self->{'nodes'}{$node}{'parents'}}) {
> ./lib/Lintian/Processable/Pool.pm:347:return scalar %{$self->groups} == 0;

Wow, I saw the second one and almost inserted 'keys' because it is
easier to read. Please file an MR with Lintian, if you have time. Your
authorship and hard detective work should be recognized. Thanks so
much!

Kind regards,
Felix Lechner

Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package

[Holger Wansing]

Hi,

Ben Hutchings  wrote:
> > That looks reasonable.
> > I have prepared a proposal for this:
> 
> The new text looks good to me.
> 
> [...]
> > > Also, this should be an error message, not a question.
> > 
> > For this, I would need some help, since I'm lacking the needed skills there.
> > The relevant part of anna.c seems to be:
> []
> > if (!kernel_packages_present) {
> > di_log(DI_LOG_LEVEL_WARNING, "no packages matching running 
> > kernel %s in archive", running_kernel);
> > #ifdef __GNU__
> > /* GNU Mach does not have modules */
> > #else
> > debconf_input(debconf, "critical", "anna/no_kernel_modules");
> > if (debconf_go(debconf) == 30)
> > return 0;
> > debconf_get(debconf, "anna/no_kernel_modules");
> > if (strcmp(debconf->value, "false") == 0)
> > return 0;
> 
> I think that for an error message the above 5 lines (after
> debconf_input(...)) can be changed to:
> 
>   debconf_go(debconf);
>   return 0;

A patch is attached.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/anna.c b/anna.c
index e03d34a..3e4552f 100644
--- a/anna.c
+++ b/anna.c
@@ -57,11 +57,8 @@ int packages_ok (di_packages *packages) {
 		/* GNU Mach does not have modules */
 #else
 		debconf_input(debconf, "critical", "anna/no_kernel_modules");
-		if (debconf_go(debconf) == 30)
-			return 0;
-		debconf_get(debconf, "anna/no_kernel_modules");
-		if (strcmp(debconf->value, "false") == 0)
-			return 0;
+		debconf_go(debconf);
+		return 0;
 #endif
 	}
 
diff --git a/debian/anna.templates b/debian/anna.templates
index 66677ee..1c95573 100644
--- a/debian/anna.templates
+++ b/debian/anna.templates
@@ -63,17 +63,16 @@ _Description: Failed to load installer component
  Loading ${PACKAGE} failed for unknown reasons. Aborting.
 
 Template: anna/no_kernel_modules
-Type: boolean
-Default: false
+Type: error
 # :sl2:
-_Description: Continue the install without loading kernel modules?
+_Description: No kernel modules found
  No kernel modules were found. This probably is due to a mismatch between
  the kernel used by this version of the installer and the kernel version
  available in the archive.
  .
- If you're installing from a mirror, you can work around this problem by
- choosing to install a different version of Debian. The install will probably
- fail to work if you continue without kernel modules.
+ You should make sure that your installation image is current (check if you
+ are using an up-to-date netboot image), or - if that's the case - try a
+ different mirror, preferably deb.debian.org.
 
 Template: anna/retriever
 Type: string
diff --git a/debian/changelog b/debian/changelog
index 806f59e..b2671e2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+anna (1.73) UNRELEASED; urgency=medium
+
+  * Change template, to give a senseful message to the user, when no kernel
+modules can be found with netboot image. Also, turn that from a question
+into an error message.
+
+ -- Holger Wansing   Fri, 01 Nov 2019 22:52:30 +0100
+
 anna (1.72) unstable; urgency=medium
 
   * Team upload

Bug#943969: RM: disk-manager -- RoQA; dead upstream, unmaintained, depends on legacy libs

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove disk-manager. It's dead upstream (no activity after 2011), 
unmaintained
(last upload in 2011) and depends on software scheduled for removal (pygtk, 
Python 2)

Cheers,
Moritz

Bug#943968: libipc-run-perl: Please add Multi-Arch: foreign

[Elrond]

Package: libipc-run-perl
Version: 20180523.0-1
Severity: wishlist
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

Hi,

It looks like libipc-run-perl offers an architecture
independent interface to its users.

See #872088 where this was already requested for
libwww-perl and accepted.

Would you mind setting it to Multi-Arch: foreign?  It's
usually a matter of adding one line to debian/control.


Cheers

Elrond

Bug#943910: lintian: FTBFS in stretch-bpo: Cannot parse line Argument "1/8" isn't numeric in numeric eq (==) at /build/lintian-2.31.0/lib/Lintian/Processable/Pool.pm line 348.

[Andreas Beckmann]

On 01/11/2019 06.17, Felix Lechner wrote:
> I did not intentionally use features of newer Perls, but it's possible
> that it plays a role.

Found it:
https://perldoc.perl.org/perl5260delta.html#scalar(%25hash)-return-signature-changed

stretch$ perl -e '%a = (1,2,3); print scalar %a, " -- ", scalar keys %a, "\n";'
2/8 -- 2

buster$ perl -e '%a = (1,2,3); print scalar %a, " -- ", scalar keys %a, "\n";'
2 -- 2

Some documentation of the old behavior:
https://www.perlmonks.org/?node=perldata
"If you evaluate a hash in a scalar context, it returns a value that is true if 
and only if the hash contains any key/value pairs. (If there are any key/value 
pairs, the value returned is a string consisting of the number of used buckets 
and the number of allocated buckets, separated by a slash. ..."


A backwards compatible solution should be the use of "scalar keys %hash"
(which also occurs about a dozen times in the code).
I only found two obvious occurrences of "scalar %hash" in current git master:

./lib/Lintian/DepMap.pm:162:unless ($parents || scalar 
%{$self->{'nodes'}{$node}{'parents'}}) {
./lib/Lintian/Processable/Pool.pm:347:return scalar %{$self->groups} == 0;

Andreas

PS: backporting coreutils 8.30 to stretch locally was a trivial no-change 
rebuild
PPS: I'll now try a 2.32.0 stretch backport with the above "keys" fix and 
locally backported coreutils
(I had to build lintianwith nocheck due to several tests failing due to 
coreutils
not being 8.30 at build time (and maybe other errors))

Bug#941016: ITP: gnome-firmware-updater -- GTK tool to upgrade, downgrade, and reinstall firmware on devices supported by fwupd

[Mike Gabriel]

Hi Jesper,
(Cc:ing Martin Wimpress from Ubuntu MATE)


I'm ok with that. Thank you for taking your time, I will do my best to
help. I've applied some upstream patches that fix
the manpage issue and i've also taken care of the lintian issues.
looking forward to hearing your review comments soon!


Here comes the review:

1.
src:pkg name: upstream names it gnome-firmware-updater, so why do you  
name it gnome-firmware


2.
bin:pkg name: same as with src:pkg name

3.
debian/control:

  - SYNOPSIS: gtk front end for fwupd -> GTK
  - LONG_DESCRIPTION: indent the itemizations by two characters
  - LONG_DESCRIPTION: why don't you use the wording from
upstream's README.md file? Please do.
 
https://gitlab.gnome.org/hughsie/gnome-firmware-updater/blob/master/README.md
  - Build-Depends: please add a comma after the last pkg name, it  
makes diffs look nicer

one the line below Build-Depends gets changed (e.g. with another pkg name)
  - Vcs-*: fields are missing, we should put the pkg on salsa under  
the debian/ folder

  - Depends: field, I recommend having one package per row.
  - Please use appropriate upper case and lower case letters

debian/copyright:

  - personally, I don't like the "Files: *" debian/copyright style,  
but ftpmaster

wave it through, so...
  - Source: field: no URL with a release number here, I'd put the  
releases/ folder

here as URL or even better, the GitLab repo.

  A general thing: you did good, but for other packages you might  
maintain... I normally

  use all licenses appearing in the upstream code for debian/.


debian/changelog:

  - my spelling: "Initial release to Debian. (Closes: #941016)."
-> thus, using full-stops

4.
The pristine-tar branch is not on salsa, I cannot build without that  
branch using gbp-buildpackage.


There are three options now:

  (a) you work on those bits and pieces and I take a second look
  (b) you are ok with me adding some commits
  (c) a mixture of (a) and (b)

We should created an empty Git repo (gnome-firmware-updater) under  
salsa.debian.org/debian (I can do that, if you agree) and push a clone  
of your Git repo there. Please let me know if you are ok with  
continueing using that repository as the official packaging VCS  
location.


Another option would be placing the packaging Git repo onto the Debian  
GNOME team's namespace on GitLab, but gnome-firmware-updater has  
"gnome" in its name, but as I learned from upstream, it is a suitable  
add-on tool for all GTK-based desktop environments, so a "neutral"  
spot like the /debian team folder salsa is probably the better way to  
go.


Also, Martin Wimpress from Ubuntu MATE and I would like to add  
ourselves as uploaders. Furthermore, I recommend adding the Debian  
GNOME team and the Debian+Ubuntu MATE team as uploaders, too. In old  
times, most Debian packages had been 1-person-maintained, which turned  
out to be a bad concept in case devs went missing in action (MIA).  
Allowing team uploads to packages makes Debian a much more flexible  
place to be at. Please let me know, if you are ok with this, too.


Thanks for your work!
Mike

--

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

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



pgpE4Gflnf264.pgp
Description: Digitale PGP-Signatur

Bug#943967: /usr/share/vim/vim81/debian.vim: runtimepath overriden in debian.vim without /etc/vim path

[Václav Ovsík]

Package: vim-common
Version: 2:8.1.0875-5
Severity: normal
File: /usr/share/vim/vim81/debian.vim

Dear Maintainer,

A directory /etc/vim is missing from the VIM runtimepath and so my
syntax file at /etc/vim/syntax/dhcpd.vim is not loaded after upgrade
to the Debian Buster release.

You mentioned addition of /etc/vim into the default 'runtimepath' in
changelog for version 2:8.1.0693-2. That is true, but this default
runtimepath is overriden in the debian.vim file.

 zito@confl-priv:~$ vim -D

 Entering Debug mode.  Type "cont" to continue.
 /usr/share/vim/vimrc
 line 10: runtime! debian.vim
 >set rtp
   
runtimepath=~/.vim,/etc/vim,/usr/share/vim/vimfiles,/usr/share/vim/vim81,/usr/share/vim/vimfiles/after,/etc/vim/after,~/.vim/after
 
 >n
 /usr/share/vim/vimrc
 line 26: syntax on
 >set rtp
   
runtimepath=~/.vim,/var/lib/vim/addons,/usr/share/vim/vimfiles,/usr/share/vim/vim81,/usr/share/vim/vimfiles/after,/var/lib/vim/add
 ons/after,~/.vim/after
 >

Addition a line bellow into /etc/vim/vimrc fixes the problem a dirty way.

@@ -8,6 +8,8 @@
 " This line should not be removed as it ensures that various options are
 " properly set to work with the Vim-related packages available in Debian.
 runtime! debian.vim
+" FIXME bugworkaround FIXME
+set 
runtimepath=~/.vim,/etc/vim,/var/lib/vim/addons,/usr/share/vim/vimfiles,/usr/share/vim/vim81,/usr/share/vim/vimfiles/after,/var/lib/vim/addons/after,/etc/vim/after,~/.vim/after

 " Vim will load $VIMRUNTIME/defaults.vim if the user does not have a vimrc.
 " This happens after /etc/vim/vimrc(.local) are loaded, so it will override

Thanks for your work!
Cheers
-- 
Zito


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

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

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


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.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 vim-common depends on:
ii  xxd  2:8.1.0875-5

Versions of packages vim-common recommends:
ii  vim   2:8.1.0875-5
ii  vim-tiny  2:8.1.0875-5

vim-common suggests no packages.

-- Configuration Files:
/etc/vim/vimrc changed [not included]

-- no debconf information

Bug#943962: [debian-mysql] Bug#943962: mariadb-server-10.3: mysqld crashes and hangs, no longer processing requests

[Otto Kekäläinen]

Hello!

Did you report this bug upstream (as the output said "To report this
bug, see https://mariadb.com/kb/en/reporting-bugs;). This is unlikely
related to the packaging done in Debian.


pe 1. marrask. 2019 klo 22.57 Richard van den Berg
(rich...@vdberg.org) kirjoitti:
>
> Package: mariadb-server-10.3
> Version: 1:10.3.17-0+deb10u1
> Severity: important
>
> I run mysqldump (through automysqlbackup) daily. Several times per week
> during this backup mysqld hangs. The process however stays running and still
> accepts TCP and socket connections, however no SQL queries are ever
> answered anymore. This is very serious because systemd does not catch this
> and leaves the process running. Only a "pkill -9 mysqld" can resolve the
> situation.
>
> In the 15+ years I have been using mysql/mariadb I have never encoutered
> this situation where my system is left hanging without a working database.
> If mysqld crashed (this is bad enough) the process should end itself so
> systemd can restart it.
>
> The messages in error.log are:
>
> corrupted size vs. prev_size
> 191101  7:23:41 [ERROR] mysqld got signal 6 ;
> This could be because you hit a bug. It is also possible that this binary
> or one of the libraries it was linked against is corrupt, improperly built,
> or misconfigured. This error can also be caused by malfunctioning hardware.
>
> To report this bug, see https://mariadb.com/kb/en/reporting-bugs
>
> We will try our best to scrape up some info that will hopefully help
> diagnose the problem, but since we have already crashed,
> something is definitely wrong and this may fail.
>
> Server version: 10.3.17-MariaDB-0+deb10u1
> key_buffer_size=134217728
> read_buffer_size=131072
> max_used_connections=5
> max_threads=153
> thread_count=8
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467422
> K  bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> Thread pointer: 0x7f2b600014b8
> Attempting backtrace. You can use the following information to find out
> where mysqld died. If you see no messages after this, something went
> terribly wrong...
> stack_bottom = 0x7f2bc4814dd8 thread_stack 0x49000
>
>
> -- System Information:
> Debian Release: 10.1
>   APT prefers stable
>   APT policy: (990, 'stable'), (900, 'oldstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to C.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
> set to C.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages mariadb-server-10.3 depends on:
> ii  adduser   3.118
> ii  debconf [debconf-2.0] 1.5.71
> ii  galera-3  25.3.25-2
> ii  gawk  1:4.2.1+dfsg-1
> ii  iproute2  4.20.0-2
> ii  libc6 2.28-10
> ii  libdbi-perl   1.642-1+b1
> ii  libgnutls30   3.6.7-4
> ii  libpam0g  1.3.1-5
> ii  libstdc++68.3.0-6
> ii  lsb-base  10.2019051400
> ii  lsof  4.91+dfsg-1
> ii  mariadb-client-10.3   1:10.3.17-0+deb10u1
> ii  mariadb-common1:10.3.17-0+deb10u1
> ii  mariadb-server-core-10.3  1:10.3.17-0+deb10u1
> ii  passwd1:4.5-1.1
> ii  perl  5.28.1-6
> ii  psmisc23.2-1
> ii  rsync 3.1.3-6
> ii  socat 1.7.3.2-2
> ii  zlib1g1:1.2.11.dfsg-1
>
> Versions of packages mariadb-server-10.3 recommends:
> ii  libhtml-template-perl  2.97-1
>
> Versions of packages mariadb-server-10.3 suggests:
> ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1
> ii  mailx  1:20071201-3
> pn  mariadb-test   
> pn  netcat-openbsd 
> pn  tinyca 
>
> -- debconf information excluded
>
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint



-- 
- Otto

Bug#943966: cookiecutter: failing tests with python3.8

[Steve Langasek]

Package: cookiecutter
Version: 1.6.0-4
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Vincent,

The cookiecutter package fails to build from source in Ubuntu focal, because
Ubuntu has begun the transition to python3.8 and cookiecutter is not
source-compatible with python3.8:

[...]
 ERRORS 
_ ERROR collecting 
.pybuild/cpython3_3.8_cookiecutter/build/tests/test_default_extensions.py _
tests/test_default_extensions.py:7: in 
import freezegun
/usr/lib/python3/dist-packages/freezegun/__init__.py:9: in 
from .api import freeze_time
/usr/lib/python3/dist-packages/freezegun/api.py:28: in 
real_clock = time.clock
E   AttributeError: module 'time' has no attribute 'clock'
[...]

  
(https://launchpad.net/ubuntu/+source/cookiecutter/1.6.0-4ubuntu1/+build/18010482)

Debian has not yet started the transition to python3.8 - the version of
python3-defaults that adds python3.8 as supported is currently in
experimental - but this will eventually become a serious bug in Debian as
well once that transition begins.

For the moment I have worked around the failure in Ubuntu by changing the
packaging to test only against the current version of python3 and not
against all supported versions, but this is a very short-term fix given that
python3.8 will become the default in the next 6 months.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru cookiecutter-1.6.0/debian/control cookiecutter-1.6.0/debian/control
--- cookiecutter-1.6.0/debian/control   2019-09-01 08:01:10.0 -0700
+++ cookiecutter-1.6.0/debian/control   2019-11-01 13:58:02.0 -0700
@@ -5,7 +5,7 @@
 Uploaders: Debian Python Modules Team 

 Build-Depends: debhelper-compat (= 9), dh-python,
git,
-   python3-all,
+   python3,
python3-sphinx (>= 1.0.7+dfsg), python3-sphinx-rtd-theme,
python3-setuptools,
python3-jinja2,

Bug#943965: gnuradio/block.h depends on gmpxx.h, but no dep on libgmp-dev

[Steve Langasek]

Package: gnuradio
Version: 3.8.0.0-5
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Maitland,

In Ubuntu, I found that the gr-hpsdr package was failing to rebuild against
new gnuradio, because it includes gnuradio/block.h and this header in turn
requires gmpxx.h, but gnuradio-dev does not depend on libgmp-dev.

The attached patch fixes this build failure for me.  Please consider
applying it in Debian.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gnuradio-3.8.0.0/debian/control gnuradio-3.8.0.0/debian/control
--- gnuradio-3.8.0.0/debian/control 2019-08-30 17:21:31.0 -0700
+++ gnuradio-3.8.0.0/debian/control 2019-11-01 14:02:48.0 -0700
@@ -148,6 +148,7 @@
  libboost-thread-dev,
  libcppunit-dev,
  libfftw3-dev,
+ libgmp-dev,
 libgsm1-dev,
  liblog4cpp5-dev,
  libvolk2-dev,

Bug#943963: twisted 18.9.0-4 breaks multiple autopkgtests: pkg_resources.DistributionNotFound: The 'PyHamcrest>=1.9.0' distribution was not found and is required by Twisted

[Paul Gevers]

Source: twisted
Version: 18.9.0-4
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: breaks
Control: affects -1 src:incremental src:automat src:nevow src:txsocksx

Dear maintainers,

With a recent upload of twisted the autopkgtest of incremental (and
three others) fails in testing when that autopkgtest is run with the
binary packages of twisted from unstable. It passes when run with only
packages from testing. In tabular form:
   passfail
twistedfrom testing18.9.0-4
incrementalfrom testing16.10.1-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. The error is
very similar in all four reports, hence it looks like an issue on the
twisted side. Feel free to clone and reassign to all the affected
packages if I judged this wrongly.

Currently this regression is blocking the migration of twisted to
testing [1].

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=twisted

https://ci.debian.net/data/autopkgtest/testing/amd64/i/incremental/3308991/log.gz

Traceback (most recent call last):
  File "/usr/bin/trial", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
line 3250, in 
@_call_aside
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
line 3234, in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
line 3263, in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
line 583, in _build_master
ws.require(__requires__)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
line 900, in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
line 786, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'PyHamcrest>=1.9.0' distribution
was not found and is required by Twisted



signature.asc
Description: OpenPGP digital signature

Bug#943964: printer-driver-gutenprint: Typo in sources concerning Canon CP-300. Error: backend not found

[Andreas B. Mundt]

Package: printer-driver-gutenprint
Version: 5.3.3-2
Severity: normal
Tags: patch upstream

Hi Odyx, dear maintainer,

there is a typo in the gutenprint backend for the Canon CP300 (Postcard)
printer.  This printer seems to be detected and configured nicely by
cups, however when printing, the error "unknown backend" is reported
and nothing happens.  The printer is automatically configured with the
URI: 

 "DeviceURI gutenprint53+usb://selpyhcp300/NONE_UNKNOWN"
   ^^
Looking at the sources gives a single occurence of 'selpyh', at all
other places instead of 'selpyh' the string 'selphy' is used
(c.f. patch).  When the device URI in /etc/cups/printers.conf is
modified to read: 

 "DeviceURI gutenprint53+usb://selphycp300/NONE_UNKNOWN",
   ^^
printing works fine.

Best regards,

  Andi



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

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

Versions of packages printer-driver-gutenprint depends on:
ii  cups 2.3.0-5
ii  cups-client  2.3.0-5
ii  cups-filters [ghostscript-cups]  1.25.11-1
ii  libc62.29-2
ii  libcups2 2.3.0-5
ii  libgutenprint9   5.3.3-2
ii  libusb-1.0-0 2:1.0.23-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

printer-driver-gutenprint recommends no packages.

Versions of packages printer-driver-gutenprint suggests:
pn  gutenprint-doc  
pn  gutenprint-locales  

-- no debconf information
>From 8c471b4bf862dfb684cdb94be9d9086064241cc9 Mon Sep 17 00:00:00 2001
From: "Andreas B. Mundt" 
Date: Fri, 1 Nov 2019 21:42:04 +0100
Subject: [PATCH] Fix typo concerning CP-300.

---
 src/cups/backend_canonselphy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/cups/backend_canonselphy.c b/src/cups/backend_canonselphy.c
index 978df0d..3ef0c31 100644
--- a/src/cups/backend_canonselphy.c
+++ b/src/cups/backend_canonselphy.c
@@ -1165,7 +1165,7 @@ struct dyesub_backend canonselphy_backend = {
{ USB_VID_CANON, USB_PID_CANON_CP100, P_CP_XXX, NULL, 
"canon-cp100"},
{ USB_VID_CANON, USB_PID_CANON_CP200, P_CP_XXX, NULL, 
"canon-cp200"},
{ USB_VID_CANON, USB_PID_CANON_CP220, P_CP_XXX, NULL, 
"canon-cp220"},
-   { USB_VID_CANON, USB_PID_CANON_CP300, P_CP_XXX, NULL, 
"selpyhcp300"},
+   { USB_VID_CANON, USB_PID_CANON_CP300, P_CP_XXX, NULL, 
"selphycp300"},
{ USB_VID_CANON, USB_PID_CANON_CP330, P_CP_XXX, NULL, 
"canon-cp330"},
{ USB_VID_CANON, USB_PID_CANON_CP400, P_CP_XXX, NULL, 
"canon-cp400"},
{ USB_VID_CANON, USB_PID_CANON_CP500, P_CP_XXX, NULL, 
"canon-cp500"},
-- 
2.23.0

Bug#943961: ceph: autopkgtest needs update for new version of python3.7: deprecation warning

[Paul Gevers]

Source: ceph
Version: 12.2.11+dfsg1-2.1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, python...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3.7

Dear maintainers,

With a recent upload of python3.7 the autopkgtest of ceph fails in
testing when that autopkgtest is run with the binary packages of
python3.7 from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
python3.7  from testing3.7.5-2
ceph   from testing12.2.11+dfsg1-2.1
all others from testingfrom testing

I copied some of the output at the bottom of this report, the failure is
on a deprecation *warning*. Please disable warnings like that, or enable
the allow-stderr restriction in your test as we don't want autopkgtest
to fail on warning in the Debian setup.

Currently this regression is blocking the migration of python3.7 to
testing [1]. Of course, python3.7 shouldn't just break your autopkgtest
(or even worse, your package), but it seems to me that the change in
python3.7 was intended and your package needs to update to the new
situation. I'll mark your test as allowed to fail to enable python3.7 to
migrate.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python3.7

https://ci.debian.net/data/autopkgtest/testing/amd64/c/ceph/3308028/log.gz

autopkgtest [02:14:20]: test python3-ceph: [---
/tmp/autopkgtest-lxc.w6gyq64p/downtmp/build.p0D/src/debian/tests/python3-ceph:8:
DeprecationWarning: Using or importing the ABCs from 'collections'
instead of from 'collections.abc' is deprecated since Python 3.3,and in
3.9 it will stop working
  import rbd
python3-ceph: OK
autopkgtest [02:14:20]: test python3-ceph: ---]



signature.asc
Description: OpenPGP digital signature

Bug#943962: mariadb-server-10.3: mysqld crashes and hangs, no longer processing requests

[Richard van den Berg]

Package: mariadb-server-10.3
Version: 1:10.3.17-0+deb10u1
Severity: important

I run mysqldump (through automysqlbackup) daily. Several times per week
during this backup mysqld hangs. The process however stays running and still
accepts TCP and socket connections, however no SQL queries are ever
answered anymore. This is very serious because systemd does not catch this
and leaves the process running. Only a "pkill -9 mysqld" can resolve the
situation.

In the 15+ years I have been using mysql/mariadb I have never encoutered
this situation where my system is left hanging without a working database.
If mysqld crashed (this is bad enough) the process should end itself so
systemd can restart it.

The messages in error.log are:

corrupted size vs. prev_size
191101  7:23:41 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.3.17-MariaDB-0+deb10u1
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=5
max_threads=153
thread_count=8
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467422
K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f2b600014b8
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7f2bc4814dd8 thread_stack 0x49000


-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (900, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  galera-3  25.3.25-2
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  libdbi-perl   1.642-1+b1
ii  libgnutls30   3.6.7-4
ii  libpam0g  1.3.1-5
ii  libstdc++68.3.0-6
ii  lsb-base  10.2019051400
ii  lsof  4.91+dfsg-1
ii  mariadb-client-10.3   1:10.3.17-0+deb10u1
ii  mariadb-common1:10.3.17-0+deb10u1
ii  mariadb-server-core-10.3  1:10.3.17-0+deb10u1
ii  passwd1:4.5-1.1
ii  perl  5.28.1-6
ii  psmisc23.2-1
ii  rsync 3.1.3-6
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.3 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1
ii  mailx  1:20071201-3
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

-- debconf information excluded

Bug#934870: statsmodels: Please drop python2 support

[Steve Langasek]

Package: statsmodels
Version: 0.9.0-6
Followup-For: Bug #934870
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hello,

Here is an updated debdiff for 0.9.0-6.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru statsmodels-0.9.0/debian/control statsmodels-0.9.0/debian/control
--- statsmodels-0.9.0/debian/control2019-09-15 09:56:31.0 -0700
+++ statsmodels-0.9.0/debian/control2019-11-01 13:04:59.0 -0700
@@ -8,23 +8,6 @@
 Priority: optional
 Build-Depends: debhelper-compat (= 12),
sphinx-common,
-# for Python 3 only (untested) remove here...
-   python-all-dev,
-   python-setuptools,
-   python-colorama ,
-   python-dateutil ,
-   python-numpy,
-   python-scipy,
-   python-nose ,
-   python-pytest ,
-   python-matplotlib,
-   python-pandas,
-   python-patsy ,
-   python-joblib ,
-   cython,
-   python-tk ,
-   python-cvxopt ,
-# ...to here
dh-python (>= 3.20180313~),
cython3,
python3-all-dev,
@@ -71,47 +54,6 @@
 Vcs-Git: https://salsa.debian.org/science-team/statsmodels.git
 Homepage: https://www.statsmodels.org
 
-# Reminder: when this goes away, the links in python-statsmodels-doc.links and 
python-statsmodels-doc.doc-base need updating
-Package: python-statsmodels
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends},
- python-numpy,
- python-scipy,
- python-statsmodels-lib (>= ${source:Version}),
- python-patsy,
- python-pandas
-Recommends: python-matplotlib,
-python-joblib,
-python-colorama,
-python-cvxopt
-Suggests: python-statsmodels-doc
-Breaks: python-scikits-statsmodels
-Provides: ${python:Provides}
-Replaces: python-scikits-statsmodels
-Description: Python module for the estimation of statistical models
- statsmodels Python module provides classes and functions for the
- estimation of several categories of statistical models. These
- currently include linear regression models, OLS, GLS, WLS and GLS
- with AR(p) errors, generalized linear models for several distribution
- families and M-estimators for robust linear models. An extensive list
- of result statistics are available for each estimation problem.
-
-Package: python-statsmodels-lib
-Architecture: any
-Multi-Arch: same
-Depends: ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends},
- python-numpy
-Breaks: python-scikits-statsmodels
-Replaces: python-scikits-statsmodels
-Description: Python2 low-level implementations and bindings for statsmodels
- Statsmodels is a Python module for the estimation of statistical models.
- .
- This package contains internal libraries for python-statsmodels.  Users
- should not need to install it directly.
-
 Package: python-statsmodels-doc
 Architecture: all
 Section: doc
diff -Nru statsmodels-0.9.0/debian/python3-statsmodels.examples 
statsmodels-0.9.0/debian/python3-statsmodels.examples
--- statsmodels-0.9.0/debian/python3-statsmodels.examples   1969-12-31 
16:00:00.0 -0800
+++ statsmodels-0.9.0/debian/python3-statsmodels.examples   2019-02-13 
13:33:01.0 -0800
@@ -0,0 +1 @@
+examples/*
diff -Nru statsmodels-0.9.0/debian/python-statsmodels-doc.links 
statsmodels-0.9.0/debian/python-statsmodels-doc.links
--- statsmodels-0.9.0/debian/python-statsmodels-doc.links   2019-08-10 
04:50:15.0 -0700
+++ statsmodels-0.9.0/debian/python-statsmodels-doc.links   2019-10-25 
22:24:26.0 -0700
@@ -1,4 +1,2 @@
-usr/share/doc/python-statsmodels/examples 
usr/share/doc/python-statsmodels-doc/examples
-usr/share/doc/python-statsmodels/examples 
usr/share/doc/python3-statsmodels/examples
-usr/share/doc/python-statsmodels/html usr/share/doc/python-statsmodels-doc/html
-usr/share/doc/python-statsmodels/html usr/share/doc/python3-statsmodels/html
+usr/share/doc/python3-statsmodels/examples 
usr/share/doc/python-statsmodels-doc/examples
+usr/share/doc/python3-statsmodels/html 
usr/share/doc/python-statsmodels-doc/html
diff -Nru statsmodels-0.9.0/debian/rules statsmodels-0.9.0/debian/rules
--- statsmodels-0.9.0/debian/rules  2019-08-10 04:50:15.0 -0700
+++ statsmodels-0.9.0/debian/rules  2019-11-01 13:04:59.0 -0700
@@ -16,7 +16,7 @@
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
 %:
-   dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+   dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 # To guarantee HOME existence with mpl 1.3.0
 # See 

Bug#943960: python-livereload autopkgtest depends on python-django which isn't build from source anymore

[Paul Gevers]

Source: python-livereload
Version: 2.6.1-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainer,

The maintainer of src:python-django decided to stop building the binary package
python-django on which your autopkgtest depends. Once src:python-django
migrates to testing, your package will fail its autopkgtest. Please migrate
away from using python-django in your autopkgtest.

Paul

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

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl28lGAACgkQnFyZ6wW9
dQrIDAf/f1RljkRy4PjFuoFRHsVNyOtRDkzlDlbFE4vqqz2rLvNCK+ozW8EusGFN
AMZWlVAfW99rf8jWA3NT7M/ZMJjdPGSuUtqzoNA5EsLlLa+XTDP5J5FYxChk+oZY
LtlKySI4bXSjhsHS8DLTfp/SswD7MDout40BrFrv1oL3W8pS/QwXJ3Fiazmrp6yQ
HYHeNR2MruIvVGTzY5oKFmYH5ObxBB4HrJi1E76pZmvYwR2qtKPF5rhOlDwjjuMM
iYqbD+H3Ci15gMpRCzwfUfkLb05SwNfdBIdeuBM+Ddxreob1+SZb+ja06WEZWYwE
FiYfoOJzsCPWPk1zL9Kp3F3WUW3vKg==
=knHH
-END PGP SIGNATURE-

Bug#943710: RFS: systune/0.5.9 -- kernel tuning through the /proc file system

[Sudip Mukherjee]

Hi All,

I have updated the package and this is the updated changelog:

   * Update Standards-Version
   * Update compat level to 12
   * Update maintainer in debian/control
   * Update copyright file
   * Added link to github as Vcs-Git
   * Source format added
   * Fix lintian issue of init.d-script-does-not-source-init-functions
   * Fix lintian issue of skip-systemd-native-flag-missing-pre-depends
   * Fix lintian issue of lsb-base

--
Regards
Sudip

Bug#943782: vdr-plugin-epgsearch: Wish to backport unstable to buster.

[Tobias Grimm]

Hello Jari,

I have armhf builds of the VDR packages in my private repository at:

deb https://packages.e-tobi.net/vdr-experimental buster base
vdr-multipatch addons

Currently I don't plan to do any official backports. Maybe once all
packages have been migrated to Testing.

BR,

Tobias

On 29.10.19 20:22, Jari Fredriksson wrote:
> Package: vdr-plugin-epgsearch
> Version: 2.2.0+git20170817-2+b1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I'm running Debian Buster (as Raspbian) in my VDR box and the the 
> vdr-plugin-epgsearch in Buster is unusable
> as it crashes the vdr when there is a timer collision. This was patched in 
> upstream and the patched version
> is uncluded in Debian unstable.
> 
> I would like to have unstable vdr-plugin-epgsearch backported to stable to 
> make it happen in Raspbian.
> 
> I do know that you do not maintain Raspbian, but that is not relevant. 
> Raspbian is a straight Debian derivative
> and it will get everything from Debian stable in a rapid fashion.
> 
> Pleas :)
> 
> -- System Information:
> Distributor ID:   Raspbian
> Description:  Raspbian GNU/Linux 10 (buster)
> Release:  10
> Codename: buster
> Architecture: armv7l
> 
> Kernel: Linux 4.19.75-v7l+ (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_CRAP
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages vdr-plugin-epgsearch depends on:
> ii  libc6   2.28-10+rpi1
> ii  libgcc1 1:8.3.0-6+rpi1
> ii  libstdc++6  8.3.0-6+rpi1
> ii  sendemail   1.56-5
> ii  vdr [vdr-abi-2.4.0-debian]  2.4.0-1+b1
> 
> vdr-plugin-epgsearch recommends no packages.
> 
> vdr-plugin-epgsearch suggests no packages.
> 
> -- no debconf information
> 
> ___
> pkg-vdr-dvb-devel mailing list
> pkg-vdr-dvb-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-vdr-dvb-devel
> 

Bug#943959: mailscripts: add decryption capability for email-print-mime-structure

[Daniel Kahn Gillmor]

Package: mailscripts
Version: 0.11-1
Tags: patch

Hi Sean--

Attached are two patches for mailscripts that in combination permit
decryption using OpenPGP Transferable Secret Keys that are found in the
filesystem.

I'm finding this particularly useful when i'm working on writing
specifications and documentation that use (for example) the OpenPGP
Sample Keys [0].

Here's what it looks like:

$ email-print-mime-structure --pgpkey al...@openpgp.example.sec.asc < 
msg.eml
└┬╴multipart/encrypted 2190 bytes
 ├─╴application/pgp-encrypted 11 bytes
 └─╴application/octet-stream 1613 bytes
  ↧ (decrypts to)
  └─╴text/plain 425 bytes
$

Note that this doesn't use GnuPG or even attempt to access the user's
GnuPG secret keyring, so that it's not handling any
personally-confidential message info.

If that's something that people want (e.g. it might be useful when using
this script in encrypted-message debugging contexts), then i can work on
adding that too.

But this is already a sufficiently-useful featureset that i think it is
worth sharing.

You can also just merge these patches from the mimestructure-pgpmime
branch at https://salsa.debian.org/dkg/mailscripts

Thanks for maintaining mailscripts!

--dkg


[0] https://datatracker.ietf.org/doc/draft-bre-openpgp-samples/

From 65fcb89b4d774d02ccafea735737a106ba05f295 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Fri, 1 Nov 2019 14:13:27 -0400
Subject: [PATCH 1/2] email-print-mime-structure: be typesafe

This adds enough typechecking that the following check passes:

mypy --strict email-print-mimestructure

Signed-off-by: Daniel Kahn Gillmor 
---
 email-print-mime-structure | 54 ++
 1 file changed, 32 insertions(+), 22 deletions(-)

diff --git a/email-print-mime-structure b/email-print-mime-structure
index 7adeb2b..185173f 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -29,44 +29,49 @@ Example:
 If you want to number the parts, i suggest piping the output through
 something like "cat -n"
 '''
-import email
 import sys
+import email
+import logging
 
-def print_part(z, prefix):
-fname = '' if z.get_filename() is None else ' [' + z.get_filename() + ']'
-cset = '' if z.get_charset() is None else ' (' + z.get_charset() + ')'
-disp = z.get_params(None, header='Content-Disposition')
-if (disp is None):
-disposition = ''
-else:
-disposition = ''
+from typing import Optional, Union, List, Tuple, Any
+from email.charset import Charset
+from email.message import Message
+
+def print_part(z:Message, prefix:str) -> None:
+ofname:Optional[str] = z.get_filename()
+fname:str = '' if ofname is None else f' [{ofname}]'
+ocharset:Union[Charset, str, None] = z.get_charset()
+cset:str = '' if ocharset is None else f' ({ocharset})'
+disp:Union[List[Tuple[str,str]], List[str], None] = z.get_params(None, header='Content-Disposition')
+disposition:str = ''
+if (disp is not None):
 for d in disp:
 if d[0] in [ 'attachment', 'inline' ]:
 disposition = ' ' + d[0]
+nbytes:int
 if z.is_multipart():
+# FIXME: it looks like we are counting chars here, not bytes:
 nbytes = len(z.as_string())
 else:
-nbytes = len(z.get_payload())
+payload:Union[List[Message], str, bytes, None] = z.get_payload()
+if not isinstance(payload, (str,bytes)):
+raise TypeError(f'expected payload to be either str or bytes, got {type(payload)}')
+nbytes = len(payload)
 
-print('{}{}{}{}{} {:d} bytes'.format(
-prefix,
-z.get_content_type(),
-cset,
-disposition,
-fname,
-nbytes,
-))
+print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname} {nbytes} bytes')
 
-def test(z, prefix=''):
+def test(z:Message, prefix:str='') -> None:
 if (z.is_multipart()):
 print_part(z, prefix+'┬╴')
 if prefix.endswith('└'):
 prefix = prefix.rpartition('└')[0] + ' '
 if prefix.endswith('├'):
 prefix = prefix.rpartition('├')[0] + '│'
-parts = z.get_payload()
+parts:Union[List[Message], str, bytes, None] = z.get_payload()
+if not isinstance(parts, list):
+raise TypeError(f'parts was {type(parts)}, expected List[Message]')
 i = 0
-while (i < parts.__len__()-1):
+while (i < len(parts)-1):
 test(parts[i], prefix + '├')
 i += 1
 test(parts[i], prefix + '└')
@@ -74,4 +79,9 @@ def test(z, prefix=''):
 else:
 print_part(z, prefix+'─╴')
 
-test(email.message_from_file(sys.stdin), '└')
+msg:Union[Message, str, int, Any] = email.message_from_file(sys.stdin)
+
+if isinstance(msg, Message):
+test(msg, '└')
+else:
+logging.error('Input was not an e-mail message')
-- 
2.24.0.rc1

fFrom 53b56fc1dfd7236a51881de373a4586db3d16966 Mon Sep 17 00:00:00 2001
From: 

Bug#874878: [freemat] Future Qt4 removal from Buster

[Anton Gladky]

Removal requested: #943958

Anton

Bug#943958: RM: freemat -- ROM; RC-bug, no active uploader in the team

[Anton Gladky]

Proper link is here:

 https://lists.debian.org/debian-science/2019/09/msg00018.html

Anton

Bug#943958: RM: freemat -- ROM; RC-bug, no active uploader in the team

[Anton Gladky]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On behalf of Debian Science Team I request to remove freemat package.

The package has RC-Bug #874878 (depending on Qt4) and has no an active
uploader in the team. After the call [1] no interest was identified in the
team.

[1] https://lists.debian.org/debian-science/2019/09/msg00018.htmlo

Regards,

Anton

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl28hqERHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wbvRg//bGZbytequy2He/EblUbxHlRex0MzTLgM
7dofn52/IwWYlLlJ/oBoZl+R8ujkObv1j2k9b627zU3CPnssBGMg4lnHHtH1JPac
y+XZaZD6QLIj5wfvQy280ocvShCr3b11nXy4GlhT4q8EAClAOP+ODwZEhYhfWQXQ
0zinKE1twqIALh06rlUkmfzHYbax1sjaS1F8kGEECyCZzmbIpYt4BWy6oeWO0uOj
BFvo2HVpkEeSipAFUyTnjNOBqtqkZz0ppk9CVO4MhLjMksFEWTd988Zrnvi91xj5
kh5RoX7Xl5GmS5tXRNMloTkGQl41ow+FdXNCBQA6Hmf1KbG+MdAG0x5e4vbn3XLl
TszoZ02GKN/v/JzG6rNi+AyiNFLAAIY33Lg/BZF4kQ5xjMmKva+pTHaRbLiDNvQO
o9wMrXhyToUziWac7+03cqbS8Zf7ZvWXTPnnsvvSvsC3PT2QaHETKp8/iSInVYSd
Cg6thQLi63z9kNDRTsm46iUl2f9Jwkikb1/RSKJGJ0GU/BQJ2PjlSylsYPRtCdhL
+G0q9jq46Or6m+3lZcHiYRhPYCLn/PIVg/7cWvnEUotPGEcLs6CVeSqPkGmFUWlI
u5MAFYI42VEnmodQZMXNpI72GeoNRTH/qfkmEuhSJmMTfyajl8vYUWmDFEpGyTEt
CJ6uzUev8wE=
=hVBf
-END PGP SIGNATURE-

Bug#943957: lintian: missing-systemd-service-for-init.d-script should be a warning, not just pedantic

[Holger Levsen]

package: lintian
severity: wishlist
version: 2.32.0
x-debbugs-cc: 941...@bugs.debian.org, r...@debian.org, ans...@43-1.org

On Fri, Nov 01, 2019 at 11:20:59AM -0700, Russ Allbery wrote:
> > I think there is already a lintian warning:
> >   
> > https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
> Oh!  I should have checked rather than assuming.  It would ideally be nice
> to make it a warning rather than a pedantic tag before we add it to
> Policy, but meh, and the count of tags isn't all that high.
 
I'm pretty sure this is trival and just a matter of asking via a
wishlist bug, thus doing so here.

See #941198 for more context.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#943956: snakemake: please make the build reproducible

[Chris Lamb]

Source: snakemake
Version: 5.7.4-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
snakemake could still not be built reproducibly. This is because my
previous patch did not cover quite everything. Do excuse the patch-to-
a-patch but please apply the following:

  --- a/debian/patches/0012-reproducible-build.patch
  +++ b/debian/patches/0012-reproducible-build.patch
  @@ -22,6 +22,15 @@ Last-Update: 2019-07-15
raise ValueError("Path to report output has to be an HTML file.")
   --- snakemake.orig/snakemake/utils.py
   +++ snakemake/snakemake/utils.py
  +@@ -202,7 +202,7 @@ def makedirs(dirnames):
  + def report(
  + text,
  + path,
  +-stylesheet=os.path.join(os.path.dirname(__file__), "report.css"),
  ++stylesheet=None,
  + defaultenc="utf8",
  + template=None,
  + metadata=None,
  
... and this should cover it. :)

 [0] https://reproducible-builds.org/


Best wishes,

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

Bug#943955: pcb-rnd: /usr/lib/lib*.so.* symlinks point to (absolute) build directory

[Chris Lamb]

Package: pcb-rnd
Version: 2.1.4-1
Severity: serious
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

It looks like the pcb-rnd binary package ships with symlinks pointing
to the absolute build directory which, of course, does not exist on
the installed/runtime system:

$ dget pcb-rnd
dget: using existing pcb-rnd_2.1.4-1_amd64.deb

$ dpkg -c pcb-rnd_2.1.4-1_amd64.deb | grep -- '->'
lrwxrwxrwx root/root 0 2019-10-29 21:17 ./usr/lib/librnd-3rd.so.2 
-> 
/build/pcb-rnd-luR6aw/pcb-rnd-2.1.4/debian/pcb-rnd/usr/lib/librnd-3rd.so.2.1.4
lrwxrwxrwx root/root 0 2019-10-29 21:17 ./usr/lib/librnd-hid.so.2 
-> 
/build/pcb-rnd-luR6aw/pcb-rnd-2.1.4/debian/pcb-rnd/usr/lib/librnd-hid.so.2.1.4
lrwxrwxrwx root/root 0 2019-10-29 21:17 ./usr/lib/librnd-poly.so.2 
-> 
/build/pcb-rnd-luR6aw/pcb-rnd-2.1.4/debian/pcb-rnd/usr/lib/librnd-poly.so.2.1.4

Discovered as the package is not reproducible too due to this, but
solving this obviously-worse problem will implicitly fix this.


Best wishes,

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

Bug#941198: initscripts: packages should ship systemd units

[Russ Allbery]

Ansgar  writes:
> Russ Allbery writes:
>> Ansgar  writes:

>> I think we can proceed to add a Policy "should" for including a systemd
>> unit file unless someone raises objections pretty soon here.  So far, I
>> haven't seen any objections to the basic idea.

> Okay.  Anything further I should do except wait?

I'll take a look at the wording hopefully this weekend.

>> We're doing some of that already even by introducing a "should," and
>> there's some argument to be made for starting with a Lintian warning
>> instead, but I'm not inclined to be that conservative here, mostly
>> because we're long-overdue for saying something, and I think the should
>> is fairly mild in this case.

> I think there is already a lintian warning:

>   
> https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html

Oh!  I should have checked rather than assuming.  It would ideally be nice
to make it a warning rather than a pedantic tag before we add it to
Policy, but meh, and the count of tags isn't all that high.

-- 
Russ Allbery (r...@debian.org)  

Bug#943826: gnome: Type 'A' when switching desktop

[Thomas Fischbach]

Package: gnome
Version: 1:3.30+2
Followup-For: Bug #943826

Seems to be related to shortcuts.
I use Ctrl+Alt+Up and Ctrl+Alt+Down to switch desktops.

Now I disabled this default setting via dconf-editor.

When I now got to terminal and press Ctrl+Alt+Up an 'A' is written and on
Ctrl+Alt+Down a 'B' is written.

This only happens in console windows, not in text editor, browsers or other
applicants as I can see so far.



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

Kernel: Linux 5.3.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, 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 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome depends on:
ii  avahi-daemon 0.7-4+b1
ii  cheese   3.34.0-1+b1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 10.0.3
ii  evolution3.34.1-2+b1
ii  evolution-plugins3.34.1-2+b1
ii  file-roller  3.32.2-1
ii  gedit-plugins3.34.0-3
ii  gnome-calendar   3.34.2-1+b1
ii  gnome-clocks 3.34.0-1+b2
ii  gnome-color-manager  3.32.0-2
ii  gnome-core   1:3.30+2
ii  gnome-documents  3.34.0-1
ii  gnome-getting-started-docs   3.34.0-2
ii  gnome-maps   3.34.1-1
ii  gnome-music  3.32.2-1
ii  gnome-photos 3.34.0-2
ii  gnome-screenshot 3.34.0-1
ii  gnome-sound-recorder 3.34.0-1
ii  gnome-todo   3.28.1-5
ii  gnome-tweaks 3.34.0-2
ii  gnome-weather3.34.0-1
ii  gstreamer1.0-libav   1.16.1-1
ii  gstreamer1.0-plugins-ugly1.16.1-1
ii  libgsf-bin   1.14.46-1
ii  libproxy1-plugin-networkmanager  0.4.15-7
ii  libreoffice-calc 1:6.3.3~rc1-1
ii  libreoffice-gnome1:6.3.3~rc1-1
ii  libreoffice-impress  1:6.3.3~rc1-1
ii  libreoffice-writer   1:6.3.3~rc1-1
ii  nautilus-sendto  3.8.6-3
ii  network-manager-gnome1.8.24-1
ii  orca 3.34.0-2
ii  rhythmbox3.4.3-2+b1
ii  rhythmbox-plugin-cdrecorder  3.4.3-2+b1
ii  rhythmbox-plugins3.4.3-2+b1
ii  rygel-playbin0.36.2-4
ii  rygel-tracker0.36.2-4
ii  seahorse 3.34-1
ii  simple-scan  3.34.1-1
ii  totem-plugins3.34.1-2
ii  vinagre  3.22.0-6
ii  vino 3.22.0-5
ii  xdg-user-dirs-gtk0.10-3

Versions of packages gnome recommends:
ii  gnome-games 1:3.30+2
ii  nautilus-extension-brasero  3.12.2-6
ii  transmission-gtk2.94-2+b1

Versions of packages gnome suggests:
ii  alacarte 3.11.91-5
pn  empathy  
pn  firefox-esr-l10n-all | firefox-l10n-all  
pn  gnome-remote-desktop 
pn  goobox | sound-juicer
ii  polari   3.34.0-1
pn  webext-ublock-origin 

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.34.0-2
ii  at-spi2-core  2.34.0-3
ii  baobab3.34.0-1
ii  caribou   0.4.21-7
ii  chromium  76.0.3809.100-1
ii  dconf-cli 0.34.0-1
ii  dconf-gsettings-backend   0.34.0-1
ii  eog   3.34.1-1
ii  epiphany-browser  3.34.1-1+b1
ii  evince3.34.1-1
ii  evolution-data-server 3.34.1-1+b1
ii  firefox   70.0-1
ii  fonts-cantarell   0.111-2
ii  gdm3  3.34.1-1
ii  gedit 3.34.0-1
ii  gkbd-capplet  3.26.1-1
ii  glib-networking   2.62.1-1
ii  gnome-backgrounds 3.34.0-1
ii  gnome-bluetooth   3.34.0-1
ii  gnome-calculator  3.34.1-1
ii  gnome-characters  3.32.1-2
ii  gnome-contacts3.34-2
ii  gnome-control-center  1:3.34.1-1
ii  gnome-disk-utility3.34.0-2
ii  gnome-font-viewer 3.34.0-1+b1
ii  gnome-keyring 3.34.0-1
ii  gnome-logs3.34.0-1
ii  gnome-menus   3.32.0-1
ii  gnome-online-accounts 3.34.1-1
ii  gnome-online-miners   3.34.0-1
ii  gnome-session 3.34.1-1
ii  gnome-settings-daemon 3.34.1-1+b1
ii  

Bug#759008: libtdb1: FTBFS on hurd-i386

[Samuel Thibault]

Hello,

Proper record locking support has been added, the testsuite now runs
fine.  Could you add again the hurd-i386 arch as the attached patch
does?

Thanks,
Samuel
--- debian/control.original 2019-11-01 13:20:51.0 +
+++ debian/control  2019-11-01 13:20:53.0 +
@@ -18,7 +18,7 @@
 Package: libtdb1
 Pre-Depends: ${misc:Pre-Depends}
 Multi-Arch: same
-Architecture: linux-any kfreebsd-any
+Architecture: any
 Section: libs
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: Trivial Database - shared library
@@ -30,7 +30,7 @@
 
 Package: tdb-tools
 Section: utils
-Architecture: linux-any kfreebsd-any
+Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: Trivial Database - bundled binaries
  This is a simple database API. It is modelled after the structure
@@ -43,7 +43,7 @@
 Multi-Arch: same
 Provides: tdb-dev
 Section: libdevel
-Architecture: linux-any kfreebsd-any
+Architecture: any
 Depends: libc6-dev, libtdb1 (= ${binary:Version}), ${misc:Depends}
 Description: Trivial Database - development files
  This is a simple database API. It is modelled after the structure
@@ -54,7 +54,7 @@
 
 Package: python3-tdb
 Section: python
-Architecture: linux-any kfreebsd-any
+Architecture: any
 Depends: libtdb1 (= ${binary:Version}),
  ${misc:Depends},
  ${python3:Depends},

Bug#941198: initscripts: packages should ship systemd units

[Ansgar]

Russ Allbery writes:
> Ansgar  writes:
>> How to proceed with this?  Do you still require any wording changes?
>
> I think we can proceed to add a Policy "should" for including a systemd
> unit file unless someone raises objections pretty soon here.  So far, I
> haven't seen any objections to the basic idea.

Okay.  Anything further I should do except wait?

>> Or should we consider making shipping a sysvinit script, but no systemd
>> unit a RC bug?  Dmitry seems to be concerned that people might just
>> waive it away; I don't think this needs to be a RC bug, but it might
>> slow adoption.
>
> Making it an RC bug seems much too aggressive to start with.  We can look
> at whether that makes sense later, but right now it would make far too
> many packages instantly buggy.

I agree.  I think it should likely stay "should" in the future anyway
(as it is currently for sysvinit too).

> We're doing some of that already even by introducing a "should," and
> there's some argument to be made for starting with a Lintian warning
> instead, but I'm not inclined to be that conservative here, mostly because
> we're long-overdue for saying something, and I think the should is fairly
> mild in this case.

I think there is already a lintian warning:

  https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html

Ansgar

Bug#943931: [Python-modules-team] Bug#943931: cloudpickle: autopkgtests still run python 2 tests

[Diane Trout]

Drat, I thought I'd only forgotten to push the fix, 
and I thought I pulled before updating.

I'll try to resolve the merge conflict in about 10-12 hours.

Diane

On Fri, 2019-11-01 at 09:26 -0300, Emmanuel Arias wrote:
> Hi,
> 
> I believe that the fixed package uploaded is not the same of salsa.
> https://salsa.debian.org/python-team/modules/cloudpickle
> 
> 
> Cheers,
> Arias Emmanuel
> @eamanu
> http://eamanu.com
> 
> El vie., 1 de nov. de 2019 a la(s) 00:30, Diane Trout (di...@ghic.org
> ) escribió:
> > Thanks for noticing and telling me.
> > 
> > Just uploaded a fixed package.
> > 
> > Diane
> > 
> > On Fri, 2019-11-01 at 12:54 +1300, Michael Hudson-Doyle wrote:
> > > Source: cloudpickle
> > > Version: 1.2.1-1
> > > Severity: normal
> > > Tags: patch
> > > 
> > > Dear Maintainer,
> > > 
> > > As subject. Best not to test packages that are no longer
> > > built.  Patch
> > > attached but really, it's trivial :)
> > > 
> > > Cheers,
> > > mwh
> > > 
> > > -- System Information:
> > > Debian Release: buster/sid
> > >   APT prefers eoan-updates
> > >   APT policy: (500, 'eoan-updates'), (500, 'eoan'), (400, 'eoan-
> > > proposed'), (100, 'eoan-backports')
> > > Architecture: amd64 (x86_64)
> > > 
> > > Kernel: Linux 5.3.0-19-generic (SMP w/8 CPU cores)
> > > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN,
> > > TAINT_OOT_MODULE
> > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> > > LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> > > Shell: /bin/sh linked to /usr/bin/dash
> > > Init: systemd (via /run/systemd/system)
> > > LSM: AppArmor: enabled
> > 
> > ___
> > Python-modules-team mailing list
> > python-modules-t...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#943954: tm-align: please make the build reproducible

[Chris Lamb]

Source: tm-align
Version: 20190708+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
tm-align could not be built reproducibly.

This is because the manual call to the gfortran binary was not passing
CFLAGS. Patch attached that modifies this.

Whilst this means we are passing some incorrect-for-Fortran flags
these are ignored by the compiler and it does ensure that we pass the
-fdebug-prefix-map argument required for a reproducible build... as
well as respects all the other dpkg-buildflags injunctions set by the
user.


 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2019-11-01 09:33:56.21542 -0700
--- b/debian/rules  2019-11-01 09:52:36.027717070 -0700
@@ -7,7 +7,7 @@
 
 override_dh_auto_build:
for src in `ls *.f` ; do \
-   gfortran -O3 -g -ffast-math $(CPPFLAGS) $(LDFLAGS) -lm -o `basename 
$${src} .f` $${src} ; \
+   gfortran -ffast-math $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -lm -o 
`basename $${src} .f` $${src} ; \
done
 
 override_dh_auto_clean:

Bug#635223: epiphany-browser: When viewing page from local filesystem, links are dead

[Adam Danischewski]

Epiphany 3.34 / WebKitGTK 2.26.1

When viewing a file:/// url, the links do not open any files - nothing
happens at all.
To open a file I need to copy the location and past it into the address
bar.

-- 

Adam Michael Danischewski

"Cotidie Validiorem"

Software Engineer

55 Austin Place Apt 4P

Staten Island, NY 10304

Phone: (929) 308-9674 • Email: adam.danischew...@gmail.com

http://github.com/AdamDanischewski

Bug#943953: linux: DKMS module builds are failing on arm64 due to lack of armhf cross-compiler

[Raphaël Hertzog]

Source: linux
Version: 5.3.7-1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

https://salsa.debian.org/kernel-team/linux/commit/82c843e1577930c4eb168f626ab9bd483b118efc
seems to break DKMS on arm64:


root@pinebook-kali:/usr/src# dkms autoinstall

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
'make' -j4 ARCH=arm64 KVER=5.3.0-kali1-arm64 
KSRC=/lib/modules/5.3.0-kali1-arm64/build/...(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.3.0-kali1-arm64 (aarch64)
Consult /var/lib/dkms/rtl8723cs/2019.07.31/build/make.log for more information.
root@pinebook-kali:/usr/src# cat 
/var/lib/dkms/rtl8723cs/2019.07.31/build/make.log 
DKMS make.log for rtl8723cs-2019.07.31 for kernel 5.3.0-kali1-arm64 (aarch64)
Fri Nov  1 03:50:50 CDT 2019
make ARCH=arm64 CROSS_COMPILE= -C /lib/modules/5.3.0-kali1-arm64/build/ 
M=/var/lib/dkms/rtl8723cs/2019.07.31/build  modules
make[1]: Entering directory '/usr/src/linux-headers-5.3.0-kali1-arm64'
arch/arm64/Makefile:58: *** arm-linux-gnueabihf-gcc not found, check 
CROSS_COMPILE_COMPAT.  Stop.
make[1]: *** [/usr/src/linux-headers-5.3.0-kali1-common/Makefile:179: sub-make] 
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.3.0-kali1-arm64'
make: *** [Makefile:1670: modules] Error 2


Some more information gathered on IRC:

16:51  Oh, we have the Depends right, so I think the check in 
arch/arm64/Makefile needs to be suppressed when building out-of-tree modules
16:54  bwh: what do you mean with "we have the Depends right" (i.e. with 
or without the cross-compiler)? on what package are you looking?
16:55  The Depends for the linux-headers package don't include an armhf 
compiler, which is correct
16:55  but the kernel build system still looks for it, which is not
16:55  There are some upstream changes around this that might fix it

Cheers,
 Raphaël.

Bug#943664: xserver-xorg-video-radeon: Same behaviour on Thinkpad T41

[Petra R.-P.]

On Thu 31 Oct 2019 at 20:39:18 +0100  Michel Dänzer  wrote:

> We'd again need to see the corresponding Xorg log file.

1. Modified /etc/X11/xorg.conf :

# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc105"
Option  "XkbLayout" "de"
# Option"XkbVariant""nodeadkeys"
  Option"XkbOptions" "compose:caps" # P. R.-P., Mo., 25. Mai 2009
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
EndSection

Section "Device"
Identifier  "Configured Video Device"
  Driver"modesetting"
EndSection

Section "Monitor"
Identifier  "Configured Monitor"
EndSection

Section "Screen"
Identifier  "Default Screen"
Monitor "Configured Monitor"
EndSection



2. /home/petra/.local/share/xorg/Xorg.0.log :

[   451.063] 
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[   451.063] Build Operating System: Linux 4.9.0-8-amd64 i686 Debian
[   451.064] Current Operating System: Linux netty 5.2.0-3-686 #1 SMP Debian 
5.2.17-1 (2019-09-26) i686
[   451.064] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.2.0-3-686 
root=UUID=496e0e0a-6e7c-46c2-9132-315243394a2d ro framebuffer=false quiet 
fb=false systemd.show_status=true
[   451.065] Build Date: 05 March 2019  08:11:12PM
[   451.065] xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
[   451.065] Current version of pixman: 0.36.0
[   451.066]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   451.066] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   451.068] (==) Log file: "/home/petra/.local/share/xorg/Xorg.0.log", Time: 
Thu Oct 31 21:08:45 2019
[   451.098] (==) Using config file: "/etc/X11/xorg.conf"
[   451.106] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   451.232] (==) No Layout section.  Using the first Screen section.
[   451.232] (**) |-->Screen "Default Screen" (0)
[   451.232] (**) |   |-->Monitor "Configured Monitor"
[   451.268] (==) No device specified for screen "Default Screen".
Using the first device section listed.
[   451.268] (**) |   |-->Device "Configured Video Device"
[   451.268] (==) Automatically adding devices
[   451.268] (==) Automatically enabling devices
[   451.268] (==) Automatically adding GPU devices
[   451.268] (==) Max clients allowed: 256, resource mask: 0x1f
[   451.369] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   451.369]Entry deleted from font path.
[   451.509] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[   451.509] (==) ModulePath set to "/usr/lib/xorg/modules"
[   451.509] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[   451.509] (II) Loader magic: 0x6eb740
[   451.509] (II) Module ABI versions:
[   451.509]X.Org ANSI C Emulation: 0.4
[   451.509]X.Org Video Driver: 24.0
[   451.509]X.Org XInput driver : 24.1
[   451.509]X.Org Server Extension : 10.0
[   451.512] (++) using VT number 1

[   451.519] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/_35
[   451.522] (II) xfree86: Adding drm device (/dev/dri/card0)
[   451.524] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11 paused 0
[   451.531] (--) PCI:*(1@0:0:0) 1002:4c57:1014:0530 rev 0, Mem @ 
0xe000/134217728, 0xc010/65536, I/O @ 0x3000/256, BIOS @ 
0x/131072
[   451.551] (II) LoadModule: "glx"
[   451.589] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   452.136] (II) Module glx: vendor="X.Org Foundation"
[   452.136]compiled for 1.20.4, module version = 1.0.0
[   452.136]ABI class: X.Org Server Extension, version 10.0
[   452.136] (II) LoadModule: "modesetting"
[   

Bug#941198: initscripts: packages should ship systemd units

[Russ Allbery]

Ansgar  writes:

> How to proceed with this?  Do you still require any wording changes?

I think we can proceed to add a Policy "should" for including a systemd
unit file unless someone raises objections pretty soon here.  So far, I
haven't seen any objections to the basic idea.

> Or should we consider making shipping a sysvinit script, but no systemd
> unit a RC bug?  Dmitry seems to be concerned that people might just
> waive it away; I don't think this needs to be a RC bug, but it might
> slow adoption.

Making it an RC bug seems much too aggressive to start with.  We can look
at whether that makes sense later, but right now it would make far too
many packages instantly buggy.

We're doing some of that already even by introducing a "should," and
there's some argument to be made for starting with a Lintian warning
instead, but I'm not inclined to be that conservative here, mostly because
we're long-overdue for saying something, and I think the should is fairly
mild in this case.

-- 
Russ Allbery (r...@debian.org)  

Bug#943952: Acknowledgement (gpg --locate-key fails to find keys via "basic/direct" URLs)

[Hans-Christoph Steiner]

I think I found the source of the issue, it seems that gpg ignores HTTP
Redirects:

$ curl --head
https://at.or.at/.well-known/openpgpkey/hu/tyyfxn4t6ytctsfpzfogin37su9pzssg
HTTP/1.1 200 Connection established
HTTP/1.1 301 Moved Permanently
Date: Fri, 01 Nov 2019 16:04:32 GMT
Server: Apache/2.4.38
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
X-Xss-Protection: 1; mode=block
Referrer-Policy: strict-origin
Content-Security-Policy: default-src 'self'; script-src 'self';
style-src 'self' 'unsafe-inline';
Location:
https://keys.openpgp.org/vks/v1/by-fingerprint/EE6620C7136B0D2C456C0A4DE9E28DEA00AA5556
Content-Type: text/html; charset=iso-8859-1

$ gpg --auto-key-locate clear,wkd,nodefault --locate-key h...@at.or.at
gpg: using pgp trust model
gpg: error retrieving 'h...@at.or.at' via WKD: No data
gpg: error retrieving 'h...@at.or.at' via None: No public key
gpg: key "h...@at.or.at" not found: No public key

$ curl --head
https://at.or.at/.well-known/openpgpkey/hu/tyyfxn4t6ytctsfpzfogin37su9pzssg
HTTP/1.1 200 Connection established
HTTP/1.1 200 OK
Date: Fri, 01 Nov 2019 16:04:26 GMT
Server: Apache/2.4.38
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
X-Xss-Protection: 1; mode=block
Referrer-Policy: strict-origin
Content-Security-Policy: default-src 'self'; script-src 'self';
style-src 'self' 'unsafe-inline';
Last-Modified: Fri, 01 Nov 2019 15:18:42 GMT
ETag: "2592-5964a7b2f5880"
Accept-Ranges: bytes
Content-Length: 9618
Strict-Transport-Security: max-age=15768

$ gpg --auto-key-locate clear,wkd,nodefault --locate-key h...@at.or.at
gpg: using pgp trust model
gpg: pub  rsa4096/E9E28DEA00AA5556 2015-10-31  Hans-Christoph Steiner

gpg: key E9E28DEA00AA5556: "Hans-Christoph Steiner
" not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
gpg: auto-key-locate found fingerprint
EE6620C7136B0D2C456C0A4DE9E28DEA00AA5556
gpg: automatically retrieved 'h...@at.or.at' via WKD
pub   rsa4096 2015-10-31 [C]
  EE6620C7136B0D2C456C0A4DE9E28DEA00AA5556
uid   [  full  ] Hans-Christoph Steiner 
uid   [  full  ] Hans-Christoph Steiner 
uid   [  full  ] Hans-Christoph Steiner 
uid   [  full  ] [jpeg image of size 5375]
sub   rsa2048 2015-10-31 [E] [expires: 2020-10-29]
sub   rsa2048 2015-10-31 [S] [expires: 2020-10-29]
sub   rsa2048 2015-10-31 [A]

Bug#941664: vtk6: was the removal of vtk6-examples and vtk6-doc intentional?

[Gert Wollny]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: vtk6-doc,vtk6-examples -- NBS;not built anymore

Yes, the removal was intentional, since vtk6 is EOL upstream and will
get phased out slowly, 

Best, 
Gert 

Bug#908862: Building in reproducible build

[Santiago Vila]

Hi. Some technical notes:

This night I tried to build "neutron" in bullseye a lot of times in a
lot of different virtual machines. These are the failure rates
according to the machine type:

Heztner CX11 with 1 CPU, 2GB of RAM and 2GB of swap
  Failure rate: 100%

Self-hosted KVM machine with 1 CPU, 7GB of RAM and 4GB swap
  Failure rate: 100%

Scaleway DEV1-S machine with 2 CPUs, 2GB of RAM and 2GB of swap
  Failure rate: 100%

Hetzner CX21 with 2 CPU, 4GB of RAM and 4GB of swap
  Failure rate: 6%


My wild guess:

I think it's not lack of RAM, because it builds ok on CX21 most of the
type and it fails on my self-hosted KVM machines which have more RAM.

I guess it should be some sort of race condition which is just more
likely to happen on single-CPU systems (but not impossible to happen
on multi-core, just less likely).

Before you ask: Building on single-CPU is still useful and convenient:

https://people.debian.org/~sanvila/single-cpu/

Thanks.

Bug#943952: gpg --locate-key fails to find keys via "basic/direct" URLs

[Hans-Christoph Steiner]

Package: gpg
Version: 2.2.12-1+deb10u1
Severity: normal

Dear Maintainer,

I recently tried setting up three domains with Web Key Directory (WKD)
"basic/direct" URLs:

https://wiki.gnupg.org/WKDHosting says
>  .well-known/openpgpkey/hu if using the fallback "direct" URL scheme

https://www.ietf.org/id/draft-koch-openpgp-webkey-service-08.txt says:
>
>   The direct method requires no additional DNS entries and constructs
>   the URI from the concatenation of these items:
>
>   o  The scheme "https://;,
>   o  the domain-part,
>   o  the string "/.well-known/openpgpkey/hu/",
>   o  the above constructed 32 octet string,
>   o  the unchanged local-part as a parameter with name "l" using proper
>  percent escaping.

Here are the URLs I setup:

h...@at.or.at
https://at.or.at/.well-known/openpgpkey/hu/tyyfxn4t6ytctsfpzfogin37su9pzssg

h...@guardianproject.info
https://guardianproject.info/.well-known/openpgpkey/hu/tyyfxn4t6ytctsfpzfogin37su9pzssg

ad...@f-droid.org
https://f-droid.org/.well-known/openpgpkey/hu/4y36rkzdjnzmk3oxaekyi5biowgr5kcz

Using this test command fails to find any of them, all failing with the
same error:

$ gpg -v --auto-key-locate clear,wkd,nodefault --locate-key
ad...@f-droid.org
gpg: using pgp trust model
gpg: error retrieving 'ad...@f-droid.org' via WKD: No data
gpg: error retrieving 'ad...@f-droid.org' via None: No public key
gpg: key "ad...@f-droid.org" not found: No public key


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

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

Versions of packages gpg depends on:
ii  gpgconf2.2.12-1+deb10u1
ii  libassuan0 2.5.2-1
ii  libbz2-1.0 1.0.6-9.2~deb10u1
ii  libc6  2.28-10
ii  libgcrypt201.8.4-5
ii  libgpg-error0  1.35-1
ii  libreadline7   7.0-5
ii  libsqlite3-0   3.27.2-3
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages gpg recommends:
ii  gnupg  2.2.12-1+deb10u1

gpg suggests no packages.

-- no debconf information

Bug#908862: Building in reproducible build

[Thomas Goirand]

On 11/1/19 4:12 PM, Santiago Vila wrote:
>> So yes,
>> this is a bug, but it doesn't affect Debian directly.
> 
> It affects my work as QA tester. Look: I'm trying to track all
> packages which FTBFS randomly:
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;include=subject%3AFTBFS+randomly;submitter=sanvila%40debian.org
> 
> because I believe that packages should either build all the time or
> show a clear error message explaining why the build fails.
> 
> By closing this bug, you are implicitly telling me that I should track
> all those bugs outside the Debian BTS, in which case I should better
> stop doing QA on Debian altogether.

Ok, got you. I've reopened the bug.

Thomas Goirand (zigo)

Bug#943951: RFS: gexiv2/0.12.0-1 [RC] -- GObject-based wrapper around the Exiv2 library

[Jason Crain]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

Also, I received a request to upload a version of this to experimental,
using the exiv2 library from experimental, so after this is done I'll
follow up with a new sponsorship request for that.

 * Package name: gexiv2
   Version : 0.12.0-1
   Upstream Author : gexiv2-l...@gnome.org
 * URL : https://wiki.gnome.org/Projects/gexiv2
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/gexiv2
   Section : libs

It builds those binary packages:

  libgexiv2-2 - GObject-based wrapper around the Exiv2 library
  gir1.2-gexiv2-0.10 - GObject-based wrapper around the Exiv2 library - 
introspection data
  libgexiv2-dev - GObject-based wrapper around the Exiv2 library - development 
files
  libgexiv2-doc - GObject-based wrapper around the Exiv2 library - documentation

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gexiv2/gexiv2_0.12.0-1.dsc

Changes since the last upload:

   * New upstream version 0.12.0
   * Update d/copyright
 * Add gexiv2 mailing list to Upstream-Contact.
   * Update d/rules
 * Remove dbgsym migration code since migration is complete.
 * No longer need to specify meson build system since autotools build was
   removed.
 * Renamed enable-gtk-doc option to gtk_doc.
   * Update d/control
 * Bump debhelper level to 12.
 * Switch to the 'debhelper-compat' dependency style. Remove the d/compat
   file.
 * Update Standards-Version to 4.4.1 No changes necessary.
 * Add Rules-Requires-Root: no
   * Update symbols
   * Dynamically generate d/libgexiv2-2.symbols.
 Upstream removed the script which kept C++ symbols from being exported due
 to regressions on OpenBSD 
(https://gitlab.gnome.org/GNOME/gexiv2/issues/27).
 Mark all C++ symbols as optional since these aren't part of the API.
   * Use 'python3' instead of 'python' in autopkgtest.
 Thanks to Matthias Klose (Closes: #943447)
   * Install /usr/share/vala/vapi/gexiv2.deps.
 This file tells vala about dependencies.
   * Add patch Use-exiv2-version-0.25.patch.
 This modifies gexiv2 to use exiv2 version 0.25, the version currently in
 Debian unstable. Upstream is set to use exiv2 version 0.26 or later,
 which is only currently available in Debian experimental.

Regards,

-- 
  Jason Crain

Bug#943905: Bug#943947: Bug#943905: gnutls28 FTCBFS during guile bindings

[Felix Lechner]

FYI, for the related bug #943947:

https://salsa.debian.org/lintian/lintian/commit/e145d962ed99641df8f4bdbc77e6bfdfb51bcdf1

Brings Lintian's list of build profiles in line with the official list
located at:

https://wiki.debian.org/BuildProfileSpec#Registered_profile_names

It would be nice if Lintian had a automated update script to glean
this information from that URL. The script would be used manually when
necessary.

Kind regards,
Felix Lechner

On Fri, Nov 1, 2019 at 6:45 AM Helmut Grohne  wrote:
>
> Hi Andreas,
>
> On Fri, Nov 01, 2019 at 01:42:24PM +0100, Andreas Metzler wrote:
> > This was not the fine point I had been was trying to ask about, though. ;-)
> > - I was wondering why you suggested using a gnutls specific
> > profile ("pkg.gnutls28.noguile") while the BuildProfileSpec lists
> > "noguile" as registered profile name.
>
> I'm sorry. The sole reason was me not remembering that we registered it
> already. I didn't check the docs and just assumed that it wasn't
> registered. As it is, I second #943947 and of course do prefer "noguile"
> over "pkg.something.noguile"!
>
> Helmut
>

Bug#908862: Building in reproducible build

[Santiago Vila]

> > Because it's a bug. This is a matter of principles. We don't close
> > bugs just because we are not motivated enough to fix them, we close them
> > when they are fixed.
> 
> Technically speaking, there's no issue in Debian itself, just in some
> environment which aren't setup in a "normal way", apparently.

We don't really know. You describe your laptop as "normal" and both
my autobuilders and reproducible-builds (where there is a build
failure in unstable, btw) as "not normal", but without a real
understanding of the root cause, this is pure speculation.

It could be, for example, that the test suite assumes a certain
feature to be present on the build machine which is not mandated by
policy (for example a CPU speed greater than "X").

> So yes,
> this is a bug, but it doesn't affect Debian directly.

It affects my work as QA tester. Look: I'm trying to track all
packages which FTBFS randomly:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;include=subject%3AFTBFS+randomly;submitter=sanvila%40debian.org

because I believe that packages should either build all the time or
show a clear error message explaining why the build fails.

By closing this bug, you are implicitly telling me that I should track
all those bugs outside the Debian BTS, in which case I should better
stop doing QA on Debian altogether.

> IMO, going through
> the technical committee for this is a waste of their time: we both agree
> there's an issue that's worth fixing. You just don't agree on my way
> triaging the bugs of the team, and probably feel disappointed that I
> don't wish to spend more time on this.

Not really. I'm disappointed that you want to remove this bug from the
list of bugs we would like to see fixed.

> I do understand the frustration,

I'm not really sure you understand the frustration. Please take a look
at my list of "FTBFS randomly" bugs above.

> Let's make it clear: in no way, I consider there's no problem. (or said
> otherwise: thanks for the bug report, I do recognize there's a bug)

Then please allow it to be in the BTS with whatever severity you feel
comfortable with (including wishlist).

> [...] so I can focus on other things which I
> evaluate as more important.

Nothing will prevent you from focusing on those more important things
if we keep the bug open with a lower severity. That's what severities
are for.

> I feel like
> keeping open bugs for years is lying to our users, and doesn't help.

I agree. However, if we close a bug without actually fixing it, that
would be also a way of lying.

> Anyway, to move forward, I did what you suggested, and I have open a bug
> upstream:
> https://bugs.launchpad.net/neutron/+bug/1850928

Thanks a lot! But I still expect the BTS to be a reflect of the known
problems, regardless of our willingness or motivation to fix them.

Severities exist to prioritize the bugs. If you think this bug is low
priority, set it to "wishlist".

"Closed" is not a severity.

Thanks.

Bug#943509: libsqlite3 (Re: Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4)

[GCS]

Hi Chiaki,

On Thu, Oct 31, 2019 at 9:09 PM ISHIKAWA,chiaki  wrote:
> I vouch that there seems to be a serious issue in libsqlite3 3.30.1-1.
 It's not that fatal like it may seem so.

> I came here because it seems that I have an issue with sqlite3 on my
> linux installation.
> The problem manifested as database operation failures during thunderbird
> mail client regression testing (called mach xcpshell-tests|)
 Is there a documented way to get and run it locally?

> I looks someone on Ubuntu did not see it this month and mozilla's
> compilation and testing farm machines do not seem to see it. They run
> CentOs if I am not mistaken.
 Which version of CentOS? Its latest release, versioned 8 has SQLite3
3.26.0 if I'm not mistaken.

> https://bugzilla.mozilla.org/show_bug.cgi?id=1589779
>
> So I thought maybe the current installation of libsqlite3 on my linux PC
> was to blame.
 Might be, but SQLite3 3.30.1 should be safe.

> Well, it looks that is the case if I read the exchanges here correctly.
> My libsqlite3 seems to be affected: the version is 3.30.1-1
> (The problem was not observed in August. I am not sure if the upgrade of
> libsqlite3 happened during then and now.)
>
> What do people suggest that best course of action under the circumstances?
>
> Downgrade (to which version and how) or install newer libsqlite3 (where)?
 All uploaded SQLite3 Debian packages should be archived[1]. Try
downgrading it to 3.29.0-2 first and see if it helps.

> All I can say is that the same tests that deal with database that worked
> for years suddenly broke in the last several weeks. So my bug report
> would not be that useful :-(
 May you have a date when you first experienced it? As sqlite3 3.30.0
is in the Debian archives since the fifth of October, this may narrow
down the issue a bit.

Regards,
Laszlo/GCS
[1] http://snapshot.debian.org/package/sqlite3/

Bug#874878: [freemat] Future Qt4 removal from Buster

[Anton Gladky]

Yes, I think the package should be removed.

Also the package has no active uploader and nobody in
science group identified such an interest [1].

I will take care about it.

[1] https://lists.debian.org/debian-science/2019/09/msg00018.html

Anton