Bug#945760: matrix-synapse: stop doesn't work

[sergio]

Package: matrix-synapse
Version: 1.5.1-1~bpo10+1
Severity: normal

Dear Maintainer,


% ps | grep matr
 3865 matrix-+ ? 19   0  10:18 Sl 2  0.4  2.1 00:00:03 python3

% sudo /etc/init.d/matrix-synapse stop

% ps | grep matr
 3865 matrix-+ ? 19   0  10:18 Sl 2  0.4  2.1 00:00:03 python3

Bug#945759: matrix-synapse: signing_key_path not found

[sergio]

Package: matrix-synapse
Version: 1.5.1-1~bpo10+1
Severity: normal

# /etc/init.d/matrix-synapse start

chown: missing operand after ‘matrix-synapse:nogroup’
Try 'chown --help' for more information.
chmod: missing operand after ‘0600’
Try 'chmod --help' for more information.



# grep signing_key_path  /etc/matrix-synapse/homeserver.yaml
signing_key_path: "/etc/matrix-synapse/homeserver.signing.key"



# python3 -m synapse.config read signing_key_path --config-path 
/etc/matrix-synapse/homeserver.yaml --config-path /etc/matrix-synapse/conf.d/   
 
This server is configured to use 'matrix.org' as its trusted key server via the
'trusted_key_servers' config option. 'matrix.org' is a good choice for a key
server since it is long-lived, stable and trusted. However, some admins may
wish to use another server for this purpose.

To suppress this warning and continue using 'matrix.org', admins should set
'suppress_key_server_warning' to 'true' in homeserver.yaml.

Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/synapse/config/__main__.py", line 31, in 

print(getattr(config, key))
  File "/usr/lib/python3/dist-packages/synapse/config/_base.py", line 222, in 
__getattr__
return self._get_unclassed_config(None, item)
  File "/usr/lib/python3/dist-packages/synapse/config/_base.py", line 245, in 
_get_unclassed_config
raise AttributeError(item, "not found in %s" % 
(list(self._configs.keys()),))
AttributeError: ('signing_key_path', "not found in ['server', 'tls', 
'database', 'logging', 'ratelimiting', 'media', 'captcha', 'voip', 
'registration', 'metrics', 'api', 'appservice', 'key', 'saml2', 'cas', 'jwt', 
'password', 'email', 'worker', 'authproviders', 'push', 'spamchecker', 
'groups', 'userdirectory', 'consent', 'stats', 'servernotices', 
'roomdirectory', 'thirdpartyrules', 'tracing']")
zsh: exit 1 python3 -m synapse.config read signing_key_path --config-path  
--config-path 




# python3 -m synapse.config read signing_key_file --config-path 
/etc/matrix-synapse/homeserver.yaml --config-path /etc/matrix-synapse/conf.d/
This server is configured to use 'matrix.org' as its trusted key server via the
'trusted_key_servers' config option. 'matrix.org' is a good choice for a key
server since it is long-lived, stable and trusted. However, some admins may
wish to use another server for this purpose.

To suppress this warning and continue using 'matrix.org', admins should set
'suppress_key_server_warning' to 'true' in homeserver.yaml.

Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/synapse/config/__main__.py", line 31, in 

print(getattr(config, key))
  File "/usr/lib/python3/dist-packages/synapse/config/_base.py", line 222, in 
__getattr__
return self._get_unclassed_config(None, item)
  File "/usr/lib/python3/dist-packages/synapse/config/_base.py", line 245, in 
_get_unclassed_config
raise AttributeError(item, "not found in %s" % 
(list(self._configs.keys()),))
AttributeError: ('signing_key_file', "not found in ['server', 'tls', 
'database', 'logging', 'ratelimiting', 'media', 'captcha', 'voip', 
'registration', 'metrics', 'api', 'appservice', 'key', 'saml2', 'cas', 'jwt', 
'password', 'email', 'worker', 'authproviders', 'push', 'spamchecker', 
'groups', 'userdirectory', 'consent', 'stats', 'servernotices', 
'roomdirectory', 'thirdpartyrules', 'tracing']")
zsh: exit 1 python3 -m synapse.config read signing_key_file --config-path  
--config-path 

Bug#945628: apt-offline: Python2 removal in sid/bullseye

[Ritesh Raj Sarraf]

Control: tag -1 +fixed-upstream, pending

THank you for reporting this bug. It has been committed into my
repository and will be part of next upload.

commit 81f92cdb4843aaccfd2c36e61595b4cf3449b44b (HEAD -> debian, origin/debian)
Author: Ritesh Raj Sarraf 
Date:   Thu Nov 28 12:27:55 2019 +0530

Drop some python2 based recommends

Thanks: Sandro Tosi
Closes: #945628

python-soappy is not needed anymore. We use python3-debianbts
python-lzma is not needed anymore. lzma module is part of Python
standard modules now

diff --git a/debian/control b/debian/control
index 7083461..6b14456 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Vcs-Browser: 
https://anonscm.debian.org/cgit/apt-offline/apt-offline.git
 Package: apt-offline
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}, apt, less, python3-magic
-Recommends: python-soappy, debian-archive-keyring, python-lzma, 
python3-debianbts
+Recommends: debian-archive-keyring, python3-debianbts
 Description: offline APT package manager
  apt-offline is an Offline APT Package Manager.
  .


On Wed, 2019-11-27 at 23:58 +, Sandro Tosi wrote:
> Source: apt-offline
> Version: 1.8.1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses
> Python2
> in the autopkg tests (the specific reason can be found searching this
> source package in
> https://people.debian.org/~morph/mass-bug-py2removal_take3.txt ).
> Please stop using Python2, and fix this issue by one of the following
> actions.
> 
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider
> dropping
>   the python-foo package, and only build a python3-foo
> package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>   
>   This is the preferred option.
> 
> - If the package is dead upstream, cannot be converted or maintained
>   in Debian, it should be removed from the distribution.  If the
>   package still has reverse dependencies, raise the severity to
>   "serious" and document the reverse dependencies with the BTS
> affects
>   command.  If the package has no reverse dependencies, confirm that
>   the package can be removed, reassign this issue to ftp.debian.org,
>   make sure that the bug priority is set to normal and retitle the
>   issue to "RM: PKG -- removal triggered by the Python2 removal".
> 
> - If the package has still many users (popcon >= 300), or is needed
> to
>   build another package which cannot be removed, document that by
>   adding the "py2keep" user tag (not replacing the py2remove tag),
>   using the debian-pyt...@lists.debian.org user.  Also any
>   dependencies on an unversioned python package (python, python-dev)
>   must not be used, same with the python shebang.  These have to be
>   replaced by python2/python2.7 dependencies and shebang.
> 
>   This is the least preferred option.
> 
> If there are questions, please refer to the wiki page for the
> removal:
> https://wiki.debian.org/Python/2Removal, or ask for help on IRC
> #debian-python, or the debian-pyt...@lists.debian.org mailing list.
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

The only thing I can do is to allow the user to configure AGS_RT_PRIORITY

http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/thread/ags_audio_loop.c?h=3.0.x=93bddce14d8b1bf98f30867babd9d36db1487fbf#n660

regards,
Joël

On Thu, Nov 28, 2019 at 6:21 AM westlake  wrote:
>
> It looks like I needed to do a reboot to verify the RT-bandwidth cap at
> the 50 limit for kernel.sched_rt_runtime_us in sysctl.. so "top"
> shows gsequencer at 200% (when ags is set with 'jack')
>
> 50 is about half rt period of 1 second(100), and so 200% on this
> computer means it is half the cpu bandwidth on a 4-core machine I'm
> using.. so this confirms the application is still saturating the RT
> bandwidth.
>
> 50/100 = 50%
> 200/400% = 50%
>
> If you have a 2-core system, then saturation in the output of "top"
> would be saying "100%" because the maximum cpu-bandwidth capacity is
> 200% for 2 cores.
>
> By default, the cap-protection for RT-bandwidth is set at 95.. I was
> curious to see if sysctl's setting of kernel.sched_rt_runtime_us was
> effective..
>
> I've only known the basics, and I suppose there's something verifying
> for me here as well, I'm pretty confident I've been learning about RT
> things correctly as I've been setting up ardour+jack to work effectively..
>
> maybe someone from debian team can help with the scheduling call things..
>
> unfortunately I wouldn't be able to mentor coding specifics, but I know
> it has something to do with schedule functions.
>
> good luck..
>

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

[Cyril Brulebois]

Holger Wansing  (2019-11-01):
> 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.

AFAICT from reading the bug log, it seems the part where the priority is
downgraded was implemented. But was there any modifications to ensure
that d-i would still install it, so that pkgsel can run tasksel? Or was
such modifications not needed at all?


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


signature.asc
Description: PGP signature

Bug#945195: [PATCH v2 2/7] email-print-mime-structure: Generic pipe decryption

[Daniel Kahn Gillmor]

On Wed 2019-11-27 08:34:32 -0700, Sean Whitton wrote:
> Hello,
>
> On Mon 25 Nov 2019 at 04:45PM -05, Daniel Kahn Gillmor wrote:
>
>> Signed-off-by: Daniel Kahn Gillmor 
>> ---
>>  email-print-mime-structure | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/email-print-mime-structure b/email-print-mime-structure
>> index cdbe2ee..6c68eb3 100755
>> --- a/email-print-mime-structure
>> +++ b/email-print-mime-structure
>> @@ -94,7 +94,7 @@ class MimePrinter(object):
>>  if self.args.pgpkey:
>>  cryptopayload = self.pgpy_decrypt(self.args.pgpkey, 
>> ciphertext)
>>  if cryptopayload is None and self.args.use_gpg_agent:
>> -cryptopayload = self.gpg_decrypt(ciphertext)
>> +cryptopayload = self.pipe_decrypt(ciphertext, ['gpg', 
>> '--batch', '--decrypt'])
>>  if cryptopayload is None:
>>  logging.warning(f'Unable to decrypt')
>>  return
>> @@ -121,13 +121,13 @@ class MimePrinter(object):
>>  pass
>>  return None
>>
>> -def gpg_decrypt(self, ciphertext:bytes) -> Optional[Message]:
>> +def pipe_decrypt(self, ciphertext:bytes, cmd:List[str]) -> 
>> Optional[Message]:
>>  inp:int
>>  outp:int
>>  inp, outp = os.pipe()
>>  with open(outp, 'wb') as outf:
>>  outf.write(ciphertext)
>> -out:subprocess.CompletedProcess[bytes] = subprocess.run(['gpg', 
>> '--batch', '--decrypt'],
>> +out:subprocess.CompletedProcess[bytes] = subprocess.run(cmd,
>>  stdin=inp,
>>  
>> capture_output=True)
>>  if out.returncode == 0:
>
> Likewise, I can add "no functional change" when I apply this, right?

Yes, this is another "no functional change" :)

 --dkg


signature.asc
Description: PGP signature

Bug#945195: [PATCH v2 1/7] email-print-mime-structure: decrypt PGP/MIME parts as bytes

[Daniel Kahn Gillmor]

On Wed 2019-11-27 08:33:41 -0700, Sean Whitton wrote:
> Hello,
>
> On Mon 25 Nov 2019 at 04:45PM -05, Daniel Kahn Gillmor wrote:
>
>> Fully decode the encrypted part before passing it to any decryption
>> mechanism.
>
> I can go ahead and add "no functional change" to this commit message
> right?

Hm, this is actually *not quite* "no functional change".

In particular, it means we're passing around a bytestream version of the
inner part, not the potentially-encoded (base64 or quoted-printable)
string-like variant.

This actually will have an impact on how we handle some messages -- it's
not just a code reorganization.  for example, if someone were to make an
OpenPGP encrypted message, and they didn't ASCII-armor the encrypted
part, but rather attached it as a binary blob, then their MUA would
probably wrap it in a Content-Transfer-Encoding: base64.

If we then passed the un-decoded blob to an OpenPGP decryptor, it
wouldn't have the OpenPGP armor header, and it wouldn't have the right
bytestream to mark it as a "raw" OpenPGP packet.  so the decryptor
wouldn't be able to handle it.

In practice, all the encrypted messages that i've found to throw at
email-print-mime-structure thus far have had OpenPGP-specific
ASCII-Armoring already, and thus haven't needed to be decoded, and for
*those* messages, there is no functional change needed.

But that won't be the case for the PKCS7 (S/MIME) objects we encounter
later in the series, so it's nice to also make this more robust for
PGP/MIME messages as well.

Hope this makes sense,

   --dkg


signature.asc
Description: PGP signature

Bug#945195: [PATCH v2 3/7] email-print-mime-structure: move decrypt_part to its own function

[Daniel Kahn Gillmor]

On Wed 2019-11-27 08:41:08 -0700, Sean Whitton wrote:
> On Mon 25 Nov 2019 at 04:45PM -05, Daniel Kahn Gillmor wrote:
>
>> Signed-off-by: Daniel Kahn Gillmor 
>> ---
>>  email-print-mime-structure | 31 +++
>>  1 file changed, 19 insertions(+), 12 deletions(-)
>>
>> diff --git a/email-print-mime-structure b/email-print-mime-structure
>> index 6c68eb3..d152b34 100755
>> --- a/email-print-mime-structure
>> +++ b/email-print-mime-structure
>> @@ -32,6 +32,7 @@ something like "cat -n"
>>  '''
>>  import os
>>  import sys
>> +import enum
>>  import email
>>  import logging
>>  import subprocess
>> @@ -51,6 +52,8 @@ try:
>>  except ImportError:
>>  argcomplete = None
>>
>> +EncType = enum.Enum('EncType', ['PGPMIME', 'SMIME'])
>> +
>>  class MimePrinter(object):
>>  def __init__(self, args:Namespace):
>>  self.args = args
>> @@ -79,7 +82,6 @@ class MimePrinter(object):
>>
>>  print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname} 
>> {nbytes:d} bytes')
>>  cryptopayload:Optional[Message] = None
>> -ciphertext:Union[List[Message],str,bytes,None] = None
>>  try_pgp_decrypt:bool = self.args.pgpkey or self.args.use_gpg_agent
>>
>>  if try_pgp_decrypt and \
>> @@ -87,23 +89,28 @@ class MimePrinter(object):
>> (parent.get_content_type().lower() == 'multipart/encrypted') and 
>> \
>> (str(parent.get_param('protocol')).lower() == 
>> 'application/pgp-encrypted') and \
>> (num == 2):
>> -ciphertext = z.get_payload(decode=True)
>> -if not isinstance(ciphertext, bytes):
>> -logging.warning('encrypted part was not a leaf mime part 
>> somehow')
>> -return
>> -if self.args.pgpkey:
>> -cryptopayload = self.pgpy_decrypt(self.args.pgpkey, 
>> ciphertext)
>> -if cryptopayload is None and self.args.use_gpg_agent:
>> -cryptopayload = self.pipe_decrypt(ciphertext, ['gpg', 
>> '--batch', '--decrypt'])
>> -if cryptopayload is None:
>> -logging.warning(f'Unable to decrypt')
>> -return
>> +cryptopayload = self.decrypt_part(z, EncType.PGPMIME)
>>
>>  if cryptopayload is not None:
>>  newprefix = prefix[:-3] + ' '
>>  print(f'{newprefix}↧ (decrypts to)')
>>  self.print_tree(cryptopayload, newprefix + '└', z, 0)
>>
>> +def decrypt_part(self, msg:Message, flavor:EncType) -> 
>> Optional[Message]:
>> +ciphertext:Union[List[Message],str,bytes,None] = 
>> msg.get_payload(decode=True)
>> +cryptopayload:Optional[Message] = None
>> +if not isinstance(ciphertext, bytes):
>> +logging.warning('encrypted part was not a leaf mime part 
>> somehow')
>> +return None
>> +if flavor == EncType.PGPMIME:
>> +if self.args.pgpkey:
>> +cryptopayload = self.pgpy_decrypt(self.args.pgpkey, 
>> ciphertext)
>> +if cryptopayload is None and self.args.use_gpg_agent:
>> +cryptopayload = self.pipe_decrypt(ciphertext, ['gpg', 
>> '--batch', '--decrypt'])
>> +if cryptopayload is None:
>> +logging.warning(f'Unable to decrypt')
>> +return cryptopayload
>> +
>>  def pgpy_decrypt(self, keys:List[str], ciphertext:bytes) -> 
>> Optional[Message]:
>>  if pgpy is None:
>>  logging.warning(f'Python module pgpy is not available, not 
>> decrypting (try "apt install python3-pgpy")')
>
> This seems fine -- no functional change, right?

Yep, this is also "no functional change", just a code reorganization.
I'll try to remember to include that specific text in future patches --
it's a nice hint to the reader in any case :)

   --dkg


signature.asc
Description: PGP signature

Bug#945758: bochs FTCBFS: undefined reference to symbol 'pthread_create@@GLIBC_2.17'

[Helmut Grohne]

Source: bochs
Version: 2.6.9+dfsg-4
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

boch started failing to cross build in the -4 upload. I guess this is
due to the gtk2 removal and now we exercise different paths in
./configure that happen to be broken upstream. Notably, -pthread goes
missing. Generally, this seems to stem from cross/native differences
made by upstream. The attached patch removes two such differences and
makes bochs cross buildable again. Please consider applying it.

Helmut
--- bochs-2.6.9+dfsg.orig/configure.in
+++ bochs-2.6.9+dfsg/configure.in
@@ -2874,7 +2874,7 @@
 AC_SUBST(DIALOG_OBJS)
 AC_SUBST(EXPORT_DYNAMIC)
 
-if test "$use_curses" = yes -a "$cross_configure" = 0; then
+if test "$use_curses" = yes; then
   AC_CHECK_LIB(curses, mvaddch, GUI_LINK_OPTS_TERM='-lcurses')
   AC_CHECK_LIB(ncurses, mvaddch, GUI_LINK_OPTS_TERM='-lncurses')
   AC_CHECK_LIB(termlib, mvaddch, GUI_LINK_OPTS_TERM='-ltermlib')
@@ -3129,7 +3129,7 @@
 
 # since some features need the pthread library, check that it was found.
 # But on win32 platforms, the pthread library is not needed.
-if test "$cross_configure" = 0; then
+if test "$target_os" != "windows"; then
   # assuming that the GUI debuggers require pthreads or are for Win32
   if test "$pthread_ok" = yes; then
 if test "$with_rfb" = yes; then

Bug#945741: tcvt: Python2 removal in sid/bullseye

[Helmut Grohne]

Hi Sandro,

On Wed, Nov 27, 2019 at 11:58:53PM +, Sandro Tosi wrote:
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests (the specific reason can be found searching this
> source package in
> https://people.debian.org/~morph/mass-bug-py2removal_take3.txt ).
> Please stop using Python2, and fix this issue by one of the following
> actions.

Thank you for filing these bugs.

I'm kinda surprised that this bug report comes so "late" given that tcvt
is an application package, which should have received such a bug much
earlier given that converting applications is much less controversial
than removing python2 libraries.

> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.

Upstream here. While tcvt started on Python2, much of its development
actually happend on Python3, so just changing the #! should work.

I was briefly looking whether this is easily fixable upstream. PEP-0394
appears to indicate that plain python is not the worst choice for
publishers, so it seems to me that fixing this in the packaging is the
way to go.

Helmut

Bug#944589: gsequencer: stalls system

[westlake]

It looks like I needed to do a reboot to verify the RT-bandwidth cap at 
the 50 limit for kernel.sched_rt_runtime_us in sysctl.. so "top" 
shows gsequencer at 200% (when ags is set with 'jack')


50 is about half rt period of 1 second(100), and so 200% on this 
computer means it is half the cpu bandwidth on a 4-core machine I'm 
using.. so this confirms the application is still saturating the RT 
bandwidth.


50/100 = 50%
200/400% = 50%

If you have a 2-core system, then saturation in the output of "top" 
would be saying "100%" because the maximum cpu-bandwidth capacity is 
200% for 2 cores.


By default, the cap-protection for RT-bandwidth is set at 95.. I was 
curious to see if sysctl's setting of kernel.sched_rt_runtime_us was 
effective..


I've only known the basics, and I suppose there's something verifying 
for me here as well, I'm pretty confident I've been learning about RT 
things correctly as I've been setting up ardour+jack to work effectively..


maybe someone from debian team can help with the scheduling call things..

unfortunately I wouldn't be able to mentor coding specifics, but I know 
it has something to do with schedule functions.


good luck..

Bug#945757: RM: ncc -- ROM; removal triggered by the Python2 removal, abandoned upstream

[Anuradha Weeraman]

Package: ftp.debian.org
Severity: normal

I request that this package be removed from the distribution as it is
unmaintained upstream and depends on Python 2.

-- 
Regards
Anuradha

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

Thank you very much for your information.

As you might have noticed there is much going on related to new threading API
in GSequencer v3.0.0

And thanks to your information you pointed me to allow adjusting
realtime priorities
by configuration seems to be mandatory.

https://savannah.nongnu.org/task/index.php?15477

best regards,
Joël

On Thu, Nov 28, 2019 at 5:51 AM westlake  wrote:
>
> it will just spike back to 110% when there is even a small load because
> you're not addressing the scheduling issue.
>
> On a 4-core system, when 50% is reserved for the RT-bandwidth the
> greatest percentage for CPU% utilization becomes 200%.
>
> But it is 200% that is shared for all RT-policy tasks..
>
> basically this means 2 cores are fully saturated by that task in "cpu
> bandwidth"..
>
> it could be 2 cores each at 100% or 4 cores each having 50% utilization
> by the various threads by the application.
>
> A properly made application wouldn't saturate all available RT
> bandwidth, as that's called an out-of-control RT application...it's a
> scheduling-function coding issue...
>
> Any-time you have a run-away and in-appropriately scheduled application,
> you automatically have an improperly behaving application that can be
> used to do things it shouldn't..
>
> eg:: fork-bombing a webserver to saturate a server, ddos-attacks is
> doing what ags is doing in saturating the cpu so that no other security
> task can run..
>
> haven't coded in long time, but I'm experienced enough to understand the
> implications about process-bombing/saturation and run-away tasks..
>
> The "FIFO" you see in the pictures -- threads with this policy class are
> RT, and so is RR, as well as BATCH policy task.. so everything of these
> three all need to fit inside the same RT bandwidth.
>
> Ags incorrectly saturates the whole rt bandwidth leaving no  RT
> bandwidth for any other RT task --- such as "drivers" which run on FIFO
> threads.
>
> I wouldn't be a strong mentor on programming at this point in time...
> but basically your application is running out of control when it is
> doing this -- and there's stability as well security issue related.
>
> My gut feeling here is you should be investigating scheduling functions
> as I think it's pretty obvious because there's an error message showing
> exactly this..
>
> Come back and update this report and let me know when this gets fixed.
> -- I could wait ..
>
> thanks
>

Bug#944589: gsequencer: stalls system

[westlake]

it will just spike back to 110% when there is even a small load because 
you're not addressing the scheduling issue.


On a 4-core system, when 50% is reserved for the RT-bandwidth the 
greatest percentage for CPU% utilization becomes 200%.


But it is 200% that is shared for all RT-policy tasks..

basically this means 2 cores are fully saturated by that task in "cpu 
bandwidth"..


it could be 2 cores each at 100% or 4 cores each having 50% utilization 
by the various threads by the application.


A properly made application wouldn't saturate all available RT 
bandwidth, as that's called an out-of-control RT application...it's a 
scheduling-function coding issue...


Any-time you have a run-away and in-appropriately scheduled application, 
you automatically have an improperly behaving application that can be 
used to do things it shouldn't..


eg:: fork-bombing a webserver to saturate a server, ddos-attacks is 
doing what ags is doing in saturating the cpu so that no other security 
task can run..


haven't coded in long time, but I'm experienced enough to understand the 
implications about process-bombing/saturation and run-away tasks..


The "FIFO" you see in the pictures -- threads with this policy class are 
RT, and so is RR, as well as BATCH policy task.. so everything of these 
three all need to fit inside the same RT bandwidth.


Ags incorrectly saturates the whole rt bandwidth leaving no  RT 
bandwidth for any other RT task --- such as "drivers" which run on FIFO 
threads.


I wouldn't be a strong mentor on programming at this point in time... 
but basically your application is running out of control when it is 
doing this -- and there's stability as well security issue related.


My gut feeling here is you should be investigating scheduling functions 
as I think it's pretty obvious because there's an error message showing 
exactly this..


Come back and update this report and let me know when this gets fixed. 
-- I could wait ..


thanks

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

This one liner patch would reduce CPU usage from 300 % to 100 %.

cheers,
Joël

On Thu, Nov 28, 2019 at 5:35 AM Joël Krähemann  wrote:
>
> Hi,
> Just checked the CPU usage again as running the AgsDrum sequencer,
> during playback the usage goes down to 80 %.
>
> I think with a small patch we can fix this behavior.
>
> regards,
> Joël
>
> On Thu, Nov 28, 2019 at 4:26 AM Joël Krähemann  wrote:
> >
> > Hi,
> > I take your complain about CPU usage serious. I intend to target it
> > in GSequencer v2.4.x
> >
> > The high CPU usage is due to AgsThreadPool providing non-blocking
> > calls to AgsTaskThread.
> >
> > But I don't see any way to provide it to buster.
> >
> > If you are interested in what is going on related to the thread API,
> > here are further informations:
> >
> > http://savannah.nongnu.org/forum/forum.php?forum_id=9601
> >
> > sorry,
> > Joël
> >
> > On Thu, Nov 28, 2019 at 3:26 AM Joël Krähemann  
> > wrote:
> > >
> > > Hi,
> > > Yes, it is true. GSequencer consumes too much power as doing no audio
> > > processing.
> > > This was targeted with next major release v3.0.0 expected available
> > > within a half year.
> > >
> > > To change this behavior, I had to refactor the threading API of
> > > GSequencer. Currently
> > > it creates many threads without running any audio processing.
> > >
> > > The thread pool is the main cause for this, which is used by 
> > > AgsTaskThread.
> > >
> > > In GSequencer v3.0.0 the AgsTask objects are launched in GMainContext. 
> > > But for
> > > now they run asynchronous exclusive and are added by a non-blocking call.
> > >
> > >
> > > On Thu, Nov 28, 2019 at 2:00 AM westlake  
> > > wrote:
> > > >
> > > > Here when I use gsequencer, (pasuspender not needed)
> > > > LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" gsequencer
> > > >
> > > > I can run skipping the plugin-scan, I can get the graphical interface
> > > > within a second...
> > > >
> > > > dragging the window skimps as this app is not throttling it's cpu
> > > > utilization correctly..
> > > >
> > > > When using "top", the app is using 300%...
> > > >
> > > > The limits setting /etc/security/limits.conf::
> > > > (for security limits.conf, I comment-out everything in
> > > > /etc/security/limits.d/  to keep the configuration easier to read)
> > > > ""
> > > > * hard core 0
> > > > * hard nofile 1048576
> > > > * hard rtprio 95
> > > > * - memlock unlimited
> > > > * - msgqueue 65536
> > > > * - nice -19
> > > > * - nice -20
> > > > * - rttime 10
> > > > * soft core 0
> > > > * soft nofile 1048576
> > > > * soft rtprio 95
> > > > @users  -  priority 0
> > > > ""
> > > >
> > > > changed rtprio to 35, and "top"(command) still says gsequencer is using
> > > > 300% even after reboot.
> > > > "* hard rtprio 95
> > > > * soft rtprio 95"
> > > > "* hard rtprio 35
> > > > * soft rtprio 35"
> > > >
> > > >
> > > > The observation when rtprio is set at 95-> majority of threads go at
> > > > FIFO 95. [ screenshot  provided ]
> > > >
> > > > The observation when rtprio is set at 35-> all threads are set to
> > > > SCHED_OTHER and only one gets set at FIFO with priority 20.
> > > >
> > > > 'jack' for both rtprio cases in ags' settings, 1 reboot with the
> > > > different rtprio settings.  So the rtprio gets set aggressively with 95,
> > > > but barely nothing set with 35. << buggy.
> > > >
> > > > More buggy because with both rtprio settings the cpu is still at 300%.
> > > >
> > > >   --> ags should be down at 2-5% when it is not doing any work.
> > > >
> > > > When I look at an RT-driven application such as ardour, while it runs it
> > > > does spike in cpu it immediately goes back down to 5%.
> > > >
> > > > ..also the rt-safe option in ags doesn't do anything. cpu% is still
> > > > spiked high..
> > >
> > > The RT-safe option does reduce the calls to malloc().
> > >
> > > >
> > > > Other observation:
> > > > When ags is set at alsa, the cpu% is lower but it is still very high at
> > > > 110%.
> > > >
> > > > The threads with the alsa setting show 0.3% cpu utilization instead of
> > > > 10% when ags is set to jack..   the "main" process I suppose is the one
> > > > that is always going 100+% for both alsa and jack cases.
> > > >
> > > > quick summary::
> > > > Alsa (top without -H) --> 110%
> > > > Jack (top without -H) --> 300%
> > > >
> > > > When it says 100+%, ags is using more than 1 core..
> > > >
> > > > With jack, 3 cores are now bogged down..  That tells me there is
> > > > something very wrong.
> > > >
> > > > I can now see what is happening... there's a bug because gsequencer is
> > > > doing no work but it polls the cpu at 100%-300%...
> > >
> > > There many threads running. Especially AgsThreadPoll creates some
> > > threads that might be used.
> > >
> > > >
> > > > The cpu% is still grabbed even when I change  kernel.sched_rt_runtime_us
> > > > = 95  to 50
> > > >
> > > > so there's a serious violation of scheduling policy happening here with
> > > > RT kernels for this software.
> > >
> > > 

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,
Just checked the CPU usage again as running the AgsDrum sequencer,
during playback the usage goes down to 80 %.

I think with a small patch we can fix this behavior.

regards,
Joël

On Thu, Nov 28, 2019 at 4:26 AM Joël Krähemann  wrote:
>
> Hi,
> I take your complain about CPU usage serious. I intend to target it
> in GSequencer v2.4.x
>
> The high CPU usage is due to AgsThreadPool providing non-blocking
> calls to AgsTaskThread.
>
> But I don't see any way to provide it to buster.
>
> If you are interested in what is going on related to the thread API,
> here are further informations:
>
> http://savannah.nongnu.org/forum/forum.php?forum_id=9601
>
> sorry,
> Joël
>
> On Thu, Nov 28, 2019 at 3:26 AM Joël Krähemann  wrote:
> >
> > Hi,
> > Yes, it is true. GSequencer consumes too much power as doing no audio
> > processing.
> > This was targeted with next major release v3.0.0 expected available
> > within a half year.
> >
> > To change this behavior, I had to refactor the threading API of
> > GSequencer. Currently
> > it creates many threads without running any audio processing.
> >
> > The thread pool is the main cause for this, which is used by AgsTaskThread.
> >
> > In GSequencer v3.0.0 the AgsTask objects are launched in GMainContext. But 
> > for
> > now they run asynchronous exclusive and are added by a non-blocking call.
> >
> >
> > On Thu, Nov 28, 2019 at 2:00 AM westlake  wrote:
> > >
> > > Here when I use gsequencer, (pasuspender not needed)
> > > LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" gsequencer
> > >
> > > I can run skipping the plugin-scan, I can get the graphical interface
> > > within a second...
> > >
> > > dragging the window skimps as this app is not throttling it's cpu
> > > utilization correctly..
> > >
> > > When using "top", the app is using 300%...
> > >
> > > The limits setting /etc/security/limits.conf::
> > > (for security limits.conf, I comment-out everything in
> > > /etc/security/limits.d/  to keep the configuration easier to read)
> > > ""
> > > * hard core 0
> > > * hard nofile 1048576
> > > * hard rtprio 95
> > > * - memlock unlimited
> > > * - msgqueue 65536
> > > * - nice -19
> > > * - nice -20
> > > * - rttime 10
> > > * soft core 0
> > > * soft nofile 1048576
> > > * soft rtprio 95
> > > @users  -  priority 0
> > > ""
> > >
> > > changed rtprio to 35, and "top"(command) still says gsequencer is using
> > > 300% even after reboot.
> > > "* hard rtprio 95
> > > * soft rtprio 95"
> > > "* hard rtprio 35
> > > * soft rtprio 35"
> > >
> > >
> > > The observation when rtprio is set at 95-> majority of threads go at
> > > FIFO 95. [ screenshot  provided ]
> > >
> > > The observation when rtprio is set at 35-> all threads are set to
> > > SCHED_OTHER and only one gets set at FIFO with priority 20.
> > >
> > > 'jack' for both rtprio cases in ags' settings, 1 reboot with the
> > > different rtprio settings.  So the rtprio gets set aggressively with 95,
> > > but barely nothing set with 35. << buggy.
> > >
> > > More buggy because with both rtprio settings the cpu is still at 300%.
> > >
> > >   --> ags should be down at 2-5% when it is not doing any work.
> > >
> > > When I look at an RT-driven application such as ardour, while it runs it
> > > does spike in cpu it immediately goes back down to 5%.
> > >
> > > ..also the rt-safe option in ags doesn't do anything. cpu% is still
> > > spiked high..
> >
> > The RT-safe option does reduce the calls to malloc().
> >
> > >
> > > Other observation:
> > > When ags is set at alsa, the cpu% is lower but it is still very high at
> > > 110%.
> > >
> > > The threads with the alsa setting show 0.3% cpu utilization instead of
> > > 10% when ags is set to jack..   the "main" process I suppose is the one
> > > that is always going 100+% for both alsa and jack cases.
> > >
> > > quick summary::
> > > Alsa (top without -H) --> 110%
> > > Jack (top without -H) --> 300%
> > >
> > > When it says 100+%, ags is using more than 1 core..
> > >
> > > With jack, 3 cores are now bogged down..  That tells me there is
> > > something very wrong.
> > >
> > > I can now see what is happening... there's a bug because gsequencer is
> > > doing no work but it polls the cpu at 100%-300%...
> >
> > There many threads running. Especially AgsThreadPoll creates some
> > threads that might be used.
> >
> > >
> > > The cpu% is still grabbed even when I change  kernel.sched_rt_runtime_us
> > > = 95  to 50
> > >
> > > so there's a serious violation of scheduling policy happening here with
> > > RT kernels for this software.
> >
> > What scheduling policy are you talking about?
> >
> > >
> > > ..
> > > I also don't know what makes you think pulseaudio is being used, here I
> > > have it masked under ~/.config/systemd/user ..  Jackdbus here is also
> > > not handled by the dbus-auto-activation,...
> > >
> > > ~/.local/share/dbus-1/services/org.jackaudio.service
> > > "
> > > [D-BUS Service]
> > > Name=org.jackaudio.service
> > >
> > > 

Bug#920340: low priority

[sergio]

Subject: [package on hold] unattended-upgrades result for synapse.host:
SUCCESS

Unattended upgrade result: All upgrades installed

Packages with upgradable origin but kept back:
 matrix-synapse

Unattended-upgrades log:
Initial blacklist :
Initial whitelist:
Starting unattended upgrades script
Allowed origins are: origin=Debian,codename=buster,label=Debian,
origin=Debian,codename=buster,label=Debian-Security, origin=Debian,
origin=Debian Backports, origin=Outerface
Packages that will be upgraded:


% apt policy matrix-synapse
matrix-synapse:
  Installed: 1.3.0-1~bpo10+1
  Candidate: 1.5.1-1~bpo10+1
  Version table:
 1.5.1-1~bpo10+1 100
100 https://deb.debian.org/debian buster-backports/main amd64
Packages
 *** 1.3.0-1~bpo10+1 100
100 /var/lib/dpkg/status
 0.99.2-6 500
500 https://deb.debian.org/debian buster/main amd64 Packages

% apt-mark showhold
% s apt dist-upgrade
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.


-- 
sergio.

Bug#945756: ITP: golang-github-flynn-noise -- Go implementation of the Noise Protocol Framework

[Christian Barcenas]

Package: wnpp
Severity: wishlist
Owner: Christian Barcenas 

* Package name: golang-github-flynn-noise
  Version : 0.0~git20180327.2492fe1-1
  Upstream Author : Flynn
* URL : https://github.com/flynn/noise
* License : BSD-3-Clause
  Programming Lang: Go
  Description : Go implementation of the Noise Protocol Framework

 This is a Go package that implements the Noise Protocol Framework
 (https://noiseprotocol.org).
 .
 Noise is a framework for building crypto protocols. Noise protocols
 support mutual and optional authentication, identity hiding, forward secrecy,
 zero round-trip encryption, and other advanced features.

I would like to submit this package for inclusion in the Debian Archive as
a dependency of WIP packaging for Nebula (github.com/slackhq/nebula).

Bug#944022: Firehol /etc/default

[Michael Norton]

I think any fix for this bug that relies on preserving the old behaviour of 
/etc/default/firehol is the wrong approach. I had a look through Debian Policy 
Manual Section 9.3: System run levels and init.d scripts; here’s some snippets:


"This extra file [/etc/default] should be sourced by the [init.d] script when 
the script runs.”

"If [...] the daemon should not be autostarted unless the local administrator 
has explicitly requested this, [...] add to your postinst script, 'update-rc.d 
package defaults-disabled', and add a dependency on init-system-helpers (>= 
1.50), which introduced the defaults-disabled option. Then the local 
administrator can enable autostarting the daemon…."

"An older practice, which should not be used, was to include a line like 
DISABLED=yes in the package's /etc/default file. The package's init script 
would not start the service until the local system administrator changed this 
to DISABLED=no, or similar. The problem with this approach was that it hides 
from the init system whether or not the daemon should actually be started, 
which leads to inconsistent and confusing behavior: service  start may 
return success but not start the service; services with a dependency on this 
service will be started even though the service isn’t running..."


I believe the correct solution would be:

1. Upon package upgrades, check for existing /etc/default/firehol and enable or 
disable the systemd unit according to the existing $START_FIREHOL value.
2. For fresh installs, systemd unit should ship as disabled.
3. Remove the /etc/default/firehol config file.
4. Remove the /etc/init.d/firehol script.
5. Update the documentation. ;-)


I am willing to work on that but it’s unlikely to be any time soon.

-mn

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,
I take your complain about CPU usage serious. I intend to target it
in GSequencer v2.4.x

The high CPU usage is due to AgsThreadPool providing non-blocking
calls to AgsTaskThread.

But I don't see any way to provide it to buster.

If you are interested in what is going on related to the thread API,
here are further informations:

http://savannah.nongnu.org/forum/forum.php?forum_id=9601

sorry,
Joël

On Thu, Nov 28, 2019 at 3:26 AM Joël Krähemann  wrote:
>
> Hi,
> Yes, it is true. GSequencer consumes too much power as doing no audio
> processing.
> This was targeted with next major release v3.0.0 expected available
> within a half year.
>
> To change this behavior, I had to refactor the threading API of
> GSequencer. Currently
> it creates many threads without running any audio processing.
>
> The thread pool is the main cause for this, which is used by AgsTaskThread.
>
> In GSequencer v3.0.0 the AgsTask objects are launched in GMainContext. But for
> now they run asynchronous exclusive and are added by a non-blocking call.
>
>
> On Thu, Nov 28, 2019 at 2:00 AM westlake  wrote:
> >
> > Here when I use gsequencer, (pasuspender not needed)
> > LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" gsequencer
> >
> > I can run skipping the plugin-scan, I can get the graphical interface
> > within a second...
> >
> > dragging the window skimps as this app is not throttling it's cpu
> > utilization correctly..
> >
> > When using "top", the app is using 300%...
> >
> > The limits setting /etc/security/limits.conf::
> > (for security limits.conf, I comment-out everything in
> > /etc/security/limits.d/  to keep the configuration easier to read)
> > ""
> > * hard core 0
> > * hard nofile 1048576
> > * hard rtprio 95
> > * - memlock unlimited
> > * - msgqueue 65536
> > * - nice -19
> > * - nice -20
> > * - rttime 10
> > * soft core 0
> > * soft nofile 1048576
> > * soft rtprio 95
> > @users  -  priority 0
> > ""
> >
> > changed rtprio to 35, and "top"(command) still says gsequencer is using
> > 300% even after reboot.
> > "* hard rtprio 95
> > * soft rtprio 95"
> > "* hard rtprio 35
> > * soft rtprio 35"
> >
> >
> > The observation when rtprio is set at 95-> majority of threads go at
> > FIFO 95. [ screenshot  provided ]
> >
> > The observation when rtprio is set at 35-> all threads are set to
> > SCHED_OTHER and only one gets set at FIFO with priority 20.
> >
> > 'jack' for both rtprio cases in ags' settings, 1 reboot with the
> > different rtprio settings.  So the rtprio gets set aggressively with 95,
> > but barely nothing set with 35. << buggy.
> >
> > More buggy because with both rtprio settings the cpu is still at 300%.
> >
> >   --> ags should be down at 2-5% when it is not doing any work.
> >
> > When I look at an RT-driven application such as ardour, while it runs it
> > does spike in cpu it immediately goes back down to 5%.
> >
> > ..also the rt-safe option in ags doesn't do anything. cpu% is still
> > spiked high..
>
> The RT-safe option does reduce the calls to malloc().
>
> >
> > Other observation:
> > When ags is set at alsa, the cpu% is lower but it is still very high at
> > 110%.
> >
> > The threads with the alsa setting show 0.3% cpu utilization instead of
> > 10% when ags is set to jack..   the "main" process I suppose is the one
> > that is always going 100+% for both alsa and jack cases.
> >
> > quick summary::
> > Alsa (top without -H) --> 110%
> > Jack (top without -H) --> 300%
> >
> > When it says 100+%, ags is using more than 1 core..
> >
> > With jack, 3 cores are now bogged down..  That tells me there is
> > something very wrong.
> >
> > I can now see what is happening... there's a bug because gsequencer is
> > doing no work but it polls the cpu at 100%-300%...
>
> There many threads running. Especially AgsThreadPoll creates some
> threads that might be used.
>
> >
> > The cpu% is still grabbed even when I change  kernel.sched_rt_runtime_us
> > = 95  to 50
> >
> > so there's a serious violation of scheduling policy happening here with
> > RT kernels for this software.
>
> What scheduling policy are you talking about?
>
> >
> > ..
> > I also don't know what makes you think pulseaudio is being used, here I
> > have it masked under ~/.config/systemd/user ..  Jackdbus here is also
> > not handled by the dbus-auto-activation,...
> >
> > ~/.local/share/dbus-1/services/org.jackaudio.service
> > "
> > [D-BUS Service]
> > Name=org.jackaudio.service
> >
> > SystemdService=dbus-org.jackaudio.service
> > "
> >
> > ~/.config/systemd/user/dbus-org.jackaudio.service -- allows the user to
> > enable/disable jackdbus and whether to have it auto-start or not..  This
> > is user-defined startup unit file and is what I use here to stop jack as
> > needed.
> >
> > pulseaudio cannot be autostarted because it is masked..
> >
> > ls ~/.config/systemd/user/
> > pulseaudio.service -> /dev/null
> > pulseaudio.socket -> /dev/null
> >
> > things in ~/.config/systemd/user override things in /usr/lib/systemd/user/
> > 

Bug#945754: Allow /etc/ntpsec/ntp.keys in apparmor policy

[Richard Laager]

I've cloned this issue into a new bug.

On 11/26/19 12:44 PM, Stephan Seitz wrote:
> On Mo, Nov 18, 2019 at 09:05:35 -0600, Richard Laager wrote:
> Ah, concerning the apparmor policy: I had to do a manual overwrite for
> ntp.keys (default only in /etc):
> /etc/ntpsec/ntp.keys r,

You make a good point that this should be in /etc/ntpsec. I'll look into
making that happen.

Use of ntp.keys is a scenario that doesn't get discussed much.
README.Debian says:
ntpkeygen can be used to generate an MD5 ntp.keys file in /etc.  Use
of these keys has not yet been tested; please report success or
failure in using them to the maintainer." I believe that text, or at
least the spirit, is inherited from the ntp package, and both
upstreams are curious to hear from users of this too.

Are you using this between your own server and clients, or between your
server and external servers? Do you anticipate NTS replacing your use of
ntp.keys? (If not, why?)

> And since you’ll probably need an entry for NTS key and certificate,
> this should maybe be mentioned in ntp.conf.

Agreed! ntp.conf has an example of the bits that belong there. The
apparmor bit is covered in README.Debian:

When configuring ntpd as an NTS server, if your certificate and key
files are not already covered by
/etc/apparmor.d/abstractions/ssl_certs and ssl_keys, you will need
to add rules to /etc/apparmor.d/local/usr.sbin.ntpd to allow reading
them.

If you have suggested changes to that, please let me know.

The first goal is for this to work out of the box, so I have used the
existing Apparmor abstractions, which cover certbot, etc.

-- 
Richard

Bug#945755: RFS: ipgrab/0.9.10-4 [QA] -- tcpdump-like utility that prints detailed header information

[Thiago]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: ipgrab
   Version : 0.9.10-4
   Upstream Author : Mike Borella 
 * URL : https://sourceforge.net/projects/ipgrab/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/ipgrab
   Section : net

It builds those binary packages:

  ipgrab - tcpdump-like utility that prints detailed header information

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/ipgrab/ipgrab_0.9.10-4.dsc

Changes since the last upload:

   * QA upload.
   * debian/control: Adding VCS fields in control file.

Regards,

--
...
⢀⣴⠾⠻⢶⣦⠀ Thiago Andrade Marques
⣾⠁⢰⠒⠀⣿⡁ GPG: 4096R/F8CDB08B
⢿⡄⠘⠷⠚⠋⠀ GPG Fingerprint: 1D38 EE3C 624F 955C E1FA  3C85 5A30 3591 F8CD B08B
⠈⠳⣄ Cel: 19 98181-1156

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,
Yes, it is true. GSequencer consumes too much power as doing no audio
processing.
This was targeted with next major release v3.0.0 expected available
within a half year.

To change this behavior, I had to refactor the threading API of
GSequencer. Currently
it creates many threads without running any audio processing.

The thread pool is the main cause for this, which is used by AgsTaskThread.

In GSequencer v3.0.0 the AgsTask objects are launched in GMainContext. But for
now they run asynchronous exclusive and are added by a non-blocking call.


On Thu, Nov 28, 2019 at 2:00 AM westlake  wrote:
>
> Here when I use gsequencer, (pasuspender not needed)
> LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" gsequencer
>
> I can run skipping the plugin-scan, I can get the graphical interface
> within a second...
>
> dragging the window skimps as this app is not throttling it's cpu
> utilization correctly..
>
> When using "top", the app is using 300%...
>
> The limits setting /etc/security/limits.conf::
> (for security limits.conf, I comment-out everything in
> /etc/security/limits.d/  to keep the configuration easier to read)
> ""
> * hard core 0
> * hard nofile 1048576
> * hard rtprio 95
> * - memlock unlimited
> * - msgqueue 65536
> * - nice -19
> * - nice -20
> * - rttime 10
> * soft core 0
> * soft nofile 1048576
> * soft rtprio 95
> @users  -  priority 0
> ""
>
> changed rtprio to 35, and "top"(command) still says gsequencer is using
> 300% even after reboot.
> "* hard rtprio 95
> * soft rtprio 95"
> "* hard rtprio 35
> * soft rtprio 35"
>
>
> The observation when rtprio is set at 95-> majority of threads go at
> FIFO 95. [ screenshot  provided ]
>
> The observation when rtprio is set at 35-> all threads are set to
> SCHED_OTHER and only one gets set at FIFO with priority 20.
>
> 'jack' for both rtprio cases in ags' settings, 1 reboot with the
> different rtprio settings.  So the rtprio gets set aggressively with 95,
> but barely nothing set with 35. << buggy.
>
> More buggy because with both rtprio settings the cpu is still at 300%.
>
>   --> ags should be down at 2-5% when it is not doing any work.
>
> When I look at an RT-driven application such as ardour, while it runs it
> does spike in cpu it immediately goes back down to 5%.
>
> ..also the rt-safe option in ags doesn't do anything. cpu% is still
> spiked high..

The RT-safe option does reduce the calls to malloc().

>
> Other observation:
> When ags is set at alsa, the cpu% is lower but it is still very high at
> 110%.
>
> The threads with the alsa setting show 0.3% cpu utilization instead of
> 10% when ags is set to jack..   the "main" process I suppose is the one
> that is always going 100+% for both alsa and jack cases.
>
> quick summary::
> Alsa (top without -H) --> 110%
> Jack (top without -H) --> 300%
>
> When it says 100+%, ags is using more than 1 core..
>
> With jack, 3 cores are now bogged down..  That tells me there is
> something very wrong.
>
> I can now see what is happening... there's a bug because gsequencer is
> doing no work but it polls the cpu at 100%-300%...

There many threads running. Especially AgsThreadPoll creates some
threads that might be used.

>
> The cpu% is still grabbed even when I change  kernel.sched_rt_runtime_us
> = 95  to 50
>
> so there's a serious violation of scheduling policy happening here with
> RT kernels for this software.

What scheduling policy are you talking about?

>
> ..
> I also don't know what makes you think pulseaudio is being used, here I
> have it masked under ~/.config/systemd/user ..  Jackdbus here is also
> not handled by the dbus-auto-activation,...
>
> ~/.local/share/dbus-1/services/org.jackaudio.service
> "
> [D-BUS Service]
> Name=org.jackaudio.service
>
> SystemdService=dbus-org.jackaudio.service
> "
>
> ~/.config/systemd/user/dbus-org.jackaudio.service -- allows the user to
> enable/disable jackdbus and whether to have it auto-start or not..  This
> is user-defined startup unit file and is what I use here to stop jack as
> needed.
>
> pulseaudio cannot be autostarted because it is masked..
>
> ls ~/.config/systemd/user/
> pulseaudio.service -> /dev/null
> pulseaudio.socket -> /dev/null
>
> things in ~/.config/systemd/user override things in /usr/lib/systemd/user/
> /usr/lib/systemd/user/pulseaudio.service
> /usr/lib/systemd/user/pulseaudio.socket
>
> there may be a "pulse" entry in "aplay -L", but its a dormant entry as
> "pgrep -fa pulseaudio" and "pacmd" do not show no pulseaudio ever gets
> loaded...
>
> For security/audit team:
> Ags-> 2 megabytes, uses 300% of the cpu cores.
> Ardour-> a 100+ megabyte application uses just 5%.
>

What makes you think memory usage has anything to do with CPU
consumption?

> This package severely ignores scheduling restrictions. --- its' the only
> RT audio application on debian that violates and ignores settings in
> both /etc/security/limits.conf and /etc/sysctl.d/ for
> kernel.sched_rt_runtime_us.

So you think I should parse these files?

Bug#931695: libgit-raw-perl: FTBFS with libgit2 0.28

[Peter Green]

tags 931695 +patch
thanks

Some poking around revealed that upstream fixed this by removing the last (NULL) 
parameter from the call. This was done in a commit titled "minor fixes". 
https://github.com/jacquesg/p5-Git-Raw/commit/30f7a4491ab453d28ae1fa1b393fcd023f6c344d . 
There was also another apparently unrelated change in the commit, which did not seem 
relavent to the version in Debian.

I did a test build with this change in a raspbian bullseye-staging chroot.

A couple of tests failed, but that could have just been my build environment, I 
decided this was good enough to disable the testsuite and upload to raspbian.

While working on this I ran into an issue with the clean target not cleaning up 
properly, so I fixed that too.

A debdiff should appear soon at 
https://debdiffs.raspbian.org/main/libg/libgit-raw-perl

No intent to NMU in debian.

Bug#945753: gnome-screenshot: Wrong size image captured for active window, scaling at 200%

[Hank Barta]

Package: gnome-screenshot
Version: 3.30.0-2
Severity: normal
Tags: patch

Dear Maintainer,


   * What led up to the situation?

Capture an image of "Active Window" with Display property scaling set to 200%.
Result is upper left 1/4 of image is captured.

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

Select area to capture - results as expected.
Select entire screen to capture - results as expected.

   * What was the outcome of this action?

Result is upper left 1/4 of "Active Window" is captured.

   * What outcome did you expect instead?

Complete active window should be captured.

   * Additional information

Other users have confirmed that this is fixed in more recent versions of gnome-
screenshot. I am using 3.30 on Buster.

barta@rocinante:~/Downloads/gnome-screenshot/src$ apt-cache policy gnome-
screenshot
gnome-screenshot:
  Installed: 3.30.0-2
  Candidate: 3.30.0-2
  Version table:
 *** 3.30.0-2 500
500 http://deb.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status
hbarta@rocinante:~/Downloads/gnome-screenshot/src$


At https://gitlab.gnome.org/GNOME/gnome-screenshot/blob/master/src/screenshot-
utils.c
Most recent entry in the git log sounds like the fix for the problem

commit e0c4cd438a1e8225499a44dbca4013e3dc92e7d9
Author: Cosimo Cecchi 
Date:   Wed Jul 24 17:45:35 2019 +0200

utils: fix X11 fallback code path for HiDPi

The X11 fallback code path did not correctly account for the
scale factor, and would lead to screenshots of a quarter size only.




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

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

Versions of packages gnome-screenshot depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-0   3.24.5-1
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2

gnome-screenshot recommends no packages.

gnome-screenshot suggests no packages.

-- no debconf information
I do not have a patch. I could not determine how to unselect that option. I did 
include the git commit ID of the upstream fix.
I do not have a patch. I could not determine how to unselect that option. I did 
include the git commit ID of the upstream fix.

Bug#873651: O: flask-openid -- OpenID support for Flask applications

[Sandro Tosi]

On Sat, 2 Nov 2019 20:51:44 -0300 Emmanuel Arias
 wrote:
> Hi!
>
> I am interest to adopt it  :-)

did you get to it? please drop its py2 package when you do so, hopefully soon

Bug#945752: ITP: janus -- thread-safe asyncio-aware queue for Python

[dr]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : python3-janus
  Version  : 0.4.0
  Upstream Author  : Andrew Svetlov
* Url  : https://github.com/aio-libs/janus
* Licenses : Apache-2.0
  Programming Lang : Python

 Mixed sync-async queue,
 supposed to be used for communicating
 between classic synchronous (threaded) code
 and asynchronous (in terms of asyncio) one.
 .
 Like Janus god,
 the queue object from the library has two faces:
 synchronous and asynchronous interface.
 .
 Synchronous is fully compatible with standard queue,
 asynchronous one follows asyncio queue design.

Package is needed by pantalaimon.

I plan to maintain this package myself, keeping debianization in 
following Git repository:

 https://salsa.debian.org/debian/python-janus.git

 - Jonas

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

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


signature.asc
Description: signature

Bug#944930: RFS: libt3highlight/0.4.6-2

[Adam Borowski]

Control: tags -1 +moreinfo

On Wed, Nov 27, 2019 at 09:11:07AM +0100, Gertjan Halkes wrote:
> I would like to kindly bring this bug to your attention again. I think it may
> have fallen through the cracks as I accidentally didn't wait for the upload
> to finish and it got rejected on the first try. I would very much like to
> have some feedback on whether I correctly packaged the fix for the stable
> release.

Alas, the cracks are pretty wide :/

> On Sun, 17 Nov 2019 19:57:23 +0100, Gertjan Halkes  wrote:
> >I have prepared a fix for the stable version of my package "libt3highlight".
> >It is a simple back-port of a fix that is already available in
> >unstable/testing. I would appreciate it if you could have a look and provide
> >guidance on whether I have packaged this correctly (this is the first time
> >I'm preparing a bug-fix for a package in stable).

I'm afraid that there's a non-trivial process for a stable update.

It is described in developers-reference section 5.5.1.:
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions

First, you need to file a bug on release.debian.org explaining the reason
and including the debdiff between 0.4.6-1 and the new upload.  Only once
approved, we can continue with actually uploading.

> >* Package name: libt3highlight
> >  Version : 0.4.6-2

The version must end with +deb10u1 (u2 for second update, etc; deb11 for
Bullseye, ...).  So it'd be 0.4.6-1+deb10u1 .

> >Changes since the last upload:
> >
> >  * Back-port of bugfix from version 0.4.8 that prevents crashes due to
> >calling free on an invalid pointer.

It would be good to describe all other changes as well.
Adding a way to verify upstream signatures is good.
Making the build verbose may get allowed, but I'm not sure.

So, you need to seek the stable release team's approval, then come back
here.  Good luck!


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#945751: openafs-modules-dkms: openafs-dkms kernel module does not build for kernel 5.3.0-2-amd64

[Robert Senger]

Package: openafs-modules-dkms
Version: 1.8.4~pre1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

The openafs-dkms kernel module fails to build on kernel 5.3.0-2 on buster.

In file included from
/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-2-amd64-SP/rx_kmutex.c:24:
/var/lib/dkms/openafs/1.8.4pre1/build/src/afs/LINUX/osi_compat.h: In function
‘afs_linux_search_keyring’:
/var/lib/dkms/openafs/1.8.4pre1/build/src/afs/LINUX/osi_compat.h:225:12: error:
too few arguments to function ‘keyring_search’
  225 |  key_ref = keyring_search(
  |^~
In file included from /usr/src/linux-
headers-5.3.0-2-common/include/linux/cred.h:13,
 from /usr/src/linux-
headers-5.3.0-2-common/include/linux/seq_file.h:12,
 from /usr/src/linux-
headers-5.3.0-2-common/include/linux/seq_file_net.h:5,
 from /usr/src/linux-
headers-5.3.0-2-common/include/net/net_namespace.h:177,
 from /usr/src/linux-
headers-5.3.0-2-common/include/linux/netdevice.h:38,
 from /usr/src/linux-
headers-5.3.0-2-common/include/net/inet_sock.h:19,
 from /usr/src/linux-
headers-5.3.0-2-common/include/linux/udp.h:16,
 from
/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-2-amd64-SP/./netinet/udp.h:1,
 from
/var/lib/dkms/openafs/1.8.4pre1/build/src/rx/rx_kcommon.h:110,
 from
/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-2-amd64-SP/rx_kmutex.c:20:
/usr/src/linux-headers-5.3.0-2-common/include/linux/key.h:387:18: note:
declared here
  387 | extern key_ref_t keyring_search(key_ref_t keyring,
  |  ^~
make[5]: *** [/usr/src/linux-headers-5.3.0-2-common/scripts/Makefile.build:286:
/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-2-amd64-SP/rx_kmutex.o]
Fehler 1
make[4]: *** [/usr/src/linux-headers-5.3.0-2-common/Makefile:1639:
_module_/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-2-amd64-SP]
Fehler 2
make[3]: *** [/usr/src/linux-headers-5.3.0-2-common/Makefile:179: sub-make]
Fehler 2
make[3]: Verzeichnis „/usr/src/linux-headers-5.3.0-2-amd64“ wird verlassen
FAILURE: make exit code 2
make[2]: *** [Makefile.afs:280: openafs.ko] Fehler 1
make[2]: Verzeichnis
„/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs/MODLOAD-5.3.0-2-amd64-SP“
wird verlassen
make[1]: *** [Makefile:187: linux_compdirs] Fehler 2
make[1]: Verzeichnis „/var/lib/dkms/openafs/1.8.4pre1/build/src/libafs“ wird
verlassen
make: *** [Makefile:15: all] Fehler 2



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

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

Versions of packages openafs-modules-dkms depends on:
ii  dkms   2.8.1-3
ii  libc6-dev  2.29-3
ii  perl   5.30.0-9

Versions of packages openafs-modules-dkms recommends:
ii  openafs-client  1.8.4~pre1-1

openafs-modules-dkms suggests no packages.

-- no debconf information

Bug#945750: ITP: golang-github-hashicorp-go-bexpr -- generic boolean expression evaluation in Golang

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 src:consul

   Package name: golang-github-hashicorp-go-bexpr
Version: 0.1.2
Upstream Author: HashiCorp
License: MPL-2.0
URL: https://github.com/hashicorp/go-bexpr
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-hashicorp-go-bexpr
Description: generic boolean expression evaluation in Golang
 Bexpr is a Golang library to provide generic boolean expression evaluation
 and filtering for Go data structures.


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

Bug#944648: sagemath FTBFS on i386

[peter green]

All three failures give the error message

OverflowError: Python int too large to convert to C long

from

File "sage/rings/polynomial/polynomial_integer_dense_flint.pyx", line 284, in 
sage.rings.polynomial.polynomial_integer_dense_flint.Polynomial_integer_dense_flint.__init__
 (build/cythonized/sage/rings/polynomial/polynomial_integer_dense_flint.cpp:6548)
 fmpz_poly_set_coeff_si(self.__poly, i, a)

Help on finding a fix would be appreciated.

On line 282 of that file (assuming the version at 
https://github.com/sagemath/sage/blob/master/src/sage/rings/polynomial/polynomial_integer_dense_flint.pyx
 is the same as the one in the Debian package).

"if type(a) is int:"

If that conditional is true then the code takes a fast path, which assumes that the value 
of "a" fits in a C long.

In python 2 "int" was a type limited to the size of a c long, so the check was 
appropriate. However in python 3 "int" is an arbitrary precision type, so we need to 
check if it will fit in the range of a C long.

There are several other conditionals on types being "int" in the file that presumably 
need fixing in the same way. I also spotted a "isinstance(x0, long):" which i'm pretty 
sure will fail in python 3 as there is no type long in python 3.

I have attached a completely untested patch.

Description: fix python integer type checks in polynomial_integer_dense_flint.pyx
 python 3 changes the standard integer types, in python2 a python "int" was
 equivilent to a C "long" and a python "long" was an arbitary precision type.
 
 In python 3 a python "int" is now an arbitary precision type and a python
 "long" does not exist any more.
 
 This patch adds additional checks that a python int will fit in the range of
 a C long before passing it to routines that require it to fit in one. It also
 locally defines long=int on python 3 so that isinstance(x0,long) will correctly
 test for an arbitary precision python integer.
Author: Peter Michael Green 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 2019-11-28

--- sagemath-8.9.orig/sage/src/sage/rings/polynomial/polynomial_integer_dense_flint.pyx
+++ sagemath-8.9/sage/src/sage/rings/polynomial/polynomial_integer_dense_flint.pyx
@@ -36,12 +36,21 @@ from __future__ import absolute_import,
 from cysignals.memory cimport sig_free
 from cysignals.signals cimport sig_on, sig_off
 
+from libc.limits cimport LONG_MIN
+from libc.limits cimport LONG_MAX
+
 include "sage/libs/ntl/decl.pxi"
 
 from cpython.int cimport PyInt_AS_LONG
 from sage.libs.gmp.mpz cimport *
 from sage.arith.long cimport pyobject_to_long
 
+import sys
+#we use this later in an isinstance test to detect a python arbitary precision
+#integer
+if sys.version_info.major > 3:
+long = int
+
 from sage.rings.polynomial.polynomial_element cimport Polynomial
 from sage.structure.element cimport ModuleElement, Element
 from sage.structure.element import coerce_binop
@@ -241,7 +250,7 @@ cdef class Polynomial_integer_dense_flin
 # now fill them in
 for ii, a in x:
 i = ii[0] if type(ii) is tuple else ii
-if type(a) is int:
+if (type(a) is int) and (LONG_MIN <= a <= LONG_MAX):
 sig_on()
 fmpz_poly_set_coeff_si(self.__poly, i, a)
 sig_off()
@@ -279,7 +288,7 @@ cdef class Polynomial_integer_dense_flin
 sig_off()
 for i from 0 <= i < len(x):
 a = x[i]
-if type(a) is int:
+if (type(a) is int) && (LONG_MIN <= a <= LONG_MAX):
 sig_on()
 fmpz_poly_set_coeff_si(self.__poly, i, a)
 sig_off()
@@ -398,7 +407,7 @@ cdef class Polynomial_integer_dense_flin
 ( x0).__poly)
 sig_off()
 return f
-if isinstance(x0, int):
+if isinstance(x0, int) and (LONG_MIN <= x0 <= LONG_MAX):
 z = Integer.__new__(Integer)
 sig_on()
 fmpz_init(a_fmpz)
@@ -1287,7 +1296,7 @@ cdef class Polynomial_integer_dense_flin
 """
 if n < 0:
 raise IndexError("n must be >= 0")
-if isinstance(value, int):
+if isinstance(value, int) and (LONG_MIN <= value <= LONG_MAX):
 sig_on()
 fmpz_poly_set_coeff_si(self.__poly, n, value)
 sig_off()

Bug#945729: zomg: Python2 removal in sid/bullseye

[Clint Adams]

block 945729 by 937094
affects 937094 + src:zomg
kthxbye

On Wed, Nov 27, 2019 at 11:58:54PM +, Sandro Tosi wrote:
> Source: zomg

zomg has a weak dependency on /usr/bin/mutagen-inspect, which
is expressed as a Recommends on python-mutagen.  If
mutagen-inspect is moved to python3-mutagen or another package,
the Recommends can be adjusted accordingly.

Bug#945749: RFS: pyenv/1.2.15-1 -- Python version manager

[Russell Pagden]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: pyenv
   Version : 1.2.15-1
   Upstream Author : Christopher Hunt
chrah...@gmail.com
* URL :
https://github.com/pyenv/pyenv
* License : MIT
 * Vcs : Git
   Section : misc

It builds those binary packages:

  pyenv - Python version manager

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/pyenv
Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/p/pyenv/pyenv_1.2.15-1.dsc
Changes since the last upload:

   * Initial release. Closes: [no ITP as yet]

Regards,

--
  Russell Pagden

Bug#945622: mkpasswd.1: Some typographic corrections to the man page

[Bjarni Ingi Gislason]

Package: whois
Version: 5.5.3
Severity: minor
Tags: patch

  _Not all affected lines are changed in the patch!_

  Short description of changes:

Fix warnings from test-groff.

Change -- in x--y to \(em (em-dash), or, if an
option, to "\-\-".

Change a two-fonts macro to an one-font macro for a
single argument.

Use a macro to change to the italic font.

Change a HYPHEN-MINUS (code 0x55, 2D) to a dash
(minus) if it matches " -[:alpha:]" or \(aq-[:alpha:] (for options).

Begin a sentence on a new line.

Use \(en for a dash where appropriate.

Add a missing right italic correction or use a macro.


Split a punctuation from a single argument for a two-fonts marco


Set the name of a man page in bold but the section in roman.



Long description with the associated lines:

Input file is mkpasswd.1

chk_man: Next line: execute mandoc -T lint mkpasswd.1
mandoc: mkpasswd.1:1:16: WARNING: cannot parse date, using it verbatim: 21 
March 2008
mandoc: mkpasswd.1:8:2: WARNING: skipping paragraph macro: PP empty

###

chk_man: Next line: execute doclifter -w -v mkpasswd.1
mkpasswd.1 uses man macros...
"mkpasswd.1", line 51: warning - variable-list header just before section break
"mkpasswd.1": warning - portability warning: nonportable requests 'end' seen.


###

Test nr. 2:

Enable and fix warnings from 'test-groff'.

Input file is ./mkpasswd.1

:6 (macro BR): only 1 argument, but more are expected
:7 (macro BR): only 1 argument, but more are expected
:12 (macro BR): only 1 argument, but more are expected
:52 (macro IR): only 1 argument, but more are expected
:53 (macro IR): only 1 argument, but more are expected
:54 (macro IR): only 1 argument, but more are expected
:55 (macro IR): only 1 argument, but more are expected
:56 (macro IR): only 1 argument, but more are expected
:57 (macro IR): only 1 argument, but more are expected

Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z

  [ "test-groff" is a developmental version of "groff" ]



Test nr. 13:

Change -- in x--y to \(em (em-dash), or, if an
option, to \-\-

16:.B -S, --salt=STRING
19:.B -R, --rounds=NUMBER
23:The behavior is undefined if this option is used without \fI--method\fP.
25:.B -m, --method=TYPE
32:Like \fI--method=md5\fP.
34:.B -P, --password-fd=NUM
40:.B -s, --stdin
41:Like \fI--password-fd=0\fP.
47:If the \fI--stdin\fP option is used, passwords containing some control

#

Test nr. 16:

Use the correct macro for the font change of a single argument.

6:.BR PASSWORD
7:.BR SALT

#

Test nr. 21:

Use a macro to change to the italic font, instead of \fI [1], if
possible.
The macros have the italic corrections, but "\c" removes the "\/" part.

  Or

add the italic corrections.
[1] man-pages(7) [package "manpages"]

17:Use the \fISTRING\fP as salt. It must not contain prefixes such as \fI$1$\fP.
20:Use \fINUMBER\fP rounds. This argument is ignored if the method chosen
23:The behavior is undefined if this option is used without \fI--method\fP.
26:Compute the password using the \fITYPE\fP method.
27:If \fITYPE\fP is \fIhelp\fP then the available methods are printed.
28:If \fITYPE\fP begins and end with \fI$\fP characters then the string
29:is passed to \fIcrypt_gensalt(3)\fP as-is.
32:Like \fI--method=md5\fP.
35:Read the password from file descriptor \fINUM\fP instead of using
36:\fIgetpass(3)\fP.
41:Like \fI--password-fd=0\fP.
47:If the \fI--stdin\fP option is used, passwords containing some control
60:and this man page were written by Marco d'Itri <\f...@linux.it\fP>

#

Test nr. 25:

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

16:.B -S, --salt=STRING
19:.B -R, --rounds=NUMBER
25:.B -m, --method=TYPE
34:.B -P, --password-fd=NUM
40:.B -s, --stdin

#

Test nr. 41:

Wrong distance between sentences or protect the indicator.

a) Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) [package "manpages"] and "info groff".

Or

b) Adjust space between sentences (two spaces),

c) or protect the indicator by adding "\&" after it.

The "indicator" is an "end-of-sentence character" (.!?).

  The amount of space in the output can then be controlled with the
".ss" request.

17:Use the \fISTRING\fP as salt. It must not contain prefixes such as \fI$1$\fP.
20:Use \fINUMBER\fP rounds. This argument is ignored if the method chosen
21:does not support variable rounds. For the OpenBSD Blowfish method this is

#

Test nr. 46:

Add a missing right italic correction after \fI (and before "\f[BPR]"), or use 
a macro

60:and this man page were written by Marco d'Itri <\f...@linux.it\fP>

#

Test nr. 52:

Split a punctuation mark from a single argument for a two-fonts marco

52:.IR passwd(1),
53:.IR passwd(5),
54:.IR crypt(3),
55:.IR crypt(5),
56:.IR crypt_gensalt(3),

#

Test nr. 53:

The name of a man page is set in bold and the section in roman (see
man-pages(7).

3:mkpasswd \- Overfeatured front end to crypt(3)
12:.BR crypt(3)

Bug#945561: dbus: fails for user context

[westlake]

somehow it got fixed with-> "dbus-launch systemctl --user"

for some reason that did something and I now just use "systemctl --user"
(even after a reboot)

I'm able to see user-specific unit files I created in
~/.config/systemd/user , so I know I am really looking at the user
context entries..

I wonder if a setting got marked when I used dbus-launch..

thanks

Bug#945620: petsc4py: rename python-petsc4py-docs to python-petsc4py-doc

[Sandro Tosi]

Source: petsc4py
Severity: important

Python doc package should have a -doc suffix, not -docs, please rename

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#945621: slepc4py: rename python-slepc4py-docs to python-slepc4py-doc

[Sandro Tosi]

Source: slepc4py
Severity: important

Python doc packages should have -doc suffix, not -docs. please rename

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#945618: regression: 5.3 and above kernels in Debian are not allowing Intel processor to enter package c states

[thomasw]

package: src:linux
1. run powertop --auto-tune to ensure settings are optimal for power saving. 
This may require a laptop.
2. Run powertop, press tab, and notice that the values in pc2 through pc10 are 
not incrementing.
Reproduced on Broadwell and Whiskey Lake. The first version of 5.3 posted to 
experimental was fine but this regressed after that and it is still a problem 
in 5.4 in experimental. Also, things work fine in Arch kernel so its probably 
something with the Debian config. On a side note, if you want to test in 
Skylake or newer, you need the non-free firmware package for the Intel DMC 
firmware which allows the graphics controller to enter a low power state. I 
used to see pc8 on one of my machines and pc7 on the other   as the lowest 
power states incrementing in Debian. These still increment in Arch with the 
latest Kernels. This bug results in a 5 degree c higher idle temperature on the 
Whiskey Lake machine.

Bug#945596: systemd module does not include the new systemd-volatile-root of systemd 242+

[Enrico Zini]

On Wed, Nov 27, 2019 at 05:43:25PM +0100, Thomas Lange wrote:

> > I'm trying to setup a system booting on a readonly root with a tmpfs
> > overlay on top.
> > Could we have this in Debian?
> The current dracut version in Debian already has such a feature
> without using systemd.
> 
> If you add the parameter rootovl to the kernel cmdline, the initrd
> created by dracut will make a read only rootfs writable by putting a
> tmpfs on top. This also works when using an nfsroot.
> 
> We use this in FAI for several years without problems on CD images
> and with an nfsroot. This also works with NFS v4.

Thanks, I think I'll have to try dracut for the time being, and thanks
for pointing me out to that feature.

I would however like at some point to have in Debian a dracut with the
bits that upstream added, to support the bits that systemd added.

As a general principle and in the long term, I would like to be able to
take advantage of systemd for this, that I hope has a chance to
establish some cross-distribution system-wide standard of managing this
rather common (in my work) system setup, and would integrate cleanly
with the rest of the system boot.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 

Bug#921495: Bioperl 1.7.4 should not migrate to Buster

[Andreas Beckmann]

Followup-For: Bug #921495
Control: found -1 1.7.6-1

libbio-perl-perl is missing proper
  Breaks+Replaces: libbio-perl-run-perl (<< 1.7.3)

There is a typoed (lib?io-perl-run-perl) and wrongly versioned
  Breaks: libio-perl-run-perl (<= 1.7.3-1), roary (<= 3.12.0+dfsg-2)
without corresponding Replaces. (Without the typo it would break the
'fixed' version in sid, too.)
And (<< 1.7.3-1) would be wrong, too, since it hits a potential
1.7.3-1~bpo10+1

Also the broken version of roary is likely wrong: you most likely want
  roary (<< 3.13)
(just think of a buster-pu upload of roary 3.12.0+dfsg-2+deb10u1).


Andreas

Bug#945617: RM: bluewho -- RoQA; Depends on pygtk2, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove bluewho. It depends on pygtk2. While ported upstream
there hasn't been any reaction to the bugs and the last upload by
the person listed in the Maintainers: field is from 2010.

Cheers,
Moritz

Bug#885254: bluewho: Depends on deprecated pygtk

[Moritz Mühlenhoff]

On Fri, Dec 29, 2017 at 10:48:57AM +0200, Juhani Numminen wrote:
> Control: tags -1 fixed-upstream
> 
> On Mon, 25 Dec 2017 23:39:04 -0500 Jeremy Bicha  wrote:
> 
> > pygtk is unmaintained upstream. It has not had a release since
> > GNOME 3 was released in 2011.
> > 
> > The way forward is to port your app to use GObject Introspection
> > bindings.
> > 
> > For more information on GObject Introspection see [1] and [2].
> > 
> > Please try to do this before the Buster release as we're going to
> > try to remove pygtk this cycle.
> 
> The latest upstream version bluewho 0.2.2 (from 2014) uses GObject
> Introspection and GTK+ 3 already.

There wasn't any reaction in two years, so I've filed a removal bug
now.

Cheers,
Moritz

Bug#945616: ITP: ruby-jekyll-mentions -- Jekyll plugin to add mentionable link support

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-jekyll-mentions
  Version : 1.5.1
  Upstream Author : GitHub Inc.
* URL : https://github.com/jekyll/jekyll-mentions
* License : MIT
  Programming Lang: Ruby
  Description : Jekyll plugin to add mentionable link support

This is a Jekyll plugin to turn mentions into links. It does not notify the
mentioned user. It is possible to use a social networks, even your own.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl3e9LYACgkQS80FZ8KW
0F3Xlw//RBObGhh00qtYWcvQjmX68h1Fmc8D8AE1YTityWRSWMx0MP83ethOBPhe
e0qqnnkEV7e7EnsSuEYjiGfvg9QDzuJiboadva7x5UhwYIz5QcDBqXgs8skM0MYR
UG3pdvg1myhsUG1laSRNsVHRKqEH/mGgr1PCAslgvSJ8bIcK6m98e3JCesqR1ZKN
bMH+sZkuA1fENLeyz++bz3F76y32/3Eh+BLA7NLXCyINtMnIb2JAV/45l5GvLIHi
9kWADXPPz4U81yAl1cGUJwJ5EGvkcoIn84Qq8K/hE32YV4wKOorTukCRXccuu5ya
DtxtUdBlhmaBBaHN0gtxCTgLtOCCPgA9b+PW1D0AmXKVLhcWwZgcM8MCivymAvBV
myvEMikKqxQGQrOvXrHBljmQRo9FLrRZ0r/J+Y7FylHPfo/T8Y/W98hh9UZM3p3O
/Y5HD09N/AQjaE5OPyBGioL1g1q/zj5FxbnhZ7xH9XPwiZgjqqywbNacs/BgVLQa
bDz53zLDDnq4q40BvQLmTAzMQJhFfCgpXaHROCxtr+scHj0BK0eKbIiur1HR49JK
OK1P4vulU69lDo4ejCLzf61sNX4XnrSycmAIEVul6CzOaILamded0C4aVB4oCCg4
uHHfVCDJpl+/TqjCLgBVfiALRj8CRMZ8C51QJV77hidJhkamuho=
=WOtD
-END PGP SIGNATURE-

Bug#945615: RM: agtl -- RoQA; Depends on pygtk2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove agtl. It depends on pygtk2, is dead upstream and unmaintained
(last maintainer upload in 2011)

Cheers,
Moritz

Bug#885270: bumping severity of pygtk bugs

[Moritz Mühlenhoff]

On Tue, Nov 26, 2019 at 05:27:08PM -0600, Steve Conklin wrote:
> I have no intention to port it. Filing a removal bug sounds appropriate.
> 
> Thanks,
> 
> Steve Conklin

Ack, I've just filed an RM bug.

Cheers,
Moritz

Bug#945614: RM: d-rats -- RoQA; depends on pygtk2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove d-rats. It depends on pygtk2, which is going away
and is dead upstream. The maintainers acked the removal in #885270

Cheers,
Moritz

Bug#945613: siconos: autopkgtest failure: /build/siconos-4.2.0+git20181026.0ee5349+dfsg.2/obj-x86_64-linux-gnu/cc: Command not found

[Paul Gevers]

Source: siconos
Version: 4.2.0+git20181026.0ee5349+dfsg.2-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

Your package has an autopkgtest (great). However, it fails. I copied
some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? If needed, please
change the bug's severity.

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=siconos

https://ci.debian.net/data/autopkgtest/unstable/amd64/s/siconos/3507570/log.gz

autopkgtest [00:41:47]: test numerics-tests: [---
test_FrictionContact
CMake Warning (dev) in CMakeLists.txt:
  No project() command is present.  The top-level CMakeLists.txt file must
  contain a literal, direct call to the project() command.  Add a line of
  code such as

project(ProjectName)

  near the top of the file, but after cmake_minimum_required().

  CMake is pretending there is a "project(Project)" command on the first
  line.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- The C compiler identification is GNU 9.2.1
-- The CXX compiler identification is GNU 9.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to:
/tmp/autopkgtest-lxc.gigv2ku3/downtmp/autopkgtest_tmp/.siconos
Scanning dependencies of target fc3d_DefaultSolverOptions_test
[ 50%] Building C object
CMakeFiles/fc3d_DefaultSolverOptions_test.dir/tmp/autopkgtest-lxc.gigv2ku3/downtmp/build.SzE/src/numerics/src/FrictionContact/test/fc3d_DefaultSolverOptions_test.c.o
make[2]:
/build/siconos-4.2.0+git20181026.0ee5349+dfsg.2/obj-x86_64-linux-gnu/cc:
Command not found
make[2]: ***
[CMakeFiles/fc3d_DefaultSolverOptions_test.dir/build.make:63:
CMakeFiles/fc3d_DefaultSolverOptions_test.dir/tmp/autopkgtest-lxc.gigv2ku3/downtmp/build.SzE/src/numerics/src/FrictionContact/test/fc3d_DefaultSolverOptions_test.c.o]
Error 127
make[1]: *** [CMakeFiles/Makefile2:76:
CMakeFiles/fc3d_DefaultSolverOptions_test.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
/usr/bin/siconos:
/tmp/autopkgtest-lxc.gigv2ku3/downtmp/autopkgtest_tmp/fc3d_DefaultSolverOptions_test
build failed, Command '['cmake', '--build', '.', '--target', 'install',
'--']' returned non-zero exit status 2.
|=|
|  Siconos-Kernel version 4.2.0Copyright 2018 INRIA   |
|
 |
|Free software under Apache License.
 |
|=|
ASSERT:Unknown failure encountered running a test

Ran 5 tests.

FAILED (failures=1)
autopkgtest [00:41:48]: test numerics-tests: ---]



signature.asc
Description: OpenPGP digital signature

Bug#945612: vdjtools: autopkgtest failure: cannot stat '/usr/share/doc/#PACKAGENAME#/examples/*'

[Paul Gevers]

Source: vdjtools
Version: 1.2.1+git20190311-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

Your new package has an autopkgtest (great). However, it fails.

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? If needed, please
change the bug's severity.

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=vdjtools

https://ci.debian.net/data/autopkgtest/testing/amd64/v/vdjtools/3389890/log.gz

autopkgtest [16:24:07]: test run-unit-test: [---
cp: cannot stat '/usr/share/doc/#PACKAGENAME#/examples/*': No such file
or directory
autopkgtest [16:24:08]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#945610: FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/python3/dist-packages/launchpadlib/version.txt'

[dann frazier]

Package: python3-launchpadlib
Version: 1.10.8-1
Severity: grave

After upgrade, my scripts that use launchpadlib now fail at import (see
below). AFAIK, this makes this version unusable by most or all users,
but obviously feel free to lower the severity if that is incorrect.

dannf@xps13:~$ python3
\Python 3.7.5 (default, Oct 27 2019, 15:43:29) 
[GCC 9.2.1 20191022] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from launchpadlib.launchpad import Launchpad
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/launchpadlib/__init__.py", line 19, in 

"launchpadlib", "version.txt").strip()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1157, 
in resource_string
self, resource_name
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1401, 
in get_resource_string
return self._get(self._fn(self.module_path, resource_name))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1616, 
in _get
with open(path, 'rb') as stream:
FileNotFoundError: [Errno 2] No such file or directory: 
'/usr/lib/python3/dist-packages/launchpadlib/version.txt'
>>>

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

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

Versions of packages python3-launchpadlib depends on:
ii  python3 3.7.5-3
ii  python3-httplib20.11.3-2
ii  python3-keyring 18.0.1-1
ii  python3-lazr.restfulclient  0.14.2-2
ii  python3-lazr.uri1.0.3-4
ii  python3-simplejson  3.16.0-2+b1
ii  python3-wadllib 1.3.3-3

python3-launchpadlib recommends no packages.

Versions of packages python3-launchpadlib suggests:
ii  python3-pkg-resources  41.4.0-1
pn  python3-testresources  

-- no debconf information

Bug#945611: zorp: autopkgtest failure: /usr/lib/zorp/zorp: No such file or directory

[Paul Gevers]

Source: zorp
Version: 7.0.1~alpha2-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

Your package has an autopkgtest (great), however it fails.

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? Please, also upload
source only, as we're not allowing binaries not build on the buildd to
migrate to testing.

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=zorp

https://ci.debian.net/data/autopkgtest/testing/amd64/z/zorp/3021805/log.gz

autopkgtest [21:53:38]: test basic: [---
Starting Zorp
A zorp process cannot started
/tmp/autopkgtest-lxc.0sz50046/downtmp/build.6kS/src/debian/tests/basic:
line 22: /usr/lib/zorp/zorp: No such file or directory
Interfaces
eth0: flags=4163  mtu 1500
inet 192.168.122.186  netmask 255.255.255.0  broadcast
192.168.122.255
inet6 fe80::216:3eff:fe72:ac58  prefixlen 64  scopeid 0x20
ether 00:16:3e:72:ac:58  txqueuelen 1000  (Ethernet)
RX packets 7693  bytes 75116184 (71.6 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 5749  bytes 403455 (393.9 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1000  (Local Loopback)
RX packets 14  bytes 740 (740.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 14  bytes 740 (740.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

autopkgtest [21:53:49]: test basic: ---]



signature.asc
Description: OpenPGP digital signature

Bug#945609: black: autopkgtest regression: No module named '_black_version'

[Paul Gevers]

Source: black
Version: 19.10b0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of black the autopkgtest of black fails in testing
when that autopkgtest is run with the binary packages of black from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
black  from testing19.10b0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? If needed, please
change the bug's severity.

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=black

https://ci.debian.net/data/autopkgtest/testing/amd64/b/black/3519203/log.gz

autopkgtest [07:09:42]: test testsuite: [---
Traceback (most recent call last):
  File "setup.py", line 3, in 
from _black_version import version as __version__
ModuleNotFoundError: No module named '_black_version'
autopkgtest [07:09:43]: test testsuite: ---]





signature.asc
Description: OpenPGP digital signature

Bug#945608: qutip: autopkgtest failure: 56 failed

[Paul Gevers]

Source: qutip
Version: 4.4.1-3
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

Your new source package qutip fails its autopkgtest. There's 56 failures
reported. I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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=qutip

https://ci.debian.net/data/autopkgtest/testing/amd64/q/qutip/3466738/log.gz

=== FAILURES
===
___ test_td_brmesolve_basic


self = 
obj =
'/home/debci/.pyxbld/temp.linux-x86_64-3.7/home/debci/.pyxbld/temp.linux-x86_64-3.7/pyrex/rhs15070.o'
src = '/home/debci/.pyxbld/temp.linux-x86_64-3.7/pyrex/rhs15070.cpp'
ext = '.cpp'
cc_args = ['-I/usr/lib/python3/dist-packages/numpy/core/include',
'-I/usr/include/python3.7m', '-c']
extra_postargs = ['-w', '-O1']
pp_opts = ['-I/usr/lib/python3/dist-packages/numpy/core/include',
'-I/usr/include/python3.7m']

def _compile(self, obj, src, ext, cc_args, extra_postargs, pp_opts):
compiler_so = self.compiler_so
if sys.platform == 'darwin':
compiler_so = _osx_support.compiler_fixup(compiler_so,
cc_args +
extra_postargs)
try:
self.spawn(compiler_so + cc_args + [src, '-o', obj] +
>  extra_postargs)

/usr/lib/python3.7/distutils/unixccompiler.py:118:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 
cmd = ['x86_64-linux-gnu-gcc', '-pthread', '-Wno-unused-result',
'-Wsign-compare', '-DNDEBUG', '-g', ...]

def spawn(self, cmd):
>   spawn(cmd, dry_run=self.dry_run)

/usr/lib/python3.7/distutils/ccompiler.py:910:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

cmd = ['x86_64-linux-gnu-gcc', '-pthread', '-Wno-unused-result',
'-Wsign-compare', '-DNDEBUG', '-g', ...]
search_path = 1, verbose = 0, dry_run = 0

def spawn(cmd, search_path=1, verbose=0, dry_run=0):
"""Run another program, specified as a command list 'cmd', in a
new process.

'cmd' is just the argument list for the new process, ie.
cmd[0] is the program to run and cmd[1:] are the rest of its
arguments.
There is no way to run a program with a name different from that
of its
executable.

If 'search_path' is true (the default), the system's executable
search path will be used to find the program; otherwise, cmd[0]
must be the exact path to the executable.  If 'dry_run' is true,
the command will not actually be run.

Raise DistutilsExecError if running the program fails in any
way; just
return on success.
"""
# cmd is documented as a list, but just in case some code passes
a tuple
# in, protect our %-formatting code against horrible death
cmd = list(cmd)
if os.name == 'posix':
>   _spawn_posix(cmd, search_path, dry_run=dry_run)

/usr/lib/python3.7/distutils/spawn.py:36:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

cmd = 'x86_64-linux-gnu-gcc', search_path = 1, verbose = 0, dry_run = 0

def _spawn_posix(cmd, search_path=1, verbose=0, dry_run=0):
log.info(' '.join(cmd))
if dry_run:
return
executable = cmd[0]
exec_fn = search_path and os.execvp or os.execv
env = None
if sys.platform == 'darwin':
global _cfg_target, _cfg_target_split
if _cfg_target is None:
_cfg_target = sysconfig.get_config_var(
  'MACOSX_DEPLOYMENT_TARGET') or ''
if _cfg_target:
_cfg_target_split = [int(x) for x in
_cfg_target.split('.')]
if _cfg_target:
# ensure that the deployment target of build process is
not less
# than that used when the interpreter was built. This
ensures
# extension modules are built with correct compatibility
values
cur_target = os.environ.get('MACOSX_DEPLOYMENT_TARGET',
_cfg_target)
if _cfg_target_split > [int(x) for x in
cur_target.split('.')]:
my_msg = ('$MACOSX_DEPLOYMENT_TARGET mismatch: '
  'now "%s" but "%s" during configure'
% (cur_target, _cfg_target))
raise DistutilsPlatformError(my_msg)
env = dict(os.environ,
   MACOSX_DEPLOYMENT_TARGET=cur_target)
exec_fn = search_path and os.execvpe or os.execve
pid = 

Bug#945607: RFP: angle-grinder -- Slice and dice logs on the command line

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: angle-grinder
  Version : 0.12.0
  Upstream Author : Russel Cohen
* URL : https://github.com/rcoh/angle-grinder/
* License : MIT
  Programming Lang: Rust
  Description : Slice and dice logs on the command line

Angle-grinder allows you to parse, aggregate, sum, average, min/max,
percentile, and sort your data. You can see it, live-updating, in your
terminal. Angle grinder is designed for when, for whatever reason, you
don't have your data in
graphite/honeycomb/kibana/sumologic/splunk/etc. but still want to be
able to do sophisticated analytics.

Angle grinder can process well above 1M rows per second (simple
pipelines as high as 5M), so it's usable for fairly meaty
aggregation. The results will live update in your terminal as data is
processed. Angle grinder is a bare bones functional programming
language coupled with a pretty terminal UI.

Angle-grinder can parse logfmt, json and arbitrary messages, through
regular expressions.



In Debian, there are a few similar tools, apart from the traditional
"grep, sed, cut, awk, perl" pipelines... jq is an obvious candidate,
but it doesn't have angle-grinder's easier language and similarity
with splunk queries. angle-grinder is also similar to visidata, but
the latter is more aimed at spreadsheets than logs. Finally, I found
out about angle-grinder while reading the lnav documentation, also
present in Debian, which similarly parses log files but relies on
sqlite for querying.

I don't have time to package this and hope some rust(y) person would
have time to handle it. :)

Bug#945431: systemd: missing files

[westlake]

somehow it got fixed with-> "dbus-launch systemctl --user"

for some reason that did something and I now just use "systemctl --user" 
(even after a reboot)


I'm able to see user-specific unit files I created in 
~/.config/systemd/user , so I know I am really looking at the user 
context entries..


I wonder if a setting got marked when I used dbus-launch..

thanks

Bug#945431: systemd: missing files

[westlake]

somehow it got fixed with-> "dbus-launch systemctl --user"

for some reason that did something and I now just use "systemctl --user" 
(even after a reboot)


I'm able to see user-specific unit files I created in 
~/.config/systemd/user , so I know I am really looking at the user 
context entries..


I wonder if a setting got marked when I used dbus-launch..

thanks

Bug#872691: closed by Adam Bilbrough (Bug#872691: fixed in worklog 2.1-1)

[Helmut Grohne]

Control: reopen -1

On Sun, Nov 10, 2019 at 07:39:17PM +, Debian Bug Tracking System wrote:
>* Worklog makefile is rewritten (Closes: #872691)

Yes, the makefile was rewritten. However, that's not what the bug report
and patch asked for. It actually fails to cross build in the very same
way no.

Helmut

Bug#920118: [PATCH 2/2] sponge: preserve ownership if possible (Closes: #920118)

[Nicolas Schier]

Preserve or restore the ownership of the target output file, if
possible.  This converges the behaviour of sponge a little bit more to
the one of 'tee' and shell redirections.

Bug-Debian: https://bugs.debian.org/920118
Signed-off-by: Nicolas Schier 
---
 sponge.c   | 7 +++
 sponge.docbook | 7 +++
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/sponge.c b/sponge.c
index f852ad5..59e0a2f 100644
--- a/sponge.c
+++ b/sponge.c
@@ -379,6 +379,13 @@ int main (int argc, char **argv) {
}
copy_tmpfile(tmpfile, outfile, bufstart, bufsize);
}
+
+   /* Attempt to change ownership according to the old file, but
+* ignore errors, as most users will not have the rights to
+* change ownership. */
+   if (exists) {
+   chown(outname, statbuf.st_uid, statbuf.st_gid);
+   }
}
else {
if (tmpfile_used) {
diff --git a/sponge.docbook b/sponge.docbook
index 303d6e6..0b34561 100644
--- a/sponge.docbook
+++ b/sponge.docbook
@@ -66,10 +66,9 @@ USA
sponge preserves the
permissions of the output file
if it already exists.  But in contrast to e.g.
-   tee, sponge might
-   not preserve or restore the original file ownership, no
-   matter whether it has been called by a privileged (root)
-   user.
+   tee, sponge does 
only
+   preserve or restore the original file ownership, if the 
current
+   user has the necessary rights.


When possible, sponge creates or 
updates the
-- 
2.24.0

Bug#920118: [PATCH 0/2] moreutils: sponge: (not) attempt to preserve ownership

[Nicolas Schier]

Hi Joey,

in #920118 [1], users of sponge complained about sponge not preserving
file ownership of the output file.  They argued, that sponge should
behave (more) like 'tee' and shell redirections.  And they interpreted
the sentence

"sponge preserves the permissions of the output file if it
already exists."

from sponge(1) as 'sponge preserves permissions and ownership [...]'.

After thinking about it several times, I am still ambiguous; thus, I am
sending you two patches:

  0001: an attempt to clarify the wording such that is becomes (more)
clear that file ownership will not be preserved.

and

  0002: (might be squashed with 0001) a patch to sponge.c that
introduces the attempt to restore the original file ownership
opportunistically, neither handling nor even checking for
errors.

I am really curious about your comments, and whether you'd like to
handle the complaints somehow.

Looking forward for your reply.

Thanks and kind regards,
Nicolas


[1]: https://bugs.debian.org/920118


Nicolas Schier (2):
  sponge: mention that ownership might not be preserved (Closes:
#920118)
  sponge: preserve ownership if possible (Closes: #920118)

 sponge.c   | 7 +++
 sponge.docbook | 5 -
 2 files changed, 11 insertions(+), 1 deletion(-)

-- 
2.24.0

Bug#945606: testpath: autopkgtest regression

[Paul Gevers]

Source: testpath
Version: 0.4.2+dfsg-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of testpath the autopkgtest of testpath fails in
testing when that autopkgtest is run with the binary packages of
testpath from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
testpath   from testing0.4.2+dfsg-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. Unfortunately,
the test logs absolutely nothing. Apart from fixing the issue, it may be
smart to not output everything to /dev/null, so people can inspect the logs.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? If needed, please
change the bug's severity.

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=testpath

https://ci.debian.net/data/autopkgtest/testing/amd64/t/testpath/3517920/log.gz

autopkgtest [02:10:58]: test runtestsuite: [---
autopkgtest [02:10:59]: test runtestsuite: ---]
autopkgtest [02:10:59]: test runtestsuite:  - - - - - - - - - - results
- - - - - - - - - -
runtestsuite FAIL non-zero exit status 127



signature.asc
Description: OpenPGP digital signature

Bug#920118: [PATCH 1/2] sponge: mention that ownership might not be preserved (Closes: #920118)

[Nicolas Schier]

Users of sponge pointed out that the wording of sponge's man page caused
confusion, as "preserves the permissions" has been interpreted as
"preserves the permissions and ownership".  Thus, mention that file
ownership might not be preserved.

Bug-Debian: https://bugs.debian.org/920118
Signed-off-by: Nicolas Schier 
---
 sponge.docbook | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/sponge.docbook b/sponge.docbook
index 31bc6db..303d6e6 100644
--- a/sponge.docbook
+++ b/sponge.docbook
@@ -65,7 +65,11 @@ USA

sponge preserves the
permissions of the output file
-   if it already exists.
+   if it already exists.  But in contrast to e.g.
+   tee, sponge might
+   not preserve or restore the original file ownership, no
+   matter whether it has been called by a privileged (root)
+   user.


When possible, sponge creates or 
updates the
-- 
2.24.0

Bug#945605: python-neovim: autopkgtest needs update for new version of neovim: Invalid option name: 'listchars'

[Paul Gevers]

Source: python-neovim
Version: 0.3.0-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, neo...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:neovim

Dear maintainers,

With a recent upload of neovim the autopkgtest of python-neovim fails in
testing when that autopkgtest is run with the binary packages of neovim
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
neovim from testing0.4.3-2
python-neovim  from testing0.3.0-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of neovim to testing
[1]. Of course, neovim shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in neovim was
intended and your package needs to update to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from neovim should really add
a versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
neovim/0.4.3-2. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=neovim

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-neovim/3517661/log.gz

=== FAILURES
===
_ test_options
_

vim = 

def test_options(vim):
>   assert vim.options['listchars'] == 'tab:> ,trail:-,nbsp:+'

test/test_vim.py:84:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python3/dist-packages/neovim/api/common.py:88: in __getitem__
return self._get(key)
/usr/lib/python3/dist-packages/neovim/api/nvim.py:180: in request
res = self._session.request(name, *args, **kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 
method = 'nvim_get_option', args = ('listchars',), kwargs = {}, async_ =
False
v = [[1, b"Invalid option name: 'listchars'"], None]
err = [1, b"Invalid option name: 'listchars'"], rv = None

def request(self, method, *args, **kwargs):
"""Send a msgpack-rpc request and block until as response is
received.

If the event loop is running, this method must have been called by a
request or notification handler running on a greenlet. In that case,
send the quest and yield to the parent greenlet until a response is
available.

When the event loop is not running, it will perform a blocking
request
like this:
- Send the request
- Run the loop until the response is available
- Put requests/notifications received while waiting into a queue

If the `async_` flag is present and True, a asynchronous
notification
is sent instead. This will never block, and the return value or
error
is ignored.
"""
async_ = check_async(kwargs.pop('async_', None), kwargs, False)
if async_:
self._async_session.notify(method, args)
return

if kwargs:
raise ValueError("request got unsupported keyword
argument(s): {}"
 .format(', '.join(kwargs.keys(

if self._is_running:
v = self._yielding_request(method, args)
else:
v = self._blocking_request(method, args)
if not v:
# EOF
raise IOError('EOF')
err, rv = v
if err:
info("'Received error: %s", err)
>   raise self.error_wrapper(err)
E   neovim.api.nvim.NvimError: b"Invalid option name: 'listchars'"



signature.asc
Description: OpenPGP digital signature

Bug#945604: linux-source-5.4: Failed to build linux-source-5.4 in efi_set_secure_boot

[Jean-Luc Coulon (f5ibh)]

Package: linux-source-5.4
Version: 5.4-1~exp1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I failed to build 5.4 with the following message:
 DESCEND  objtool
  CALLscripts/atomic/check-atomics.sh
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  CHK kernel/kheaders_data.tar.xz
  GEN .version
  CHK include/generated/compile.h
  UPD include/generated/compile.h
  CC  init/version.o
  AR  init/built-in.a
  LD  vmlinux.o
  MODPOST vmlinux.o
  MODINFO modules.builtin.modinfo
  LD  .tmp_vmlinux1
ld: drivers/firmware/efi/secureboot.o: in function `efi_set_secure_boot':
/usr/src/linux/drivers/firmware/efi/secureboot.c:32: undefined reference to 
`lock_kernel_down'
make: *** [Makefile:1065: vmlinux] Error 1

I use make-kpkg to (try to) build the package.

The genuine package from kernel.org built fine.

Please find attached my .config

Regards

Jean-Luc


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

Kernel: Linux 5.4.0-i7-0.1 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-source-5.4 depends on:
ii  binutils  2.33.1-4
ii  xz-utils  5.2.4-1+b1

Versions of packages linux-source-5.4 recommends:
ii  bc1.07.1-2+b2
ii  bison 2:3.4.2+dfsg-1
ii  flex  2.6.4-6.2
ii  gcc   4:9.2.1-3.1
ii  libc6-dev [libc-dev]  2.29-3
ii  linux-config-5.4  5.4-1~exp1
ii  make  4.2.1-1.2

Versions of packages linux-source-5.4 suggests:
ii  libncurses-dev [ncurses-dev]  6.1+20191019-1
ii  libqt4-dev4:4.8.7+dfsg-19
ii  pkg-config0.29-6

- -- no debconf information

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQT5el3FKLtmYO4UlQtR0YZfPMac0AUCXd7X4gAKCRBR0YZfPMac
0JNkAJ9L+UY2XktGf8QiSofB/42inzQdDwCgqZwkjl+OQMh2z8H2adU5h7MErvc=
=1aDu
-END PGP SIGNATURE-
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 5.4.0 Kernel Configuration
#

#
# Compiler: gcc (Debian 9.2.1-20) 9.2.1 20191126
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=90201
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
# CONFIG_HEADER_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
# end of IRQ subsystem

CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
# end of Timers subsystem

# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set
# CONFIG_PSI is not set
# end of CPU/Task time and stats accounting

CONFIG_CPU_ISOLATION=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y

Bug#945603: impressive: Typo in the manpage

[Martin Quinson]

Package: impressive
Version: 0.12.0-2
Severity: minor

Dear maintainer,

the manpage reads:

   -t  or --transition 
  Using this switch, the set of transitions Impressive will 
randomly draw at page changes can be speci‐
  fied. If only one transition class is specified, this class will 
be used for all pages  that  do  not
  have another transition explicitly assigned in their page 
properties. Multiple transitions have to be
  separated by commas; they will be used in random order. The -l 
option can be used to get  a  list  of
  available transitions.

   -T  or --transtime 
  Sets  the  duration  (in milliseconds) of page transitions. 0 
(zero) disables transitions altogether.
  Default value: 1000 ms.

but actually, the -t parameter does expect a transition, not a time in ms. So I
guess that the first line should read as follows instead:

   -t  or --transition 


Thanks for packaging this great software,
Martin.

-- 
Programming in Bourne-Shell is a higher form of masochism.


signature.asc
Description: PGP signature

Bug#945602: wrong path for constants.xml/presets.xml prevent the program from starting

[nodiscc]

Package: qwinff
Version: 0.2.1-1
Severity: grave

Steps to reproduce the problem:
 - run qwinff from the desktop launcher of from a terminal emulator

What happens:
 - An error dialog is shown with the message "Cannot load
/home/user/constants.xml. The program will exit now."
 - In addition, when qwinff is launched from a terminal, there is the
error "Failed to read file: "/home/user/constants.xml"
 - Clicking the "Ok" button closes the error message, but the program
is in fact still running (appears in ps aux output/task managers).
When run from a terminal it does not give back STDIN unless I
stop/kill/Ctrl+C it

Workaround:
 - a quick search reveals a file /usr/share/qwinff/constants.xml.
Copying this file to /home/user/constants.xml makes the error message
disappear. A second message is shown about missing presets.xml, the
same workaround can be applied (it's also in /usr/share/qwinff/)

Suggested fix:
I don't know. The makefile
(https://github.com/qwinff/qwinff/blob/master/Makefile#L65)
explicitely says to install these files in $(DATA_PATH) so I assume
this path was incorrectly set when the package was built. Rebuild and
test this time :)

Severity grave because the program does not work at all by default
unless you find the workaround.

Thank you in advance

Bug#945601: rabbitmq-server: CVE-2019-11291

[Salvatore Bonaccorso]

Source: rabbitmq-server
Version: 3.7.18-1
Severity: important
Tags: security upstream
Control: found -1 3.7.8-4

Hi,

The following vulnerability was published for rabbitmq-server.

CVE-2019-11291[0]:
| Pivotal RabbitMQ, 3.7 versions prior to v3.7.20 and 3.8 version prior
| to v3.8.1, and RabbitMQ for PCF, 1.16.x versions prior to 1.16.7 and
| 1.17.x versions prior to 1.17.4, contain two endpoints, federation and
| shovel, which do not properly sanitize user input. A remote
| authenticated malicious user with administrative access could craft a
| cross site scripting attack via the vhost or node name fields that
| could grant access to virtual hosts and policy management information.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-11291
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11291
[1] https://pivotal.io/security/cve-2019-11291

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#945600: rabbitmq-server: CVE-2019-11287

[Salvatore Bonaccorso]

Source: rabbitmq-server
Version: 3.7.18-1
Severity: important
Tags: security upstream
Control: found -1 3.7.8-4

Hi,

The following vulnerability was published for rabbitmq-server.

CVE-2019-11287[0]:
| Pivotal RabbitMQ, versions 3.7.x prior to 3.7.21 and 3.8.x prior to
| 3.8.1, and RabbitMQ for Pivotal Platform, 1.16.x versions prior to
| 1.16.7 and 1.17.x versions prior to 1.17.4, contain a web management
| plugin that is vulnerable to a denial of service attack. The
| "X-Reason" HTTP Header can be leveraged to insert a malicious Erlang
| format string that will expand and consume the heap, resulting in the
| server crashing.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-11287
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11287
[1] https://pivotal.io/security/cve-2019-11287

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#945586: autodep8: autopkgtest-pkg-dkms testsuite should set restriction isolation-machine

[Hanno Stock]

Hi,

nice. Thank you!

I noticed that on a default setup kernel-headers are not installed and
so tests do still fail.

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

I assume - since it is hard to generically include this as a dependency
in the control file, it would be better if dkms autopkgtest installs the
dependency during the test if needed.

Best regards

Hanno

Bug#945586: autodep8: autopkgtest-pkg-dkms testsuite should set restriction isolation-machine

[Paul Gevers]

Control: tags -1 pending

Hi Hanno,

On 27-11-2019 14:21, Hanno Stock wrote:
> autodep8 generates restrictions
> 
> Restrictions: needs-root, allow-stderr
> 
> for dkms packages.
> 
> However testing dkms packages in a container environment fails,
> since usually the host kernel is not installed inside the container
> and dkms refuses to build the kernel module, since no suitable
> kernel versions are found.
> 
> I suggest adding "isolation-machine" to the set of restrictions
> for the automatic dkms tests.

I noticed the same and implemented it here:
https://salsa.debian.org/ci-team/autodep8/commit/474624067168334710ff4761b28005ff7d0b4011

> This problem also occurs on the Salsa CI, so it is not limited
> to my machine.

Part of the next release of autodep8.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#909740: libsdl2-dev: No longer multi-arch co-installable

[Simon McVittie]

In an attempt to unblock this bug I've implemented several versions of a
solution to it, so that the SDL2 maintainers can choose their favourite
and merge it.

On Sun, 30 Sep 2018 at 22:17:05 +0100, Simon McVittie wrote:
> Ugh, I'd missed that there's a third API for building dependent software
> (the CMake files). The autopkgtest that I added should ideally test this
> one too, but I think that'll probably need a proper CMake build system
> (at least one CMakeLists.txt), not just a one-liner?

New autopkgtest proposed in
. It passes
for the current state of libsdl2-dev, and for all my implementations.

On Sun, 30 Sep 2018 at 19:08:26 +0100, Simon McVittie wrote:
> https://salsa.debian.org/smcv/libsdl2/commits/multiarch-forwarding-header
> 
> I prefer this approach because it's relatively self-contained, and
> doesn't require us to carry non-upstreamable patches to upstream code
> or rely on a relatively obscure Debian-specific compiler option.

Now at .
I think this is still my preferred option, but the others are also viable.

On Sun, 30 Sep 2018 at 22:02:59 +0300, Adrian Bunk wrote:
> Wouldn't the least invasive option be a combination of
> 1. my --includedir=\$${prefix}/include/$(DEB_HOST_MULTIARCH) suggestion plus
> 2. the sdl2-config patching from Hugh

I've implemented this alternative at
.

I've also implemented a version of this suggestion,
but using $PKG_CONFIG instead of $CC in sdl2-config:
. I think
this is maybe a bit nicer than !4?

Other interested developers are of course welcome to propose something
better - I'm sure there are other possibilities that I've missed.

Do the SDL2 maintainers have any comments on these MRs, or preference
between them?

Thanks,
smcv

Bug#945181: ITA: libg15render -- Library for interfacing with the Logitech G15 keyboards

[Chris Knadle]

Greetings.

Thanks for your interest in maintaining the libg15render package and for
adopting the g15daemon package.  Although I don't use g15, I maintain mumble
which can optionally use it to support users that have the g15 keyboard.  Right
now I've had to disable g15 support in mumble because of the package removal
that had occurred, but I can re-enable that if it's considered safe to do so.

I'm CC:ing the current maintainer directly in order document them being notified
of the ITA.

This package IMHO is definitely available for salvage.  Just for reference, the
Debian Developer's Reference section 5.12.2 suggests normally giving the
maintainer 21 days to respond before a salvage upload:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-to-salvage-a-package

Packaging of libraries is a special category in Debian, and I've never been
involved in packaging a library so far, but am interested in how that works, and
given what this package is for this library package seems to be of relatively
low risk.  I'm having another read through the Debian Developer's Reference
section 6.7.2 concerning libraries:

http://sejnfjrq6szgca7v.onion/doc/manuals/developers-reference/best-pkging-practices.en.html#libraries

I see that Andrej Shadura is sponsoring uploads for your work with the g15daemon
package; have you checked with him to see if he's comfortable sponsoring uploads
for this package?  Mainly I'm asking because the packages are related.

Thanks
   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#945582: systemd: Upgrade fails due to missing library libsystemd-shared-241.so

[Michael Biebl]

Am 27.11.19 um 19:06 schrieb Graham Cobb:
> On 27/11/2019 16:42, Ansgar wrote:
>> On Wed, 2019-11-27 at 15:22 +, Graham Cobb wrote:
 I suspect there are some old binaries (from systemd-241) around for
 some reason.
>>>
>>> That does seem to be the case.
>>
>> Did you ever (a) install systemd yourself, or (b) tried to convert the
>> system to merged-/usr (for example with the "usrmerge" program from the
>> package of the same name), or (c) copied these files manually there
>> (maybe something else expected them in /usr)?
> 
> No. I am sure I didn't do any of those things.

Did you restore from a backup?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#942056: [ovs-dev] [PATCH] debian: Update list of copyright holders.

[Yi-Hung Wei]

On Wed, Oct 9, 2019 at 10:35 AM Ben Pfaff  wrote:
>
> The list of copyright holders was incomplete and out of date.  This
> updates it based on a "grep" for copyright notices, which I reviewed by
> hand.
>
> CC: 942...@bugs.debian.org
> Reported-by: Chris Lamb 
> Reported-at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942056
> Signed-off-by: Ben Pfaff 
> ---

LGTM.

Acked-by: Yi-Hung Wei 

Bug#945582: systemd: Upgrade fails due to missing library libsystemd-shared-241.so

[Graham Cobb]

On 27/11/2019 16:42, Ansgar wrote:
> On Wed, 2019-11-27 at 15:22 +, Graham Cobb wrote:
>>> I suspect there are some old binaries (from systemd-241) around for
>>> some reason.
>>
>> That does seem to be the case.
> 
> Did you ever (a) install systemd yourself, or (b) tried to convert the
> system to merged-/usr (for example with the "usrmerge" program from the
> package of the same name), or (c) copied these files manually there
> (maybe something else expected them in /usr)?

No. I am sure I didn't do any of those things.

> 
> That are the only three ways I currently can come up with how to end
> with the files there.

I have checked my online snapshot backups (these only go back 3 months)
and I can see that the /usr/bin/systemd-machine-id-setup and
/bin/systemd-machine-id-setup versions of the file are both present in
all the snapshots.

Also, in all but today's backup,
/usr/lib/systemd/libsystemd-shared-241.so and
/lib/systemd/libsystemd-shared-241.so are both present, but are different.

That would be consistent with assuming the /usr versions got created
some time before the upgrade to 241-7 and the non-/usr versions then got
upgraded to 241-7 (slightly different but still 241).

I will see if I can find anything other backups, but we may never know,
I guess.

> 
> What is the output from
> 
>   sha256sum /usr/bin/systemd-machine-id-setup

# sha256sum /usr/bin/systemd-machine-id-setup
681145a9d0aefd9289281118ee8dd72ce0cad560b768149dfc96d3e5d338da8e
/usr/bin/systemd-machine-id-setup

>   readelf -d /usr/bin/systemd-machine-id-setup | grep RUNPATH

# readelf -d /usr/bin/systemd-machine-id-setup | grep RUNPATH
 0x001d (RUNPATH)Library runpath: [/lib/systemd]

> We could check if that binary is identical to one provided by Debian;

I am guessing it would be the 241-5 version as the dates are consistent.

> the `readelf` command should list `/lib/systemd` as a directory where
> the binary looks for shared libraries (it not being `/usr/lib/systemd`
> is the reason it failed).
> 
>> I note that dpkg -S can find packages responsible for the /bin
>> executables but not the /usr/bin ones:
>>
>> # dpkg -S /bin/systemd-machine-id-setup
>> systemd: /bin/systemd-machine-id-setup
>> # dpkg -S /usr/bin/systemd-machine-id-setup
>> dpkg-query: no path found matching pattern /usr/bin/systemd-machine-id-setup
> 
> Note that on a merged-/usr system that would still be the case as dpkg
> doesn't care about the /bin -> /usr/bin symlink and just puts the file
> into /bin, following the symlink.  dpkg's database would still record
> the file under /bin.
> 
> Ansgar
> 

Bug#945599: datefudge: FTBFS on hurd-i386: Necessary functions disabled

[Paul Sonnenschein]

Package: datefudge
Severity: important
Version: 1.23
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Dear Maintainer,

datefudge fails to build from source on the Hurd.

The reason for the failure are the #ifndef-Blocks at the functions
time() and clock_gettime(), which are apparently no longer necessary.

The attached patch removes these #ifndef-Blocks.

Thanks.
diff --git a/datefudge.c b/datefudge.c
index fe93ef8..00cb012 100644
--- a/datefudge.c
+++ b/datefudge.c
@@ -50,8 +50,6 @@ static void set_fudge(time_t *seconds)
 *seconds -= fudge;
 }
 
-#ifndef __GNU__
-
 time_t time(time_t *x) {
 static time_t (*libc_time)(time_t *) = NULL;
 time_t res;
@@ -64,8 +62,6 @@ time_t time(time_t *x) {
 return res;
 }
 
-#endif
-
 int __gettimeofday(struct timeval *x, struct timezone *y) {
 static int (*libc_gettimeofday)(struct timeval *, struct timezone *) = NULL;
 int res;
@@ -82,8 +78,6 @@ int gettimeofday(struct timeval *x, struct timezone *y) {
 return __gettimeofday(x,y);
 }
 
-#ifndef __GNU__
-
 int clock_gettime(clockid_t x, struct timespec *y) {
 static int (*libc_clock_gettime)(clockid_t, struct timespec*);
 int res;
@@ -95,5 +89,3 @@ int clock_gettime(clockid_t x, struct timespec *y) {
 set_fudge(>tv_sec);
 return 0;
 }
-
-#endif


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

Bug#945598: openscenegraph: Plugin detection for movie files fails to select osgdb_ffmpeg.so

[Alberto Luaces]

Package: openscenegraph
Version: 3.6.4+dfsg1-2
Severity: normal
Tags: upstream

Movie files cannot be played with present3D or osgmovie since the plugin 
subsystem is unable to match popular extensions to the ffmpeg plugin:

strace -e trace=openat osgmovie file.avi

...
openat(AT_FDCWD, "osgPlugins-3.6.4/osgdb_avi.so", O_RDONLY|O_CLOEXEC) = -1 
ENOENT
...

Nevertheless, forcing the plugin selection by using the ffmpeg extension works:

osgmovie file.avi.ffmpeg


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

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

Versions of packages openscenegraph depends on:
ii  libc6 2.29-3
ii  libgcc1   1:9.2.1-19
ii  libgl11.1.0-1+b1
ii  libopenscenegraph160  3.6.4+dfsg1-2
ii  libopenthreads21  3.6.4+dfsg1-2
ii  libstdc++69.2.1-19

openscenegraph recommends no packages.

openscenegraph suggests no packages.

-- no debconf information

Bug#945410: defaultroute sets gateway to 0.0.0.0

[Joey Hess]

Chris Boot wrote:
> What is your PPP link running on? I don't expect it to be a modem, but
> is it PPPoE or PPTP or a VPN of some kind? That might also help to nail
> things down.

Actual modem (USB).

> This doesn't make much sense to me, but a before and after of your route
> table using 'ip route' would be really helpful and might shed some light
> on the situation.

root@honeybee:~>ip route
10.0.0.0/8 dev wlx9cefd5fcd6f3 proto kernel scope link src 10.1.1.1 
root@honeybee:~>pon
root@honeybee:~>ip route
default dev ppp0 scope link 
10.0.0.0/8 dev wlx9cefd5fcd6f3 proto kernel scope link src 10.1.1.1 
207.223.72.68 dev ppp0 proto kernel scope link src 72.251.70.21 

Hmm! I now notice that, even with the above routing table, I can
access the internet over that ppp link.

Apparently the 0.0.0.0 route *is* the default route. I don't remember it
looking like that some years ago when I used ppp regularly, but it does
seem to work.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#945214: Confirming the issue

[Daniele Scasciafratte]

I have the same problem with different packages on debian sid.
There is any workaround to fix it until a new release?

Bug#944294: buster-pu: package libvirt-daemon/5.0.0-4

[Guido Günther]

Hi,
On Wed, Nov 27, 2019 at 04:17:13PM +, Adam D. Barratt wrote:
> Control: tags -1 -confirmed +moreinfo
> 
> Hi,
> 
> On 2019-11-27 16:07, Guido Günther wrote:
> > Hi Adam,
> > On Wed, Nov 27, 2019 at 01:21:40PM +, Adam D. Barratt wrote:
> > > Control: tags -1 + confirmed
> > > 
> > > On 2019-11-27 13:05, Michal Arbet wrote:
> > > > I've added a patch from upstream ( sid already included it in new
> > > > version ).
> > > > Check current debdiff in attachment.
> > > 
> > > That looks OK, assuming it's been build- and runtime-tested on a
> > > buster
> > > system.
> > 
> > It would be nice to coordinate such things with the package
> > maintainers. I've had question's regarding these patches which weren't
> > answered yet:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944248#26
> 
> Apologies for that, we tend to assume that people making such requests
> either work on the package or have had that co-ordination discussion
> already.
> 
> In this case I'll put the request on hold until we hear back.

Thanks.I intend to look at the particular issue and fold it into the
update with

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

which is still pending.
 -- Guido

> 
> Regards,
> 
> Adam
> 

Bug#941074: ghostscript: ps2pdf SAFER and transparency interference

[Jonas Smedegaard]

Control: tags -1 wontfix

Quoting Markus Demleitner (2019-09-24 11:36:09)
> ps2pdf14 as delivered in buster will only produce PDF transparency 
> when run with -dNOSAFER.  This deviates from previous releases (I'm 
> quite sure about jessie), when transparency was produced without 
> further configuration.  Although I *might* see some relationship to 
> accepting pdfmarks, the connection between SAFER and transparent 
> colours frankly strikes me as just a little non-intuitive (but that 
> may be because I don't know what's going on when producing 
> transparency in PDFs).
> 
> Because of this, I'd suggest that if turning off PDF transparency 
> without -dNOSAFER is intentional, that should be documented in the 
> NEWS, even more so as I couldn't make out that fact in the upstream 
> Use.htm that the current 9.28~~rc1~dfsg-1 NEWS item refers to.  
> Perhaps that particular item could be amended with saying something 
> like "Note that that has some rather unexpected consequences (e.g., 
> PDF transparency is now lost without -dNOSAFER)."

At https://bugs.ghostscript.com/show_bug.cgi?id=701624#c1 upstream 
explains that the operators to apply transparency is non-standard when 
applied to Postscript code.

Upstream has since relaxed to permit these non-standard operators in 
SAFER mode, a change which is (not certain but) likely to appear in next 
upstream release: http://git.ghostscript.com/?p=ghostpdl.git;h=d1eac80

I prefer to not mess with this security-related code to try cherry-pick 
for older relases, and therefore flag this bug as wontfix.

Thanks for reporting,

 - Jonas

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

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


signature.asc
Description: signature

Bug#945582: systemd: Upgrade fails due to missing library libsystemd-shared-241.so

[Michael Biebl]

Am 27.11.19 um 17:42 schrieb Ansgar:
> On Wed, 2019-11-27 at 15:22 +, Graham Cobb wrote:
>>> I suspect there are some old binaries (from systemd-241) around for
>>> some reason.
>>
>> That does seem to be the case.
> 
> Did you ever (a) install systemd yourself, or (b) tried to convert the
> system to merged-/usr (for example with the "usrmerge" program from the
> package of the same name), or (c) copied these files manually there
> (maybe something else expected them in /usr)?
> 
> That are the only three ways I currently can come up with how to end
> with the files there.

If it was manually compiled, I would assume that RUNPATH points to
/usr/lib/systemd.
So only option b) or c) seem plausible.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#945596: systemd module does not include the new systemd-volatile-root of systemd 242+

[Thomas Lange]

> On Wed, 27 Nov 2019 17:27:28 +0100, Enrico Zini  said:

> I'm trying to setup a system booting on a readonly root with a tmpfs
> overlay on top.

> Could we have this in Debian?
The current dracut version in Debian already has such a feature
without using systemd.

If you add the parameter rootovl to the kernel cmdline, the initrd
created by dracut will make a read only rootfs writable by putting a
tmpfs on top. This also works when using an nfsroot.

We use this in FAI for several years without problems on CD images
and with an nfsroot. This also works with NFS v4.
-- 
regards Thomas

Bug#945582: systemd: Upgrade fails due to missing library libsystemd-shared-241.so

[Ansgar]

On Wed, 2019-11-27 at 15:22 +, Graham Cobb wrote:
> > I suspect there are some old binaries (from systemd-241) around for
> > some reason.
> 
> That does seem to be the case.

Did you ever (a) install systemd yourself, or (b) tried to convert the
system to merged-/usr (for example with the "usrmerge" program from the
package of the same name), or (c) copied these files manually there
(maybe something else expected them in /usr)?

That are the only three ways I currently can come up with how to end
with the files there.

What is the output from

  sha256sum /usr/bin/systemd-machine-id-setup
  readelf -d /usr/bin/systemd-machine-id-setup | grep RUNPATH

We could check if that binary is identical to one provided by Debian;
the `readelf` command should list `/lib/systemd` as a directory where
the binary looks for shared libraries (it not being `/usr/lib/systemd`
is the reason it failed).

> I note that dpkg -S can find packages responsible for the /bin
> executables but not the /usr/bin ones:
> 
> # dpkg -S /bin/systemd-machine-id-setup
> systemd: /bin/systemd-machine-id-setup
> # dpkg -S /usr/bin/systemd-machine-id-setup
> dpkg-query: no path found matching pattern /usr/bin/systemd-machine-id-setup

Note that on a merged-/usr system that would still be the case as dpkg
doesn't care about the /bin -> /usr/bin symlink and just puts the file
into /bin, following the symlink.  dpkg's database would still record
the file under /bin.

Ansgar

Bug#940586: ghostscript: Please add gpcl in addition to gs

[Jonas Smedegaard]

Quoting Patrik Schindler (2019-09-17 16:46:48)
> Please add gpcl as package to Debian, probably as backport available 
> for oder releases, too. Building gpcl with the debian-directory from 
> ghostscript yields file overlaps, because of files both programs use. 
> Diversions could be a solution.
> 
> Maybe it could be a better idea to split gs into ghostscript-common 
> and ghostscript-gs-bin and ghostscript-gpcl-bin to prevent unnecessary 
> disk space allocation through duplicate files.

Thanks, your proposed approach is in line with my own thinking here.

I am a bit puzzled, however, why you file a sparate bugreport instead of 
following up on bug#855219.  Would you agree that it makes sense to 
merge #855219 into this one?

Oh, and btw: Any progress on your OS/400 project?

Kind regards,

 - Jonas

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

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


signature.asc
Description: signature

Bug#945597: i3pystatus: Bad bug number in changelog

[Esteban Bosse]

Package: i3pystatus
Version: 3.35+git20190107.1c972b8-2
Severity: minor

Dear Maintainer,

The actual package release solve the bug #944910 but in the changelog
closes: #916339 (which is an old already closed bug).


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

Versions of packages i3pystatus depends on:
ii  python3  3.7.3-1

Versions of packages i3pystatus recommends:
pn  python3-colour 
pn  python3-netifaces  

i3pystatus suggests no packages.

-- no debconf information

Bug#945596: systemd module does not include the new systemd-volatile-root of systemd 242+

[Enrico Zini]

Package: dracut-core
Version: 048+80-2
Severity: normal

Hello,

I'm trying to setup a system booting on a readonly root with a tmpfs
overlay on top.

Systemd 242+ does it by default with systemd.volatile=overlay
https://www.freedesktop.org/software/systemd/man/systemd-volatile-root.service.html

However it requires systemd to start in the initrd, so I'm switching to
dracut. However, the current dracut in Debian does not include
$systemdutildir/systemd-volatile-root and
$systemdsystemunitdir/systemd-volatile-root.service  in the initd.

   Upstram seems to have done the change in:
   
   commit ce4d04bf72918b9964d49b6815e7378dbe09ac4d
   Author: Paul Robins 
   Date:   Sun May 12 18:00:37 2019 +0100
   
   Include systemd volatile root service and binary

Could we have this in Debian?


Enrico


-- System Information:
Debian Release: 10.2
  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)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dracut-core depends on:
ii  cpio2.12+dfsg-9
ii  e2fsprogs   1.44.5-1+deb10u2
ii  kmod26-1
ii  kpartx  0.7.9-3
ii  libc6   2.28-10
ii  libkmod226-1
ii  pkg-config  0.29-6
ii  udev241-7~deb10u2
ii  util-linux  2.33.1-0.1

Versions of packages dracut-core recommends:
ii  binutils   2.31.1-16
ii  console-setup  1.193~deb10u1
ii  cryptsetup 2:2.1.0-5+deb10u2
pn  dmraid 
ii  dmsetup2:1.02.155-3
ii  lvm2   2.03.02-3
ii  mdadm  4.1-1
ii  systemd241-7~deb10u2

dracut-core suggests no packages.

Bug#931640: webext-ublock-origin: confirmation

[Wim Bertels]

Markus Koschany schreef op zo 10-11-2019 om 21:05 [+0100]:
> 
> Am 10.11.19 um 20:36 schrieb wim:
> > Package: webext-ublock-origin
> > Version: 1.18.4+dfsg-2
> > Followup-For: Bug #931640
> > 
> > Hello,
> > 
> > confirmation:
> > the extension/addon
> > is not active or visible in firefox-esr
> > on the installed addons/extensions page
> 
> Please disable and reenable the addon and then restart Firefox.

This seems to fix it,
thank you,
Wim

> 
> Thanks,
> 
> Markus
> 

Bug#901446: inkscape: Bug fix latex rendering

[Jonas Smedegaard]

Version: 9.24~~rc2~dfsg-1

Quoting Marc-Olivier Buob (2018-06-13 14:58:49)
> With the current version of inkscape, when using Extensions > 
> Rendering > Latex... the latex rendering does not work.

This is believed solved with ghostscript packaging release 
9.24~~rc2~dfsg-1.

Thanks for reporting this bug!

 - Jonas

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

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


signature.asc
Description: signature

Bug#945595: New mpv in sid breaks smplayer

[Alf Gaida]

Package: smplayer
Version: 19.10.2~ds0-0.siduction
Severity: grave

Hi, 

new mpv 0.30* don't play well with smplayer in sid - new 19.10.* will solve 
that problem.

No action needed right now, will work on it.

Cheers Alf

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

Kernel: Linux 5.3.11-towo.1-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages smplayer depends on:
ii  libc6   2.29-3
ii  libgcc1 1:9.2.1-20
ii  libqt5core5a5.12.5+dfsg-2
ii  libqt5dbus5 5.12.5+dfsg-2
ii  libqt5gui5  5.12.5+dfsg-2
ii  libqt5network5  5.12.5+dfsg-2
ii  libqt5script5   5.12.5+dfsg-2
ii  libqt5widgets5  5.12.5+dfsg-2
ii  libqt5xml5  5.12.5+dfsg-2
ii  libstdc++6  9.2.1-20
ii  libx11-62:1.6.8-1
ii  mplayer 2:1.3.0-8+b5
ii  mpv 0.30.0-1
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages smplayer recommends:
ii  smplayer-l10n19.10.2~ds0-0.siduction
ii  smplayer-themes  1:18.6.0-1

smplayer suggests no packages.

-- no debconf information

Bug#944294: buster-pu: package libvirt-daemon/5.0.0-4

[Adam D. Barratt]

Control: tags -1 -confirmed +moreinfo

Hi,

On 2019-11-27 16:07, Guido Günther wrote:

Hi Adam,
On Wed, Nov 27, 2019 at 01:21:40PM +, Adam D. Barratt wrote:

Control: tags -1 + confirmed

On 2019-11-27 13:05, Michal Arbet wrote:
> I've added a patch from upstream ( sid already included it in new
> version ).
> Check current debdiff in attachment.

That looks OK, assuming it's been build- and runtime-tested on a 
buster

system.


It would be nice to coordinate such things with the package
maintainers. I've had question's regarding these patches which weren't
answered yet:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944248#26


Apologies for that, we tend to assume that people making such requests 
either work on the package or have had that co-ordination discussion 
already.


In this case I'll put the request on hold until we hear back.

Regards,

Adam

Bug#944743: (no subject)

[Gordon Ball]

Confirm this bug.

I think it was introduced when upgrading to debhelper compat 12 in
6.0.0-1; dh_installsystemduser was added to the default sequence at this
level anyway.

For now I'll make it just install the unit and not auto-enable it, then
the user can selectively enable it if desired. That was the intended
behaviour.

(The gdm copy can be disabled with `systemctl --user --global disable
jupyter-notebook`)

Bug#944294: buster-pu: package libvirt-daemon/5.0.0-4

[Guido Günther]

Hi Adam,
On Wed, Nov 27, 2019 at 01:21:40PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On 2019-11-27 13:05, Michal Arbet wrote:
> > I've added a patch from upstream ( sid already included it in new
> > version ).
> > Check current debdiff in attachment.
> 
> That looks OK, assuming it's been build- and runtime-tested on a buster
> system.

It would be nice to coordinate such things with the package
maintainers. I've had question's regarding these patches which weren't
answered yet:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944248#26

Cheers,
 -- Guido

> 
> Regards,
> 
> Adam

Bug#942305: gimp: crashes when key press on numeric keys to rotate

[Bernhard Übelacker]

... a short addition:

This issue might also the the same as
described in this upstream issue:
 
https://github.com/scim-im/scim/issues/26

Kind regards,
Bernhard

Bug#945447: RFS: emacs-websocket/1.12+1.g74e4b82-1 [ITP] -- Emacs WebSocket client and server

[Antoine Beaupré]

On 2019-11-27 07:43:59, Nicholas D Steeves wrote:
> Hi Antoine,
>
> Antoine Beaupré  writes:
>
>> A few comments...
>>
>> Why do you specify a compression level and algorithm in gbp.conf?
>>
>> compression = xz
>> compression-level = 9
>>
>
> This reduces the incidence of encountering an annoying gbp bug, where
> gbp fails, allegedly because "two tarballs were found", even when the
> tarball did not previously exist on disk and is generated on demand from
> upstream tag.

I have not found this to be a problem enough to proactively add this
setting when it's not necessary.

> Other than that it's harmless and redundant, because these settings
> are now gbp defaults.

Really! What do you base this on? The manpages of "gbp-buildpackage(1)"
in both buster and sid currently say:

   --git-compression=TYPE
  Specifies the upstream tarball compression type. This will be 
used  to  locate
  and build the upstream tarball if necessary. The default is auto 
which derives
  the compression type from the pristine-tar branch if available 
and falls  back
  to gzip otherwise. Other options are gzip, bzip2, lzma and xz.

   --git-compression-level=LEVEL
  Specifies  the upstream tarball compression level if an upstream 
tarball needs
  to be built.

The keyword here is "default is auto". :p I'm especially concerned about
the excessively high compression-level as well - it's usually not
necessary to change the compression level, and makes it diverge
needlessly from upstream.

>> Upstream doesn't seem to use any peculiar tarball format, so that
>> generated tarball won't match the one published on github.

What I should have written here, for the record, is more like "upstream
doesn't use .xz and uses the default github-generated .gz files".

> I'm using release tags directly and not github generated & published
> tarballs ("why" is another discussion).

I would argue it's the core of this discussion here. You haven't
convinced me that using a .xz tarball format is necessary at all, nor
why you need to diverge from the upstream tarballs.

> The reason the Emacsen Team requests a tarball in d/watch is because
> the git mode we previously used was too resource-intensive.

This seems like another reason to stick with .tgz and not diverge.

> The bug mentioned above also has a useful (hack of a) side-effect in
> that it seems to enforce new upstream version imports from git tags
> rather than github-generated tarballs.

I'm confused - how does compression and compression-level enforce
importing from git tags? And how does that differ from github-generated
tarballs which *are* (reproducibly too) generated frmo git-tags as well?

> Whenever the "light" git-mode becomes generally recommended and
> preferred over the tarball one I'll switch my upstream-uses-github
> packages over to it.

I don't understand what this refers to.

>> I also wonder if it's really necessary to ship a git snapshot instead of
>> the 1.12 release... I see it includes a patch to tweak the GPL version,
>> is that why that was done?
>
> For multiple past NEW packages, ftpmasters have asked me to contact
> upstream about licensing problems (eg: we're accepting, but you need to
> do xyz), so I started doing this preRFS.  Then lamby asked me not to
> carry licensing-related-changes as a quilt patch--with good rationale
> that I agree with.  Thus, packaging a git snapshot.  The contradictory
> declared license issue is here:
>
> https://github.com/ahyatt/emacs-websocket/issues/62

Cool, makes sense.

>> Are the tests included in the package build? or autopkgtest? could that
>> be done? Not a blocker.
>>
>
> Sorry, I don't understand what you mean...  ERT tests are already run
> during the build, autopkgtest-pkg-elpa has been activated
> (d/control:L12), I've confirmed autopkgtest runs the tests, and I've
> also opened an upstream issue about integrating the functional tests
> into the ERT framework:
>
> https://github.com/ahyatt/emacs-websocket/issues/64

Awesome, that answers my question, thanks!

> Since all NEW packages now require two uploads before they can enter
> testing, I like to add value to the second upload, and the following
> brand new commit seems like a good candidate for this:
>
> https://github.com/ahyatt/emacs-websocket/commit/69ee80a88ba825a925e82a5576a340b3ec03fd51
>
> Depending on how long it takes this package to pass NEW upstream might
> tag a new release including that commit, which would be ideal for the
> second upload!

Cool.

>> Otherwise looks good.
>>
>
> Thanks for reviewing :-)  'hope my reply sufficiently addresses your
> concerns!

Not quite. Your reply about the compression level stuff makes me more
worried than anything, to be honest. :p

I would like us to stick with the actual gbp defaults here, which are
"auto" and can easily pick up upstream tgz defaults.

A.

-- 
One of the strongest motives that leads men to art and science is
escape from 

Bug#945195: [PATCH v2 3/7] email-print-mime-structure: move decrypt_part to its own function

[Sean Whitton]

Hello,

On Mon 25 Nov 2019 at 04:45PM -05, Daniel Kahn Gillmor wrote:

> Signed-off-by: Daniel Kahn Gillmor 
> ---
>  email-print-mime-structure | 31 +++
>  1 file changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/email-print-mime-structure b/email-print-mime-structure
> index 6c68eb3..d152b34 100755
> --- a/email-print-mime-structure
> +++ b/email-print-mime-structure
> @@ -32,6 +32,7 @@ something like "cat -n"
>  '''
>  import os
>  import sys
> +import enum
>  import email
>  import logging
>  import subprocess
> @@ -51,6 +52,8 @@ try:
>  except ImportError:
>  argcomplete = None
>
> +EncType = enum.Enum('EncType', ['PGPMIME', 'SMIME'])
> +
>  class MimePrinter(object):
>  def __init__(self, args:Namespace):
>  self.args = args
> @@ -79,7 +82,6 @@ class MimePrinter(object):
>
>  print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname} 
> {nbytes:d} bytes')
>  cryptopayload:Optional[Message] = None
> -ciphertext:Union[List[Message],str,bytes,None] = None
>  try_pgp_decrypt:bool = self.args.pgpkey or self.args.use_gpg_agent
>
>  if try_pgp_decrypt and \
> @@ -87,23 +89,28 @@ class MimePrinter(object):
> (parent.get_content_type().lower() == 'multipart/encrypted') and \
> (str(parent.get_param('protocol')).lower() == 
> 'application/pgp-encrypted') and \
> (num == 2):
> -ciphertext = z.get_payload(decode=True)
> -if not isinstance(ciphertext, bytes):
> -logging.warning('encrypted part was not a leaf mime part 
> somehow')
> -return
> -if self.args.pgpkey:
> -cryptopayload = self.pgpy_decrypt(self.args.pgpkey, 
> ciphertext)
> -if cryptopayload is None and self.args.use_gpg_agent:
> -cryptopayload = self.pipe_decrypt(ciphertext, ['gpg', 
> '--batch', '--decrypt'])
> -if cryptopayload is None:
> -logging.warning(f'Unable to decrypt')
> -return
> +cryptopayload = self.decrypt_part(z, EncType.PGPMIME)
>
>  if cryptopayload is not None:
>  newprefix = prefix[:-3] + ' '
>  print(f'{newprefix}↧ (decrypts to)')
>  self.print_tree(cryptopayload, newprefix + '└', z, 0)
>
> +def decrypt_part(self, msg:Message, flavor:EncType) -> Optional[Message]:
> +ciphertext:Union[List[Message],str,bytes,None] = 
> msg.get_payload(decode=True)
> +cryptopayload:Optional[Message] = None
> +if not isinstance(ciphertext, bytes):
> +logging.warning('encrypted part was not a leaf mime part 
> somehow')
> +return None
> +if flavor == EncType.PGPMIME:
> +if self.args.pgpkey:
> +cryptopayload = self.pgpy_decrypt(self.args.pgpkey, 
> ciphertext)
> +if cryptopayload is None and self.args.use_gpg_agent:
> +cryptopayload = self.pipe_decrypt(ciphertext, ['gpg', 
> '--batch', '--decrypt'])
> +if cryptopayload is None:
> +logging.warning(f'Unable to decrypt')
> +return cryptopayload
> +
>  def pgpy_decrypt(self, keys:List[str], ciphertext:bytes) -> 
> Optional[Message]:
>  if pgpy is None:
>  logging.warning(f'Python module pgpy is not available, not 
> decrypting (try "apt install python3-pgpy")')

This seems fine -- no functional change, right?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#945195: [PATCH v2 2/7] email-print-mime-structure: Generic pipe decryption

[Sean Whitton]

Hello,

On Mon 25 Nov 2019 at 04:45PM -05, Daniel Kahn Gillmor wrote:

> Signed-off-by: Daniel Kahn Gillmor 
> ---
>  email-print-mime-structure | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/email-print-mime-structure b/email-print-mime-structure
> index cdbe2ee..6c68eb3 100755
> --- a/email-print-mime-structure
> +++ b/email-print-mime-structure
> @@ -94,7 +94,7 @@ class MimePrinter(object):
>  if self.args.pgpkey:
>  cryptopayload = self.pgpy_decrypt(self.args.pgpkey, 
> ciphertext)
>  if cryptopayload is None and self.args.use_gpg_agent:
> -cryptopayload = self.gpg_decrypt(ciphertext)
> +cryptopayload = self.pipe_decrypt(ciphertext, ['gpg', 
> '--batch', '--decrypt'])
>  if cryptopayload is None:
>  logging.warning(f'Unable to decrypt')
>  return
> @@ -121,13 +121,13 @@ class MimePrinter(object):
>  pass
>  return None
>
> -def gpg_decrypt(self, ciphertext:bytes) -> Optional[Message]:
> +def pipe_decrypt(self, ciphertext:bytes, cmd:List[str]) -> 
> Optional[Message]:
>  inp:int
>  outp:int
>  inp, outp = os.pipe()
>  with open(outp, 'wb') as outf:
>  outf.write(ciphertext)
> -out:subprocess.CompletedProcess[bytes] = subprocess.run(['gpg', 
> '--batch', '--decrypt'],
> +out:subprocess.CompletedProcess[bytes] = subprocess.run(cmd,
>  stdin=inp,
>  
> capture_output=True)
>  if out.returncode == 0:

Likewise, I can add "no functional change" when I apply this, right?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#942305: gimp: crashes when key press on numeric keys to rotate

[Bernhard Übelacker]

Control: reassign -1 scim-gtk-immodule 1.4.18-2.1
Control: affects -1 + gimp


Hello Masa O,
I tried to reproduce the crash you describe in a Buster/stable VM,
but was not able to reach the crash.

>From your backtrace there are some modules for scim input method
visible, but failed also to setup it correctly to have it loaded
into the gimp process. Some hints how to configure scim correctly
might be good.

I try to reassign this bug to the scim package, maybe you can
also confirm you are using the version above.

Bug #674827 could be related.

Kind regards,
Bernhard



Reconstructed backtrace:
  libgimpbase-2.0.so.0(gimp_stack_trace_print+0x397)[0x7f85411e3e27]   in 
gimp_stack_trace_print at gimputils.c:1378
  gimp(+0xd14a0)[0x5632946ef4a0]   in 
gimp_eek at errors.c:377
  gimp(+0xd18d8)[0x5632946ef8d8]   in 
gimp_fatal_error at errors.c:234
  gimp(+0xd2037)[0x5632946f0037]   in 
gimp_sigfatal_handler at signals.c:165
   libpthread.so.0(+0x12730)[0x7f85404eb730]   ??:?
 libgdk-x11-2.0.so.0(gdk_x11_drawable_get_xdisplay+0x49)[0x7f85412a3369]   in 
IA__gdk_x11_drawable_get_xdisplay at ./gdk/x11/gdkdrawable-x11.c:908
im-scim.so(scim_bridge_key_event_gdk_to_bridge+0xde)[0x7f8522e50d5e]   in 
scim_bridge_key_event_gdk_to_bridge at 
../scim-bridge-client-key-event-utility-gtk.c:123
 im-scim.so(+0x76df)[0x7f8522e506df]   in 
filter_key_event at ../scim-bridge-client-imcontext-gtk.c:130
 im-scim.so(+0x799c)[0x7f8522e5099c]   in 
scim_bridge_client_imcontext_filter_key_event at 
../scim-bridge-client-imcontext-gtk.c:787
  libgtk-x11-2.0.so.0(+0x11bc63)[0x7f854141ec63]   in 
gtk_im_multicontext_filter_keypress at ./gtk/gtkimmulticontext.c:333
   libgtk-x11-2.0.so.0(+0xc8da4)[0x7f85413cbda4]   in 
gtk_entry_key_press at ./gtk/gtkentry.c:4073
  libgtk-x11-2.0.so.0(+0x1331eb)[0x7f85414361eb]   in 
_gtk_marshal_BOOLEAN__BOXED at ./gtk/gtkmarshalers.c:84
  libgobject-2.0.so.0(g_closure_invoke+0xb1)[0x7f85407b1ba1]   in 
g_closure_invoke at ../../../gobject/gclosure.c:810
   libgobject-2.0.so.0(+0x23bbd)[0x7f85407c4bbd]   in 
signal_emit_unlocked_R at ../../../gobject/gsignal.c:3673
 libgobject-2.0.so.0(g_signal_emit_valist+0x47b)[0x7f85407cd9ab]   in 
g_signal_emit_valist at ../../../gobject/gsignal.c:3401
 libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f85407ce97f]   in 
g_signal_emit at ../../../gobject/gsignal.c:3447
  libgtk-x11-2.0.so.0(+0x249cac)[0x7f854154ccac]   in 
gtk_widget_event_internal at ./gtk/gtkwidget.c:5010
libgtk-x11-2.0.so.0(gtk_window_propagate_key_event+0xa8)[0x7f85415604e8]   in 
IA__gtk_window_propagate_key_event at ./gtk/gtkwindow.c:5199
 gimp(+0x2ccdbb)[0x5632948eadbb]   in 
gimp_window_key_press_event at gimpwindow.c:185
  libgtk-x11-2.0.so.0(+0x1331eb)[0x7f85414361eb]   in 
_gtk_marshal_BOOLEAN__BOXED at ./gtk/gtkmarshalers.c:84
 libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7f85407b1c8d]   in 
g_closure_invoke at ../../../gobject/gclosure.c:810
   libgobject-2.0.so.0(+0x23bbd)[0x7f85407c4bbd]   in 
signal_emit_unlocked_R at ../../../gobject/gsignal.c:3673
 libgobject-2.0.so.0(g_signal_emit_valist+0x47b)[0x7f85407cd9ab]   in 
g_signal_emit_valist at ../../../gobject/gsignal.c:3401
 libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f85407ce97f]   in 
g_signal_emit at ../../../gobject/gsignal.c:3447
  libgtk-x11-2.0.so.0(+0x249cac)[0x7f854154ccac]   in 
gtk_widget_event_internal at ./gtk/gtkwidget.c:5010
  libgtk-x11-2.0.so.0(gtk_propagate_event+0x17d)[0x7f854143455d]   in 
IA__gtk_propagate_event at ./gtk/gtkmain.c:2477
libgtk-x11-2.0.so.0(gtk_main_do_event+0x2eb)[0x7f854143487b]   in 
IA__gtk_main_do_event at ./gtk/gtkmain.c:1698
   libgdk-x11-2.0.so.0(+0x5bbac)[0x7f85412a7bac]   in 
gdk_event_dispatch at ./gdk/x11/gdkevents-x11.c:2425
 libglib-2.0.so.0(g_main_context_dispatch+0x2ae)[0x7f85406cff2e]   in 
g_main_dispatch at ../../../glib/gmain.c:3182
  libglib-2.0.so.0(+0x4e1c8)[0x7f85406d01c8]   in 
g_main_context_iterate at ../../../glib/gmain.c:3920
  libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7f85406d04c2]   in 
g_main_loop_run at ../../../glib/gmain.c:4116
 gimp(app_run+0x357)[0x5632946eecb7]   in 
app_run at app.c:440
gimp(main+0x395)[0x5632946ee5b5]   in 
main at main.c:524
   libc.so.6(__libc_start_main+0xeb)[0x7f854033a09b]   in 
__libc_start_main at ../csu/libc-start.c:308
   

Bug#945195: [PATCH v2 1/7] email-print-mime-structure: decrypt PGP/MIME parts as bytes

[Sean Whitton]

Hello,

On Mon 25 Nov 2019 at 04:45PM -05, Daniel Kahn Gillmor wrote:

> Fully decode the encrypted part before passing it to any decryption
> mechanism.

I can go ahead and add "no functional change" to this commit message
right?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#945593: Acknowledgement (pbuilder: Use autodep8 in autopkgtest hook to check existence of tests)

[Rafael Laboissière]

Sorry, the patch attached to the original submission was wrong.  Please, 
consider the new one attached below.


BTW, I just filed a merge request against the Git repository for pbuilder 
at salsa.debian.org: 
https://salsa.debian.org/pbuilder-team/pbuilder/merge_requests/8


Best,

Rafael Laboissière

* Debian Bug Tracking System  [2019-11-27 15:09]:


Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 945593: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945593.

This is an automatically generated reply to let you know your message 
has been received.


Your message is being forwarded to the package maintainers and other 
interested parties for their attention; they will reply in due course.


Your message has been sent to the package maintainer(s): 
Debian pbuilder maintenance team 


If you wish to submit further information on this problem, please 
send it to 945...@bugs.debian.org.


Please do not send mail to ow...@bugs.debian.org unless you wish 
to report a problem with the Bug-tracking system.


--
945593: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945593
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

commit 3d5d7a24d2153604fb4f6acd445bd589148daf5a
Author: Rafael Laboissière 
Date:   Wed Nov 27 12:05:00 2019 -0300

e/B20autopkgtest: Use autodep8 in autopkgtest hook to check existence of tests

The hook script B20autopkgtest fails to detect the existence of unit
tests for packages that have no debian/tests/control file but that
have autodep8 support.  This commit fixes the issue.

Closes: #945593

diff --git a/examples/B20autopkgtest b/examples/B20autopkgtest
index 61eff862..ad85e582 100644
--- a/examples/B20autopkgtest
+++ b/examples/B20autopkgtest
@@ -36,8 +36,11 @@ set -ex
 
 cd "$BUILDDIR"/*/debian/..
 
-if [ ! -f debian/tests/control ]; then
-echo "Package does not have autopkgtest support, debian/tests/control is missing"
+apt-get --yes install autodep8
+
+if [ -z "$(autodep8)" ]; then
+echo "Package does not have autopkgtest support.  Either file"
+echo "debian/tests/control is missing or there is no autodep8 support."
 exit 0
 fi
 

Bug#945582: systemd: Upgrade fails due to missing library libsystemd-shared-241.so

[Graham Cobb]

On 27/11/2019 14:05, Ansgar wrote:
> On Wed, 2019-11-27 at 11:49 +, Graham Cobb wrote:
>> I am upgrading my debian testing system but the upgrades fail as systemd 
>> cannot be configured.
>>
>> Output from dpkg --configure systemd:
>>
>> Setting up systemd (243-8) ...
>> systemd-machine-id-setup: error while loading shared libraries: 
>> libsystemd-shared-241.so: cannot open shared object file: No such file or 
>> directory
>> dpkg: error processing package systemd (--configure):
>>  installed systemd package post-installation script subprocess returned 
>> error exit status 127
> 
> Hmm, this is strange.  When the package is configured, it should
> already be extracted.  And systemd-machine-id-setup from systemd-243
> shouldn't link against a libsystemd-shared-241.so.
> 
> You said your system doesn't have merged-/usr, so I wonder why there
> seems to be /usr/bin/systemd-machine-id-setup and libsystemd-shared-
> 241.so in /usr.
> 
> Could you run
> 
>   ls -l /usr/bin/systemd-machine-id-setup \
> /bin/systemd-machine-id-setup \
> /usr/lib/systemd/libsystemd-shared* \
> /lib/systemd/libsystemd-shared*

# ls -l /usr/bin/systemd-machine-id-setup \
> /bin/systemd-machine-id-setup \
> /usr/lib/systemd/libsystemd-shared* \
> /lib/systemd/libsystemd-shared*
-rwxr-xr-x 1 root root   26792 Nov 19 08:17 /bin/systemd-machine-id-setup
-rw-r--r-- 1 root root 2806128 Nov 19 08:17
/lib/systemd/libsystemd-shared-243.so
-rwxr-xr-x 1 root root   26792 May 24  2019
/usr/bin/systemd-machine-id-setup
-rw-r--r-- 1 root root 2670992 May 24  2019
/usr/lib/systemd/libsystemd-shared-241.so

> I suspect there are some old binaries (from systemd-241) around for
> some reason.

That does seem to be the case.

I note that dpkg -S can find packages responsible for the /bin
executables but not the /usr/bin ones:

# dpkg -S /bin/systemd-machine-id-setup
systemd: /bin/systemd-machine-id-setup
# dpkg -S /usr/bin/systemd-machine-id-setup
dpkg-query: no path found matching pattern /usr/bin/systemd-machine-id-setup

Bug#924560: cryptsetup luksOpen requires 1GB of RAM in the default configuration

[Ondrej Kozina]

On Tue, 26 Mar 2019 10:42:29 +0100 Ondrej Kozina  wrote:
On Thu, 14 Mar 2019 19:43:26 +0100 Guilhem Moulin  
wrote:

> Hi Milan,
> 
> On Thu, 14 Mar 2019 at 19:22:42 +0100, Milan Broz wrote:

> > (...)
> > FYI we know about that parallel unlocking problem already and we are trying
> > to find (with systemd people) some solution (perhaps based on cgroups 
memory limits
> > and some locking).
> 
> Cool, do you have a link to refer to?  Couldn't find anything from a

> quick glance at systemd's issue tracker.

FYI, I've opened cryptsetup issue for parallel Argon2 invocation case 
(https://gitlab.com/cryptsetup/cryptsetup/issues/446).


There should be some systemd issue/PR soon as well. I'll link it to the 
cryptsetup issue when I see it.


Not so soon, but here it is: https://github.com/systemd/systemd/pull/14168

Regards O.