Bug#782952: Bug #782951: Please provide a python3 module

[Scott Kitterman]

severity 782952 serious
thanks

python-pyramid-tm depends on python-pyramid which depends on python-
zope.deprecation which has already been dropped by the zope.deprecation source 
package.

Scott K

Bug#931950: transition: libgeotiff

[Sebastiaan Couwenberg]

On 9/10/19 8:11 AM, Sebastiaan Couwenberg wrote:
> libgeotiff (1.5.1-2) is in testing, but libgeotiff-dfsg (1.4.3-1) cannot
> be removed from testing due to gnudatalanguage, which I don't
> understand. But this should be resolved when the package get autoremoved
> on the 14th.

gnudatalanguage was not removed yesterday, it's still marked for removal
on 14 September.

Version 0.9.9-10+b1 of the gnudatalanguage binary packages is in
testing, but 0.9.9-10+b3 is in unstable. It seems that these two NMUs
never migrated to testing.

Can gnudatalanguage (and grib-api) be hinted out of testing to unblock
the removal of libgeotiff-dfsg?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#940278: new upstream (1.0)

[Daniel Baumann]

Package: gparted
Severity: wishlist

Hi,

it would be nice if you could update gparted to the current upstream
version (1.0), released earlier in May.

Regards,
Daniel

Bug#935381: Please drop the Python 2 subpackage

[Scott Kitterman]

severity 935381 serious
thanks

python-pyramid-multiauth depends on python-pyramid which depends on python-
zope.deprecation which has already been dropped by the zope.deprecation source 
package.

Scott K

Bug#935380: Please drop the Python 2 subpackage

[Scott Kitterman]

On Thu, 22 Aug 2019 11:25:42 +0500 Andrey Rahmatullin  wrote:
> Package: src:pyramid-jinja2
> Version: 2.7+dfsg-1
> Severity: important
> User: debian-pyt...@lists.debian.org
> Usertag: py2removal py2leaf py3available
> 
> As a part of removing Python 2 from unstable we would like to remove python-
> pyramid, and python-pyramid-jinja2 blocks that. Please drop the Python 2
> subpackage when possible.

NMU diff attached.  I plan to upload this shortly.

Scott Kdiff -Nru pyramid-jinja2-2.7+dfsg/debian/changelog pyramid-jinja2-2.7+dfsg/debian/changelog
--- pyramid-jinja2-2.7+dfsg/debian/changelog	2017-01-14 00:44:09.0 -0500
+++ pyramid-jinja2-2.7+dfsg/debian/changelog	2019-09-15 01:04:51.0 -0400
@@ -1,3 +1,10 @@
+pyramid-jinja2 (2.7+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop obsolete python-pyramid-jinja2 binary (Closes: #935380)
+
+ -- Scott Kitterman   Sun, 15 Sep 2019 01:04:51 -0400
+
 pyramid-jinja2 (2.7+dfsg-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru pyramid-jinja2-2.7+dfsg/debian/control pyramid-jinja2-2.7+dfsg/debian/control
--- pyramid-jinja2-2.7+dfsg/debian/control	2017-01-14 00:44:09.0 -0500
+++ pyramid-jinja2-2.7+dfsg/debian/control	2019-09-15 01:04:51.0 -0400
@@ -4,36 +4,19 @@
 Maintainer: Pirate Praveen 
 Build-Depends: debhelper (>= 9),
  dh-python,
- python-all,
- python-setuptools,
  python3-all,
  python3-setuptools,
- python-markupsafe,
  python3-markupsafe,
- python-jinja2,
  python3-jinja2,
- python-zope.deprecation,
  python3-zope.deprecation,
- python-pyramid,
  python3-pyramid,
 Standards-Version: 3.9.8
 Homepage: https://pypi.python.org/pypi/pyramid_jinja2
-X-Python-Version: >= 2.6
 X-Python3-Version: >= 3.2
 Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/pyramid-jinja2.git
 Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/pyramid-jinja2.git/
 Testsuite: autopkgtest-pkg-python
 
-Package: python-pyramid-jinja2
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Suggests: python-pyramid-jinja2-doc
-Description: Jinja2 template bindings for the Pyramid web framework (Python 2)
- These are bindings for the Jinja2 templating system for the Pyramid web
- framework.
- .
- This package installs the library for Python 2.
-
 Package: python3-pyramid-jinja2
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru pyramid-jinja2-2.7+dfsg/debian/rules pyramid-jinja2-2.7+dfsg/debian/rules
--- pyramid-jinja2-2.7+dfsg/debian/rules	2017-01-14 00:44:09.0 -0500
+++ pyramid-jinja2-2.7+dfsg/debian/rules	2019-09-15 01:04:51.0 -0400
@@ -6,7 +6,7 @@
 export PYBUILD_NAME=pyramid-jinja2
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_install:
 	dh_auto_install -XLICENSE.txt -X.git -X.gitignore

Bug#940203: Bugs in the outdated version

[Shmerl]

Also, current outdated version of faudio in Debian actually has bugs
that break games like Dragon Age: Origins in Wine. That should be
fixed in the newest upstream.

Bug#940277: FTBFS with recent PHPUnit (8)

[David Prévot]

Package: php-klogger
Version: 1.2.1-2
Severity: serious

Hi,

This package FTBFS with recent PHPUnit (8). Even if the fix may be
trivial, I open this bug report to see php-klogger removed from testing
(at least until it is actually used by Debian packages), unless there is
a good reason to keep it in Debian.

Regards

David


signature.asc
Description: PGP signature

Bug#940275: FTBFS with recent PHPUnit (8)

[David Prévot]

Package: php-cache-lite
Version: 1.8.2-1
Severity: serious

Hi,

This package FTBFS with recent PHPUnit (8). Even if the fix may be
trivial, I open this bug report to see php-cache-lite removed from
testing unless there is a good reason to keep it in Debian.

“This package is not maintained” [Upstream], is only a php-xml-rpc2
dependency in Debian (and php-xml-rpc2 is a leaf package), and has a low
popcon.

Upstream: https://pear.php.net/package/Cache_Lite/

Regards

David


signature.asc
Description: PGP signature

Bug#940276: postgresql-client-common: infinite recusion in installed versions search

[Timur Khanjanov]

Package: postgresql-client-common
Version: 206
Severity: important

Dear Maintainer,

after upgrading postgresql-client-common/postgresql-common
process is stopped an configuration of postgresql-common with errors

Deep recursion on subroutine "PgCommon::get_versions" at
/usr/share/perl5/PgCommon.pm line 706.
Deep recursion on subroutine "PgCommon::get_program_path" at
/usr/share/perl5/PgCommon.pm line 697.
Deep recursion on subroutine "PgCommon::get_program_path" at
/usr/share/perl5/PgCommon.pm line 697.
Deep recursion on subroutine "PgCommon::get_program_path" at
/usr/share/perl5/PgCommon.pm line 697.
Deep recursion on subroutine "PgCommon::get_program_path" at
/usr/share/perl5/PgCommon.pm line 697.
Deep recursion on subroutine "PgCommon::get_program_path" at
/usr/share/perl5/PgCommon.pm line 697.
Deep recursion on subroutine "PgCommon::get_program_path" at
/usr/share/perl5/PgCommon.pm line 697.
Deep recursion on subroutine "PgCommon::get_newest_version" at
/usr/share/perl5/PgCommon.pm line 473.

if wait some time, system freezes

if interrupt process, postgres can't start anymore with same error

downgrading to version 205 solves problem



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

Kernel: Linux 5.2.0-1-amd64 (SMP w/3 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8),
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages postgresql-client-common depends on:
ii  netbase  5.6

Versions of packages postgresql-client-common recommends:
ii  libreadline8  8.0-3

postgresql-client-common suggests no packages.

-- no debconf information

-- 
Homo Homini Dominus est

Bug#940237: linphone segfault by clicking on its tray icon (a bit more debug information)

[Vladislav Vetrov]

[206443.252049] traps: linphone[15398] general protection ip:7fe44c5b45cd 
sp:7fffe1219510 error:0 in libgail.so[7fe44c59f000+2d000]



-- 

Bug#911997: git: Apply diff from Ubuntu

[Anders Kaseorg]

Never mind, it looks like I wasn’t added to the Debian upload ACL, so my upload 
was rejected.

Anders

Bug#911997: git: Apply diff from Ubuntu

[Anders Kaseorg]

I’ve gone ahead and uploaded these changes. Since I don’t have access to the 
repository on repo.or.cz, I’ve pushed my commits to 
https://salsa.debian.org/andersk-guest/git debian-sid. Jonathan, you can mirror 
these to repo.or.cz at your convenience, or we can take this opportunity to set 
up a shared repository on salsa.

Anders

Bug#933749: confirmed

[Karl Schmidt]

Same problem here - close to a gig..

What I did to get to a sane size:

$ systemctl stop fail2ban.service
$ rm /var/lib/fail2ban/fail2ban.sqlite3
$ iptables -F dynamic
$ systemctl start fail2ban.service


To get a count of dynamic

$ iptables -L dynamic |wc -l

I need to check back to see if it grows again - could be with updates over time?





Politicians are authors of fiction that specialize in the genre of the false 
narrative. -kps

Bug#940274: python3-sagetex: update fails due to file conflicts (missing replace)

[Norbert Preining]

Package: python3-sagetex
Version: 3.3+ds-4
Severity: serious

dpkg: error processing archive 
/var/cache/apt/archives/python3-sagetex_3.3+ds-4_all.deb (--unpack):
 trying to overwrite '/usr/share/texmf/scripts/sagetex/extractsagecode.py', 
which is also in package python-sagetex 3.3+ds-2


missing replace, or the common files need to be installed into a
separate package.

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

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

Versions of packages python3-sagetex depends on:
ii  python3 3.7.3-1
ii  python3-tk  3.7.4-3
ii  sagemath8.9~beta9-1
ii  tex-common  6.12

Versions of packages python3-sagetex recommends:
iu  sagetex  3.3+ds-4

Versions of packages python3-sagetex suggests:
pn  sagetex-doc  

Bug#940273: netsurf: crashes with DuckDuckGo Search Provider

[Paul Wise]

On Sun, 15 Sep 2019 09:37:02 +0800 Paul Wise wrote:

> When I select DuckDuckGo as the Search Provider in the preferences, or
> when I start netsurf with DuckDuckGo selected as the search provider, I
> get a crash (SIGABRT). This seems like it was caused by an upgrade of
> curl becoming more strict.

In addition it crashes when merely visiting http://duckduckgo.com/ but
not when visiting the https encrypted version of that URL.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#940273: netsurf: crashes with DuckDuckGo Search Provider

[Paul Wise]

Package: netsurf
Version: 3.6-3.2
Severity: important
Usertags: crash

When I select DuckDuckGo as the Search Provider in the preferences, or
when I start netsurf with DuckDuckGo selected as the search provider, I
get a crash (SIGABRT). This seems like it was caused by an upgrade of
curl becoming more strict.

Here is the backtrace from selecting DuckDuckGo in the preferences:

$ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 
'thread apply all bt full' --args netsurf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffebd75700 (LWP 1411)]
[New Thread 0x7fffeb574700 (LWP 1412)]
[New Thread 0x7fffead13700 (LWP 1413)]
[Thread 0x7fffead13700 (LWP 1413) exited]
[New Thread 0x7fffead13700 (LWP 2281)]
[New Thread 0x7fffe9e97700 (LWP 2282)]
[Thread 0x7fffe9e97700 (LWP 2282) exited]
[New Thread 0x7fffe9e97700 (LWP 2283)]
[Thread 0x7fffe9e97700 (LWP 2283) exited]
netsurf: content/fetchers/curl.c:683: fetch_curl_initiate_fetch: Assertion 
`codem == CURLM_OK || codem == CURLM_CALL_MULTI_PERFORM' failed.

Thread 1 "netsurf" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0  0x7665a7bb in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
#1  0x76645535 in __GI_abort () at abort.c:79
#2  0x7664540f in __assert_fail_base (fmt=0x767a7ee0 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", assertion=0x631090 "codem == CURLM_OK || codem 
== CURLM_CALL_MULTI_PERFORM", file=0x630d58 "content/fetchers/curl.c", 
line=683, function=) at assert.c:92
#3  0x76653102 in __GI___assert_fail 
(assertion=assertion@entry=0x631090 "codem == CURLM_OK || codem == 
CURLM_CALL_MULTI_PERFORM", file=file@entry=0x630d58 "content/fetchers/curl.c", 
line=line@entry=683, function=function@entry=0x6311a0 
<__PRETTY_FUNCTION__.20962> "fetch_curl_initiate_fetch") at assert.c:101
#4  0x004d080c in fetch_curl_initiate_fetch (handle=, 
fetch=0x11c4040) at content/fetchers/curl.c:683
#5  0x004d080c in fetch_curl_start (vfetch=0x11c4040) at 
content/fetchers/curl.c:715
#6  0x004cd91d in fetch_dispatch_job (fetch=0x11c3b80) at 
content/fetch.c:165
#7  0x004cd91d in fetch_choose_and_dispatch () at content/fetch.c:196
#8  0x004cd91d in fetch_dispatch_jobs () at content/fetch.c:253
#9  0x004cdfaa in fetch_start (url=0x11c3ec0, referer=0x0, 
callback=callback@entry=0x523e30 , p=p@entry=0x11c3f50, 
only_2xx=, post_urlenc=post_urlenc@entry=0x0, 
post_multipart=0x0, verifiable=false, downgrade_tls=false, headers=0x11c3d70, 
fetch_out=0x11c3fa8) at content/fetch.c:574
#10 0x005226ba in llcache_object_refetch (object=0x11c3f50) at 
content/llcache.c:882
#11 0x00522817 in llcache_object_fetch (object=, 
flags=flags@entry=0, referer=referer@entry=0x0, post=post@entry=0x0, 
redirect_count=redirect_count@entry=1) at content/llcache.c:943
#12 0x00523343 in llcache_object_retrieve_from_cache (post=0x0, 
result=0x7fffaea0, redirect_count=1, referer=0x0, flags=0, url=) at content/llcache.c:1724
#13 0x00523343 in llcache_object_retrieve (url=, 
flags=0, referer=0x0, post=post@entry=0x0, redirect_count=1, 
result=result@entry=0x7fffaf00) at content/llcache.c:1819
#14 0x0052470f in llcache_fetch_redirect (replacement=, target=, object=0xfbf230) at content/llcache.c:1973
#15 0x0052470f in llcache_fetch_callback (msg=, 
p=0xfbf230) at content/llcache.c:2656
#16 0x004cfebd in fetch_curl_process_headers (f=f@entry=0xfc0600) at 
content/fetchers/curl.c:879
#17 0x004d1351 in fetch_curl_data (data=data@entry=0x1121690 
"\r\n301 Moved 
Permanently\r\n\r\n301 Moved 
Permanently\r\nnginx\r\n\r\n\r\n",
 size=size@entry=1, nmemb=nmemb@entry=162, _f=0xfc0600) at 
content/fetchers/curl.c:1287
#18 0x77c89805 in chop_write (conn=0x1125820, conn=0x1125820, olen=162, 
optr=0x1121690 "\r\n301 Moved 
Permanently\r\n\r\n301 Moved 
Permanently\r\nnginx\r\n\r\n\r\n",
 type=1) at sendf.c:600
#19 0x77c89805 in Curl_client_write (conn=conn@entry=0x1125820, 
type=type@entry=1, ptr=0x1121690 "\r\n301 Moved 
Permanently\r\n\r\n301 Moved 
Permanently\r\nnginx\r\n\r\n\r\n",
 len=162) at sendf.c:684
#20 0x77c9bb53 in readwrite_data (comeback=0x7fffb14b, 
done=0x7fffb14a, didwhat=, k=0x111fef0, conn=0x1125820, 
data=0x111fe10) at transfer.c:874
#21 0x77c9bb53 in Curl_readwrite (conn=0x1125820, 
data=data@entry=0x111fe10, done=done@entry=0x7fffb14a, 
comeback=comeback@entry=0x7fffb14b) at transfer.c:1234
#22 0x77ca5084 in multi_runsingle (multi=multi@entry=0xa619b0, now=..., 
data=data@entry=0x111fe10) at multi.c:1829
#23 0x77ca60f9 in curl_multi_perform (multi=0xa619b0, 
running_handles=running_handles@entry=0x7fffb2d0) at multi.c:2090
#24

Bug#940210: ncbi-cn3d: missing Breaks+Replaces: ncbi-tools-x11 (<< 6.1.20170106+dfsg1-5)

[Aaron M. Ucko]

Andreas Beckmann  writes:

> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.

It declared one, but accidentally with too strict a range because I
wound up deferring the split due to a REJECT for an unrelated reason
whose fix I prioritized.  I uploaded a correction just now.

Thanks for the report, and sorry about that!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#702816: Missing soft dependency on libunrar

[Nicholas D Steeves]

Hi,

On Wed, Jun 26, 2013 at 06:28:01AM +0200, Martin Pitt wrote:
> Nick Andrik [2013-06-26  1:11 +0200]:
> > calibre already includes support for .cbr files but needs to find the
> > libunrar.so in order to do so.
> > This file is included in the libunrar0 binary package (which is
> > obviously in non-free):
> > http://packages.debian.org/sid/libunrar0
> > 
> > What I am suggesting is to remove all code in calibre that includes
> > parts of the unrar (non-free) program (are there anyway?) but still
> > leave the support for rar files if the external libunrar.so library is
> > found.
> > This method is dynamic linking, which should not be a problem
> > license-wise, right?
> 
> Ack, I wasn't aware that it is that clever! I'm happy to put back the
> Suggests: then, I reopened the bug.
> 
> > In any case, if you decide to include such a "Suggests: libunrar0"
> > then please let me know and give me a bit of time to upload the newest
> > unrar version which will probably include a rename of the binary
> > libunrar0 (API changed)
> 
> Sure, please go ahead. I'll prepare the latest calibre version in the
> meantime in bzr. Please let me know when it's time for upload.
> 
> Thanks!

Was this bug solved in 3.34.0+dfsg-1 via:

  * suggest python-unrardll for rar/cbr support (Closes: #733513)


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#940272: lftp: command "open" does not initiate the connection: unusable with some sshd servers

[Vincent Lefevre]

Package: lftp
Version: 4.8.4-2+b1
Severity: normal

The "open" command does not initiate the connection, and it appears
impossible to do that. This makes lftp unusable with SimpleSSHD under
Android when a key hasn't been defined yet, for instance. There is
no such issue with sftp.

The problem is the following: when SimpleSSHD has just been installed,
there isn't a key yet. Thus, when one connects by sftp, SimpleSSHD
outputs a random, temporary password for security. The password is
provided only once one has initiated the connection (since it will
change at each connection). The problem with lftp is that when it
asks the password, it hasn't initiated the connection, so that one
does not know the password.

Note: If one gives a dummy password, lftp tries to connect, and
SimpleSSHD outputs the password that should have been used. But
after the login failure, lftp closes the connection, so that at
the next connection the password will change. Thus this does not
solve the problem.

Note: This method with the random, temporary password must be used
in order to upload the key in authorized_keys.

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

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

Versions of packages lftp depends on:
ii  libc6 2.29-1
ii  libgcc1   1:9.2.1-8
ii  libgnutls30   3.6.9-5
ii  libidn2-0 2.2.0-2
ii  libreadline8  8.0-3
ii  libstdc++69.2.1-8
ii  libtinfo6 6.1+20190803-1
ii  netbase   5.6
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages lftp recommends:
ii  openssh-client [ssh-client]  1:8.0p1-6

lftp suggests no packages.

-- no debconf information

Bug#940271: display: selecting the area for crop is very slow on a big image (regression)

[Vincent Lefevre]

Package: imagemagick-6.q16
Version: 8:6.9.10.23+dfsg-2.1+b1
Severity: normal

1. Open a big image with "display", e.g. of size 2124x1800.
2. Click on the image to make the menu appear.
3. Click on "Transform", then "Crop".
4. Start to select an area.

The rectangle flickers for several seconds (this can be more than
20 seconds) to get the final selected area. This makes "crop"
almost unusable, and it is even impossible to do an accurate crop
as the area selection is no longer real time (or one needs to do
2 successive crops to first reduce the image size).

-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
compare:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
convert:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
composite:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
conjure:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
display:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
identify:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
import:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
mogrify:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
montage:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
stream:  ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org

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

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

Versions of packages imagemagick-6.q16 depends on:
ii  hicolor-icon-theme 0.17-2
ii  libc6  2.29-1
ii  libmagickcore-6.q16-6  8:6.9.10.23+dfsg-2.1+b1
ii  libmagickwand-6.q16-6  8:6.9.10.23+dfsg-2.1+b1

Versions of packages imagemagick-6.q16 recommends:
ii  ghostscript  9.28~~rc2~dfsg-1
ii  libmagickcore-6.q16-6-extra  8:6.9.10.23+dfsg-2.1+b1
ii  netpbm   2:10.0-15.3+b2

Versions of packages imagemagick-6.q16 suggests:
pn  autotrace
ii  cups-bsd [lpr]   2.3.0-3
ii  curl 7.65.3-1
pn  enscript 
ii  ffmpeg   7:4.1.4-1+b2
ii  fig2dev [transfig]   1:3.2.7a-7
ii  gimp 2.10.8-2+b1
ii  gnuplot-qt [gnuplot] 5.2.7+dfsg1-3
pn  grads
pn  graphviz 
ii  groff-base   1.22.4-3
pn  hp2xx
pn  html2ps  
ii  imagemagick-6-doc [imagemagick-doc]  8:6.9.10.23+dfsg-2.1
ii  libwmf-bin   0.2.8.4-14
ii  mplayer  2:1.3.0-8+b4
pn  povray   
pn  radiance 
ii  sane-utils   1.0.27-3.2
ii  texlive-binaries [texlive-base-bin]  2019.20190605.51237-2
pn  ufraw-batch  
ii  xdg-utils1.1.3-1

-- no debconf information

Bug#940270: mumble-server: Server fails to start with valid SSL Certs enabled.

[Andrew Lawrence DeMarsh]

Package: mumble-server
Version: 1.3.0~git20190125.440b173+dfsg-2
Severity: important

Dear Maintainer,

When adding SSL Certs from LetsEncrypt to the mumble server that was
operating with self signed certs it was found that the Server would
fail to start up with the following error:

root@mumble:/# murmurd -ini /etc/mumble-server.ini -v
2019-09-14 23:40:58.428 SSL: OpenSSL version is 'OpenSSL 1.1.1c  28 May 2019'
2019-09-14 23:40:58.428 Initializing settings from /etc/mumble-ff-server.ini 
(basepath /etc) 
 
2019-09-14 23:40:58.430 MetaParams: Failed to find certificate matching 
private key.
2019-09-14 23:40:58.430 MetaParams: Failed to load SSL settings. See 
previous errors.

This is not a permissions issue as the certificates are in roots home folder 
and it is running as root.
These are standard SSL Cert from letsencrypt recieved using acme.sh.

despite every action I have taken until this point I cannot seem to get the 
server to start with these ssl
certs enabled. commenting the ssl section out the server starts up fine.

Please note that we use a systemd unit file not the standard startup provided 
because
of Systemd not respecting Sysv init script dependancies. this is not the 
problem.  
 
*** Reporter, please consider answering these questions, where appropriate ***

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

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


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

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

Versions of packages mumble-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libavahi-compat-libdnssd1  0.7-4+b1
ii  libc6  2.28-10
ii  libcap21:2.25-2
ii  libgcc11:8.3.0-6
ii  libprotobuf17  3.6.1.3-2
ii  libqt5core5a   5.11.3+dfsg1-1
ii  libqt5dbus55.11.3+dfsg1-1
ii  libqt5network5 5.11.3+dfsg1-1
ii  libqt5sql5 5.11.3+dfsg1-1
ii  libqt5sql5-sqlite  5.11.3+dfsg1-1
ii  libqt5xml5 5.11.3+dfsg1-1
ii  libssl1.1  1.1.1c-1
ii  libstdc++6 8.3.0-6
ii  libzeroc-ice3.73.7.2-4
ii  lsb-base   10.2019051400

mumble-server recommends no packages.

mumble-server suggests no packages.

-- Configuration Files:
/etc/default/mumble-server changed:
MURMUR_USE_CAPABILITIES=1

/etc/init.d/mumble-server [Errno 2] No such file or directory: 
'/etc/init.d/mumble-server'
/etc/mumble-server.ini [Errno 13] Permission denied: '/etc/mumble-server.ini'

-- debconf information:
* mumble-server/use_capabilities: true
* mumble-server/start_daemon: true

Bug#940190: gegl: FTBFS on mips64el and mipsel while it did built before

[Jeremy Bicha]

On Sat, Sep 14, 2019 at 12:21 AM Bernhard Übelacker
 wrote:
> Running just the mentioned test it returns a timeout message.
> Therefore I guess that this test has just a too short timeout.
> Increasing it from 3 to 40 seconds make it succeed also in my
> (very slow) VM.

Could one of you report this issue and the proposed change to the gegl
developers?

https://gitlab.gnome.org/GNOME/gegl/issues

The Debian GNOME team is a bit short on developers right now.

Thanks,
Jeremy Bicha

Bug#940187: RFS: qosmic/1.6.0-001 [ITP] -- GUI for creating & rendering fractal flame images

[Adam Borowski]

On Fri, Sep 13, 2019 at 06:31:08PM +0100, Peter wrote:
>  * Package name: qosmic
>Version : 1.6.0-001

> It builds those binary packages:
> 
>   qosmic - GUI for creating & rendering fractal flame images

The package seems in a good shape in general.

However, you have debian/source/include-binaries which lists a lot of .o
objects plus the executable itself.  These binaries don't get actually
included as they're gone after clean, but that's still an error in packaging
that should be fixed.

Also, a nitpick: the Debian revision of -001 instead of -1 is technically
correct, but it will make people scratch their heads.  It'd be nice to use
the standard spelling.


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#911997: git: Apply diff from Ubuntu

[Jeremy Bicha]

Ping!

Jeremy

On Wed, Jan 23, 2019 at 11:51 AM Jeremy Bicha  wrote:
>
> Jonathan,
>
> Ubuntu has accepted pcre2 in to main so the Ubuntu diff is now a
> single line. Please apply this patch to your git tree. And I guess you
> can drop the pcre3 alternate Build-Depends too.
>
> By the way, there are several other Debian bugs tagged 'patch' for git
> so please review those when you have time.
>
> Thanks,
> Jeremy Bicha

Bug#931401: syncthing: incorrect warning please upgrade to v0.14.14 or newer

[BenWiederhake.GitHub]

Hello,

I also have this issue.  It prevents me from syncing symlinks. :/

It seems that d/rules is trying to inject a clever version string, and
it fails for some reason.

Cheers,
Ben

Bug#940240: e2scrub_all: File descriptor 3 […] leaked on lvs invocation

[Thorsten Glaser]

Hi Ted,

>I believe this is a bug in cron or lvm, in that cron fd 3 open for
>some unknown reason.  And then LVM whines about it.  See:

Indeed, I think this is most likely a bug in cron.
It’s (while annoying) okay for LVM to complain (IceWM also does, IIRC).

>The simplest way to work around this should be to add to the following
>command to the beginning of /sbin/e2scrub_all:
>
>exec 3<&-
>
>Can you confirm this fixes things for you?

Yes, it does. (The Korn shell (when not in POSIX mode) also closes
those fds by default, but given none is in base, this fix is easier
than switching to #!/bin/mksh ☻)

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Bug#939994: mailscripts: use https instead of http

[Daniel Kahn Gillmor]

Hi Sean--

On Sat 2019-09-14 09:19:01 -0700, Sean Whitton wrote:
> Can I get a Signed-off-by please?
>
> Please see CONTRIBUTING.md.

sure thing, please see the "use-https" branch on
https://salsa.debian.org/dkg/mailscripts.git

--dkg


signature.asc
Description: PGP signature

Bug#939993: mailscripts: adopt printmimestructure from notmuch

[Daniel Kahn Gillmor]

On Sat 2019-09-14 12:16:28 -0700, Sean Whitton wrote:
> Just fyi, I had to re-order your commits slightly for the sake of `git
> bisect`: you added the installation of the manpage before the commit
> which provided the manpage to be installed.

thanks for cleaning that up!

   --dkg


signature.asc
Description: PGP signature

Bug#907041: ITP: swupdate - Pulled from the NEW queue

[Bastian Germann]

Hi,

The package was in the NEW queue but does not appear there anymore. Do
you still plan to get it into Debian?

Cheers,
Bastian Germann

Bug#909048: [PKG-Openstack-devel] Bug#909048: This isn't a bug

[Thomas Goirand]

Hi Santiago!

On 9/14/19 7:00 PM, Santiago Vila wrote:
> I guess the things you do in override_dh_install before that are
> required for the tests to work, otherwise I suppose you would have
> just moved the tests to dh_auto_test.

Indeed~

With many packages in OpenStack, if you want the tests to run correctly,
the Python package *must* be installed in the Python folder, together
with the correctly generated egg-info and all. Otherwise, tests may just
fail. This is so increasingly the case, that I've now taken the habit to
always do it for all OpenStack services as much as possible, otherwise I
get some surprises and waste my time.

What's not completely apparent is that pkgos-dh_auto_test does:
PYTHONPATH=$(CURDIR)/debian/tmp/usr/lib/python3/dist-packages

when running the tests.

The same way, pkgos-dh_auto_install has now gained a --in-tmp parameter
so that pkgos-dh_auto_test can automatically set the correct PYTHONPATH
value that will help the tests to pass.

Also, this package (ie: Glare) is a bad example, because it is largely
unmaintained upstream, which is why I kind of lost interest in it, and
didn't care enough for fixing issues for it for Buster. I probably
should ask for it to be removed from Debian... :(

Cheers,

Thomas Goirand (zigo)

Bug#933967: bug Wifi card Ralink

[lpeweb]

Bus 003 Device 002: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 
Wireless Adapter





I confirm it was impossible make association with my router with this card that 
disabling predictable ifnames with net.ifnames=0 fixed it



Thanks.



Marco

Bug#940234: debian-policy: add a section about source reproducibility

[Guillem Jover]

On Sat, 2019-09-14 at 08:58:21 -0700, Sean Whitton wrote:
> On Sat 14 Sep 2019 at 02:01PM +00, Holger Levsen wrote:
> > On Sat, Sep 14, 2019 at 01:34:49PM +0200, Aurelien Jarno wrote:
> >> There is already a section about reproducibility in the debian-policy,
> >> but it only mentions the binary packages. It might be a good idea to
> >> add a new requirement that repeatedly building the source package in
> >> the same environment produces identical .dsc file modulo the GPG
> >> signature.
> >>
> >> I haven't checked how many packages do not fulfill this condition
> >
> > please do check. last (and only) time we (=r-b) looked, it wasn't
> > practical at all. this was around 5 years ago, but I don't remember any
> > work done on improving this.
> 
> Right.  While we can all agree that it would be nice for source package
> builds to reproducible, I think our current source package formats make
> it quite a hard problem, so it would be good to have some data before we
> spend any time discussing this further.

Back when we were fixing the binary package reproducible problems
within dpkg, I also checked the source side, and fixed a few
problematic cases. Assuming the same tools installed as defined in
the .buildinfo file, and the same content in the unpacked source
tree, dpkg-source should be producing the same output source packages.
If this does not hold, I'd consider it a bug to be fixed.

Thanks,
Guillem

Bug#940209: info desktop file is missing the additional category 'ConsoleOnly'

[Hilmar Preuße]

Hi Jörg,

> The desktop file for Linux (/usr/share/applications/info.desktop) is
missing the additional category 'ConsoleOnly' which is a sub-category of
'Utility'. Please see the documentation about desktop files here:
> 
> 
> This category should be added.
> 
Currently we have:

Categories=Utility;Documentation

How should the line should look like after change?

Categories=Utility;Documentation;ConsoleOnly

?

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#940240: e2scrub_all: File descriptor 3 […] leaked on lvs invocation

[Theodore Y. Ts'o]

On Sat, Sep 14, 2019 at 02:42:29PM +0200, Thorsten Glaser wrote:
> Package: e2fsprogs
> Version: 1.45.3-4
> Severity: minor
> 
> From: Cron Daemon 
> Message-ID: <20190914011004.3afc6220...@tglase.lan.tarent.de>
> To: r...@tglase.lan.tarent.de
> Date: Sat, 14 Sep 2019 03:10:04 +0200 (CEST)
> Subject: Cron  test -e /run/systemd/system || SERVICE_MODE=1 
> /sbin/e2scrub_all -A -r
> 
> File descriptor 3 (pipe:[24666004]) leaked on lvs invocation. Parent PID 
> 17610: /bin/bash

I believe this is a bug in cron or lvm, in that cron fd 3 open for
some unknown reason.  And then LVM whines about it.  See:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581339
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466138
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432986

The simplest way to work around this should be to add to the following
command to the beginning of /sbin/e2scrub_all:

exec 3<&-

Can you confirm this fixes things for you?

Thanks,

- Ted

Bug#939768: Solved

[Christophe TROESTLER]

Hi,

In my case, removing ~/.config/GIMP fixes the problem at startup.  However 
creating or opening an image crashes gimp.  Following the discussion I confirm 
that

apt-cache policy libgegl-0.4-0

fixes the problem.

Bug#940268: dvisvgm: FTBFS on 32bit arches

[Hilmar Preuße]

Control: forwarded 940268 https://github.com/mgieseki/dvisvgm/issues/117

On 14.09.19 22:52, Hilmar Preuße wrote:

> Dear Maintainer,
> 
>* What led up to the situation?
> 
> Upload of new package, try to build on 32 bit architectures. The test
> suite fails on all 32 bit architectures, see [1].
> 
Already known @upstream.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#939961: FTBFS with OCaml 4.08.0 (safe strings)

[Andy Li]

Hi Stéphane,

On Tue, Sep 10, 2019 at 9:09 PM Stéphane Glondu  wrote:

> You package haxe FTBFS with OCaml 4.08.0 because -safe-string is now
> the default. Full log:
>
>   https://ocaml.debian.net/transitions/ocaml-4.08.0/pool/haxe.log


The link returns ERR_NAME_NOT_RESOLVED for me. Is it down?


Please fix your package so that it compiles with -safe-string. This is
> possible with the version of OCaml currently in unstable (4.05.0).
>

The upcoming version of Haxe (4.0.0) will be safe-string compatible, but
the current version will remain incompatible (difficult to patch).
I will just add "OCAMLPARAM=safe-string=0,_" as a workaround. Is that okay?


Best,
Andy

Bug#940108: nexus: FTBFS with GCC 9: dereferencing pointer to incomplete type 'mxml_node_t' error

[Emmanuel Bourg]

Control: retitle -1 nexus: FTBFS with mxml 3

Le 12/09/2019 à 15:32, Emmanuel Bourg a écrit :

> With the Java 9 fix applied (#893383) nexus still fails to build,
> I assume due to more strict checks by GCC 9:

Actually the build failure was caused by the upgrade of mxml to the
version 3 last month. With the version 2 from Buster it builds fine.

@Alastair: any hint how to fix this? Is this due to the _mxml_index_s
struct being moved to mxml-private.h and thus no longer exposed by
libmxml-dev?

Emmanuel Bourg

Bug#940269: kopano-webapp-files: Does not appear in plugins list

[Axel]

Package: kopano-webapp-files
Version: 2.1.5+dfsg1-1
Severity: important

Dear Maintainer,

after installation and restart of both the Kopano server and Apache, the plugin 
is still
not listed (the only plugin appearing is “WebApp Manual”).


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

Versions of packages kopano-webapp-files depends on:
ii  kopano-webapp-common3.5.2+dfsg1-1
ii  php-curl2:7.3+69
ii  php-sabre-dav   1.8.12-7
ii  php-sabre-vobject   2.1.7-4
ii  php7.3-curl [php-curl]  7.3.4-2

kopano-webapp-files recommends no packages.

kopano-webapp-files suggests no packages.

-- no debconf information

Bug#940268: dvisvgm: FTBFS on 32bit arches

[Hilmar Preuße]

Package: dvisvgm
Version: 2.7.3-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source

Dear Maintainer,

   * What led up to the situation?

Upload of new package, try to build on 32 bit architectures. The test
suite fails on all 32 bit architectures, see [1].

FAIL: GFGlyphTracerTest
===

[==] Running 3 tests from 1 test case.
[--] Global test environment set-up.
[--] 3 tests from GFGlyphTracerTest
[ RUN  ] GFGlyphTracerTest.executeChar
GFGlyphTracerTest.cpp:77: Failure
Expected equality of these values:
  scaled_pathstr(glyph)
Which is: "M3.5 4.3C3.2 4.1 3.1 4.1 2.9 4.3C1.9 4.8 .6 4 .6 3C.6 2.8 .7 2.4 
.8 2.3C.9 2.1 1 2 .9 1.7C.7 1.3 .7 .8 .9 .5C1 .3 1 .3 .6-.1C0-.7 .1-1.4 
1.1-1.9C1.7-2.2 3.3-2.2 3.8-1.9C4.4-1.6 4.7-1.2 4.7-.8C4.7 .2 3.9 .7 2.4 .7C1.3 
.7 1 .9 1.1 1.4C1.1 1.7 1.2 1.7 1.4 1.7C1.5 1.7 1.8 1.6 2 1.6C3.2 1.4 4.2 2.8 
3.5 3.7C3.4 3.9 3.4 4 3.6 4.1C4 4.4 4.3 4.4 4.2 4.1C4.2 3.9 4.4 3.7 4.6 3.8C4.7 
3.8 4.8 4 4.8 4.1C4.8 4.6 4.2 4.7 3.5 4.3ZM2.7 3.9C3 3.6 3 2.4 2.7 2.1C2.4 1.7 
1.9 1.7 1.6 2.1C1.3 2.4 1.3 3.6 1.6 3.9C1.9 4.3 2.4 4.3 2.7 3.9ZM3.5-.1C4-.2 
4.2-.7 4-1.1C3.6-2 1.7-2.2 1.1-1.4C.8-1 .8-.6 1.1-.2C1.3 .1 1.4 .1 2.2 .1C2.7 
.1 3.3 0 3.5-.1Z"
  "M3.5 4.3C3.2 4.1 3.1 4.1 2.9 4.3C1.9 4.8 .6 4 .6 3C.6 2.8 .7 2.4 .8 2.3C.9 
2.1 1 2 .9 1.7" "C.7 1.3 .7 .8 .9 .5C1 .3 1 .3 .6-.1C0-.7 .1-1.4 
1.1-1.9C1.7-2.2 3.3-2.2 3.8-1.9" "C4.4-1.6 4.7-1.2 4.7-.8C4.7 .2 3.9 .7 2.4 
.7C1.3 .7 1 .9 1.1 1.4C1.1 1.7 1.2 1.7 1.4 1.7" "C1.5 1.7 1.8 1.6 2 1.6C3.2 1.4 
4.2 2.8 3.5 3.7C3.4 3.9 3.4 4 3.6 4.1C4 4.4 4.3 4.4 4.2 4.1" "C4.2 3.9 4.4 3.7 
4.6 3.8C4.7 3.8 4.8 4 4.8 4.1C4.8 4.6 4.2 4.7 3.5 4.3Z" "M2.7 3.9C2.9 3.8 2.9 
3.5 2.9 3C2.9 2.2 2.7 1.8 2.2 1.8C1.6 1.8 1.4 2.2 1.4 3C1.4 3.8 1.6 4.2 2.2 
4.2C2.3 4.2 2.6 4.1 2.7 3.9Z" "M3.5-.1C4-.2 4.2-.7 4-1.1C3.6-2 1.7-2.2 
1.1-1.4C.8-1 .8-.6 1.1-.2C1.3 .1 1.4 .1 2.2 .1C2.7 .1 3.3 0 3.5-.1Z"
Which is: "M3.5 4.3C3.2 4.1 3.1 4.1 2.9 4.3C1.9 4.8 .6 4 .6 3C.6 2.8 .7 2.4 
.8 2.3C.9 2.1 1 2 .9 1.7C.7 1.3 .7 .8 .9 .5C1 .3 1 .3 .6-.1C0-.7 .1-1.4 
1.1-1.9C1.7-2.2 3.3-2.2 3.8-1.9C4.4-1.6 4.7-1.2 4.7-.8C4.7 .2 3.9 .7 2.4 .7C1.3 
.7 1 .9 1.1 1.4C1.1 1.7 1.2 1.7 1.4 1.7C1.5 1.7 1.8 1.6 2 1.6C3.2 1.4 4.2 2.8 
3.5 3.7C3.4 3.9 3.4 4 3.6 4.1C4 4.4 4.3 4.4 4.2 4.1C4.2 3.9 4.4 3.7 4.6 3.8C4.7 
3.8 4.8 4 4.8 4.1C4.8 4.6 4.2 4.7 3.5 4.3ZM2.7 3.9C2.9 3.8 2.9 3.5 2.9 3C2.9 
2.2 2.7 1.8 2.2 1.8C1.6 1.8 1.4 2.2 1.4 3C1.4 3.8 1.6 4.2 2.2 4.2C2.3 4.2 2.6 
4.1 2.7 3.9ZM3.5-.1C4-.2 4.2-.7 4-1.1C3.6-2 1.7-2.2 1.1-1.4C.8-1 .8-.6 
1.1-.2C1.3 .1 1.4 .1 2.2 .1C2.7 .1 3.3 0 3.5-.1Z"
[  FAILED  ] GFGlyphTracerTest.executeChar (1 ms)
[ RUN  ] GFGlyphTracerTest.defaultCallback
[   OK ] GFGlyphTracerTest.defaultCallback (0 ms)
[ RUN  ] GFGlyphTracerTest.fail
[   OK ] GFGlyphTracerTest.fail (0 ms)
[--] 3 tests from GFGlyphTracerTest (1 ms total)

[--] Global test environment tear-down
[==] 3 tests from 1 test case ran. (1 ms total)
[  PASSED  ] 2 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] GFGlyphTracerTest.executeChar

 1 FAILED TEST
FAIL GFGlyphTracerTest (exit status: 1)

[1] https://buildd.debian.org/status/package.php?p=dvisvgm
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 5.2.0-2-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#940266: z3: FTBFS on hppa - objects in shared libraries need to be compiled with -fPIC

[John David Anglin]

On 2019-09-14 4:27 p.m., Sylvestre Ledru wrote:
> For curiosity, do you know why?
Shared libraries need to be position independent.  Same for PIE executables.  
The default
on 32-bit hppa is to generate non-position independent code.  It is somewhat 
more efficient.
It uses some different relocations and global data is loaded using global 
pointer.  One doesn't
need to load address from got.

This runtime model was defined by HP years ago (1980s).  Strangely, HP decided 
to generate
PIC code by default for hppa64.

Regards,
Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#940266: z3: FTBFS on hppa - objects in shared libraries need to be compiled with -fPIC

[Sylvestre Ledru]

Le 14/09/2019 à 22:14, John David Anglin a écrit :

Source: z3
Version: 4.8.4-1
Severity: normal

Dear Maintainer,

On hppa and some other architectures, objects linked in shared libraries
need to be compiled with -fPIC.


For curiosity, do you know why?

Thanks

Sylvestre

Bug#697030: Unreproducible

[Magnus Holmgren]

onsdag 11 september 2019 kl. 15:57:44 CEST skrev du:
> tags -1 + unreproducible
> 
> I have been unable to reproduce this since 2012, that said, the original
> system this was on was a VERY low-spec VPS, in recent years I've run my
> own infrastructure so it's not really an issue anymore.
> 
> Whether this is up for closure or not is the Maintainer's decision,
> however I have not been able to replicate this in any setup since.

Okay; I was going to add a -l parameter to the config anyway, but if clients 
have a habit of connecting without sending a query, a lower timeout might be 
wise to set.

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer 

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

Bug#940267: ibus: CVE-2019-14822

[Salvatore Bonaccorso]

Source: ibus
Version: 1.5.19-4
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1 1.5.14-3+deb9u1
Control: found -1 1.5.14-3
Control: fixed -1 1.5.14-3+deb9u2
Control: fixed -1 1.5.19-4+deb10u1

Hi,

The following vulnerability was published for ibus.

CVE-2019-14822[0]:
missing authorization flaw

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-14822
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14822
[1] https://www.openwall.com/lists/oss-security/2019/09/13/1
[2] https://github.com/ibus/ibus/commit/3d442dbf936d197aa11ca0a71663c2bc61696151

We plan to release an update for ibus with the attached debdiffs, but
some further verification is pending needed.

Regards,
Salvatore
diff -Nru ibus-1.5.14/debian/changelog ibus-1.5.14/debian/changelog
--- ibus-1.5.14/debian/changelog2018-09-18 20:14:51.0 +0200
+++ ibus-1.5.14/debian/changelog2019-09-11 23:13:56.0 +0200
@@ -1,3 +1,10 @@
+ibus (1.5.14-3+deb9u2) stretch-security; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * bus: Implement GDBusAuthObserver callback (CVE-2019-14822)
+
+ -- Salvatore Bonaccorso   Wed, 11 Sep 2019 23:13:56 +0200
+
 ibus (1.5.14-3+deb9u1) stretch; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ibus-1.5.14/debian/patches/CVE-2019-14822.patch 
ibus-1.5.14/debian/patches/CVE-2019-14822.patch
--- ibus-1.5.14/debian/patches/CVE-2019-14822.patch 1970-01-01 
01:00:00.0 +0100
+++ ibus-1.5.14/debian/patches/CVE-2019-14822.patch 2019-09-11 
23:13:07.0 +0200
@@ -0,0 +1,134 @@
+From 7aa556c043fbda5c3b499cf7ec1bb0e3b30e1b65 Mon Sep 17 00:00:00 2001
+From: fujiwarat 
+Date: Tue, 03 Sep 2019 19:06:52 +0900
+Subject: [PATCH] bus: Implement GDBusAuthObserver callback
+
+ibus uses a GDBusServer with 
G_DBUS_SERVER_FLAGS_AUTHENTICATION_ALLOW_ANONYMOUS,
+and doesn't set a GDBusAuthObserver, which allows anyone who can connect
+to its AF_UNIX socket to authenticate and be authorized to send method calls.
+It also seems to use an abstract AF_UNIX socket, which does not have
+filesystem permissions, so the practical effect might be that a local
+attacker can connect to another user's ibus service and make arbitrary
+method calls.
+
+BUGS=rhbz#1717958
+[Salvatore Bonaccorso: Backport to 1.5.19
+ - Adjust for context changes
+ - Drop update to copyright statements
+]
+[Salvatore Bonaccorso: Backport to 1.5.14
+ - Adjust for context changes
+ - Drop huncks marking user_data with G_GNUC_UNUSED for
+   _server_connect_start_portal_cb and bus_acquired_handler as not
+   present in 1.5.14.
+]
+---
+
+--- a/bus/server.c
 b/bus/server.c
+@@ -70,16 +70,63 @@ _restart_server (void)
+ }
+ 
+ /**
++ * bus_allow_mechanism_cb:
++ * @observer: A #GDBusAuthObserver.
++ * @mechanism: The name of the mechanism.
++ * @user_data: always %NULL.
++ *
++ * Check if @mechanism can be used to authenticate the other peer.
++ * Returns: %TRUE if the peer's mechanism is allowed.
++ */
++static gboolean
++bus_allow_mechanism_cb (GDBusAuthObserver *observer,
++const gchar   *mechanism,
++G_GNUC_UNUSED gpointer user_data)
++{
++if (g_strcmp0 (mechanism, "EXTERNAL") == 0)
++return TRUE;
++return FALSE;
++}
++
++/**
++ * bus_authorize_authenticated_peer_cb:
++ * @observer: A #GDBusAuthObserver.
++ * @stream: A #GIOStream.
++ * @credentials: A #GCredentials.
++ * @user_data: always %NULL.
++ *
++ * Check if a peer who has already authenticated should be authorized.
++ * Returns: %TRUE if the peer's credential is authorized.
++ */
++static gboolean
++bus_authorize_authenticated_peer_cb (GDBusAuthObserver *observer,
++ GIOStream *stream,
++ GCredentials  *credentials,
++ G_GNUC_UNUSED gpointer user_data)
++{
++gboolean authorized = FALSE;
++if (credentials) {
++GCredentials *own_credentials = g_credentials_new ();
++if (g_credentials_is_same_user (credentials, own_credentials, NULL))
++authorized = TRUE;
++g_object_unref (own_credentials);
++}
++return authorized;
++}
++
++/**
+  * bus_new_connection_cb:
+- * @user_data: always NULL.
+- * @returns: TRUE when the function can handle the connection.
++ * @observer: A #GDBusAuthObserver.
++ * @dbus_connection: A #GDBusconnection.
++ * @user_data: always %NULL.
+  *
+  * Handle incoming connections.
++ * Returns: %TRUE when the function can handle the connection.
+  */
+ static gboolean
+-bus_new_connection_cb (GDBusServer *server,
+-   GDBusConnection *dbus_connection,
+-   gpointer user_data)
++bus_new_connection_cb (GDBusServer

Bug#940265: emacs: Please backport patch to fix build on m68k

[John Paul Adrian Glaubitz]

Source: emacs
Severity: normal
Tags: upstream patch
User: debian-...@lists.debian.org
Usertags: m68k

Hello!

Upstream contains a patch since May that fixes the build on m68k. For
some reason, this patch hasn't propagated into the Debian package yet
although I thought upstream backported it to stable.

Anyway, could this patch be included in the next upload so emacs gets
fixed on m68k? The patch is part of the upstream repository and can
be found in [1]. I'll attach it as well.

Thanks,
Adrian

> [1] 
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=967711995ecedc0ed79602ad71af57f45d6a3720

---
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>From 967711995ecedc0ed79602ad71af57f45d6a3720 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 13 May 2019 12:43:13 -0700
Subject: Fix broken build on m68k

The GCC + valgrind fix caused the m68k build to fail (Bug#35711).
Simplify string allocation a bit to make similar problems less
likely in the future.
* src/alloc.c (sdata, SDATA_NBYTES, SDATA_DATA) [GC_CHECK_STRING_BYTES]:
Use the same implementation as with !GC_CHECK_STRING_BYTES,
as the special case is no longer needed.
(SDATA_ALIGN): New constant.
(SDATA_SIZE): Remove this macro, replacing with ...
(sdata_size): ... this new function.  All uses changed.
Properly account for sizes and alignments even in the m68k case,
and even if GC_CHECK_STRING_BYTES is not defined.
---
 src/alloc.c | 77 -
 1 file changed, 25 insertions(+), 52 deletions(-)

diff --git a/src/alloc.c b/src/alloc.c
index 948a0e8..af4adb3 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -1447,9 +1447,7 @@ mark_interval_tree (INTERVAL i)
 
 #define LARGE_STRING_BYTES 1024
 
-/* The SDATA typedef is a struct or union describing string memory
-   sub-allocated from an sblock.  This is where the contents of Lisp
-   strings are stored.  */
+/* The layout of a nonnull string.  */
 
 struct sdata
 {
@@ -1468,13 +1466,8 @@ struct sdata
   unsigned char data[FLEXIBLE_ARRAY_MEMBER];
 };
 
-#ifdef GC_CHECK_STRING_BYTES
-
-typedef struct sdata sdata;
-#define SDATA_NBYTES(S)(S)->nbytes
-#define SDATA_DATA(S)  (S)->data
-
-#else
+/* A union describing string memory sub-allocated from an sblock.
+   This is where the contents of Lisp strings are stored.  */
 
 typedef union
 {
@@ -1502,8 +1495,6 @@ typedef union
 #define SDATA_NBYTES(S)(S)->n.nbytes
 #define SDATA_DATA(S)  ((struct sdata *) (S))->data
 
-#endif /* not GC_CHECK_STRING_BYTES */
-
 enum { SDATA_DATA_OFFSET = offsetof (struct sdata, data) };
 
 /* Structure describing a block of memory which is sub-allocated to
@@ -1586,31 +1577,20 @@ static char const 
string_overrun_cookie[GC_STRING_OVERRUN_COOKIE_SIZE] =
 # define GC_STRING_OVERRUN_COOKIE_SIZE 0
 #endif
 
-/* Value is the size of an sdata structure large enough to hold NBYTES
-   bytes of string data.  The value returned includes a terminating
-   NUL byte, the size of the sdata structure, and padding.  */
-
-#ifdef GC_CHECK_STRING_BYTES
-
-#define SDATA_SIZE(NBYTES) FLEXSIZEOF (struct sdata, data, (NBYTES) + 1)
+/* Return the size of an sdata structure large enough to hold N bytes
+   of string data.  This counts the sdata structure, the N bytes, a
+   terminating NUL byte, and alignment padding.  */
 
-#else /* not GC_CHECK_STRING_BYTES */
-
-/* The 'max' reserves space for the nbytes union member even when NBYTES + 1 is
-   less than the size of that member.  The 'max' is not needed when
-   SDATA_DATA_OFFSET is a multiple of FLEXALIGNOF (struct sdata),
-   because then the alignment code reserves enough space.  */
-
-#define SDATA_SIZE(NBYTES)   \
- ((SDATA_DATA_OFFSET \
-   + (SDATA_DATA_OFFSET % FLEXALIGNOF (struct sdata) == 0 \
- ? NBYTES\
- : max (NBYTES, FLEXALIGNOF (struct sdata) - 1)) \
-   + 1   \
-   + FLEXALIGNOF (struct sdata) - 1) \
-  & ~(FLEXALIGNOF (struct sdata) - 1))
-
-#endif /* not GC_CHECK_STRING_BYTES */
+static ptrdiff_t
+sdata_size (ptrdiff_t n)
+{
+  /* Reserve space for the nbytes union member even when N + 1 is less
+ than the size of that member.  */
+  ptrdiff_t unaligned_size = max (SDATA_DATA_OFFSET + n + 1,
+ sizeof (sdata));
+  int sdata_align = max (FLEXALIGNOF (struct sdata), alignof (sdata));
+  return (unaligned_size + sdata_align - 1) & ~(sdata_align - 1);
+}
 
 /* Extra bytes to allocate for each string.  */
 #define GC_STRING_EXTRA GC_STRING_OVERRUN_COOKIE_SIZE
@@ -1664,21 +1644,14 @@ string_bytes (struct Lisp_String *s)
 static void
 check_sblock (struct sblock *b)
 {
-  sdata *from, *end, *from_end;
-
-  e

Bug#940266: z3: FTBFS on hppa - objects in shared libraries need to be compiled with -fPIC

[John David Anglin]

Source: z3
Version: 4.8.4-1
Severity: normal

Dear Maintainer,

On hppa and some other architectures, objects linked in shared libraries
need to be compiled with -fPIC.  See for example the following build log:
https://buildd.debian.org/status/fetch.php?pkg=z3&arch=hppa&ver=4.8.4-1&stamp=1567753798&raw=0

This may not be the best way to fix the problem but adding "export 
CXXFLAGS=-fPIC"
to debian rules results in a successful build of z3 on hppa.  See:
https://buildd.debian.org/status/fetch.php?pkg=z3&arch=hppa&ver=4.8.4-1&stamp=1568491166&raw=0

Regards,
Dave Anglin

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.14.142+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#940264: vpnc-scripts: vpnc-script ignores netmask in VPN-provided routes

[Dmitry Semyonov]

Package: vpnc-scripts
Version: 0.1~git20190117-1
Severity: normal

Dear Maintainer,

When VPN server (Cisco in my case) provides a list of sub-nets that should not
be routed through VPN, the script creates a bunch of corresponding routes but
omits the provided netmasks, thus effectively ignoring the feature. Moreover,
on termination of VPN connection the script is not able to properly remove
created routes because they use invalid netmask (/32 by default).

I traced the problem down to the 'route add' command executed inside
set_exclude_route(). The following hack fixes the issue for me:

cmd="$IPROUTE route add `$IPROUTE route get "$NETWORK/$NETMASKLEN"
| fix_ip_get_output`"
cmd=`echo $cmd | sed -e 's@ via @'"/$NETMASKLEN via @"` # add proper netmask
$cmd

(A similar change is needed for set_ipv6_exclude_route() if you use IPv6.)

I noticed the issue after upgrade from Stretch to Buster. I don't know whether
it worked before, or just was not supported, and whether it could be caused by
a potential change in 'ip route get' output format or not.

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

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

Versions of packages vpnc-scripts depends on:
ii  iproute2   4.20.0-2
ii  net-tools  1.60+git20180626.aebd88e-1

vpnc-scripts recommends no packages.

Versions of packages vpnc-scripts suggests:
pn  dnsmasq 
ii  openssh-server  1:7.9p1-10
pn  resolvconf  

-- no debconf information

-- 
...Bye..Dmitry.

Bug#894663: transition: wxwidgets3.0

[Scott Talbert]

On Sat, 14 Sep 2019, Gunter Königsmann wrote:


 *  Scroll Wheels and Two-Finger scroll are broken in this combination, if
Wayland is used (934386) and


Is two finger scrolling really a high priority issue?  It seems like a 
nice to have rather than a must-have IMHO.



 *  If a horizontal scrollbar is visible all custom controls (e.G.
wxMaxima's worksheet) flicker badly (934386)


On this issue, I'm not convinced that upstream can reproduce it, based on 
the comments in the ticket.  I don't think that I've reproduced it either. 
Since you claim that it doesn't occur with wx 3.1, can you do a bisection 
between wx 3.0 and 3.1 to determine which commit fixed it?  If we can 
figure that out, we can backport the patches.



If wxMaxima otherwise would be dropped from debian I am willing to switch
to a flickering version that uses GTK3. But if I don't occur this risk I
would rather stay at GTK3 until wxGTK 3.2 is released - which will fix this
issue. The wxWidgets maintainers told me that wxGTK 3.2 will be released
"soon". But the same was true a year ago - which I normally would be fine
with: wxGTK 3.1 works fine, the combination of wxGTK 3.0 and GTK2 works
fine, too - and it is wise to release a library when it is ready, not
according to an arbitrary schedule.


Well, there is still time to fix the issues - Bullseye release is still a 
long way off.


And yes, upstream wx claims that wx 3.2 will be "soon" but we have heard 
that for a long time.  :)  So I don't think we can depend on that.


Scott

Bug#909075: Keep libhandy out of testing for now

[Jeremy Bicha]

Can we close this bug now and let libhandy migrate to testing? GNOME
3.34 has several components that use it.

Thanks,
Jeremy Bicha

Bug#939993: mailscripts: adopt printmimestructure from notmuch

[Sean Whitton]

control: tag -1 +pending

Hello,

On Sat 14 Sep 2019 at 03:00PM -04, Daniel Kahn Gillmor wrote:

> works for me.  let me know if you need anything else to finish the
> adoption of email-print-mime-structure into mailscripts!

Just fyi, I had to re-order your commits slightly for the sake of `git
bisect`: you added the installation of the manpage before the commit
which provided the manpage to be installed.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#935443: [PATCH] dgit-maint-bpo(7): Mention occasional need for --new

[Ian Jackson]

Sean Whitton writes ("Bug#935443: [PATCH] dgit-maint-bpo(7): Mention occasional 
need for --new"):
> On Mon 09 Sep 2019 at 01:38PM +01, Ian Jackson wrote:
> > But if you prefer it towards the end then OK.
> 
> I don't think it's that odd to put it before TERMINOLOGY but I do think
> it is bad to put it between TERMINOLOGY and the proceeding section.

OK.  I will put it between INTRODUCTION and TERMINOLOGY.  (And fix the
accidental heading drop.)

> On Mon 09 Sep 2019 at 01:50PM +01, Ian Jackson wrote:
> 
> > Maybe what we need instead is
> >   dgit-push-adoption(7)
> > ?
> 
> What else would go there?

I'm not sure but I get the feeling that people feel it's hard to get
from where they are now to wher we are advertising that it would be
nice for them to be.  I'm too sleepy right now to make much sense on
this point.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#940019: cups: No more options for remote shared printers

[Vincent Danjean]

  Hi,

Le 14/09/2019 à 14:47, Brian Potkin a écrit :
> On Fri 13 Sep 2019 at 22:28:04 +0200, Vincent Danjean wrote:
> 
>> Le 13/09/2019 à 12:58, Brian Potkin a écrit :
> 
> [...]

>> I also checked it by :
>> 1) stopping cups and cups-browsed
>> 2) checking that no reference to a "brother" printer exists in
>>all files under /etc/cups (I removed /etc/cups/printers.O for example)
>> 3) removing all files under /var/cache/cups/
>> 4) restarting cups
>>=> the brother printer was not listed by "lpstat -l -e"
> 
> Would give the output of 'lpoptions -p  -l' (please see below)
> and attach the CUPS generated PPD in /etc/cups/ppd. You have a minute to
> do this before the PPD disappears.

When I stop cups-browsed, and cups, in /etc/cups/ppd, I've only the
ppd of cups-pdf (the virtual printer). (and "lpstat -l -e" reports
nothing)

When I start cups (but not cups-browsed), as soon as cups is initialized,
I get the (avahi found?) printer :

# lpstat -l -e && echo ok && /etc/init.d/cups start && lpstat -l -e && echo ok2 
&& sleep 1 && lpstat -l -e
ok
Starting cups (via systemctl): cups.service.
ok2
Brother_DCP_9020CDW_kooot_2 network none 
ipps://Brother%20DCP-9020CDW%20%40%20kooot-2._ipps._tcp.local/cups
PDF permanent ipp://localhost/printers/PDF cups-pdf:/
#

No additionnal ppd is present in the /etc/cups/ppd (only PDF.ppd)

When I start cups-browsed, I get the 'brother' printer and its (small) PPD
in attachment.

# lpstat -l -e && /etc/init.d/cups-browsed start && lpstat -l -e && echo ok && 
sleep 1 && lpstat -l -e
Brother_DCP_9020CDW_kooot_2 network none 
ipps://Brother%20DCP-9020CDW%20%40%20kooot-2._ipps._tcp.local/cups
PDF permanent ipp://localhost/printers/PDF cups-pdf:/
Starting cups-browsed (via systemctl): cups-browsed.service.
Brother_DCP_9020CDW_kooot_2 network none 
ipps://Brother%20DCP-9020CDW%20%40%20kooot-2._ipps._tcp.local/cups
PDF permanent ipp://localhost/printers/PDF cups-pdf:/
ok
brother permanent ipp://localhost/printers/brother implicitclass://brother/
Brother_DCP_9020CDW_kooot_2 network none 
ipps://Brother%20DCP-9020CDW%20%40%20kooot-2._ipps._tcp.local/cups
PDF permanent ipp://localhost/printers/PDF cups-pdf:/
#

>> 5) restarting cups-browsed
>>=> the brother printer appears as before with "lpstat -l -e", ie:
>>   brother permanent ipp://localhost/printers/brother implicitclass://brother/
>>
 Brother_DCP_9020CDW_kooot_2 network none 
 ipps://Brother%20DCP-9020CDW%20%40%20kooot-2._ipps._tcp.local/cups
>>>
>>> This appears to be a print queue or printer on the network.
>>
>> This one is directly discovered by cups itself (appears at step 4 above)

[...]

> The option order is significant. 'lpoptions -p  -l' is what
> should be used for printer specific options and their current settings.

Oh! Indeed. I did not remark the options were position dependent and that
I was getting the cups-pdf options (my default printer).

# lpoptions -p brother -l
PageSize/Media Size: 128.06x182.03mm 182.03x257.18mm 184.15x260mm 
195.09x269.88mm 197x273mm 209.9x269.88mm 220.13x110.07mm 3x5 *A4 A5 A6 B5 B6 
Env10 EnvC5 EnvChou3 EnvDL EnvMonarch EnvYou4 Executive FanFoldGermanLegal 
ISOB5 Legal Letter Postcard roc16k
cupsPrintQuality/Print Quality: *4
# lpoptions -p Brother_DCP_9020CDW_kooot_2 -l
PageSize/Media Size: 184.15x260mm 195.09x269.88mm 209.9x269.88mm 
220.13x110.07mm 3x5 *A4 A5 A6 B5 B6 Env10 EnvC5 EnvChou3 EnvDL EnvMonarch 
EnvYou4 Executive FanFoldGermanLegal ISOB5 Legal Letter Postcard roc16k
cupsPrintQuality/cupsPrintQuality: *Normal
#




On the laptop of my wife (still with stretch), when I stop cups-browsed
and cups, /etc/cups/ppd is empty.
When I start cups (only), no printer is available and /etc/cups/ppd is
still empty:
# lpstat -a
lpstat: Aucune destination ajoutée.
# ls /etc/cups/ppd/
# lpstat -l -e
lpstat: Error - unknown option "e".
# lpstat -l
#

When I start cups-browsed, the brother printer appears (with its ppd
file)
# /etc/init.d/cups-browsed start
[ ok ] Starting cups-browsed (via systemctl): cups-browsed.service.
root@arwen:/home/vdanjean# lpstat -a
brother accepting requests since sam. 14 sept. 2019 20:46:29 CEST
root@arwen:/home/vdanjean# ls /etc/cups/ppd/
brother.ppd
root@arwen:/home/vdanjean#

I also put it in attachment as brother-stretch.ppd

> What do you get with 'lpoptions -p brother -l'? Would you also post the
> PPD in /etc/cups/ppd that cups-browsed generates.

done (as said above)

>>   The result is that the printing system is unusabled for now.
>> Both at home and at work, I cannot manage important options.
> 
> I believe we can restore the home system to your control.

I also hope. However, I read the links you provide to me. In particular
https://github.com/OpenPrinting/cups-filters/issues/124

So, I tried the command
ipptool -tv  get-printer-attributes-2.0.test
getting the file from 
https://github.com/steveathon/cups/blob/master/test/get-printer-attributes-2.0.test
with URI being ipp://kooot:631/printers/brother

Here is the result I got with the 

Bug#939993: mailscripts: adopt printmimestructure from notmuch

[Daniel Kahn Gillmor]

On Sat 2019-09-14 09:27:02 -0700, Sean Whitton wrote:
> Yup, let's add this to mailscripts.  Thank you for the idea and the
> work!

great!

> Yes.  I'd be happy to merge and upload if you can just add a
> Signed-off-by: to *each* commit (per CONTRIBUTING.md).

ok, done, and force-pushed to an updated branch.

> I'm keen on the idea that git is a distributed system, so I prefer just
> receiving "please consider merging branch foo in repo https://..."; as
> you have done here.

works for me.  let me know if you need anything else to finish the
adoption of email-print-mime-structure into mailscripts!

  --dkg


signature.asc
Description: PGP signature

Bug#936764: jhbuild: Python2 removal in sid/bullseye

[Jeremy Bicha]

On Fri, Aug 30, 2019 at 6:51 AM Andreas Henriksson  wrote:
> I'm not aware why jhbuild is packaged at all. It's a tool to do gnome
> development on top of gnome git head. You generally need to run jhbuild
> git head for things to work properly while doing so. The package has not
> been updated with a new upstream snapshot in years and there are
> virtually no users according to popcon. The package also has no reverse
> dependencies.

I like the Debian package for jhbuild. Unfortunately, keeping it
updated was a lower priority to me than the other parts of GNOME.

Let me see if I can save the package.

Thanks,
Jeremy

Bug#940263: automake: ignores suffix for a new language for objects in a library

[Nicolas Boulenguez]

Package: automake
Version: 1.16.1
Severity: minor

Hello.

The documentation says that, given the proper suffix rule, automake
should build objects from non-C sources and link them. This works for
executables but fails for libraries.

The issue is minor because the documentation only promises
experimental support.

I have tested the following reproducer with automake/1.16.1 and
libtoolize/2.4.6.

Thanks.


#!/bin/sh
set -e

# Some context.
touch AUTHORS ChangeLog NEWS README
cat > main.c <
#include 
int main () {
  printf ("ok\n");
  return 0;
}
EOF
cat > bla.yal < configure.ac < Makefile.am < Makefile.am <

Bug#940262: firefox-esr: Exiting fullscreen video on dual-monitor moves window to main monitor

[Jack Underwood]

Package: firefox-esr
Version: 60.9.0esr-1~deb10u1
Severity: normal

Dear Maintainer,
Using LXDE with a dual-monitor setup on laptop via LXRandR.

Steps to reproduce:
1. I have the External VGA monitor set up as the left monitor, i.e. this monitor
functions as the main monitor with the taskbar.
2. Opening firefox and moving it to the laptop monitor on the right.
3. Play a youtube video and click to open it on fullscreen.
4. Press (esc) to exit full screen.

What happened:
Entering fullscreen the video played on the same monitor as expected but upon
exiting the whole firefox window with all the other tabs that were open has
now shifted to the left external monitor meaning that I have to drag the
window back.

What I expected:
That upon exiting full screen, firefox would stay on the same monitor.

I have tried mpv and mplayer and both return to the original monitor screen as
expected.


-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.6.1
ii  fontconfig2.13.1-2
ii  libasound21.1.8-1
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:8.3.0-6
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u1
ii  libgtk-3-03.24.5-1
ii  libhunspell-1.7-0 1.7.0-2
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.42.1-1+deb10u1
ii  libpango-1.0-01.42.4-7~deb10u1
ii  libsqlite3-0  3.27.2-3
ii  libstartup-notification0  0.12-6
ii  libstdc++68.3.0-6
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages firefox-esr recommends:
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  7:4.1.4-1~deb10u1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-3
ii  libgtk2.0-02.24.32-3
ii  pulseaudio 12.2-4+deb10u1

-- no debconf information

Bug#939889: tmux: removal followed by reinstallation uses /etc/shells entry

[Romain Francoise]

On Fri, Sep 13, 2019 at 8:07 PM Sven Joachim  wrote:
> I think that would be correct.  When filing the bug, I was worried that
> leaving the entry in /etc/shells might fool an unsuspecting user to
> chsh(1) to a non-existent program, but chsh does not actually let you do
> this (unless you are root in which case it only warns, and then
> /etc/shells is ignored anyway).

Good, thanks for checking.

> Since apparently just about everyone currently gets this wrong, I think
> it would be good to discuss it on debian-devel and file bugs against the
> affected packages when a solution is agreed upon.

Would you like to lead the charge here? My time budget for Debian is
quite limited these days...

Thanks.

Bug#940261: postgresql-server-dev-11: depend on clang and llvm-dev rather than clang-7 and llvm-7-dev

[Asher Gordon]

Package: postgresql-server-dev-11
Version: 11.5-2
Severity: normal

Dear Maintainer,

I just upgraded clang which now depends on clang-8 since that is the new
default in Debian. I would like to remove clang-7 (and llvm-7, etc.),
but postgresql-server-dev-11 depends on those packages.

  $ aptitude why clang-7
  i   postgresql-server-dev-all Depends postgresql-server-dev-11
  i A postgresql-server-dev-11  Depends clang-7 

This prevents me from removing clang-7 & co.

Unless postgresql-server-dev-11 depends specifically on version 7 of
clang for a reason, the dependencies should be corrected to clang and
llvm-dev which depend on the defaults in Debian.

Thanks,
Asher

-- 
A witty saying proves nothing, but saying something pointless gets
people's attention.


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 postgresql-server-dev-11 depends on:
ii  clang-71:7.0.1-9+b1
ii  libc6  2.29-1
ii  libpq-dev  11.5-2
ii  llvm-7-dev 1:7.0.1-9+b1
ii  postgresql-common  205

postgresql-server-dev-11 recommends no packages.

postgresql-server-dev-11 suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#894663: transition: wxwidgets3.0

[Gunter Königsmann]

Dear all,

If I interpreted the last mail I got right transition to GTK3 is now
deemed "important".

Unfortunately wxMaxima is only barely usable if the combination wxgtk3.0
and GTK3 is used:

  * Scroll Wheels and Two-Finger scroll are broken in this combination,
if Wayland is used (934386
) and
  * If a horizontal scrollbar is visible all custom controls (e.G.
wxMaxima's worksheet) flicker badly (934386
)

I assume these bugs limit the usability of other applications, as well,
but might not be visible in the first tests after packaging; On the
application's side even with the help of the wxWidgets community I
failed to find a workaround:

  * If you manually enable double-buffering of wxMaxima's worksheet
instead of letting wxWidgets decide if the compositor already
provides double-buffering the worksheet goes completely blank.
  * If you disable double-buffering it flickers.
  * If you let wxWidgets decide if double-buffering is necessary it
flickers, as well.
  * If you try to do a manual double-buffering: You render the visible
part of the worksheet into a bitmap and then blit the bitmap into
the window the bitmap is correctly generated and contains the given
worksheet portion. But blitting the bitmap into the output window
results in a black window.

Hence not having to much debian experience my question is: "How
important is important?"

If wxMaxima otherwise would be dropped from debian I am willing to
switch to a flickering version that uses GTK3. But if I don't occur this
risk I would rather stay at GTK3 until wxGTK 3.2 is released - which
will fix this issue. The wxWidgets maintainers told me that wxGTK 3.2
will be released "soon". But the same was true a year ago - which I
normally would be fine with: wxGTK 3.1 works fine, the combination of
wxGTK 3.0 and GTK2 works fine, too - and it is wise to release a library
when it is ready, not according to an arbitrary schedule.

Kind regards,

   Gunter.

Bug#909048: This isn't a bug

[Santiago Vila]

Oh, I see it now. Nevermind.

The call to "pkgos-dh_auto_test" is already enclosed inside

ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
  pkgos-dh_auto_test [...]
endif

That was exactly the patch I was going to propose...

I guess the things you do in override_dh_install before that are
required for the tests to work, otherwise I suppose you would have
just moved the tests to dh_auto_test.

Thanks.

Bug#909048: This isn't a bug

[Santiago Vila]

On Sat, Sep 14, 2019 at 06:28:13PM +0200, Thomas Goirand wrote:

> I really don't understand why you're thinking this is a bug, or why this
> would be a problem.

Packages should honor "nocheck" in DEB_BUILD_OPTIONS.
This package does not honor "nocheck" in DEB_BUILD_OPTIONS.

Do you really find this explanation not to be enough?

Thanks.

Bug#921695: libvirt-glib 2.0.0

[Simon McVittie]

On Fri, 08 Feb 2019 at 17:05:08 +0100, Guido Günther wrote:
> On Fri, Feb 08, 2019 at 09:58:37AM -0500, Jeremy Bicha wrote:
> > Oh, it doesn't involve a transition?
> > 
> > That looks like strange version numbering from upstream then.
> 
> Yeah, it only seems to have two added symbols.

Thanks for packaging the new libvirt-glib in experimental. Now that the
buster release has happened, is this version ready to go to unstable?

This would enable the GNOME team to release GNOME Boxes 3.34 to unstable.
It seems to work OK in some brief testing with virt-manager 1:2.0.0-3 and
gnome-boxes 3.30.3-2.

Thanks,
smcv

Bug#935084: git-debpush manpage suggestions

[Sean Whitton]

control: tag -1 +patch
control: severity -1 minor

Hello,

On Mon 19 Aug 2019 at 11:45AM +01, Ian Jackson wrote:

> * --quilt=baredebian[+git] etc. should explicitly say that the +git is
>   an alias.  Otherwise the reader wonders what effect it has.
>
> * Under --force, the reader should be warned that use of these options
>   might cause the upload to fail later in the process.

Patches attached.

-- 
Sean Whitton
From 8e36414bf03a5675799347b1d371a2fca86c61bf Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Sat, 14 Sep 2019 09:54:10 -0700
Subject: [PATCH 1/2] git-debpush(1): note that --quilt=baredebian+git is an
 alias

Suggested-by: Ian Jackson 
Signed-off-by: Sean Whitton 
---
 git-debpush.1.pod | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/git-debpush.1.pod b/git-debpush.1.pod
index 5e40e3c8..defc0744 100644
--- a/git-debpush.1.pod
+++ b/git-debpush.1.pod
@@ -109,6 +109,8 @@ You are using git-dpm(1)'s branch format.
 You are using the 'bare debian' branch format, with the upstream
 source in the form of an upstream tag.
 
+B<--quilt=baredebian+git> is an alias for B<--quilt=baredebian>.
+
 =item B<--quilt=linear>
 
 You are using the 'manually maintained applied' branch format or
-- 
2.20.1

From f0f51f60c24e44597cbc5aed18736046c810b1d0 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Sat, 14 Sep 2019 09:54:34 -0700
Subject: [PATCH 2/2] git-debpush(1): warning about use of forcing options

Suggested-by: Ian Jackson 
Signed-off-by: Sean Whitton 
---
 git-debpush.1.pod | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/git-debpush.1.pod b/git-debpush.1.pod
index defc0744..3e065ab6 100644
--- a/git-debpush.1.pod
+++ b/git-debpush.1.pod
@@ -187,7 +187,12 @@ Ignore the results of all checks designed to prevent broken uploads.
 =item B<--force>=I[,I] ...
 
 Override individual checks designed to prevent broken uploads.  May be
-specified more than once.  Valid values for I are:
+specified more than once.
+
+Using B<--force> or B<--force=>I might cause the upload to fail
+at some later point in the process.
+
+Valid values for I are:
 
 =over 4
 
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#940260: nova: [INTL:de] updated German debconf translation

[Helge Kreutzmann]

Package: nova
Version: 2:19.0.2-2
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for nova
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# GERMAN TRANSLATION OF THE NOVA DEBCONF TEMPLATE.
# Copyright (c) 2010 OpenStack LLC.
# This file is distributed under the same license as the NOVA package.
# Copyright of this file Erik Pfannenstein 2012,
# Chris Leick 2013-2018.
# Helge Kreutzmann 2019
msgid ""
msgstr ""
"Project-Id-Version: nova 2:19.0.2-2\n"
"Report-Msgid-Bugs-To: n...@packages.debian.org\n"
"POT-Creation-Date: 2019-08-09 10:06+0200\n"
"PO-Revision-Date: 2019-09-14 18:47+0200\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: multiselect
#. Description
#: ../nova-common.templates.in:2001
msgid "API to activate:"
msgstr "API, die aktiviert werden soll:"

#. Type: multiselect
#. Description
#: ../nova-common.templates.in:2001
msgid ""
"Openstack Nova supports different API services, each of them binding on a "
"different port. Select which one nova-api should support."
msgstr ""
"Openstack Nova unterstützt verschiedene API-Dienste, von denen jeder "
"einzelne an einen anderen Port gebunden ist. Wählen Sie aus, welche von "
"»nova-api« unterstützt werden sollen."

#. Type: multiselect
#. Description
#: ../nova-common.templates.in:2001
msgid ""
"If it is a compute node that you are setting-up, then you only need to run "
"the metadata API server. If you run Cinder, then you don't need osapi_volume "
"(you cannot run osapi_volume and cinder-api on the same server: they bind on "
"the same port)."
msgstr ""
"Falls Sie einen Rechenknoten einrichten, müssen Sie nur den Metadaten-API-"
"Server ausführen. Falls Sie Cinder ausführen, benötigen Sie »osapi_volume« "
"nicht (Sie können »osapi_volume« und »cinder-api« nicht auf demselben Server "
"ausführen, sie binden sich an den selben Port)."

#. Type: string
#. Description
#: ../nova-common.templates.in:3001
msgid "Value for my_ip:"
msgstr "Wert für »my_ip«:"

#. Type: string
#. Description
#: ../nova-common.templates.in:3001
msgid "This value will be stored in the my_ip directive of nova.conf."
msgstr "Dieser Wert wird im Eintrag »my_ip« der »nova.conf« gespeichert."

#. Type: string
#. Description
#: ../nova-common.templates.in:4001
msgid "Neutron server URL:"
msgstr "URL des Neutron-Servers:"

#. Type: string
#. Description
#: ../nova-common.templates.in:4001
msgid "Please enter the URL of the Neutron server."
msgstr "Bitte geben Sie die URL des Neutron-Servers ein."

#. Type: string
#. Description
#: ../nova-common.templates.in:5001
msgid "Neutron admin tenant name:"
msgstr "Tenant-Name des Neutron-Administrators:"

#. Type: string
#. Description
#: ../nova-common.templates.in:5001
msgid ""
"Nova needs to be able to communicate with Neutron through Keystone. "
"Therefore Nova needs to know the Neutron admin tenant, username and password."
msgstr ""
"Nova muss mit Neutron über Keystone kommunizieren. Daher muss Nova den "
"Tenant, Benutzernamen und das Passwort des Neutron-Administrators kennen."

#. Type: string
#. Description
#: ../nova-common.templates.in:5001
msgid "Please enter the name of the admin tenant for Neutron."
msgstr "Bitte geben Sie den Namen des Administrator-Tenants für Neutron ein."

#. Type: string
#. Description
#: ../nova-common.templates.in:6001
msgid "Neutron administrator username:"
msgstr "Benutzername des Neutron-Administrators:"

#. Type: string
#. Description
#: ../nova-common.templates.in:6001
msgid "Please enter the username of the Neutron administrator."
msgstr "Bitte geben Sie den Benutzernamen des Neutron-Administrators ein."

#. Type: password
#. Description
#: ../nova-common.templates.in:7001
msgid "Neutron administrator password:"
msgstr "Passwort des Neutron-Administrators:"

#. Type: password
#. Description
#: ../nova-common.templates.in:7001
msgid "Please enter the password of the Neutron administrator."
msgstr "Bitte geben Sie das Passwort des Neutron-Administrators ein."

#. Type: password
#. Description
#: ../nova-common.templates.in:8001
msgid "Metadata proxy shared secret:"
msgstr "Gemeinsam benutztes Geheimnis des Metadaten-Proxys:"

#. Type: password
#. Description
#: ../nova-common.templates.in:8001
msgid ""
"VM instances using Neutron to handle networking retrieve their metadata "
"through the Neutron metadata agent, which serves as a proxy to the Nova "
"metadata REST API server."
msgstr ""
"VM-Instanzen, die Neutron verwenden, um sich um die Vernetzung zu kümmern, "
"fragen ihre Metadaten über den Neutron-Metadat

Bug#939896: Two-finger touchpad scroll is broken in wxgtk3.0-gtk3 on wayland

[Gunter Königsmann]

> With GTK3 you can probably work around this by forcing X11, e.g.:
>
> env GDK_BACKEND=x11 /usr/bin/app

For many applications that might be a valuable hint. But it causes
hideous flicker, due to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934386.

Kind regards,

   Gunter.

Bug#864502: 'power' group

[Francois Marier]

I was also curious about that 'power' group I've seen in the error log.
According to https://github.com/intel/thermal_daemon/issues/162, it's for a
user space GUI, which doesn't appear to be packaged for Debian.

Francois

-- 
https://fmarier.org/

Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

[Johannes Schauer]

Hi,

Quoting Patrick Schleizer (2019-09-14 08:00:00)
> Awesome! Great to know you're interested in this!
> 
> Good question. I am not sure what I meant with that either. :) Will look
> into it again.
> 
> First thing:
> 
> 
> 
> debootstrap:
> 
> --arch=ARCH
> 
> mmdebstrap:
> 
> --architectures=native[,foreign1,...]
> 
> 
> 
> In other words, grml-debootstrap calls debootstrap with --arch=ARCH.
> This will fail since mmdebstrap does not support --arch=ARCH but wants
> --architectures.
> 
> 

you seem to claim that mmdebstrap does not support the --arch argument. But it
does. It does so by configuring Getopt::Long with auto_abbrev. This means that
a long option like --architectures can also be written with less characters. It
works on my system. It does not on yours? Also from the man page:

 Long options require a double dash and may be abbreviated to uniqueness.

> 
> cowbuilder (or pbuilder?) calls debootstrap with:
> 
> + args='--include=apt --variant=buildd --force-check-gpg buster
> /var/cache/pbuilder/base.cow_amd64 http://HTTPS///deb.debian.org/debian'
> 
> I.e. it is possible to pass an apt repository URI through command line
> (above last argument).
> 
> However, I am translating that in the wrapper to:
> 
> --verbose --architectures=amd64
> --aptopt=/home/user/whonix_binary/aptgetopt.conf
> --include=apt,sudo,devscripts,debhelper,strip-nondeterminism,fakeroot,apt-transport-tor,apt-transport-https,python,eatmydata,aptitude,cowdancer
> buster /var/cache/pbuilder/base.cow_amd64
> /home/user/Whonix/build_sources/debian_stable_current_clearnet.list
> 
> Using a file
> /home/user/Whonix/build_sources/debian_stable_current_clearnet.list
> which contains both, Debian "standard" repository as well as Debian
> security repository.
> 
> This is to make use of mmdebstrap excellent security feature to
> bootstrap from two repositories at once. If the APT version in Debian
> "standard" repository had a vulnerability, then the vulnerable version
> would be installed first before vulnerable APT would be used to upgrade
> in a later step from Debian security repository.
> 
> "Incompatibility" is perhaps a far stretched term. How do we "teach"
> grml-debootstrap, cowbuilder (or pbuilder?) "use both, Debian "standard"
> repository and Debian security repository when using mmdebstrap"?
> 
> It's like "the ecosystem does not take advantage of mmdebstrap" yet.

Okay, but as far as I can see there is nothing that can be done in mmdebstrap
about this, right?

> Not sure anymore why I added:
> --include=apt,sudo,devscripts,debhelper,strip-nondeterminism,fakeroot,apt-transport-tor,apt-transport-https,python,eatmydata,aptitude,cowdancer
> 
> apt-transport-https might be required to support https repositories in
> sources list.

Yes, old apt versions (1.4.9 and earlier) require that package. It is since a
dummy package.

> apt-transport-tor might be required to support tor+https and .onion in
> sources list.

Yes, but mmdebstrap auto-detects tor URLs and adds the package. This behaviour
is also documented in its man page.

> Johannes Schauer:
> > I added a no-op --force-check-gpg option.
> 
> Where is the source code for that? git clones just now.
> 
> git clone http://gitlab.mister-muffin.de/josch/mmdebstrap.git
> 
> But cannot find any mention of "force-check-gpg".

Yes, I didn't push these changes because I am travelling and have only limited
internet access. It has now been pushed.

> Once I have the new version, and can get past the "force-check-gpg" option, I
> will re-try these tools and see how far I get step by step.

I'm looking forward to your review!

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#939993: mailscripts: adopt printmimestructure from notmuch

[Sean Whitton]

control: tag -1 +confirmed

Hello Daniel,

On Tue 10 Sep 2019 at 04:25PM -04, Daniel Kahn Gillmor wrote:

> notmuch has held the `printmimestructure` utility in its source repo for
> a half-dozen years, but we've never shipped it and made it accessible to
> non-developers.
>
> It's pretty handy for debugging e-mail formatting issues and writing
> specifications about e-mail, so i want to contribute it to mailscripts.

Yup, let's add this to mailscripts.  Thank you for the idea and the
work!

> This is on the "email-print-mime-structure" branch at
> https://salsa.debian.org/dkg/mailscripts.git -- maybe you can merge from
> there directly?

Yes.  I'd be happy to merge and upload if you can just add a
Signed-off-by: to *each* commit (per CONTRIBUTING.md).

> See also:
>
>   https://salsa.debian.org/dkg/mailscripts/merge_requests/2
>
> (if you want to put mailscripts into a shared repo on salsa, i'd be
> happy to make merge requests against it directly for things like this,
> let me know what workflow you prefer)

I'm keen on the idea that git is a distributed system, so I prefer just
receiving "please consider merging branch foo in repo https://..."; as
you have done here.

(Or, patches in the BTS or in my personal inbox with git-send-email, but
of course pushing a branch is more appropriate in this case, as you
say.)

(there's an authoritative repo for the contents of mailscripts in the
archive on the dgit-repos server)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#940258: ITP: libbio-db-ncbihelper-perl -- collection of routines useful for queries to NCBI databases.

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-db-ncbihelper-perl -- collection of routines useful for 
queries to NCBI databases.
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-db-ncbihelper-perl
  Version : 1.7.4
  Upstream Author : Copyright: Aaron Mackey , Brian 
Osborne , Jason Stajich , Lincoln 
Stein 
* URL : https://metacpan.org/release/Bio-DB-NCBIHelper
* License : Artistic
  Programming Lang: Perl
  Description : collection of routines useful for queries to NCBI databases.
 Provides a single place to setup some common methods for querying NCBI web
 databases. Bio::DB::NCBIHelper just centralizes the methods for constructing
 a URL for querying NCBI GenBank and NCBI GenPept and the common HTML
 stripping done in postprocess_data().
 .
 The base NCBI query URL used is:
 https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi

Remark: This package is maintained by Michael R. Crusoe at
   https://salsa.debian.org/med-team/libbio-db-ncbihelper-perl

Bug#940259: RM: python-requestbuilder -- ROM; No reverse (build-)depends

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal


Hi,

It looks like python-requestbuilder isn't needed in Debian anymore. Let's
remove it.

Cheers,

Thomas Goirand (zigo)

Bug#939994: mailscripts: use https instead of http

[Sean Whitton]

control: tag -1 confirmed

Hello Daniel,

On Tue 10 Sep 2019 at 04:26PM -04, Daniel Kahn Gillmor wrote:

> It's 2019, please use https!

Can I get a Signed-off-by please?

Please see CONTRIBUTING.md.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#940257: ITP: libbio-tools-run-remoteblast-perl -- Object for remote execution of the NCBI Blast via HTTP

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-tools-run-remoteblast-perl -- Object for remote execution 
of the NCBI Blast via HTTP
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-tools-run-remoteblast-perl
  Version : 1.7.3
  Upstream Author : Copyright: Jason Stajich 
* URL : https://metacpan.org/release/Bio-Tools-Run-RemoteBlast
* License : Artistic
  Programming Lang: Perl
  Description : Object for remote execution of the NCBI Blast via HTTP
 Class for remote execution of the NCBI Blast via HTTP.
 .
 For a description of the many CGI parameters see:
 https://www.ncbi.nlm.nih.gov/BLAST/Doc/urlapi.html
 .
 Various additional options and input formats are available.
 .
 This description was automagically extracted from the module by dh-make-perl.

Remark: This package is maintained by Michael R. Crusoe at
   https://salsa.debian.org/med-team/libbio-tools-run-remoteblast

Bug#940162: [mmdebstrap] Allow overriding of binfmt_misc search

[Johannes Schauer]

Hi,

Quoting Giovanni Mascellani (2019-09-14 08:27:19)
> Il 13/09/19 23:20, Johannes Schauer ha scritto:
> > you write that support for the foreign executable is available in the 
> > container
> > as well. If so, then why does arch-test determine that armhf cannot be
> > executed?
> Maybe "support for foreign executable" was not the right choice of words: it
> still goes through qemu-user, so it is excluded by arch-test called with -n
> (as mmdebstrap does). So execution of foreign executables is available,
> meaning that the kernel is configured through binfmt_misc to reroute them to
> qemu-user, but binfmt_misc is not visible inside the container. arch-test
> detects them in the same way it does outside of the container: with -n it
> only sees native archs, but without it perfectly sees the qemu-user (and
> wine) ones.

ah okay, great! Then I think there is an even better solution. I guess
mmdebstrap should first run "arch-test" (without the -n) to check if support
exists without qemu-user emulation. Only if that does *not* work, should
mmdebstrap run "arch-test -n" and then check /proc for possible problem
reasons.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#940234: debian-policy: add a section about source reproducibility

[Sean Whitton]

Hello,

On Sat 14 Sep 2019 at 02:01PM +00, Holger Levsen wrote:

> On Sat, Sep 14, 2019 at 01:34:49PM +0200, Aurelien Jarno wrote:
>> There is already a section about reproducibility in the debian-policy,
>> but it only mentions the binary packages. It might be a good idea to
>> add a new requirement that repeatedly building the source package in
>> the same environment produces identical .dsc file modulo the GPG
>> signature.
>>
>> I haven't checked how many packages do not fulfill this condition
>
> please do check. last (and only) time we (=r-b) looked, it wasn't
> practical at all. this was around 5 years ago, but I don't remember any
> work done on improving this.

Right.  While we can all agree that it would be nice for source package
builds to reproducible, I think our current source package formats make
it quite a hard problem, so it would be good to have some data before we
spend any time discussing this further.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#940256: ITP: libbio-cluster-perl -- BioPerl cluster modules

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-cluster-perl -- BioPerl cluster modules
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-cluster-perl
  Version : 1.7.3
  Upstream Author : Copyright: Allen Day , Andrew Macgregor 
, David Green, Hilmar Lapp , Jo-Ann 
Stanton, Shawn Hoon , Stan Nelson 
* URL : https://metacpan.org/release/Bio-Cluster
* License : Artistic
  Programming Lang: Perl
  Description : BioPerl cluster modules
 The ClusterIO module works with the ClusterIO format module to read various
 cluster formats such as NCBI UniGene.
 .
 This description was automagically extracted from the module by dh-make-perl.

Remark: This package is maintained by Michael R. Crusoe at
   https://salsa.debian.org/med-team/libbio-cluster-perl

Bug#939119: gnustep-base-runtime: Upgrading to Debian 10 causes gdomap network service to become enabled

[Yavor Doganov]

Control: severity -1 important

On Sun, 01 Sep 2019 14:24:05 +0300,
Alan Jenkins wrote:
> Package: gnustep-base-runtime
> Version: 1.26.0-4
> Severity: grave
> Tags: security
> Justification: user security hole

Many thanks for the report but like Michael Biebl I disagree with the
severity.  This is an unfortunate regression that I'd like to fix in
buster but I don't think it has anything to do with security.  If the
gdomap daemon is vulnerable that is a separate issue which may or may
not be RC.

Starting the daemon has been the default in Debian for many years;
people rightfully complained about it since 99.5% of the users won't
need it.

> "update-rc.d" does not do anything in this case.  The man page says
> 
> > If any files named /etc/rcrunlevel.d/[SK]??name already exist then
> > update-rc.d does nothing.  The program was written this way so that
> > it will never change an existing configuration, which may have been
> > customized by the system administrator.  The program will only  
> > install links if none are present, i.e., if it appears that the 
> > service has never been installed before.
> 
> It is unfortunate that "Policy 9.3.3.1" does not have an explicit
> warning about this potential security problem.

Indeed, thanks for the analysis.  I thought I have followed Policy to
the letter but apparently missed this, and my tests on a sid system
back then were somehow successful which has misleaded me, apparently.
 
Michael Biebl wrote:
> On 01.09.19 13:52, Michael Biebl wrote:
> > I guess gnustep-base-runtime explicitly needs to remove the existing
> > /etc/rc?.d/???gdomap symlinks on upgrades in preinst (possibly guarded
> > by a check which reads the old /etc/default/gdomap and tests if
> > ENABLED=NO) so they can be properly re-created (and disabled) by
> > "update-rc.d defaults-disabled"
> 
> But since /etc/default/gdomap could have been upgraded in the mean time,
> not finding ENABLED=NO in /etc/default/gdomap probably also means that
> you want to remove the /etc/rc?.d/???gdomap symlinks.
> 
> That on the other hand could blow away the changes for a system where
> gdomap was explicity enable via "update-rc.d enable gdomap", so you need
> to handle that case as well (i.e. don't remove the symlinks if there is
> no ENABLED= key but a /etc/rc2.d/S??gdomap symlink)

IOW, something like this snippet:

if [ ! -h /etc/rc2.d/S*gdomap ]; then
find /etc/rc?.d -name \*gdomap -delete
fi

Seems a bit brutal to me but it looks like there is no other way.

Bug#940255: ITP: libbio-db-seqfeature-perl -- Normalized feature for use with Bio::DB::SeqFeature::Store

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-db-seqfeature-perl -- Normalized feature for use with 
Bio::DB::SeqFeature::Store
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-db-seqfeature-perl
  Version : 1.7.3
  Upstream Author : Copyright: Lincoln Stein , Nathan Weeks 

* URL : https://metacpan.org/release/Bio-DB-SeqFeature
* License : Artistic
  Programming Lang: Perl
  Description : Normalized feature for use with Bio::DB::SeqFeature::Store
 The Bio::DB::SeqFeature object is the default SeqFeature class stored in
 Bio::DB::SeqFeature databases. It implements both the
 Bio::DB::SeqFeature::NormalizedFeatureI and
 Bio::DB::SeqFeature::NormalizedTableFeatureI interfaces, which means that its
 subfeatures, if any, are stored in the database in a normalized fashion, and
 that the parent/child hierarchy of features and subfeatures are also stored
 in the database as set of tuples. This provides efficiencies in both storage
 and retrieval speed.
 .
 Typically you will not create Bio::DB::SeqFeature directly, but will ask the
 database to do so on your behalf, as described in Bio::DB::SeqFeature::Store.

Remark: This package is maintained by Michael R. Crusoe at
   https://salsa.debian.org/med-team/libbio-db-seqfeature-perl

Bug#935945: linux-image-5.2.0-2-amd64: does not load signed kernel modules when UEFI Secure Boot is enabled

[Marek Rusinowski]

I have this problem too and opened a duplicate #939773 earlier with some
investigation. Rephrasing my investigation from that duplicate:

In this kernel MOK key gets inserted into the .platform keyring (I see
CONFIG_INTEGRITY_PLATFORM_KEYRING is set to true in the kernel config) which
isn't used for validation of module signatures. I've found this related bug in
Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1701096. There are some
links to upstream patches but I've just checked linux master and
kernel/module_signing.c is still using only .secondary_trusted_keyring and
.builtin_trusted_keyring to verify modules signatures while MOK key is added
to .platform keyring.

Bug#940254: ITP: libbio-db-embl-perl -- Database object interface for EMBL entry retrieval

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-db-embl-perl -- Database object interface for EMBL entry 
retrieval
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-db-embl-perl
  Version : 1.7.4
  Upstream Author : Copyright: Heikki Lehvaslaiho 
* URL : https://metacpan.org/release/Bio-DB-EMBL
* License : Artistic
  Programming Lang: Perl
  Description : Database object interface for EMBL entry retrieval
 Allows the dynamic retrieval of sequence objects Bio::Seq from the EMBL
 database using the dbfetch script at EBI:
 http://www.ebi.ac.uk/Tools/dbfetch/dbfetch.
 .
 In order to make changes transparent we have host type (currently only ebi)
 and location (defaults to ebi) separated out. This allows later additions of
 more servers in different geographical locations.
 .
 The functionality of this module is inherited from Bio::DB::DBFetch which
 implements Bio::DB::WebDBSeqI.

Remark: This package is maintained by Michael R. Crusoe at
   https://salsa.debian.org/med-team/libbio-db-embl-perl

Bug#939541: closed by Sébastien Villemot (Bug#939541: fixed in sbcl 2:1.5.6-2)

[John Paul Adrian Glaubitz]

Hi!

That particular patch was unfortunately incomplete and will need another update.

I hadn’t got around submitting the updated patch yet.

Sorry for that.

Adrian

Bug#940253: ITP: libbio-db-ace-perl -- Database object interface to ACeDB servers

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-db-ace-perl -- Database object interface to ACeDB servers
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-db-ace-perl
  Version : 1.7.3
  Upstream Author : Copyright: Ewan Birney , Lincoln Stein 

* URL : https://metacpan.org/release/Bio-DB-Ace
* License : Artistic
  Programming Lang: Perl
  Description : Database object interface to ACeDB servers
 This provides a standard BioPerl database access to Ace, using Lincoln Steins
 excellent AcePerl module.
 .
 This interface is designed at the moment to work through a
 aceclient/aceserver type mechanism

Remark: This package is maintained by Michael R. Crusoe at
   https://salsa.debian.org/med-team/libbio-db-ace-perl

--help

Bug#939773: Duplicate

[Marek Rusinowski]

Sorry, this is a duplicate of #935945

Bug#940252: ITP: libbio-db-gff-perl -- Storage and retrieval of sequence annotation data

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-db-gff-perl -- Storage and retrieval of sequence 
annotation data
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-db-gff-perl
  Version : 1.7.3
  Upstream Author : Copyright: (c) 2001-2003, 2005, 2008 Cold Spring Harbor 
Laboratory
* URL : https://metacpan.org/release/Bio-DB-GFF
* License : Artistic
  Programming Lang: Perl
  Description : Storage and retrieval of sequence annotation data
 Bio::DB::GFF provides fast indexed access to a sequence annotation database.
 It supports multiple database types (ACeDB, relational), and multiple schemas
 through a system of adaptors and aggregators.
 .
 The following operations are supported by this module:
 .
  - retrieving a segment of sequence based on the ID of a landmark
 .
  - retrieving the DNA from that segment
 .
  - finding all annotations that overlap with the segment
 .
  - finding all annotations that are completely contained within the
 segment
 .
  - retrieving all annotations of a particular type, either within a
 segment, or globally
 .
  - conversion from absolute to relative coordinates and back again,
 using any arbitrary landmark for the relative coordinates
 .
  - using a sequence segment to create new segments based on relative
 offsets

Remark: This package is maintained by Michael R. Crusoe at
   https://salsa.debian.org/med-team/libbio-db-gff-perl

Bug#940251: lists.debian.org: Please add three additional people to debconf-sponsors-team@l.d.o

[Daniel Lange]

Package: lists.debian.org
Severity: wishlist
User: lists.debian@packages.debian.org
Usertags: newlist

Please add

kap...@debian.org
tzaf...@debian.org
kar...@campus.technion.ac.il

to the debconf-sponsors-team mailing list.

I double checked the existing subscribers (thanks for the list Don!)
and they are all still valid to be kept.

Thanks,
Daniel

Bug#939453: sbcl: Please pass host architecture explicitly when calling make.sh in debian/rules

[Sébastien Villemot]

Hi,

Le jeudi 05 septembre 2019 à 09:10 +0200, John Paul Adrian Glaubitz a écrit :

> I was just trying to build sbcl for ppc64 on a powerpc Debian with a ppc64
> chroot and noticed that the build set the compiler architecture to "ppc"
> during build.

It looks like this particular case is somehow expected. See line 362 of
make-config.sh: for a Debian architecture of "ppc64", the SBCL
architecture is explicitly set at "ppc". However, for a Debian
architecture of "ppc64el", then the SBCL architecture is "ppc64".

I don’t really understand why there is such a strange mapping, but at
least your problem does not come from the Debian packaging.

> In order to make sure the proper host architecture is used during build,
> the debian/rules file should pass the proper host architecture during
> build to the make.sh script using the --arch option.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org



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

Bug#940250: RM: python3-polib-doc [all] -- RoQA; NBS; renamed back to python-polib-doc

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Please remove the cruft package python3-polib-doc from sid.

python-polib-doc  | 1.1.0-3   | stable   | all
python-polib-doc  | 1.1.0-5   | testing  | all
python-polib-doc  | 1.1.0-6   | unstable | all
python3-polib-doc | 1.1.0-4   | unstable | all


Andreas

Bug#940249: mailutils: mailx makes the main body Content-Disposition: attachment in some cases where it should not

[Daniel Kahn Gillmor]

Package: mailutils
Version: 1:3.6-1+b1
Severity: normal

Here's what i ran:

$ mailx --mime --attach=tmp/test.gz --return-address=d...@fifthhorseman.net 
--subject 'bananas 3' d...@fifthhorseman.net <
X-Mailer: mail (GNU Mailutils 3.6)
Message-Id: <20190914144516.d35b020...@fifthhorseman.net>
Date: Sat, 14 Sep 2019 10:45:16 -0400 (EDT)
From: Daniel Kahn Gillmor 

--161194241-1568472316=:825
Content-Type: text/plain; charset=UTF-8
Content-Disposition: attachment
Content-ID: <20190914104516.82...@alice.fifthhorseman.net>
Content-Transfer-Encoding: quoted-printable

this is a test

a test maessage with 3 bananas.

--161194241-1568472316=:825
Content-Type: application/octet-stream; name="test.gz"
Content-Disposition: attachment; filename="tmp/test.gz"
Content-Transfer-Encoding: base64
Content-ID: <20190914104516.82...@alice.fifthhorseman.net>

dGVzdCBnemlwIC05Cg==
--161194241-1568472316=:825--


the mime structure is:

 1  └┬╴multipart/mixed 858 bytes
 2   ├─╴text/plain attachment 48 bytes
 3   └─╴application/octet-stream attachment [tmp/test.gz] 20 bytes

It is inappropriate for part 2 to be marked with Content-Disposition:
attachment.

thanks for your work on mailutils!

--dkg

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

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

Versions of packages mailutils depends on:
ii  guile-2.2-libs   2.2.4+1-3+b1
ii  libc62.28-10
ii  libfribidi0  1.0.5-3.1
ii  libgc1c2 1:7.6.4-0.4
ii  libgnutls30  3.6.9-4
ii  libgsasl71.8.1-1
ii  libkyotocabinet16v5  1.2.76-4.2+b1
ii  libldap-2.4-22.4.48+dfsg-1
ii  libmailutils61:3.6-1+b1
ii  libncurses6  6.1+20190803-1
ii  libpam0g 1.3.1-5
ii  libpython2.7 2.7.16-4
ii  libreadline8 8.0-3
ii  libtinfo66.1+20190803-1
ii  libwrap0 7.6.q-28
ii  mailutils-common 1:3.6-1

Versions of packages mailutils recommends:
ii  postfix [mail-transport-agent]  3.4.5-1+b1

Versions of packages mailutils suggests:
pn  mailutils-doc  
pn  mailutils-mh   

-- no debconf information

Bug#940101: gcc-for-build: typo in package description

[Helmut Grohne]

Hi Colin,

On Thu, Sep 12, 2019 at 01:06:15PM +0100, Colin Watson wrote:
> Package: gcc-for-build
> Version: 4.9.2-1~exp3
> Severity: minor
> 
> The package description reads:
> 
>  Ensures that there is a gcc binary that can create executable build
>  architecture binaries. No provitions are made about the build architecture
>  besides being executable.
> 
> "provitions" looks like a typo for "provisions", so at minimum this
> should be corrected.

Thank you for your attention to detail. I concur in principle. That
said, this package is supposed to be taken over, but we're not there
yet. The basic plan is:

1. binutils-for-build done
2. gcc-X.Y-for-build produced by src:gcc-X.Y aka #666743
3. gcc-for-build produced by src:gcc-defaults (no bug yet)

I don't thik it makes much sense to invest further work into this
proof-of-concept package.

> That said, I'm not sure that sentence entirely makes sense even after
> fixing the typo: "provisions" doesn't feel like quite the right word,
> and the structure of the sentence implies that the build architecture is
> executable, which is nonsensical.  I think this sentence could use a
> rewrite by somebody who understands what it was intended to mean.

For one thing, compare with binutils-for-build. If that description also
has issues, it is something we do want to improve, because it is meant
to stay. We'll likely reuse the binutils-for-build wording when working
up the stack.

Then the idea about *-for-build packages is that it somehow (e.g. via
dependencies) ensures that the relevant tools are available without an
architecture prefix. The lack of a prefix means that a user should not
make any assumption as to which architecture these tools work with
except one: Code for that architecture can be executed in the setting
where the *-for-build package is installed.

Does this explanation make it any clearer?

Helmut

Bug#940248: ITP: libbio-db-biofetch-perl -- Database object interface to BioFetch retrieval

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-db-biofetch-perl -- Database object interface to BioFetch 
retrieval
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-db-biofetch-perl
  Version : 1.7.3
  Upstream Author : Copyright: Lincoln Stein 
* URL : https://metacpan.org/release/Bio-DB-BioFetch
* License : Artistic
  Programming Lang: Perl
  Description : Database object interface to BioFetch retrieval
 Bio::DB::BioFetch is a guaranteed best effort sequence entry fetching method.
 It goes to the Web-based dbfetch server located at the EBI
 (http://www.ebi.ac.uk/Tools/dbfetch/dbfetch) to retrieve sequences in the
 EMBL or GenBank sequence repositories.
 .
 Bio::DB::BioFetch implements all the Bio::DB::RandomAccessI interface, plus
 the get_Stream_by_id() and get_Stream_by_acc() methods that are found in the
 Bio::DB::SwissProt interface.

Remark: This package is maintained by Michael R. Crusoe at
   https://salsa.debian.org/med-team/libbio-db-biofetch-perl

Bug#930997: cmake: reprotest's 'setarch linux32 dh_auto_configure' on amd64 results in CMAKE_SYSTEM_PROCESSOR = i386

[Helmut Grohne]

Hi Niels,

On Sat, Sep 14, 2019 at 06:08:00AM +, Niels Thykier wrote:
> Is there any update on this?  At the moment, this bug is not actionable
> and sprayed over three packages.

No. I don't think there are any news here. I had hoped that my previous
mails would have made my position clear. Let me try to be more explicit:
I think that running native amd64 builds in linux32 is broken and that
any tool doing so (e.g. reprotest) is buggy.

Having debhelper pass CMAKE_SYSTEM_PROCESSOR is a nice idea, but doing
so will break a fair number of packages in subtle ways. Therefore I
recommend not doing that (other than for cross compilation).

This is basically repeating what I already said. If you concur, the
logical next step is reassigning to reprotest.

Helmut

Bug#940247: openshot-qt: segmentation fault on startup

[David Bremner]

Package: openshot-qt
Version: 2.4.3+dfsg1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The following is the console output when attempting to start
openshot-qt.  No windows appear or anything else interesting on the
display. It seems to segfault in the QtCore extension

I'm running i3, no desktop env, if that matters.

  launch:INFO 
  launch:INFOOpenShot (version 2.4.3)
  launch:INFO 
 app:INFO openshot-qt version: 2.4.3
 app:INFO libopenshot version: 0.2.2
 app:INFO platform: Linux-5.2.0-2-amd64-x86_64-with-debian-bullseye-sid
 app:INFO processor: 
 app:INFO machine: x86_64
 app:INFO python version: 3.7.4+
 app:INFO qt5 version: 5.11.3
 app:INFO pyqt5 version: 5.12.3
language:INFO Qt Detected Languages: ['en-CA', 'en']
language:INFO LANG Environment Variable: en_CA.UTF-8
language:INFO LOCALE Environment Variable: 
language:INFO OpenShot Preference Language: Default
project_data:INFO Setting default profile to HD 720p 30 fps
 app:INFO Setting font to Cantarell
logger_libopenshot:INFO Connecting to libopenshot with debug port: 5556
 app:INFO Setting custom dark theme
qt.svg: link SVGID_18_-5 hasn't been detected!
qt.svg: link SVGID_18_-5 hasn't been detected!
qt.svg: link SVGID_22_-5 hasn't been detected!
qt.svg: link SVGID_24_-2 hasn't been detected!
qt.svg: link SVGID_24_-2 hasn't been detected!
QMainWindow::addDockWidget: invalid 'area' argument
 ui_util:INFO Initializing UI for MainWindow
 ui_util:INFO Binding event MainWindow:actionNew_trigger
 ui_util:WARNING Icon theme document-new not found. Will use backup icon.
 ui_util:INFO Binding event MainWindow:actionOpen_trigger
 ui_util:WARNING Icon theme document-open not found. Will use backup icon.
 ui_util:INFO Binding event MainWindow:actionSave_trigger
 ui_util:WARNING Icon theme document-save not found. Will use backup icon.
 ui_util:INFO Binding event MainWindow:actionUndo_trigger
 ui_util:WARNING Icon theme edit-undo not found. Will use backup icon.
 ui_util:INFO Binding event MainWindow:actionSaveAs_trigger
 ui_util:WARNING Icon theme document-save-as not found. Will use backup 
icon.
 ui_util:INFO Binding event MainWindow:actionImportFiles_trigger
 ui_util:WARNING Icon theme list-add not found. Will use backup icon.
 ui_util:INFO Binding event MainWindow:actionImportImageSequence_trigger
 ui_util:WARNING Icon theme list-add not found. Will use backup icon.
 ui_util:WARNING Icon theme list-add not found. Will use backup icon.
 ui_util:INFO Binding event MainWindow:actionRedo_trigger
 ui_util:WARNING Icon theme edit-redo not found. Will use backup icon.
 ui_util:INFO Binding event MainWindow:actionRemoveClip_trigger
 ui_util:WARNING Icon theme list-remove not found. Will use backup icon.
 ui_util:INFO Binding event MainWindow:actionRemoveTransition_trigger
 ui_util:WARNING Icon theme list-remove not found. Will use backup icon.
 ui_util:INFO Binding event MainWindow:actionExportVideo_trigger
 ui_util:WARNING Icon theme media-record not found. Will use backup icon.
 ui_util:INFO Binding event MainWindow:actionUploadVideo_trigger
 ui_util:WARNING Icon theme folder-remote not found. Will use backup icon.
 ui_util:WARNING Icon theme system-shutdown not found. Will use backup icon.
 ui_util:INFO Binding event MainWindow:actionAddTrack_trigger
 ui_util:WARNING Icon theme list-add not found. Will use backup icon.
 ui_util:INFO Binding event MainWindow:actionPreferences_trigger
 ui_util:WARNING Icon theme document-properties not found. Will use backup 
icon.
 ui_util:INFO Binding event MainWindow:actionPlay_trigger
 ui_util:WARNING Icon theme media-playback-start not found. Will use backup 
icon.
 ui_util:INFO Binding event MainWindow:actionJumpStart_trigger
 ui_util:WARNING Icon theme media-skip-backward not found. Will use backup 
icon.
 ui_util:INFO Binding event MainWindow:actionRewind_trigger
 ui_util:WARNING Icon theme media-seek-backward not found. Will use backup 
icon.
 ui_util:INFO Binding event MainWindow:actionFastForward_trigger
 ui_util:WARNING Icon theme media-seek-forward not found. Will use backup 
icon.
 ui_util:INFO Binding event MainWindow:actionJumpEnd_trigger
 ui_util:WARNING Icon theme media-skip-forward not found. Will use backup 
icon.
 ui_util:INFO Binding event MainWindow:actionSaveFrame_trigger
 ui_util:WARNING Icon theme camera-photo-symbolic not found. Will use 
backup icon.
 ui_util:INFO Binding event MainWindow:actionArrowTool_trigger
 ui_util:INFO Binding event MainWindow:actionRazorTool_trigger
 ui_util:INFO Binding event MainWindow:actionSnappingTool_trigger
 ui_util:INFO Binding event MainWindow:actionAdd

Bug#940234: debian-policy: add a section about source reproducibility

[David Bremner]

Aurelien Jarno  writes:

> Package: debian-policy
> Version: 4.4.0.1
> Severity: wishlist
>
> There is already a section about reproducibility in the debian-policy,
> but it only mentions the binary packages. It might be a good idea to
> add a new requirement that repeatedly building the source package in
> the same environment produces identical .dsc file modulo the GPG
> signature.
>
> I haven't checked how many packages do not fulfill this condition, but
> there are for sure packages where the Build-Depends: entry in the dsc
> file does not match the debian/control file, as they have been added
> manually after the package build. TTBOMK there is nothing preventing
> that in the debian policy.

I'm not sure if this is exactly the same issue, but I've recently been
thinking about (and messing up) source package reproducibility from git
repos. It is probably to early for policy language to be talking about
git, but it might be worth keeping in mind the fact that there are
various tools producing source packages, sometimes in non-obvious ways.

d

Bug#940245: buster-pu: package libdatetime-timezone-perl/1:2.23-1+2019c

[gregor herrmann]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded a new version of libdatetime-timezone-perl to buster,
incorporating the changes of the Olson DB 2019c as quilt patch.

Changes are (taken from the tzdata package):
- Fiji's next DST transitions will be 2019-11-10 and 2020-01-12
  instead of 2019-11-03 and 2020-01-19.
- Norfolk Island will observe Australian-style DST starting in
  spring 2019.  The first transition is on 2019-10-06.

Manually stripped down debdiff attached.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl189nBfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qga74A/+Pa5TSWvgYmlI/IPQrGnW+tfV05kttX3XqSkck+SWbT+SNLg2MWedN8nk
6KTPGjAfTtTpX3hIXzvKYJY5MIuXVXghKPbS2wZMdCF4avVu/Jr9dF9hmx6uHYeD
VbM3mKSzC090LI47ZVUvW3buyPmCR49U8bRxf+ewiVY9qjIaPYxQ/UjvkNPQrR7O
ppNJ88DTcD0iUvM3O3AX241eWiMing2EFQc4H4r9jTHWlLIbCPSRMsEC5pLqu2xW
dcB6T44EEUDwzi9mawgV0UKHUeCuL3v2FeCnFNUtckKlBPhgH+R9yjuk0AYxWkaT
0+Y5Hc0dp1h1kHn8fCoEyqXIrlwHBJiuCqw2+dIHVeoCCnSGhj9UYmOZyRZrGHax
A9Nmc3lM0hyPaM70rnfOo8kepP6fu6UNQUdjTqOjgd9p1FcaTj3J+DBBpVziW2EC
Nl5NpgqoBvlqobMeLf5EwCBQgSGSammjrb9P/N4hnSJpidPX5Mugj4Gz8ycCTv0U
6MWEoo7wASt2zWOfHr9764Zzm8INB4wsBaYx6DU52Y2rjgJykVVmBRO3zTYLVki4
jXQSVJ7OR2q5tqSa2KwcSBPG/VQJWMwuPxQCW56Os35FiQ/RWs0zsJcDI3TnS01C
OwqawU8fAw4gzsV/wzpxTyldhL4vRqLnT4ZRB/U3qZL1dxsTff4=
=SvbM
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.23/debian/changelog 
libdatetime-timezone-perl-2.23/debian/changelog
--- libdatetime-timezone-perl-2.23/debian/changelog 2019-07-09 
17:51:51.0 +0200
+++ libdatetime-timezone-perl-2.23/debian/changelog 2019-09-14 
15:57:22.0 +0200
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.23-1+2019c) buster; urgency=medium
+
+  * Update to Olson database version 2019c.
+This update contains contemporary changes for Fiji and Norfolk Island.
+
+ -- gregor herrmann   Sat, 14 Sep 2019 15:57:22 +0200
+
 libdatetime-timezone-perl (1:2.23-1+2019b) buster; urgency=medium
 
   * Update to Olson database version 2019b.
diff -Nru libdatetime-timezone-perl-2.23/debian/patches/olson-2019c 
libdatetime-timezone-perl-2.23/debian/patches/olson-2019c
--- libdatetime-timezone-perl-2.23/debian/patches/olson-2019c   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.23/debian/patches/olson-2019c   2019-09-14 
15:57:22.0 +0200
@@ -0,0 +1,11461 @@
+Description: Update to Olson DB 2019c
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2019-09-14
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2019b
++# Generated from debian/tzdata/africa.  Olson data version 2019c
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2019b'}
++sub olson_version {'2019c'}
+ 
+ sub has_dst_changes {0}
+ 
+--- a/lib/DateTime/TimeZone/Pacific/Fiji.pm
 b/lib/DateTime/TimeZone/Pacific/Fiji.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/australasia.  Olson data version 2019b
++# Generated from debian/tzdata/australasia.  Olson data version 2019c
+ #
+ # Do not edit this file directly.
+ #
+@@ -250,35 +250,35 @@
+ ],
+ [
+ 63682984800, #utc_start 2019-01-12 14:00:00 (Sat)
+-63708386400, #  utc_end 2019-11-02 14:00:00 (Sat)
++63708991200, #  utc_end 2019-11-09 14:00:00 (Sat)
+ 63683028000, #  local_start 2019-01-13 02:00:00 (Sun)
+-63708429600, #local_end 2019-11-03 02:00:00 (Sun)
++63709034400, #local_end 2019-11-10 02:00:00 (Sun)
+ 43200,
+ 0,
+ '+12',
+ ],
+ [
+-63708386400, #utc_start 2019-11-02 14:00:00 (Sat)
+-63715039200, #  utc_end 2020-01-18 14:00:00 (Sat)
+-63708433200, #  local_start 2019-11-03 03:00:00 (Sun)
+-63715086000, #local_end 2020-01-19 03:00:00 (Sun)
++63708991200, #utc_start 2019-11-09 14:00:00 (Sat)
++63714434400, #  utc_end 2020-01-11 14:00:00 (Sat)
++63709038000, #  local_start 2019-11-10 03:00:00 (Sun)
++63714481200, #local_end 2020-01-12 03:00:00 (Sun)
+ 46800,
+ 1,
+ '+13',
+ ],
+ [
+-63715039200, #utc_start 2020-01-18 14:00:00 (Sat)
+-63739836000, #  utc_end 2020-10-31 14:00:00 (Sat)
+-63715082400, #  local_start 2020-01-19 02:00:00 (Sun)
+-63739879200, #local_end 2020-11-01 02:00:00 (Sun)
++63714434400, #utc_start 2020-01-11 14:00:00 (Sat)
++63740440800, #  utc_end 2020-11-07 14:00:00 (Sat)
++63714477600, #  local_start 2020-01-12 02:00:00 (Sun)
++63740484000, #local_end 2020-11-08 02:00:00 (Sun)
+ 43200,
+ 0,
+ '+12',
+ ],
+ [
+-6373983600

Bug#940246: stretch-pu: package libdatetime-timezone-perl/1:2.09-1+2019c

[gregor herrmann]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded a new version of libdatetime-timezone-perl to stretch,
incorporating the changes of the Olson DB 2019c as quilt patch.

Changes are (taken from the tzdata package):
- Fiji's next DST transitions will be 2019-11-10 and 2020-01-12
  instead of 2019-11-03 and 2020-01-19.
- Norfolk Island will observe Australian-style DST starting in
  spring 2019.  The first transition is on 2019-10-06.

Manually stripped down debdiff attached.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl189npfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYH/w//YsudREdIKafBHQNO99cdkvxeUtrHOWQifXHLu58G4HhS8el6YIHygd6z
n7qbsHn429uvF6wXupSQUKO0+v9FuBzflda49HuJYsJ60kpIZCSRzyVaX+2ucDli
3JpKQB444T+vaqSXSm4Rf3u9t6PHaYUY6s4cW9ET34Pq+sDk/PA5omlKWGmMfj+l
oypdvHYeDE5N80e2FoEf2bGbv9+wEL9D3wpE0HqE8Ki+P22mXmLr+FMIMTiosFSe
p5LM7B0wdjQ0tQTCeFBHKfs+G2gcnoXQFp0KuMYF2XYlBrvQp1poU5k5HQvvB7dW
OMpybbKKlE3nl0F6UZvva+W+v6ApP9DW0LdVKVU76zJFy22IMO22UP6aEoAfxTtC
pVO2AShF2qx+9+BveDF6jHjmlgd8oXR0Ki+kdmk6sbX/Qqw3uyzKWy44b6JWi+iv
MX1s+cdKc3wUH6Tg1sGqGvo3rvWqsujhnzJ1C44wGD79PDmn+5oQLotG8F0VYaZN
qcXT6w6OOD8A/C0f8meD1x4iA50obLYEGLTdOA1ura3dm29IC6I3YCB/v5ovKXOz
ZucLLCDZV/vXp24TVIw/qBsxe4s6LqXyCpGo3v92rWWOBs0djCPgxL0Rtcer3Vnh
EoNl7Yfd7Oasqzm9RdshooTiAlLVlFMoegB0HE1LsOVjePO2ijg=
=RJmh
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.09/debian/changelog 
libdatetime-timezone-perl-2.09/debian/changelog
--- libdatetime-timezone-perl-2.09/debian/changelog 2019-07-09 
17:45:44.0 +0200
+++ libdatetime-timezone-perl-2.09/debian/changelog 2019-09-14 
16:09:21.0 +0200
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.09-1+2019c) stretch; urgency=medium
+
+  * Update to Olson database version 2019c.
+This update contains contemporary changes for Fiji and Norfolk Island.
+
+ -- gregor herrmann   Sat, 14 Sep 2019 16:09:21 +0200
+
 libdatetime-timezone-perl (1:2.09-1+2019b) stretch; urgency=medium
 
   * Update to Olson database version 2019b.
diff -Nru libdatetime-timezone-perl-2.09/debian/patches/olson-2019c 
libdatetime-timezone-perl-2.09/debian/patches/olson-2019c
--- libdatetime-timezone-perl-2.09/debian/patches/olson-2019c   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.09/debian/patches/olson-2019c   2019-09-14 
16:09:21.0 +0200
@@ -0,0 +1,1 @@
+Description: Update to Olson DB 2019c
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2019-09-14
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2019b
++# Generated from debian/tzdata/africa.  Olson data version 2019c
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2019b'}
++sub olson_version {'2019c'}
+ 
+ sub has_dst_changes {0}
+ 
+--- a/lib/DateTime/TimeZone/Pacific/Fiji.pm
 b/lib/DateTime/TimeZone/Pacific/Fiji.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/australasia.  Olson data version 2019b
++# Generated from debian/tzdata/australasia.  Olson data version 2019c
+ #
+ # Do not edit this file directly.
+ #
+@@ -250,35 +250,35 @@
+ ],
+ [
+ 63682984800, #utc_start 2019-01-12 14:00:00 (Sat)
+-63708386400, #  utc_end 2019-11-02 14:00:00 (Sat)
++63708991200, #  utc_end 2019-11-09 14:00:00 (Sat)
+ 63683028000, #  local_start 2019-01-13 02:00:00 (Sun)
+-63708429600, #local_end 2019-11-03 02:00:00 (Sun)
++63709034400, #local_end 2019-11-10 02:00:00 (Sun)
+ 43200,
+ 0,
+ '+12',
+ ],
+ [
+-63708386400, #utc_start 2019-11-02 14:00:00 (Sat)
+-63715039200, #  utc_end 2020-01-18 14:00:00 (Sat)
+-63708433200, #  local_start 2019-11-03 03:00:00 (Sun)
+-63715086000, #local_end 2020-01-19 03:00:00 (Sun)
++63708991200, #utc_start 2019-11-09 14:00:00 (Sat)
++63714434400, #  utc_end 2020-01-11 14:00:00 (Sat)
++63709038000, #  local_start 2019-11-10 03:00:00 (Sun)
++63714481200, #local_end 2020-01-12 03:00:00 (Sun)
+ 46800,
+ 1,
+ '+13',
+ ],
+ [
+-63715039200, #utc_start 2020-01-18 14:00:00 (Sat)
+-63739836000, #  utc_end 2020-10-31 14:00:00 (Sat)
+-63715082400, #  local_start 2020-01-19 02:00:00 (Sun)
+-63739879200, #local_end 2020-11-01 02:00:00 (Sun)
++63714434400, #utc_start 2020-01-11 14:00:00 (Sat)
++63740440800, #  utc_end 2020-11-07 14:00:00 (Sat)
++63714477600, #  local_start 2020-01-12 02:00:00 (Sun)
++63740484000, #local_end 2020-11-08 02:00:00 (Sun)
+ 43200,
+ 0,
+ '+12',
+ ],
+ [
+-637398

Bug#940234: debian-policy: add a section about source reproducibility

[Holger Levsen]

On Sat, Sep 14, 2019 at 01:34:49PM +0200, Aurelien Jarno wrote:
> There is already a section about reproducibility in the debian-policy,
> but it only mentions the binary packages. It might be a good idea to
> add a new requirement that repeatedly building the source package in
> the same environment produces identical .dsc file modulo the GPG
> signature.
> 
> I haven't checked how many packages do not fulfill this condition

please do check. last (and only) time we (=r-b) looked, it wasn't
practical at all. this was around 5 years ago, but I don't remember any
work done on improving this.


-- 
cheers,
Holger

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


signature.asc
Description: PGP signature

Bug#940244: ITP: libbio-alignio-stockholm-perl -- stockholm sequence input/output stream

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-alignio-stockholm-perl -- stockholm sequence input/output 
stream
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-alignio-stockholm-perl
  Version : 1.7.3
  Upstream Author : Copyright: Peter Schattner , Chris 
Fields 
* URL : https://metacpan.org/release/Bio-AlignIO-stockholm
* License : Artistic
  Programming Lang: Perl
  Description : stockholm sequence input/output stream
 Indexes Stockholm format alignments such as those from Pfam and Rfam. Returns
 raw stream data using the ID or a Bio::SimpleAlign object (via Bio::AlignIO).
 .
 Bio::AlignIO::stockholm also allows for ID parsing using a callback:

Remark: This package is maintained by Michael R. Crusoe at
   https://salsa.debian.org/med-team/libbio-alignio-stockholm-perl

Bug#939866: [debian-mysql] Bug#939866: Bug#939866: mariadb-server-10.1: replication hangs in state "Slave_IO_Running: Preparing" after upgrade from 10.1.38 to 10.1.41

[Adam D. Barratt]

On Fri, 2019-09-13 at 21:10 +0300, Otto Kekäläinen wrote:
> To clarify, 10.3.18 has been uploaded to Debian unstable. Issue is
> still open for Buster and Stretch.

Is there a likely ETA for when this might be resolvable?

If you could prepare (preferably targeted) updates via the usual p-u
path then we can look at releasing them via stable-updates so that
affected users don't have to wait for the next point release.

Regards,

Adam

Bug#940243: RFS: eqonomize 1.4.2-1 -- personal accounting software for the small household economy

[Fabian Wolff]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a QA upload of the eqonomize package.

The only change I made has been the introduction of a new upstream version.

The package can be found on Mentors, and my changes are also in the Git 
repository on Salsa:

  https://mentors.debian.net/package/eqonomize
  https://salsa.debian.org/debian/eqonomize

Thanks for your help!

Best regards,
Fabian

Bug#940242: RFP: python-timecode -- Python Module for SMPTE Time Code Manipulation

[Carlo Stemberger]

Package: wnpp
Severity: wishlist

* Package name: python-timecode
  Version : 1.2.1
  Upstream Author : Erkan Ozgur Yilmaz 
* URL : https://pypi.org/project/timecode/
* License : MIT
  Programming Lang: Python
  Description : Python Module for SMPTE Time Code Manipulation

Python Module for manipulating SMPTE timecode. Supports 23.976, 23.98,
24, 25, 29.97, 30, 50, 59.94, 60 frame rates and milliseconds (1000
fps).

Simple math operations like, addition, subtraction, multiplication or
division with an integer value or with a timecode is possible. Math
operations between timecodes with different frame rates are supported.

Bug#939598: [PATCH] Conflict with u-boot-tools (Closes: #939598)

[Bastian Germann]

Signed-off-by: Bastian Germann 
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 27015bb..87db86a 100644
--- a/debian/control
+++ b/debian/control
@@ -42,6 +42,7 @@ Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, libubootenv0.1 (= 
${binary:Version})
 Multi-Arch: foreign
+Conflicts: u-boot-tools
 Description: Library to access U-Boot environment - tool
  libubootenv is a library that provides a hardware independent way to access
  to U-Boot environment. U-Boot has its default environment compiled
-- 
2.23.0