Bug#891450: custodia FTBFS: TypeError: stat: path should be string, bytes, os.PathLike or integer, not NoneType

[Adrian Bunk]

On Fri, Nov 23, 2018 at 08:34:45AM +0200, Timo Aaltonen wrote:
> On 21.4.2018 23.27, Ben Finney wrote:
> > On 25-Feb-2018, Adrian Bunk wrote:
> >> Source: custodia
> > 
> > I Think this is the correct assignment for this bug report.
> > 
> > See the command-line used to invoke the coverage module:
> > 
> >> ERROR: InvocationError: '/build/1st/custodia-0.5.0/.tox/py36/bin/python -m 
> >> coverage run --parallel -m pytest --capture=no --strict --skip-servertests'
> > 
> > Note that the command line calls ‘[…]python -m coverage run’ but
> > specifies no tests to run. That's why the ‘coverage’ module eventually
> > complains that the path that was specified is None.
> > 
> > Somehow, the ‘custodia’ test suite is invoking ‘coverage’ in such a
> > way that no path is specified.
> 
> Well, it seems to build fine on my sbuild these days, so whatever caused
> the error doesn't seem to be true anymore.

It seems to fail with the common encoding error now in C locale:

https://buildd.debian.org/status/package.php?p=custodia
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/custodia.html

In debian/rules add:
export LC_ALL=C.UTF-8

> t

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#914397: nftables: after Stretch->Buster upgrade, named set needs "auto-merge"

[Gert]

After analyzing my config, I can now give a full example.
The subnet came from a geoblock list, the separate host came from an 
abusers list.

That causes the conflict in Buster (which can be fixed with auto-merge).
And I tried it again on a different Stretch machine, and it indeed works 
fine.
(Sorry, I could also have done all this for the first report, I now 
realize).


#!/usr/sbin/nft -f
table ip filter {
set blacklist {
type ipv4_addr
flags interval
elements = {
192.0.2.0/24,
192.0.2.1
}
# auto-merge # uncomment this to fix in Buster
}
}

Bug#914409: usrmerge: question: On error, is it ok to remove a package?

[Arnaud Rebillout]

Package: usrmerge
Version: 19
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I just installed usrmerge on my laptop, running debian unstable. I run
into the well-known iptables/ebtables error.

  Setting up usrmerge (19) ...
  FATAL ERROR:
  Both /sbin/ebtables and /usr/sbin/ebtables exist.

So what I did is that I removed ebtables:

  sudo apt-get purge ebtables

Which solved the problem.

Now I have a question/suggestion regarding the output of usrmerge, which
told me in this case:

  You can try correcting the errors reported and running again
  /usr/lib/convert-usrmerge until it will complete without errors.
  Do not install or update other Debian packages until the program
  has been run successfully.

usrmerge tells me not to install or update, however it doesn't say
anything about removing a package. So I just assumed it was OK to remove
ebtables, and apparently it worked.

If removing a package is supported in this case, what do you think about
explicitly mentioning it in the message? Adding a simple sentence like
"Removing a package is safe though", or something similar.

My guess is that in situation where two packages conflict, the obvious
solution is to remove one of those. But because the message above tells
me not to install or update anything, I'm left in doubt regarding removing
a package. Maybe clarifying that would be helpful.

Thanks (and thanks for all the work on usrmerge),

  Arnaud

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

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

Versions of packages usrmerge depends on:
ii  debconf [debconf-2.0]   1.5.69
ii  libfile-find-rule-perl  0.34-1

usrmerge recommends no packages.

usrmerge suggests no packages.

- -- debconf information:
* usrmerge/autoconvert: true
  usrmerge/title:

-BEGIN PGP SIGNATURE-

iQJTBAEBCgA9FiEE0Kl7ndbut+9n4bYs5yXoeRRgAhYFAlv3saofHGFybmF1ZC5y
ZWJpbGxvdXRAY29sbGFib3JhLmNvbQAKCRDnJeh5FGACFia2EACaTqzvnMGtcRIY
7EiKuh9QUdcknsA4cPuqflwyaWNoRiAr5h+ETp74oyocQLFEyMLJ+1qefDfPkKwa
IsCn/rnHc4/L3uDL1fPSH2uINQ5AQBKwOxuZM9JukYNPnjqx9fmyuJS55LdcElpC
QaJP3yZxHde+u5Fa6mE/6mfFo3NnoelV5idxrzpHc0Ore2xFBihqFBa+Mci/hKwH
q0RT5GRqhTt2tQRspi3iLdlk5w7ZT9G06YbP0ilxPlqYaUqufecT+zmc982bjkW8
qhunDUM46zq2EsYG2C3Oq+AmC6cY6GCsYyBJR5ktTWbayrB8urfAHwCfOi3mWF3N
ewqlL3Uo9kiVcExsCQLLCiHau7OR/dqXCMHjwfni1ekt9VN2hSS3w/0tNvSCxSha
MLAXULbEzaFV3WsEcwyPDaLpaskTs6UkOTfGqv7tl8ICKh/BDJ9v6enmmZOGGhzl
qT7rS3lbcN8MX/O4hlPzAHsjAzMp/H3ejGPUGUgGAk6XBBeZRu3b2yl6wRz9Tspe
RA3kfsl6xqAijab6yelpc7UTaXAKkT782d9+tEfVlWGuzY/u9mMc/LCh0iXC0mU0
k/DOMC/Sr9UyLi0K8D00I1Hk0oLtgPGPYO/XD5JQ2pPX3ycwVn4TUFsRcFxpmFmU
JkUUhpQ9F/GQUUYJt3ue6bE/07Apdg==
=GyqF
-END PGP SIGNATURE-

Bug#914408: [20181123] mirror.cs.uwm.edu: out of date, syncscript

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problems

Hi!

It seems http://mirror.cs.uwm.edu/debian/
is out of date
https://mirror-master.debian.org/status/mirror-info/mirror.cs.uwm.edu.html

Please investigate.

o If you sync off kernel.org, you might want to pick a different site
  (do not use ftp.*.debian.org names, only http is guaranteed at
   those names and they do switch around.)
  https://mirror-master.debian.org/status/mirror-hierarchy.html might help
  you pick.

o Also, please switch to using a modern ftpsync to mirroring.
  The trace file at
  http://mirror.cs.uwm.edu/debian/project/trace/mirror.cs.uwm.edu
  does not contain much information.

  Please use our ftpsync script to mirror Debian.

  Using a modern ftpsync ensures updates are done in the correct order
  so apt clients don't get confused.   In particular, it processes
  translations, contents, and more files that have been added to the
  archive in recent years in the correct stage.  It also should produce
  trace files that contain more information that is useful for us and helps
  downstream mirrors sync better.

  http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#914343: usrmerge did not install by default - some libs disturb

[Marco d'Itri]

On Nov 22, "Hans-J. Ullrich"  wrote:

> /sbin/ebtables*
> /usr/sbin/ebtables*
This one probably was #914074.

> /lib/libntrack-qt4.so.1
> /usr/lib/libntrack-qt4.so.1
This one is more interesting: where these symlinks? If so, which files 
where they were pointing to?
I have checked the current libntrack-qt4-1 and libntrack-qt4-dev and 
they are correct (no duplicated files), so I am not sure about where the 
first file comes from. Could it have been created by some non-Debian 
package or script? E.g. did you ever install qt in some unofficial way?

> The mentioned libs: Must I reinstall them?
Probably not, but it will not hurt. :-)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#851446: fixed in 2.88dsf-59.10?

[KatolaZ]

Hi there,

it looks like the blamed code in initscripts.postinst has been removed
since 2.88dsf.59-10 (see commit a2873c7d40fa4b1 - by Michael Biebl on
20170908). The symlinks are not created any more, and actually the
function compat_link in initscripts.postints is not used at all (it
can be removed).

It looks like we can close this one?

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature

Bug#914407: [20181123] debian.securedservers.com: out of date

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problems

Hi!

It seems http://debian.securedservers.com/debian/
is out of date
https://mirror-master.debian.org/status/mirror-info/debian.securedservers.com.html

Please investigate.

If you sync off kernel.org, you might want to pick a different site
(do not use ftp.*.debian.org names, only http is guaranteed at
 those names and they do switch around.)
https://mirror-master.debian.org/status/mirror-hierarchy.html might help
you pick.

Also, please update your ftpsync version -- see
https://bugs.debian.org/882757 for the mail we sent you about that.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#914406: [20181123] mirror.overthewire.com.au: out of date

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problems

Hi!

It seems http://mirror.overthewire.com.au/debian/
is out of date
https://mirror-master.debian.org/status/mirror-info/mirror.overthewire.com.au.html

Please investigate.

If you sync off kernel.org, you might want to pick a different site
(do not use ftp.*.debian.org names, only http is guaranteed at
 those names and they do switch around.)
https://mirror-master.debian.org/status/mirror-hierarchy.html might help
you pick.


(Also, you might want to move from an arch-exclude to an arch-include
 config.  You have a weird selection of archs mirrored --
 http://mirror.overthewire.com.au/debian/project/trace/mirror.overthewire.com.au
)
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#831389: Asking for help instead of Orphaning!

[Kartik Mistry]

package: libmng
version: 2.0.3+dfsg-2

retitle 831389 RFH: libmng -- Multiple-image Network Graphics library
owner 831389 !
thanks

Latest version of libmng is uploaded to experimental and also now at,
https://salsa.debian.org/debian/libmng Feel free to help and probably
take over after that too. Till that, I'm fine with maintaining it as
it should be maintain as good number of rdepends on it.

-- 
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com

Bug#914275: Massive /etc/services reindent obscuring changes

[Marco d'Itri]

On Nov 21, Steve McIntyre  wrote:

> Why was /etc/services totally reindented and switched from spaces to
> tabs going from 5.4 to 5.5? Every single sid chroot on all my machines
Was it? I checked a system with 5.4 and it does not have spaces except 
than in comments.

> demanded attention becasue of this change. That includes newly-created
> chroots where I've made no changes at all to the original file, which
Well, maybe you need to check again how they are being built. :-)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#914076: Obsolete conffile /etc/bash_completion.d/cowbuilder not removed on upgrades

[Mattia Rizzolo]

On Fri, Nov 23, 2018 at 08:15:47AM +0100, Michael Biebl wrote:
> > I know now that that version in .maintscript is wrong and should have
> > been 0.76~, but unless it just so happened that you had 0.75 installed
> > already —with would be kind of weird— it shouldn't have an inpact.
> 
> Why would this be weird to have 0.75 installed? There was after all over
> a month between 0.75 and 0.76.
> 
> > Can you please check what went wrong in your case?  From what version
> > were you upgrading that you hit this bug?
> 
> I've upgrade this system regularly, so I indeed expect that I've updated
> to 0.75 and then upgraded to 0.76, so the cleanup routine was never run
> for me.

Oh, I somehow thought of having 0.75 installed and upgrading only now;
didn't think you could have noticed the stale conffile 3 years later,
sorry.


Anyway, how do you usually deal with this thing?  I believe one could
add an arbitrary extra rm_conffile line with a newer version, but that
would be quite arbitrary.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#914326: [20181122] mirror.reismil.ch: unavailable

[Peter Palfrader]

reopen 914326
thanks

On Thu, 22 Nov 2018, Sebastian Elisa Pfeifer wrote:

> There was an issue with the upstream provider, it should be fixed.

Issue is back.

> > https://mirror-master.debian.org/status/mirror-info/mirror.reismil.ch.html

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#831388: RFH: dee -- model to synchronize mutiple instances over DBus

[Kartik Mistry]

Update:

Latest package uploaded to experimental and available in salsa at,
https://salsa.debian.org/debian/dee - feel free to send pull request
or just update directly. I plan to upload to unstable and maintain
till someone takes over!

Thanks!

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com

Bug#914405: appears to not update auto-trust-anchors without requests

[Peter Palfrader]

Package: unbound
Version: 1.6.0-3+deb9u2
Severity: normal

Hi!

we have unbound configured as a recursor on most of our hosts,
and we have a few trust-anchors in addition to the root zone's
configured with auto-trust-anchor-file.

One of the covered zone sees rarely, if ever, any queries.

It appears unbound is not maintaining the auto-trust-anchor without
seeing queries however.

| weasel@scw-arm-ams-01:~$ cat /etc/unbound/unbound.conf
| ##
| ## THIS FILE IS UNDER PUPPET CONTROL. DON'T EDIT IT HERE.
| ##
|
| server:
| verbosity: 1
|
|
|
| #chroot: ""
|
| hide-identity: yes
| hide-version: yes
|
| # Do not query the following addresses. No DNS queries are sent there.
| # List one address per entry. List classless netblocks with /size,
| # do-not-query-address: 127.0.0.1/8
| # do-not-query-address: ::1
|
| # if yes, the above default do-not-query-address entries are present.
| # if no, localhost can be queried (for testing and debugging).
| # do-not-query-localhost: yes
|
| # File with trusted keys, kept uptodate using RFC5011 probes,
| # initial file like trust-anchor-file, then it stores metadata.
| # Use several entries, one per domain name, to track multiple zones.
| # auto-trust-anchor-file: ""
| auto-trust-anchor-file: "/var/lib/unbound/root.key"
| auto-trust-anchor-file: "/var/lib/unbound/torproject.org.key"
| auto-trust-anchor-file: "/var/lib/unbound/30.172.in-addr.arpa.key"
|
| prefetch: yes
| prefetch-key: yes
|
| local-zone: "30.172.in-addr.arpa" nodefault
| forward-zone:
| name: "30.172.in-addr.arpa"
| forward-host: ns1.torproject.org
| forward-host: ns2.torproject.org
| forward-host: ns3.torproject.org
| forward-host: ns4.torproject.org
| forward-host: ns5.torproject.org

Note how the trust anchor for the 172.30/16 reverse zone is almost 2
weeks old:

} weasel@scw-arm-ams-01:~$ ls -lart /var/lib/unbound
} total 20
} drwxr-xr-x 36 rootroot4096 May 16  2018 ../
} -rw-r--r--  1 unbound unbound  794 Nov 12 09:17 30.172.in-addr.arpa.key
} -rw-r--r--  1 unbound unbound 1252 Nov 22 11:18 root.key
} -rw-r--r--  1 unbound unbound  784 Nov 23 05:42 torproject.org.key
} drwxrwxr-x  2 unbound unbound 4096 Nov 23 05:42 ./

I suspect that unbound might miss RFC5011 style updates since it
doesn't query the zone regularly.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#914404: transition: libmng

[Kartik Mistry]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi Release Team,

I plan to upload new version of libmng (already in experimental and
updating it again).

Direct reverse dependencies are:

 tuxonice-userui
 libxine2-misc-plugins
 libsynfig0a
 qt5-image-formats-plugins
 libqtgui4
 libdevil1c2
 gimp

Thanks and let me know how to proceed.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com

Bug#914076: Obsolete conffile /etc/bash_completion.d/cowbuilder not removed on upgrades

[Michael Biebl]

Am 23.11.18 um 07:55 schrieb Mattia Rizzolo:

> % cat debian/cowbuilder.maintscript
> rm_conffile /etc/bash_completion.d/cowbuilder 0.75~
> 
> 
> I know now that that version in .maintscript is wrong and should have
> been 0.76~, but unless it just so happened that you had 0.75 installed
> already —with would be kind of weird— it shouldn't have an inpact.

Why would this be weird to have 0.75 installed? There was after all over
a month between 0.75 and 0.76.

> Can you please check what went wrong in your case?  From what version
> were you upgrading that you hit this bug?

I've upgrade this system regularly, so I indeed expect that I've updated
to 0.75 and then upgraded to 0.76, so the cleanup routine was never run
for me.

Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#914076: Obsolete conffile /etc/bash_completion.d/cowbuilder not removed on upgrades

[Mattia Rizzolo]

Control: tag -1 moreinfo

On Mon, Nov 19, 2018 at 03:19:26AM +0100, Michael Biebl wrote:
> Package: cowbuilder
> Version: 0.87+b1
> Severity: normal
> File: /etc/bash_completion.d/cowbuilder
> 
> cowbuilder now ships the bash-completion file as
> /usr/share/bash-completion/completions/cowbuilder
> 
> The obsolete conffile /etc/bash_completion.d/cowbuilder should properly
> be removed on upgrades though.
> 
> The simples way to do that is using a cowbuilder.maintscript.
> See man dh_installdeb.

This is actually already done, for a long time.

cowdancer (0.76) unstable; urgency=medium
...
  * debian/cowbuilder.maintscript:
   - add to remove obsolete /etc/bash_completion/cowbuilder (Closes: #804634)
...
 -- Iain R. Learmonth   Sun, 13 Dec 2015 11:25:11 +

cowdancer (0.75) unstable; urgency=medium
...
  * Move bash completions to standard location
...
 -- Iain R. Learmonth   Tue, 03 Nov 2015 11:53:25 +


and:

% cat debian/cowbuilder.maintscript
rm_conffile /etc/bash_completion.d/cowbuilder 0.75~


I know now that that version in .maintscript is wrong and should have
been 0.76~, but unless it just so happened that you had 0.75 installed
already —with would be kind of weird— it shouldn't have an inpact.

Can you please check what went wrong in your case?  From what version
were you upgrading that you hit this bug?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#912406: systemd: reboot/poweroff usually gets stuck

[Michael Biebl]

Control: reassign -1 linux-image-4.9.0-7-686-pae
Control: retitle -1 ehci-pci.ko prevents shutdown

Hi

Am 23.11.18 um 04:12 schrieb Andrew Pavlomanolakos:
> Hi Michael,
> 
> I built a 4.9.137 kernel and added some trace code and found that the
> issue occurs during device_shutdown() in the linux kernel. Specifically
> when it tries to shutdown the following device:
> 
> 00:1d.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx
> Series USB EHCI (rev 11)
> 
> As an experiment we removed the ehci-pci.ko and ehci-hcd.ko kernel
> modules so that ehci would not be used. By doing this we found that
> reboots and powerdowns worked 100% of the time.
> 
>> This issue does not occur when I use antiX-17.1_386-core.iso (does not
>> used systemd) or a very old 32 bit PCLOS distro (does not used systemd).
> 
> I performed more testing with antiX-17.1_386-core.iso (does not used
> systemd) and found that this issue DOES occur.
> 
> I was able to confirm that the very old 32 bit PCLOS distro (does not
> used systemd) does not have this issue.
> 
>> This is logged right before systemd-shutdown calls the final
>> reboot() system call. If it get's stuck after that, it looks like it is
>> a kernel issue.
> 
> I think you are right, this looks like a kernel issue, not a systemd
> issue. Currently I have logged this as a systemd issue, how can I change
> this to a kernel issue?

Nice detective work!
Given your findings, I'm going to reassign this issue to the
linux-image-4.9.0-7-686-pae package. According to your original bug
report you were running

Kernel: Linux 4.9.0-7-686-pae (SMP w/4 CPU cores)

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



signature.asc
Description: OpenPGP digital signature

Bug#914402: qbittorrent: new upstream 4.1.4

[Jonatan Nyberg]

package: qbittorrent
severity: normal

Please consider to upgrade to the current upstream version
(4.1.4).

Regards,
Jonatan

Bug#891450: custodia FTBFS: TypeError: stat: path should be string, bytes, os.PathLike or integer, not NoneType

[Timo Aaltonen]

On 21.4.2018 23.27, Ben Finney wrote:
> On 25-Feb-2018, Adrian Bunk wrote:
>> Source: custodia
> 
> I Think this is the correct assignment for this bug report.
> 
> See the command-line used to invoke the coverage module:
> 
>> ERROR: InvocationError: '/build/1st/custodia-0.5.0/.tox/py36/bin/python -m 
>> coverage run --parallel -m pytest --capture=no --strict --skip-servertests'
> 
> Note that the command line calls ‘[…]python -m coverage run’ but
> specifies no tests to run. That's why the ‘coverage’ module eventually
> complains that the path that was specified is None.
> 
> Somehow, the ‘custodia’ test suite is invoking ‘coverage’ in such a
> way that no path is specified.

Well, it seems to build fine on my sbuild these days, so whatever caused
the error doesn't seem to be true anymore.


-- 
t



signature.asc
Description: OpenPGP digital signature

Bug#883245: Thunderbird Not Opening HTTP, HTTPS URLs With Vivaldi

[Carsten Schoenert]

Control: clone 883245 -1
Control: retitle -1 apparmor: no permission to /usr/bin/vivaldi-stable

Hello David,

your reported issue is obviously related to AppArmor. Even if the bug
report is also related to AppArmor it would have been better if you had
created a new issue as your problem is different ftom the reported issue
in 883245.
I've cloned the this old issue into anew one so the AppArmor people
don't have to hassle to figure out which problems are all reported to
this report.

Am 22.11.18 um 19:02 schrieb David Campbell:
> 
> 
>   * Edit 
>   * Report this post 
>   * Quote 
> 
> #1  Post
>  by *caffinate
> * » Thu
> Nov 22, 2018 12:00 pm
> 
> MK Linux 17.1 Thunderbird Version 52.9.1 64 Bit
> 
> One persistent problem I'm having is the inability of Thunderbird to
> open http, https URLs in emails with the Vivaldi. I also had the same
> problem with Chromium.
> 
> When I run Thunderbird in Safe Mode in a console and try to open a url
> in Thunderbird email I get this message:
> 
> *** (thunderbird:961): WARNING **: Could not launch default application for 
> URI: Failed to execute child process "/usr/bin/vivaldi-stable" (Permission 
> denied)*
> 
> EDIT: When I try to open links from Evolution Email Client - works fine.
> *EDIT2: Problem Appears to Be Solved:*
> 
> Narrowed this down to some kind of permissions problem with thunderbird:\
> Found this: https://bugs.debian.org/cgi-bin/bugrepo ... bug=883245
> 

Well, it's mostly clear that thunderbird isn't allowed to run this
binary as this is already visible on the CLI as you have posted above.

> .
> I'm experiencing the same with the version that's currently in testing. 
> However, I found a workaround: either install thunderbird/1:52.5.0-1 
> from unstable, or disable the apparmor profile yourself:
> 
> *sudo ln -s /etc/apparmor.d/usr.bin.thunderbird /etc/apparmor.d/disable/
> sudo apparmor_parser -R /etc/apparmor.d/usr.bin.thunderbird*
> 
> *Now Thunderbird URL links open correctly in Vivaldi*

Yes and no.
It's a problem related to the AppArmor profile from Thunderbird and
disabling the AppArmor profile make for sure going away the problem, but
ist's not solved. It's probably just one line you need to add to the
AppAprmor profile. That's a thing intrigeri or Vincas can answer for
sure. (CCed)

@intrigeri
You will need to add the correct BTS tagging for apparmore please.

-- 
Regards
Carsten Schoenert

Bug#913613: closed by Christoph Berg (Re: Bug#913613: data/cronjobs/vcsstats: line 1: warning: Skipping data file with no valid points)

[Mattia Rizzolo]

Control: reopen -1

On Tue, 13 Nov 2018 21:46:36 +0100, Christoph Berg  wrote:
> The immediate blame goes to Darcs for producing the first ERROR result
> ever on 2018-10-05. Before that, there were only OK and NEW scan
> results.
> 
> Of course the real blame goes to gnuplot for refusing to plot a column
> with a lot of null values and only a real single '1'.
> 
> I fixed the issue by adding a '0' ERROR count to the vcsstats table
> for the first date where Darcs results were recorded, 2006-10-01
> 00:00:00+00.

You said so, but 6 hours ago we received the same email again.
Could you please check again?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#890594: salsa script ready to review

[Xavier]

Le 22/11/2018 à 22:45, Xavier a écrit :
> Le 22/11/2018 à 21:06, Xavier a écrit :
>> Le 22/11/2018 à 10:19, Xavier a écrit :
>>> Le 22/11/2018 à 08:46, Raphael Hertzog a écrit :
 Hi,

 On Wed, 21 Nov 2018, Xavier wrote:
> Sorry, I found a SALSA_TEAM in your conf file. For clarity, SALSA_TEAM
> has been replaced by SALSA_GROUP (same for all team commands/options
> replaced by *group*).

 Working much better with SALSA_GROUP ;) But then I got this:

 wapiti:
bad irc channel: #debian-pkg-security

 It was really not clear what was wrong. But it seems that you expect:
 SALSA_IRC_CHANNEL=debian-pkg-security

 And not the value that I had put initially:
 SALSA_IRC_CHANNEL=#debian-pkg-security

 It seems strange to require to strip the leading hash. I would rather
 be more user-friendly: add the leading hash if it's missing, but otherwise
 assume that the value is the full name (some channels can start with two
 leading hashes). Also the documentation should be clear on this.
>>
>> I updated doc for this (also explanation that "#" is considered as
>> comment by "sh"). Spelling errors also fixed, thanks !
>>
>>> Hello,
>>>
>>> this is due to sh. This diff explains more:
>>> diff --git a/scripts/salsa.pl b/scripts/salsa.pl
>>> index 52a174bb..d1751ecf 100755
>>> --- a/scripts/salsa.pl
>>> +++ b/scripts/salsa.pl
>>> @@ -567,9 +567,19 @@ C<.devscripts> values: B
>>> (yes/ignore/no, default: ignore)
>>>
>>>  =item B<--irc-channel>
>>>
>>> -IRC channel for KGB or Irker.
>>> +IRC channel for KGB or Irker. Can me used more than one time only with
>>> +B<--irker>.
>>>
>>> -C<.devscript> value: B
>>> +B: channel must not include the first "#". If salsa find a
>>> channel
>>> +starting with "#", it will consider that channel starts with 2 "#"!
>>> +
>>> +C<.devscript> value: B.
>>> +
>>> +Multiple values must be space separated.
>>> +
>>> +Since configuration files are read using B, be careful when using
>>> "#": you
>>> +must enclode the channel with quotes, else B will consider it as a
>>> comment
>>> +and will ignore this value.
>>>
>>>  =item B<--irker>, B<--no-irker>, B<--disable-irker>
>>>
 Another detail I noticed, the values of SALSA_EMAIL_RECIPIENTS should 
 benefit
 from the same substitution as SALSA_DESC_PATTERN so that we can include the
 name of the repo in the generated email addresses.
>>>
>>> OK, I'm going to do this
>>
>> Done. Hope salsa works fine now ;-)
>> .deb updated
>>
>> Cheers,
>> Xavier
> 
> Last .deb contains the SALSA_RENAME_HEAD. Could you test it ?
> 
> Cheers,
> Xavier

One important thing: I set ruprecht.snow-crash.org as default value for
--irker-host. Is it a good idea ? Is this server secured [1] ?

[1]: http://www.catb.org/~esr/irker/security.html

Bug#914401: ITP: node-d3-contour -- Computes contour polygons by applying marching squares to a rectangular array.

[Kannan V M]

Package: wnpp
Severity: wishlist
Owner: Kannan V M 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name : node-d3-contour
 Version : 1.3.2
 Upstream Author : Mike Bostock (http://bost.ocks.org/mike)
* URL : https://d3js.org/d3-contour/
* License : BSD-3-Clause
 Programming Lang: JavaScript
 Description : Computes contour polygons by applying marching
 squares to a rectangular array

 Computes contour polygons by applying marching
 squares to a rectangular array of numerical values.
 .
 Contour polygons are GeoJSON, you can transform and display
 them using standard tools.
 .
 Contour plots can also visualize continuous functions by sampling.
 .
 Contours can also show the estimated density of point clouds,
 which is especially useful to avoid overplotting in large
 datasets. This library implements fast two-dimensional kernel
 density estimation.

This package is a dependency for gitlab.
There are no other similar packages are available in debian alternative
to d3-contour. It uses rollup to transform the source code, so it is not
usable for embedding.

I want to maintain this package under JavaScript maintainers team.
Praveen has agreed to sponsor this package.
-kannan

Bug#810018: Additional info possibly relevant for procps-base/pidof ...

[Josh Triplett]

On Tue, 10 Jul 2018 03:19:58 +0200 Michael Biebl  wrote:
> On Mon, 9 Jul 2018 22:03:06 +1000 Craig Small  wrote:
> > On Mon, 9 Jul 2018 at 19:38 Simon McVittie  wrote:
> > 
> > > If we want pidof to be provided by a new procps-base instead of
> > > sysvinit-utils for buster, maybe now is the time to start uploading
> > > packages with that change to experimental?
> > >
> > I'd say if it is going to happen, it should happen now.
> > 
> 
> Just wanted to say, that I had a look at the sysvinit-utils package
> (again) the other day and wondered whether we could move
> /sbin/killall5 and /sbin/fstab-decode into the (non-essential)
> initscripts package, as according to codesearch there aren't any users
> of those two binaries outside of initscripts itself (the notable
> exception being open-iscsi, which has native service files, so this
> wouldn't be a concern).
> 
> The only blocker for moving /sbin/killall5 to initscripts is that
> /bin/pidof is currently a symlink pointing at /sbin/killall5.
> 
> So if you proceed with creating such a procps-base package, we could
> make a follow-up upload for src:sysvinit, dropping /bin/pidof and moving
> /sbin/killall5 and /sbin/fstab-decode

Following up on this: I'd love to see pidof built from the procps source
package. What would it take to move forward with this?

Bug#914400: RM: context-doc-nonfree -- ROM; now in the main context package

[Norbert Preining]

Package: ftp.debian.org
Severity: normal

Formerly, the files in context-doc-nonfree were provided without
sources. This has changed, and the current context package contains
sources and the documentation files, thus the context-doc-nonfree
package is not useful anymore.

Please remove it.

Thanks

Norbert

Bug#914397: nftables: after Stretch->Buster upgrade, named set needs "auto-merge"

[Gert]

Whoops, the "System Information" is not from the affected system, but 
from the system I used to write the report. So ignore that.


System Information from the affected system:
linux-image-4.18.0-2-amd64 4.18.10-2+b1
nftables 0.9.0-1
libnftables0 0.9.0-1
libnftnl7 1.1.1-1
libxtables12 1.8.2-2
libgmp10 2:6.1.2+dfsg-3
libmnl0 1.0.4-2
libreadline7 7.0-5

Bug#914399: git-branchmove: does not cope with restricted shell SSH remotes

[Sean Whitton]

Package: chiark-scripts
Version: 6.0.3

Dear maintainer,

git-branchmove does not work with SSH remotes which do not give the user
a full shell, such as repository hosting services like GitLab, GitHub
and Gitolite.

For example,

% git-branchmove put g...@spwhitton.name:git-remote-gcrypt wip/GET-stderr
FATAL: I don't like newlines in the command: 'set -e; cd git-remote-gcrypt; 
<> git for-each-ref --format="%(refname)=%(objectname)"  
'[r]efs/heads/wip/GET-stderr'<>'

Here, my gitolite instance refuses to execute the shell script snippet
provided by git-branchmove.

If this is all that git-branchmove needs to do on the remote, couldn't
it use git-ls-remote(1) instead?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#914398: git-branchmove: does not respect insteadOf, pushInsteadOf git configuration keys

[Sean Whitton]

Package: chiark-scripts
Version: 6.0.3

Dear maintainer,

git-branchmove ignores the git configuration keys insteadOf and
pushInsteadOf.  In my ~/.gitconfig I have

[url "g...@spwhitton.name:"]
 pushInsteadOf = https://git.spwhitton.name/
 pushInsteadOf = git://spwhitton.name/
 pushInsteadOf = athena:
[url "https://git.spwhitton.name/;]
 insteadOf = athena:

and my repository has

[remote "origin"]
url = athena:git-remote-gcrypt

but then if I hack `set -x` into git-branchmove and try

% git-branchmove put origin wip/GET-stderr

I can see that git-branchmove tries to do this:

++ ssh athena 'set -e; cd git-remote-gcrypt;
git for-each-ref --format="%(refname)=%(objectname)"  
'\''[r]efs/heads/wip/GET-stderr'\''
'
bash: line 0: cd: git-remote-gcrypt: No such file or directory

which is not going to work because `ssh athena` logs into host athena as
user 'spwhitton', not user 'git'.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#914059: git-remote-gcrypt: fails without mentioning that the fingerprint for the RSA key sent by the remote host has changed

[Sean Whitton]

control: tag -1 +patch

Hello,

On Tue 20 Nov 2018 at 08:02AM +0100, intrigeri wrote:

> Hi Sean and moire,
>
> Sean Whitton:
>> I think the best option might simply be if git-remote-gcrypt
>> stops hiding the output from git when this failure occurs?
>
> Agreed (modulo I've not seen how that would look like yet; happy to
> test patches :)

Here is a patch.  Please let me know the results of any testing you're
able to do.

-- 
Sean Whitton
From c79d3e4d7b6b1ca51fd4ba5c6773700ed67ef84f Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Thu, 22 Nov 2018 20:54:56 -0700
Subject: [PATCH] output stderr from other commands when the repository is not
 found

Closes: #914059

Signed-off-by: Sean Whitton 
---
 git-remote-gcrypt | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/git-remote-gcrypt b/git-remote-gcrypt
index ba75f09..ef1a078 100755
--- a/git-remote-gcrypt
+++ b/git-remote-gcrypt
@@ -62,6 +62,7 @@ EOF
 xecho() { xfeed "$*" cat; }
 xecho_n() { xecho "$@" | tr -d \\n ; } # kill newlines
 echo_git() { xecho "$@" ; }  # Code clarity
+echo_err() { xecho "$@" >&2; }
 echo_info() { xecho "gcrypt:" "$@" >&2; }
 echo_die() { echo_info "$@" ; exit 1; }
 
@@ -492,7 +493,7 @@ read_config()
 ensure_connected()
 {
 	local manifest_= r_repoid= r_name= url_frag= r_sigmatch= r_signers= \
-		tmp_manifest=
+		tmp_manifest= tmp_stderr= stderr_=
 
 	if isnonnull "$Did_find_repo"
 	then
@@ -529,7 +530,10 @@ ensure_connected()
 
 
 	tmp_manifest="$Tempdir/maniF"
-	GET "$URL" "$Manifestfile" "$tmp_manifest" 2>/dev/null || {
+	tmp_stderr="$Tempdir/stderr"
+	GET "$URL" "$Manifestfile" "$tmp_manifest" 2>| "$tmp_stderr" || {
+		stderr_="$(cat $tmp_stderr)"
+		echo_err "$stderr_"
 		echo_info "Repository not found: $URL"
 		if ! isnull "$Repoid"; then
 			echo_info "..but repository ID is set. Aborting."
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#914397: nftables: after Stretch->Buster upgrade, named set needs "auto-merge"

[Gert]

Package: nftables
Version: 0.9.0-1
Severity: normal

Hi,
I make use of a "named set" for blacklisting purposes.
The relevant part in /etc/nftables.conf:

table ip filter {
set blacklist {
type ipv4_addr
flags interval
include "/etc/ipset-blacklist/ip-blacklist.nft"
}
}

The file /etc/ipset-blacklist/ip-blacklist.nft is generated from several
sources, its contents are not perfectly organized.

I was running Stretch, and it worked great. I just upgraded to Buster, and now
nftables.service fails to start with this message:

Error: conflicting intervals specified

Ok, apparently the file contains those.
After some Googling, I tried to add "auto-merge" to the blacklist options, and
now it works again.

I thought maybe this change should be documented somewhere for other upgraders,
or handled automatically.
Perhaps I file this bug to the wrong package (maybe it's kernel or release
notes?), but now at least it is known.

Thanks!



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

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

Versions of packages nftables depends on:
ii  dpkg 1.18.25
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u3
ii  libgmp10 2:6.1.2+dfsg-1
ii  libmnl0  1.0.4-2
pn  libnftables0 
pn  libnftnl4
ii  libreadline7 7.0-3
ii  libxtables12 1.6.0+snapshot20161117-6

nftables recommends no packages.

nftables suggests no packages.

Bug#912406: systemd: reboot/poweroff usually gets stuck

[Andrew Pavlomanolakos]

Hi Michael,

I built a 4.9.137 kernel and added some trace code and found that the 
issue occurs during device_shutdown() in the linux kernel. Specifically 
when it tries to shutdown the following device:


00:1d.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx 
Series USB EHCI (rev 11)


As an experiment we removed the ehci-pci.ko and ehci-hcd.ko kernel 
modules so that ehci would not be used. By doing this we found that 
reboots and powerdowns worked 100% of the time.


This issue does not occur when I use antiX-17.1_386-core.iso (does not 
used systemd) or a very old 32 bit PCLOS distro (does not used systemd).


I performed more testing with antiX-17.1_386-core.iso (does not used 
systemd) and found that this issue DOES occur.


I was able to confirm that the very old 32 bit PCLOS distro (does not 
used systemd) does not have this issue.



This is logged right before systemd-shutdown calls the final
reboot() system call. If it get's stuck after that, it looks like it is
a kernel issue.


I think you are right, this looks like a kernel issue, not a systemd 
issue. Currently I have logged this as a systemd issue, how can I change 
this to a kernel issue?


Other investigations showed (ehci was not forcibly removed):

 * PCLOS *with linux 3.2 is OK*
 * PCLOS with linux 4.8.7 is not OK
 * Debian Wheezy *with linux 3.2 is OK*
 * Debian Jessie with linux 3.18 is not OK
 * Debian Stretch with linux 4.9.137 is not OK

Regards, Andrew

On 08/11/18 02:11, Michael Biebl wrote:

Am 07.11.18 um 04:24 schrieb Andrew Pavlomanolakos:

Hi,

I tried with another kernel from backports:

root@entry115:~# uname -a
Linux entry115 4.18.0-0.bpo.1-686-pae #1 SMP Debian 4.18.6-1~bpo9+1
(2018-09-13) i686 GNU/Linux

The same issue was reproduced with kernel 4.18.0-0.bpo.1-686-pae. Here
is the trace:

Ok, thanks for testing.
I'm out of ideas at this point, so we should take this upstream.
For that it would be best if you can reproduce that with the current
upstream version, i.e. v239, which is also available from stretch-backports.

If the issue is still reproducible then, it would be great if you can
file a report athttps://github.com/systemd/systemd/issues

Regards,
Michael

Bug#910348: The same bug is present in 4.18.0-3

[Jiri Palecek]

found 910348 linux/4.18.20-1

thanks


Hello,

just installing the new version of the kernel in the 4.18 line, eager to 
test that its bootable again on i386 with more than 4G ram, I've found 
the nvidia module doesn't build. It seems like a reincarnation of the 
earlier problem in experimental kernels. For the record, the error 
message is:


make KBUILD_OUTPUT=/lib/modules/4.18.0-3-686-pae/build V=1 -C 
/lib/modules/4.18.0-3-686-pae/source 
M=/var/lib/dkms/nvidia-current/390.87/build ARCH=i386 
NV_KERNEL_SOURCES=/lib/modules/4.18.0-3-686-pae/source 
NV_KERNEL_OUTPUT=/lib/modules/4.18.0-3-686-pae/build 
NV_KERNEL_MODULES="nvidia nvidia-modeset nvidia-drm" 
INSTALL_MOD_DIR=kernel/drivers/video modules

make[1]: Vstupuje se do adresáře ,,/usr/src/linux-headers-4.18.0-3-common"
make -C /lib/modules/4.18.0-3-686-pae/build 
KBUILD_SRC=/usr/src/linux-headers-4.18.0-3-common \

-f /usr/src/linux-headers-4.18.0-3-common/Makefile modules
make[2]: Vstupuje se do adresáře ,,/usr/src/linux-headers-4.18.0-3-686-pae"
test -e include/generated/autoconf.h -a -e include/config/auto.conf || 
(    \

echo >&2; \
echo >&2 "  ERROR: Kernel configuration is invalid.";   \
echo >&2 " include/generated/autoconf.h or 
include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to 
fix it.";  \

echo >&2 ;  \
/bin/false)
/usr/src/linux-headers-4.18.0-3-common/Makefile:301: 
scripts/subarch.include: Adresář nebo soubor neexistuje


(meaning file not found).

Regards

    Jiri Palecek

Bug#826214: Please would 40-systemd honour __init_d_script_name

[Benda Xu]

Ian Jackson  writes:

> I think reimplementing init-d-script in C is the wrong solution to
> this bug.  Certainly, if the only thing it is buying is us an ability
> to manipulate $0.  I infer from Dmitry's closing of #913247 which
> requests init-d-script in C, that he also doesn't like that idea.
>
> So I think both Dmitry and I are in agreement that the right solution
> here is the first of Dmitry's two bullet points above.  Ie, the
> sysvinit maintainers are of the opinion that this should be fixed by
> amending 40-systemd, which is part of the systemd package.
>
> I'm therefore reassigning this bug.  Benda, if you disagree; or,
> Dmitry, if I have misunderstood your view: please do say.

I agree with Ian and Dmitry, and have no objections to this decision.

Thank you to all the parties coming together to fix this.

Yours,
Benda

Bug#914383: debian-policy: re-encode virtual package list in YAML

[Sean Whitton]

Hello,

On Thu 22 Nov 2018 at 10:17PM +0100, Bill Allombert wrote:

> Hello Jonathan,
> Thanks for your effort working on this.

Likewise, thank you.

> However, the git changelog is not shipped in the policy package, so this
> is not a replacement to the enclosed ChangeLog.

Yes.  If we replace it at all, it should be with some sort of
easily-searchable convention for tracking changes to the list of virtual
packages in debian/changelog.

> Since such virtual package names can appear in the archive before
> adoption and after deprecation, it is important that the reader
> has access to such changelog in a readable form.
>
> This is especially important because no all virtual packages appear in
> this list (due to the "cooperating group of packages" exception) so the
> fact that a name does not appear in the list does not mean it is for an
> obsolete virtual package.
>
> The changelog could be kept as comment in the YAML file, or maybe better,
> the adoption and deprecation date could be simply added to the YAML
> data (but this require adding back the obsolete packages to the list).
> This way this would be machine readable too.

I have not thought through Bill's arguments here carefully, but let's
not block making the list of virtual packages machine-parseable on the
question of whether or not we can remove the changelog.

Let's just retain the changelog in a YAML comment, and proceed to merge
the conversion to a machine-parseable format.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#776160:

[Gabriel F. T. Gomes]

Control: fixed -1 bash-completion/1:2.7-1

On 22 Nov 2018, Gabriel F. T. Gomes wrote:
>
>Control: tags -1 fixed bash-completion/1:2.7-1

This was the wrong syntax to set fixed version.

Bug#914126: svtplay-dl: bugs out on urplay.se

[Olof Johansson]

On 18-11-19 18:37 +0100, Cristian Ionescu-Idbohrn wrote:
> This is what I see:
...
> requests.exceptions.SSLError: 
> HTTPSConnectionPool(host='streaming-loadbalancer.ur.se', port=443): Max 
> retries exceeded with url: /loadbalancer.json (Caused by 
> SSLError(SSLError("bad handshake: Error([('SSL routines', 
> 'ssl_choose_client_version', 'unsupported protocol')],)",),))
> 
> when trying to download:
> 
>   https://urplay.se/program/204949-roster-fran-australiens-aboriginer
> 
> for example.  Works fine when playing it in chromium, though.
> 
> Downloading from svtplay.se works fine, though.

Thanks for the report, I have been postponing upgrading to the
new 2.0+ version, but should get on that asap. Hopefully that
should solve it.

-- 
olof

Bug#913287: Bug#912925: Is the SONAME the same for all the related libs?

[Julian Gilbey]

On Sun, Nov 18, 2018 at 03:35:11PM +, Julian Gilbey wrote:
> On Sun, Nov 18, 2018 at 09:01:19AM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > Yesterday I've uploaded qtbase with this fix, please try it.
> 
> Excellent, thanks!  I just built it on my testing machine, and it
> worked perfectly with the Python script in this bug report and the
> simplebrowser example.

Hi Lisandro,

Upstream have now patched what-I-presume-will-become 5.12.1 with
almost this patch.  But it's gone through several iterations, and now
the patch also deletes a couple of #include's.  See patch set #7 at
https://codereview.qt-project.org/#/c/245294/

I doubt it's worth uploading a new version just for this, but when you
are doing the next qtbase upload, you might consider making this
change.

Best wishes,

   Julian

Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script

[Mert Dirik]

On 11/23/18, Michael Biebl  wrote:
> Hi
>
> On Thu, 22 Nov 2018 16:01:33 + Ian Jackson
>  wrote:
>
>> To the systemd maintainers: will you have time to look at this, and
>> make the appropriate change, soon ?  If not then one of us could
>> probably prepare a patch, if that would be helpful.
>
> A patch for 40-systemd would be highly appreciated [1].
>
> A few things which should be considered:
>
>
> - It should work with both
>
> #!/usr/bin/env /lib/init/init-d-script
>
> and
>
> if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
> set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
> fi
>
> Otherwise we need a flag day and convert all packages using
> init-d-script at once.
>
>
> - Older versions of sysvinit-utils (prior to 2.88dsf-59.11) did not use
> __init_d_script_name=. 40-systemd should either work with older and
> newer versions of /lib/init/init-d-script or systemd would need a
> versioned Breaks: sysvinit-utils (<< 2.88dsf-59.11)
>
> I would prefer if we can avoid the Breaks as those are prone to
> complicate dist-upgrades.
>
>

I'll work on a patch for 40-systemd this week, but of course anyone
else should feel free to work on it before I do.

Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script

[Michael Biebl]

Hi

On Thu, 22 Nov 2018 16:01:33 + Ian Jackson
 wrote:

> To the systemd maintainers: will you have time to look at this, and
> make the appropriate change, soon ?  If not then one of us could
> probably prepare a patch, if that would be helpful.

A patch for 40-systemd would be highly appreciated [1].

A few things which should be considered:


- It should work with both

#!/usr/bin/env /lib/init/init-d-script

and

if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi

Otherwise we need a flag day and convert all packages using
init-d-script at once.


- Older versions of sysvinit-utils (prior to 2.88dsf-59.11) did not use
__init_d_script_name=. 40-systemd should either work with older and
newer versions of /lib/init/init-d-script or systemd would need a
versioned Breaks: sysvinit-utils (<< 2.88dsf-59.11)

I would prefer if we can avoid the Breaks as those are prone to
complicate dist-upgrades.



Regards,
Michael

[1] A MR via https://salsa.debian.org/systemd-team/systemd/ would be
even better
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#914396: mupdf: Add binary for mupdf-gl

[Otis Wright]

Package: mupdf
Version: 1.14.0+ds1-2
Severity: wishlist

Dear Maintainer,


mupdf have released a mupdf-gl version which has support for persistent 
bookmarks, a save file menu, and more,
link here https://mupdf.com/docs/manual-mupdf-gl.html.
Could we have this binary added to mupdf install or even as added as it's own 
package?


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

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

Versions of packages mupdf depends on:
ii  libc62.27-8
ii  libfreetype6 2.8.1-2
ii  libharfbuzz0b1.9.0-1
ii  libjbig2dec0 0.15-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libopenjp2-7 2.3.0-1
ii  libssl1.11.1.1-2
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  zlib1g   1:1.2.11.dfsg-1

mupdf recommends no packages.

Versions of packages mupdf suggests:
pn  mupdf-tools  

-- no debconf information

Bug#914368: emacspeak-ss: Error on emacspeak-ss installation.

[Zachary Kline]

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion  Architecture Description
+++-===---==
ii  emacs   1: 25.2+1-11  all  GNU Emacs editor 
(metapackage)
ii  emacs-bin-common1: 25.2+1-11  amd64GNU Emacs editor's 
shared, architecture dependent files
ii  emacs-common1: 25.2+1-11  all  GNU Emacs editor's 
shared, architecture independent infrastructure
un  emacs-common-non-dfsg (no description available)
ii  emacs-el1: 25.2+1-11  all  GNU Emacs LISP (.el) 
files
ii  emacs-gtk   1: 25.2+1-11  amd64GNU Emacs editor (with 
GTK+ GUI support)
un  emacs-lucid   (no description available)
un  emacs-nox (no description available)
un  emacs19   (no description available)
un  emacs20   (no description available)
un  emacs21   (no description available)
un  emacs21-common(no description available)
un  emacs22   (no description available)
un  emacs22-common(no description available)
un  emacs23   (no description available)
un  emacs23-common(no description available)
un  emacs24-bin-common(no description available)
un  emacs24-common(no description available)
un  emacs25   (no description available)
un  emacs25-bin-common(no description available)
un  emacs25-common(no description available)
un  emacsen   (no description available)
ii  emacsen-common  3.0.4all  Common facilities for all 
emacsen
ii  emacspeak   47.0+dfsg-5  all  speech output interface 
to Emacs
un  emacspeak-bs-tcl  (no description available)
un  emacspeak-dt  (no description available)
un  emacspeak-dt-tcl  (no description available)
ii  emacspeak-espeak-server 47.0+dfsg-5  amd64espeak synthesis server 
for emacspeak
ii  emacspeak-ss1.12.1-8 amd64Emacspeak speech servers 
for several synthesizers
un  xemacs21-support  (no description available)
Message-ID: 
<154292971515.7729.7124198335110904456.report...@zork.hsd1.wa.comcast.net>
X-Mailer: reportbug 7.5.0
Date: Thu, 22 Nov 2018 15:35:15 -0800
X-Debbugs-Cc: zkl...@speedpost.net

Package: emacspeak-ss
Version: 1.12.1-8
Followup-For: Bug #914368

Bug#906609: fixed in gnucash 1:3.3-1

[Bernhard Übelacker]

Am 22.11.2018 um 23:15 schrieb Dmitry Smirnov:
> On Thursday, 22 November 2018 9:50:02 AM AEDT Chris Lamb wrote:
>> grep-excuses claims:
>>
>> missing build on armel: gnucash, python-gnucash (from 1:2.6.19-1)
>> missing build on mips: gnucash, python-gnucash (from 1:2.6.19-1)
>>
>> Is there a bug for this? (Would you like one?)
> 
> https://bugs.gnucash.org/show_bug.cgi?id=796899
> 
> The problem is likely to be related but slightly different as this time it is 
> the test that fails...
> 

Hello Dimitry, hello Chris,
being just curious, the mips part is from gnucash,
but I cannot make a clue out of the
armel "Not-For-Us" [1] for the build dependeny guile-2.2.
What does that mean?

Kind regards,
Bernhard

[1] https://buildd.debian.org/status/package.php?p=guile-2.2=sid

Bug#914395: Acknowledgement (gpg recv-key fails with no route to host)

[Craig Small]

It appears dirmngr tries to lookup a SRV record and that's the no route to
host error.

Bug#911078: triplea: Fails to start with NullPointerException

[Markus Koschany]

Hello,

Am 22.11.18 um 23:09 schrieb Dan Van Atta:
[...]
>> Presumably the latest Substance binaries have fixed this issue.
> 
> I'm eager for confirmation that this looks to be fixed, I'm happy to
> help with what I can in that effort.

Thank you very much for responding to this bug report. I'm not 100% sure
though what you mean by "the latest Substance binaries have fixed this
issue". In Debian we use a fork of substance called insubstantial.

https://tracker.debian.org/pkg/insubstantial

If I recall correctly the old substance package had some serious issues
and didn't even compile anymore. However insubstantial hasn't received
any updates in the past years either.

https://github.com/Insubstantial/insubstantial

It would be great if you could point us to the aforementioned fix. But
to be honest it would be even greater if you or someone else from the
community lent a helping in hand in keeping triplea up-to-date because I
fear the original uploader/maintainer is no longer active. I have done
the previous updates to keep the game in Debian but it is unlikely that
I will update the game on a more regular basis.

In any case I would sponsor patches and updates or you can also make a
pull request on salsa.debian.org if you prefer that work flow.

http://salsa.debian.org/java-team/triplea

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#913757: python-numpy breaks healpy autopkgtest

[Sandro Tosi]

econtrol: reassign -1 healpy
control: notfound python-numpy/1:1.15.4-1

On Wed, Nov 14, 2018 at 3:57 PM Paul Gevers  wrote:

> === FAILURES
> ===
> __ [doctest] healpy.pixelfunc.reorder
> __
> 332 Examples
> 333 
> 334 >>> import healpy as hp
> 335 >>> hp.reorder(np.arange(48), r2n = True)
> 336 array([13,  5,  4,  0, 15,  7,  6,  1, 17,  9,  8,  2, 19, 11,
> 10,  3, 28,
> 33720, 27, 12, 30, 22, 21, 14, 32, 24, 23, 16, 34, 26, 25,
> 18, 44, 37,
> 33836, 29, 45, 39, 38, 31, 46, 41, 40, 33, 47, 43, 42, 35])
> 339 >>> hp.reorder(np.arange(12), n2r = True)
> 340 array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11])
> 341 >>> print(hp.reorder(hp.ma(np.arange(12.)), n2r = True))
> Expected:
> [0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0]
> Got:
> [  0.   1.   2.   3.   4.   5.   6.   7.   8.   9.  10.  11.]

this is a bug in healpy, that requires update in its test suite: while
it's true numpy changed how it prints nparrays, it looks like healpy
compares what `print` generates, not 2 datastructures.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#914087: mk_cmds: wrong SED path when built on a merged-/usr system and run on a non-merged-/usr system

[Theodore Y. Ts'o]

tags 914087 +pending
thanks

Thanks for reporting this; the following patch will be in the next
version of e2fsprogs.

- Ted

commit b7bb80dc7033776149bb1f33c81a753fe21a2f89
Author: Theodore Ts'o 
Date:   Thu Nov 22 18:01:56 2018 -0500

mk_cmds: don't use explicit pathname for sed

$AWK doesn't use an explicit pathname, and it's perfectly fine to
assume that awk and sed are in the user's PATH.  The problem with
using an explicit pathname is that Debian currently allows merged and
non-merged /usr.  Avoid using an explicit pathname to prevent
potential problems.

Addresses-Debian-Bug: #914087
Signed-off-by: Theodore Ts'o 

diff --git a/lib/ss/mk_cmds.sh.in b/lib/ss/mk_cmds.sh.in
index 6d4873582..53282f4dd 100644
--- a/lib/ss/mk_cmds.sh.in
+++ b/lib/ss/mk_cmds.sh.in
@@ -4,7 +4,7 @@
 
 DIR=@datadir@/ss
 AWK=@AWK@
-SED=@SED@
+SED=sed
 
 for as_var in \
   LANG LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE LC_CTYPE LC_IDENTIFICATION \

Bug#914395: gpg recv-key fails with no route to host

[Craig Small]

Package: gpg
Version: 2.2.11-1
Severity: important


Hello GPG maintainers,
  It seems that gpg will not download keys anymore. I cannot even
download my own key from the Debian keyservers.

While not making the package entirely useless, it's pretty close.
Debugging didn't seem to show anything extra.

I think the GnuPG developers pride themselves on terrible error
messages, they may as well had said unknown error 113 for this one.

 - Craig

csmall@elmo:~$ gpg --keyserver keyring.debian.org --recv-key 0xdf50fea5
gpg: keyserver receive failed: No route to host
csmall@elmo:~$ ping keyring.debian.org
PING keyring.debian.org(kaufmann.debian.org
(2001:41b8:202:deb:1a1a:0:52c3:4b6b)) 56 data bytes
64 bytes from kaufmann.debian.org (2001:41b8:202:deb:1a1a:0:52c3:4b6b):
icmp_seq=1 ttl=44 time=344 ms
^C
--- keyring.debian.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 344.037/344.037/344.037/0.000 ms
csmall@elmo:~$ ping -4 keyring.debian.org
PING kaufmann.debian.org (82.195.75.107) 56(84) bytes of data.
64 bytes from kaufmann.debian.org (82.195.75.107): icmp_seq=1 ttl=46
time=350 ms
64 bytes from kaufmann.debian.org (82.195.75.107): icmp_seq=2 ttl=46
time=352 ms
^C
--- kaufmann.debian.org ping statistics ---
3 packets transmitted, 2 received, 33.% packet loss, time 89ms
rtt min/avg/max/mdev = 349.529/350.605/351.682/1.228 ms



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

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

Versions of packages gpg depends on:
ii  gpgconf2.2.11-1
ii  libassuan0 2.5.1-2
ii  libbz2-1.0 1.0.6-9
ii  libc6  2.27-8
ii  libgcrypt201.8.4-3
ii  libgpg-error0  1.32-3
ii  libreadline7   7.0-5
ii  libsqlite3-0   3.25.3-1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages gpg recommends:
ii  gnupg  2.2.11-1

gpg suggests no packages.

-- no debconf information

Bug#914323: file: non-zero exit code for shared objects on sh4

[Christoph Biedl]

Control: severity 914323 important
Control: retitle 914323 ELF detection croaks on sh4

Andrius Merkys wrote...

> on sh4 many package builds are terminated in dh_shlibdeps stage due to:
>
> dh_shlibdeps: file -e apptype -e ascii -e encoding -e cdf -e compress -e tar 
> <> returned exit code 1

Okay, after many hours I eventually managed to reproduce the problem. Is
very likely limited to sh4 (read: arch where the file program is
executed) but still not an acceptable behaviour.

Christoph


signature.asc
Description: PGP signature

Bug#914394: px: Small typo in package description (uptim -> uptime)

[Salvatore Bonaccorso]

Source: px
Version: 1.0.12-1
Severity: minor
Tags: patch

Hi

There is a small typo in the package description saying 'uptim' where
it should be 'uptime'.

Regards,
Salvatore

Bug#911121: Please compile with CONFIG_SND_BCM2835=m

[Santiago Garcia Mantinan]

Hi!

> I don't have an rpi3 to test, but I wonder if it is really necessary to
> enable CONFIG_SND_BCM2835 to get sound.

After our talk on irc I thought you had commited this change, but a
new version of the kernel has been uploaded and doesn't include this.

What has happened?

Regards.

Bug#914393: keepalived: CVE-2018-19115 heap-based buffer overflow and DoS

[Markus Koschany]

Package: keepalived
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for keepalived.

CVE-2018-19115[0]:
| keepalived before 2.0.7 has a heap-based buffer overflow when parsing
| HTTP status codes resulting in DoS or possibly unspecified other
| impact, because extract_status_code in lib/html.c has no validation of
| the status code and instead writes an unlimited amount of data to the
| heap.

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-2018-19115
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19115

Please adjust the affected versions in the BTS as needed.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#914392: transition: coin3

[Leopold Palomo-Avellaneda]

Subject: transition: coin3
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal

Dear release team,

I would like to ask a transition slot for the coin3 library. The package
has been reworked and a new version of the upstream has been packaged.

Upstream have changed the build system to CMake and this has been used
for the package. This has an implication that it will break with FTBFS
the packages that use it: pivy, freecad, openscenegraph-3.4 and soqt, I
have contacted with all the maintainers and they are aware about it and
we are preparing patches or simple disable in any case.

Coin3 also is affected by one bug #874727 (serious) that have marked the
package to autoremoval. The two bugs of the sources are referring to the
inclusion of a embed copy of expat that in this version is dropped.

In the case of soqt, I have a new version adapted for coin3 with cmake.
When it enter to unstable we will push it.

Best regards,


Leopold

-

Ben file:

title = "coin3";
is_affected = .depends ~
/\b(libcoin\-dev|libcoin\-doc|libcoin\-runtime|libcoin80c|libcoin80\-dev|libcoin80\-doc|libcoin80\-r
is_good = .depends ~
/\b(libcoin\-dev|libcoin\-doc|libcoin\-runtime|libcoin80c)\b/;
is_bad = .depends ~
/\b(libcoin80\-dev|libcoin80\-doc|libcoin80\-runtime|libcoin80v5)\b/;


-- 

--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?





signature.asc
Description: OpenPGP digital signature

Bug#850311: Please upload newer version

[Dererk]

Hi!

Please find suitable upgrading to a newer version of netifaces, since
current one present at the archive breaks i3pystatus .


Thanks!

-- 
BOFH excuse #154:

You can tune a file system, but you can't tune a fish (from most tunefs man 
pages)

Bug#914340: [DAViCal-devel] Bug#914340: webserver sometimes needs to be restarted

[Florian Schlichting]

Hi Daniel,

On Thu, Nov 22, 2018 at 12:35:59PM +0100, Daniel Pocock wrote:
> Warning: CalDAV: No response status doing webdav sync for calendar foo
> Warning: CalDAV: Error doing webdav sync: undefined
> Warning: There has been an error reading data for calendar: foo.
> However, this error is believed to be minor, so the program will attempt
> to continue. Error code: DAV_REPORT_ERROR. Description: There has been
> an error reading data for calendar:
> https://foo.example.org/davical/caldav.php/foo/home/. It has been
> disabled until it is safe to use it.
> Warning: There has been an error reading data for calendar: foo.
> However, this error is believed to be minor, so the program will attempt
> to continue. Error code: READ_FAILED. Description:

I don't remember ever seeing this from Thunderbird for calendars on a
DAViCal server.

> Simply logging into the web server and doing
> 
>   systemctl restart apache2
> 
> resolves the issue and all the clients work again for another week or so.
> 
> Has anybody else observed this?
> 
> Where should I look for additional logging or clues next time this
> happens?  Should I enable any extra logging options in DAViCal, Apache
> or PostgreSQL?

Well I'd start with the Apache logs: when TB says "no response status",
what does Apache think happened with the request, which status did it
log, anything in the error log?

A default install of the davical package pulls in mod_php, which AFAIK
doesn't keep state between requests; do you use a different PHP
interpreter, or something like a Zend server or memcached? Nothing in
the way davical processes or responds to a request should change from a
webserver restart, really...

If you still think davical may be at fault and want to dig deeper, have
a look at https://wiki.davical.org/index.php/Debugging - I'd recommend
setting $c->dbg["ALL"] = 1; and perhaps limiting things to a single
remote IP. The result is fairly verbose but should show you what the
requests and responses look like, and will provide enough detail to pin
down where things go south on the server side.

Florian

Bug#906609: fixed in gnucash 1:3.3-1

[Dmitry Smirnov]

On Thursday, 22 November 2018 9:50:02 AM AEDT Chris Lamb wrote:
> grep-excuses claims:
> 
> missing build on armel: gnucash, python-gnucash (from 1:2.6.19-1)
> missing build on mips: gnucash, python-gnucash (from 1:2.6.19-1)
> 
> Is there a bug for this? (Would you like one?)

https://bugs.gnucash.org/show_bug.cgi?id=796899

The problem is likely to be related but slightly different as this time it is 
the test that fails...

-- 
All the best,
 Dmitry Smirnov.

---

On one level, wisdom is nothing more profound than an ability to follow
one’s own advice.
-- Sam Harris, Waking Up: A Guide to Spirituality Without Religion


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

Bug#914391: octave: "unimplemented function" helper overlooks functions in package subdirectories

[James Van Zandt]

Package: octave
Version: 4.4.1-2+b1
Severity: normal
Tags: upstream

Dear Maintainer,

Octave now has a very helpful feature which points the user to
functions available in packages:

octave:1> help random
error: help: the 'random' function belongs to the statistics package
from Octave
Forge which you have installed but not loaded.  To load the package, run
'pkg load statistics' from the Octave prompt.

However, the feature overlooks some functions.  These are also
provided in the statistics package:

octave:1> help chi2inv
error: help: 'chi2inv' not found
octave:1> help logit
error: help: 'logit' not found
octave:1> help regression
error: help: 'regression' not found

The problem appears to be that the overlooked functions are in
subdirectories of the package.

The message is printed by __unimplemented__.m, in the directory
/usr/share/octave/4.4.1/m/help, which has hard-coded lists of the
functions in each package.  I see nothing in the source package that
generates those lists, so I assume one of the upstream maintainers has
code for that.

Some directories should still be omitted (e.g., self-testing
functions).  I suggest functions in these directories be added to the
lists in __unimplemented__.m:

bsltl/mfiles
geometry/geom2d
geometry/geom3d
geometry/graphs
geometry/io
geometry/meshes3d
geometry/polygons2d
geometry/polynomialCurves2d
geometry/shape2d
geometry/utils
ltfat/auditory
ltfat/blockproc
ltfat/comp
ltfat/demos
ltfat/deprecated
ltfat/filterbank
ltfat/fourier
ltfat/frames
ltfat/gabor
ltfat/mulaclab
ltfat/nonstatgab
ltfat/operators
ltfat/quadratic
ltfat/signals
ltfat/sigproc
ltfat/thirdparty
ltfat/wavelets
statistics/base
statistics/distributions
statistics/models

- Jim Van Zandt


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

Kernel: Linux 4.18.0-2-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)
LSM: AppArmor: enabled

Versions of packages octave depends on:
ii  libamd2  1:5.3.0+dfsg-1
ii  libarpack2   3.6.3-1
ii  libasound2   1.1.7-1
ii  libatlas3-base [liblapack.so.3]  3.10.3-7+b1
ii  libblas3 [libblas.so.3]  3.8.0-1+b1
ii  libbz2-1.0   1.0.6-9
ii  libc62.27-8
ii  libcamd2 1:5.3.0+dfsg-1
ii  libccolamd2  1:5.3.0+dfsg-1
ii  libcholmod3  1:5.3.0+dfsg-1
ii  libcolamd2   1:5.3.0+dfsg-1
ii  libcxsparse3 1:5.3.0+dfsg-1
ii  libfftw3-double3 3.3.8-2
ii  libfftw3-single3 3.3.8-2
ii  libfltk-gl1.31.3.4-7
ii  libfltk1.3   1.3.4-7
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.2.0-9
ii  libglpk404.65-2
ii  libgomp1 8.2.0-9
ii  libklu1  1:5.3.0+dfsg-1
ii  liblapack3 [liblapack.so.3]  3.8.0-1+b1
ii  liboctave6   4.4.1-2+b1
ii  libportaudio219.6.0-1
ii  libqhull72015.2-4
ii  libqrupdate1 1.1.2-3
ii  libqscintilla2-qt5-132.10.4+dfsg-1+b1
ii  libqt5core5a 5.11.2+dfsg-7
ii  libqt5gui5   5.11.2+dfsg-7
ii  libqt5help5  5.11.2-5
ii  libqt5network5   5.11.2+dfsg-7
ii  libqt5opengl55.11.2+dfsg-7
ii  libqt5printsupport5  5.11.2+dfsg-7
ii  libqt5sql5   5.11.2+dfsg-7
ii  libqt5widgets5   5.11.2+dfsg-7
ii  libsndfile1  1.0.28-4
ii  libstdc++6   8.2.0-9
ii  libsuitesparseconfig51:5.3.0+dfsg-1
ii  libumfpack5  1:5.3.0+dfsg-1
ii  libx11-6 2:1.6.7-1
ii  octave-common4.4.1-2
ii  texinfo  6.5.0.dfsg.1-4+b1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages octave recommends:
ii  default-jre-headless   2:1.11-70
ii  epstool3.09-1
ii  gnuplot-x11 [gnuplot-nox]  5.2.5+dfsg1-1
ii  libatlas3-base 3.10.3-7+b1
ii  octave-doc 4.4.1-2
ii  pstoedit   3.73-1+b1

Versions of packages octave suggests:
pn  liboctave-dev  

-- no debconf information

Bug#911078: triplea: Fails to start with NullPointerException

[Dan Van Atta]

Hello! We should have this fixed in our latest stable: 1.9.0.0.13066 (
https://github.com/triplea-game/triplea/releases/latest)

I opened a ticket within the TripleA project for coordination amongst the
TripleA maintainers on this topic:
https://github.com/triplea-game/triplea/issues/4372

@ssoloff, a Triple maintainer, confirmed a fix in the latest version
(quoting from github#4372)
> Using Oracle Java 11.0.1 with a Substance L active, I was able to repro
the NPE at startup using 1.9.0.0.7062 on Fedora. I then ran both
1.9.0.0.13066 and 1.10.0.0.13112 in the same configuration, and no NPE was
observed at startup.

> Presumably the latest Substance binaries have fixed this issue.

I'm eager for confirmation that this looks to be fixed, I'm happy to help
with what I can in that effort.

Bug#913045: [Pkg-alsa-devel] Bug#913045: Bug#913045: Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave

[Eugen Dedu]

reopen 913045
thanks

On Wed, 14 Nov 2018 06:10:35 +0100 Elimar Riesebieter 
 wrote:

* Pedro Silva  [2018-11-13 23:48 +]:

> On Tue, 13 Nov 2018 23:44:35 +0100 Elimar Riesebieter
>  wrote:
> 
> > Heureka!

> >
> > Could you please test also libasound2-plugins 1.1.7-3 which arrived
> 
> $ dpkg -l | grep libasound2 | awk {'print $2,$3'}

> libasound2:amd64 1.1.7-1
> libasound2:i386 1.1.7-1
> libasound2-data 1.1.7-1
> libasound2-dev:amd64 1.1.7-1
> libasound2-plugins:amd64 1.1.7-3
> libasound2-plugins:i386 1.1.7-3
> 
> If ~/.asoundrc doesn't exist, same error:
> 
> ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
> 
> If previous ~/.asoundrc exists, everything works as expected.


Ok, so it seems to be udev's task to set the priority of soundcards.
I can't do more here so I am closing this bug hereby.


Hi Elimar,

I have the same problem: sound has always worked, until installing 1.1.7 
version.  With 1.1.7 I have to write the .asoundrc file to make sound 
work.  This happens on both my laptops.


I might be wrong, but it seems to me that the problem has nothing to do 
with udev...  Do all Debian users (at least those with Intel sound card) 
need to write the .asoundrc file to make sound work again?


Reopening, since I use unstable and 1.1.7-3 does not work without 
.asoundrc file.


Regards,
--
Eugen Dedu
http://eugen.dedu.free.fr

Bug#914256: lintian: conflict between no-template-description and untranslatable-debconf-templates

[Vincent McIntyre]

On Thu, Nov 22, 2018 at 12:24:19PM -0500, Chris Lamb wrote:
> Hi Vincent,
> 
> > E: hello source: not-using-po-debconf
> > E: hello: no-template-description hello/all-languages
> > E: hello: unknown-field-in-templates hello/all-languages _description
> > 
> > So still the same problem.
> 
> Sorry, please let us know exactly versions of Lintian you are using
> rather than "the source package" or similar. It is very easy to get
> them all mixed up and accidentally waste others time, alas.

Apologies.
The tests I just related above with "still the same problem"
were for lintian 2.5.112~bpo9+1.
I was using the source package for version 2.5.112~bpo9+1,
downloaded with 'apt-get source lintian'.
I didn't have any other version of lintian installed.

> > Still unclear why the lintian test cases are not failing.
> 
> I suspect it is something to do with debian/po/ or something like
> that but, again, debconf & translations thereof are not something
> I've ever really played with, sorry.
> 

If I get time to run it down I will update the bug but in the meantime
input from any passing experts would be appreciated.

Kind regards
Vince

Bug#913679: kopete: libjingle-call keeps crashing

[Frank Mehnert]

Same problem here.

The reason are typos in the kopete-17.08.3-openssl-1.1.patch patch which is 
supposed to make the code work with openssl 1.1. There are two places where 
the patch does

+#if OPENSSL_VERSION_NUMBER < 0x1010L
 static BIO_METHOD methods_socket = {
   BIO_TYPE_BIO,
   "socket",
@@ -98,16 +99,36 @@ static BIO_METHOD methods_socket = {
 };

 BIO_METHOD* BIO_s_socket2() { return(_socket); }
+#else
+static BIO_METHOD *methods_socket = NULL;
+
+static const BIO_METHOD * BIO_s_socket2(void) {
+  if (methods_socket == NULL) {
+  methods_socket = BIO_meth_new (BIO_TYPE_BIO | BIO_get_new_index (), 
"socket");
+  if (methods_socket == NULL ||
+  BIO_meth_set_write (methods_socket, socket_write) ||
+  BIO_meth_set_read (methods_socket, socket_read) ||
+  BIO_meth_set_puts (methods_socket, socket_puts) ||
+  BIO_meth_set_gets (methods_socket, 0) ||
+  BIO_meth_set_ctrl (methods_socket, socket_ctrl) ||
+  BIO_meth_set_create (methods_socket, socket_new) ||
+  BIO_meth_set_destroy (methods_socket, socket_free))
+  return NULL;
+}
+  return methods_socket;
+}
+#endif

The problem are the calls to the BIO_meth_set_XXX functions. Here it's an 
error if the return code is 0, not != 0! Therefore a correct patch would look 
like

+#if OPENSSL_VERSION_NUMBER < 0x1010L
 static BIO_METHOD methods_socket = {
   BIO_TYPE_BIO,
   "socket",
@@ -98,16 +99,36 @@ static BIO_METHOD methods_socket = {
 };

 BIO_METHOD* BIO_s_socket2() { return(_socket); }
+#else
+static BIO_METHOD *methods_socket = NULL;
+
+static const BIO_METHOD * BIO_s_socket2(void) {
+  if (methods_socket == NULL) {
+  methods_socket = BIO_meth_new (BIO_TYPE_BIO | BIO_get_new_index (), 
"socket");
+  if (methods_socket == NULL ||
+  !BIO_meth_set_write (methods_socket, socket_write) ||
+  !BIO_meth_set_read (methods_socket, socket_read) ||
+  !BIO_meth_set_puts (methods_socket, socket_puts) ||
+  !BIO_meth_set_gets (methods_socket, 0) ||
+  !BIO_meth_set_ctrl (methods_socket, socket_ctrl) ||
+  !BIO_meth_set_create (methods_socket, socket_new) ||
+  !BIO_meth_set_destroy (methods_socket, socket_free))
+  return NULL;
+}
+  return methods_socket;
+}
+#endif

Again, the patch contains these calls twice so please make sure to fix both 
occurrences. And this problem applies to both kopete 17.08.3-2 (Sid) as well
as to kopete 18.08.3-1.

Please fix these packages because kopete seems to be the only available Jabber 
client on Plasma. Telepathy doesn't work for me...

Thanks!

Frank

Bug#898184: still an issue

[Jade McCormick]

I experience this on an up-to-date buster and it causes problems because I run 
SELinux, and collectd
does not have permission to use the dac_override capability.

I can confirm that the latest master of rrdtool built against collectd fixes 
this problem.
or, vice versa, collectd against the lat

thanks

Bug#890594: salsa script ready to review

[Xavier]

Le 22/11/2018 à 21:06, Xavier a écrit :
> Le 22/11/2018 à 10:19, Xavier a écrit :
>> Le 22/11/2018 à 08:46, Raphael Hertzog a écrit :
>>> Hi,
>>>
>>> On Wed, 21 Nov 2018, Xavier wrote:
 Sorry, I found a SALSA_TEAM in your conf file. For clarity, SALSA_TEAM
 has been replaced by SALSA_GROUP (same for all team commands/options
 replaced by *group*).
>>>
>>> Working much better with SALSA_GROUP ;) But then I got this:
>>>
>>> wapiti:
>>> bad irc channel: #debian-pkg-security
>>>
>>> It was really not clear what was wrong. But it seems that you expect:
>>> SALSA_IRC_CHANNEL=debian-pkg-security
>>>
>>> And not the value that I had put initially:
>>> SALSA_IRC_CHANNEL=#debian-pkg-security
>>>
>>> It seems strange to require to strip the leading hash. I would rather
>>> be more user-friendly: add the leading hash if it's missing, but otherwise
>>> assume that the value is the full name (some channels can start with two
>>> leading hashes). Also the documentation should be clear on this.
> 
> I updated doc for this (also explanation that "#" is considered as
> comment by "sh"). Spelling errors also fixed, thanks !
> 
>> Hello,
>>
>> this is due to sh. This diff explains more:
>> diff --git a/scripts/salsa.pl b/scripts/salsa.pl
>> index 52a174bb..d1751ecf 100755
>> --- a/scripts/salsa.pl
>> +++ b/scripts/salsa.pl
>> @@ -567,9 +567,19 @@ C<.devscripts> values: B
>> (yes/ignore/no, default: ignore)
>>
>>  =item B<--irc-channel>
>>
>> -IRC channel for KGB or Irker.
>> +IRC channel for KGB or Irker. Can me used more than one time only with
>> +B<--irker>.
>>
>> -C<.devscript> value: B
>> +B: channel must not include the first "#". If salsa find a
>> channel
>> +starting with "#", it will consider that channel starts with 2 "#"!
>> +
>> +C<.devscript> value: B.
>> +
>> +Multiple values must be space separated.
>> +
>> +Since configuration files are read using B, be careful when using
>> "#": you
>> +must enclode the channel with quotes, else B will consider it as a
>> comment
>> +and will ignore this value.
>>
>>  =item B<--irker>, B<--no-irker>, B<--disable-irker>
>>
>>> Another detail I noticed, the values of SALSA_EMAIL_RECIPIENTS should 
>>> benefit
>>> from the same substitution as SALSA_DESC_PATTERN so that we can include the
>>> name of the repo in the generated email addresses.
>>
>> OK, I'm going to do this
> 
> Done. Hope salsa works fine now ;-)
> .deb updated
> 
> Cheers,
> Xavier

Last .deb contains the SALSA_RENAME_HEAD. Could you test it ?

Cheers,
Xavier

Bug#913887: libndctl6-dev: please add soname-less -dev Provides:

[Jeremy Bicha]

Control: reopen -1

I think we might as well do it the other way around now. I see that in
Ubuntu, the -dev packages were already named libdaxctl-dev and
libndctl-dev .

The numbered -dev packages have been in Unstable (only) such a short
time I think we don't even need a Provides for the old name.

I did an upload today to the NEW queue of libblockdev which depends on
ndctl but I used the versionless -dev package name.

Other Info
---
So sometimes, we do include version numbers in the -dev package name.
One example is libdazzle. The difference there is that the version
number 1.0 is embedded in the includes file path (
/usr/include/libdazzle-1.0/ ) and in the pkgconfig name
(libdazzle-1.0.pc) and in the Libs field inside the pkgconfig file.

But it's not the soname that's used for the -dev package name. The
-dev package is named libdazzle-1.0-dev and not libdazzle-1.0-0-dev .


Breno, would you like to do this upload or do you want me to do it?

Thanks,
Jeremy Bicha

Bug#914390: linux-image-4.18.0-2-amd64: unable to connect to wpa2-psk secured networks with mwifiex_usb

[Matthias Fritzsche]

Package: src:linux
Version: 4.18.10-2+b1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   * What led up to the situation?

I setup my mobile phone to create a wpa2-psk secured hotspot. Then I told 
NetworkManager or wpa_cli to connect
to this network. NetworkManager showed me the password prompt over and over 
again. wpa_cli showed me that the
key would be wrong.
I experienced this problem already in the past with different wpa2-psk secured 
wireless networks.

   * Wath else did you try?

I tried the debian testing amd64 nonfree live image to make shure it is not a 
problem with settings I did in the
past. I got the same behavior inside the live system. I did also tested a 
fedora 29 amd64 live image to check if
it is a general problem under GNU/Linux. Under fedora I was able to connect to 
my hotspot.

   * What was the outcome of this action?

kernel log:
[ 1557.295735] usb 1-3: info: trying to associate to 'AndroidAP' bssid 
be:44:34:eb:1b:67
[ 1557.314424] usb 1-3: info: associated to bssid be:44:34:eb:1b:67 successfully
[ 1561.335180] usb 1-3: info: successfully disconnected from be:44:34:eb:1b:67: 
reason code 1

wpa_cli log:
<3>CTRL-EVENT-SSID-REENABLED id=2 ssid="AndroidAP"
<3>CTRL-EVENT-SCAN-STARTED 
<3>CTRL-EVENT-SCAN-RESULTS 
<3>WPS-AP-AVAILABLE 
<3>Trying to associate with be:44:34:eb:1b:67 (SSID='AndroidAP' freq=2462 MHz)
<3>Associated with be:44:34:eb:1b:67
<3>CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
<3>CTRL-EVENT-DISCONNECTED bssid=be:44:34:eb:1b:67 reason=1
<3>WPA: 4-Way Handshake failed - pre-shared key may be incorrect
<3>CTRL-EVENT-SSID-TEMP-DISABLED id=2 ssid="AndroidAP" auth_failures=1 
duration=10 reason=WRONG_KEY
<3>CTRL-EVENT-SSID-TEMP-DISABLED id=2 ssid="AndroidAP" auth_failures=2 
duration=37 reason=CONN_FAILED
<3>CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD


   * What outcome did you expect instead?

Staying associated to the wpa2-psk secured WiFi.


- -- Package-specific info:
** Version:
Linux version 4.18.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-30)) #1 SMP Debian 4.18.10-2 (2018-11-02)

** Command line:
BOOT_IMAGE=/vmlinuz-4.18.0-2-amd64 
root=/dev/mapper/txtsurface--vg-debian--amd64 ro rootflags=data=journal 
elevator=deadline zswap.enabled=1 apparmor=1 security=apparmor syscall.x32=y 
kvm-intel.nested=1 quiet

** Not tainted

** Kernel log:
[   14.888684] usb 1-3: Manufacturer: Marvell
[   14.888685] usb 1-3: SerialNumber: 6045BDF91DAA
[   14.908761] usb 1-3: firmware: direct-loading firmware 
mrvl/usb8797_uapsta.bin
[   14.908786] usb 1-3: WLAN FW is active
[   15.052431] Bluetooth: Core ver 2.22
[   15.052456] NET: Registered protocol family 31
[   15.052457] Bluetooth: HCI device and connection manager initialized
[   15.052462] Bluetooth: HCI socket layer initialized
[   15.052464] Bluetooth: L2CAP socket layer initialized
[   15.052471] Bluetooth: SCO socket layer initialized
[   15.060901] usbcore: registered new interface driver btusb
[   15.117608] AVX2 or AES-NI instructions are not detected.
[   15.137950] usb 1-3: CMD_RESP: cmd 0x242 error, result=0x2
[   15.137960] usb 1-3: mwifiex_process_cmdresp: cmd 0x242 failed during
initialization
[   15.157227] usb 1-3: info: MWIFIEX VERSION: mwifiex 1.0 (14.68.29.p49) 
[   15.157231] usb 1-3: driver_version = mwifiex 1.0 (14.68.29.p49) 
[   15.159508] usb 1-3 wlx6045bdf91caa: renamed from mlan0
[   15.180891] alg: No test for xcbc(camellia) (xcbc(camellia-asm))
[   15.230747] IPv6: ADDRCONF(NETDEV_UP): wlx6045bdf91caa: link is not ready
[   15.230883] IPv6: ADDRCONF(NETDEV_UP): wlx6045bdf91caa: link is not ready
[   15.242370] IPv6: ADDRCONF(NETDEV_UP): wlx6045bdf91caa: link is not ready
[   15.267714] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   15.267716] Bluetooth: BNEP filters: protocol multicast
[   15.267720] Bluetooth: BNEP socket layer initialized
[   15.274256] alg: No test for rfc3686(ctr(camellia)) 
(rfc3686(ctr-camellia-aesni))
[   15.319636] IPv6: ADDRCONF(NETDEV_UP): wlx6045bdf91caa: link is not ready
[   15.440704] AVX2 instructions are not detected.
[   18.218833] IPv6: ADDRCONF(NETDEV_UP): wlx6045bdf91caa: link is not ready
[   18.234105] usb 1-3: info: trying to associate to 'chemnitz.freifunk.net' 
bssid c0:3f:0e:7a:88:03
[   18.249082] usb 1-3: info: associated to bssid c0:3f:0e:7a:88:03 successfully
[   18.249604] IPv6: ADDRCONF(NETDEV_CHANGE): wlx6045bdf91caa: link becomes 
ready
[   18.251613] usb 1-3: CMD_RESP: cmd 0x23f error, result=0x2
[   18.452259] Bluetooth: RFCOMM TTY layer initialized
[   18.452267] Bluetooth: RFCOMM socket layer initialized
[   18.452276] Bluetooth: RFCOMM ver 1.11
[   74.337249] tun: Universal TUN/TAP device driver, 1.6
[   78.966483] usb 1-3: CMD_RESP: cmd 0x23f error, result=0x2
[ 1417.371184] usb 1-3: CMD_RESP: cmd 0x23f error, result=0x2
[ 1417.377391] usb 1-3: CMD_RESP: cmd 0x23f error, result=0x2
[ 1417.384775] usb 1-3: info: successfully disconnected from 

Bug#913371: gnat-gps fails to build on 32-bit kernels, address space exhaustion.

[Ludovic Brenta]

I think this is the best way forward.

--
Ludovic Brenta.

Bug#914389: libhtml-calendarmonth-perl FTBFS:

[Adrian Bunk]

Source: libhtml-calendarmonth-perl
Version: 2.04-1
Severity: serious
Tags: ftbfs buster sid

Some recent change in unstable makes libhtml-calendarmonth-perl FTBFS:

https://tests.reproducible-builds.org/debian/history/libhtml-calendarmonth-perl.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libhtml-calendarmonth-perl.html

...
ok
#   Failed test '(2010/03 i8n) Irish Ireland (wb:2) using auto-detect'
#   at /build/1st/libhtml-calendarmonth-perl-2.04/t/testload.pm line 246.
#  got: 'Mrta2010LuanMirtCadDarAoineSathDomh12345678910111213141516171819202122232425262728293031'
# expected: 'Mrta2010DomhLuanMirtCadDarAoineSath12345678910111213141516171819202122232425262728293031'
# Looks like you failed 1 test of 8.
t/20_i8n.t . 
...
Test Summary Report
---
t/20_i8n.t   (Wstat: 256 Tests: 8 Failed: 1)
  Failed test:  2
  Non-zero exit status: 1
Files=10, Tests=1096, 65 wallclock secs ( 0.39 usr  0.09 sys + 25.03 cusr  0.71 
csys = 26.22 CPU)
Result: FAIL
Failed 1/10 test programs. 1/1096 subtests failed.
make[1]: *** [Makefile:841: test_dynamic] Error 255

Bug#914388: Add gzip compression for json mimetype

[Stéphane Blondon]

Package: apache2
Version: 2.4.25
Severity: minor
Tags: patch

Web services get often data in JSON format. The size can be important
but is compressed efficiently because it's text.
So it would be nice to enable the compression with mod_deflate:

--- /etc/apache2/mods-available/deflate.conf2017-09-19
20:56:09.0 +0200
+++ deflate.conf2018-11-22 22:10:54.550445644 +0100
@@ -8,6 +8,7 @@
AddOutputFilterByType DEFLATE application/x-javascript
application/javascript application/ecmascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/xml
+   AddOutputFilterByType DEFLATE application/json

 



signature.asc
Description: OpenPGP digital signature

Bug#914383: debian-policy: re-encode virtual package list in YAML

[Bill Allombert]

On Thu, Nov 22, 2018 at 08:22:42PM +, Jonathan Dowland wrote:
> Convert the plain-text virtual-package-names-list to a structured,
> machine-readable document, encoded in YAML.
> 
> Delete the suffixed ChangeLog. From this point forward, changes to the file
> should be recorded in the version control system in which Policy is 
> maintained.

Hello Jonathan,
Thanks for your effort working on this.

However, the git changelog is not shipped in the policy package, so this
is not a replacement to the enclosed ChangeLog.

Since such virtual package names can appear in the archive before
adoption and after deprecation, it is important that the reader
has access to such changelog in a readable form.

This is especially important because no all virtual packages appear in
this list (due to the "cooperating group of packages" exception) so the
fact that a name does not appear in the list does not mean it is for an
obsolete virtual package.

The changelog could be kept as comment in the YAML file, or maybe better,
the adoption and deprecation date could be simply added to the YAML
data (but this require adding back the obsolete packages to the list).
This way this would be machine readable too.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#914387: python3-pip: cannot import name 'main' from 'pip'

[Alexander William Wong]

Package: python3-pip
Version: 9.0.1-2.3
Severity: important


Dear Maintainer,

I upgraded python3-pip and python3 today.

Running pip3, I see that the wrapper script is broken.
The wrapper script should import from main.__internal__ instead of main.

The paths for pip3 and python3 -m pip --version are the same.

=
$ pip3
Traceback (most recent call last):
  File "/usr/bin/pip3", line 9, in 
from pip import main
ImportError: cannot import name 'main' from 'pip' 
(/home/alexander/.local/lib/python3.7/site-packages/pip/__init__.py)

$ python3 -m pip --version
pip 18.1 from /home/alexander/.local/lib/python3.7/site-packages/pip (python 
3.7)
=


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

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

Versions of packages python3-pip depends on:
ii  ca-certificates20180409
ii  python-pip-whl 9.0.1-2.3
ii  python33.7.1-2
ii  python3-distutils  3.7.1-1

Versions of packages python3-pip recommends:
ii  build-essential 12.5
ii  python3-dev 3.7.1-2
ii  python3-setuptools  40.5.0-1
ii  python3-wheel   0.30.0-0.2

python3-pip suggests no packages.

-- no debconf information

Bug#914301: tmux: CVE-2018-19387: NULL Pointer Dereference in format_cb_pane_tabs in format.c

[Salvatore Bonaccorso]

Hi Romain,

On Thu, Nov 22, 2018 at 06:26:59PM +0100, Romain Francoise wrote:
> Hi Salvatore,
> 
> On Wed, Nov 21, 2018 at 8:57 PM Salvatore Bonaccorso  
> wrote:
> > The following vulnerability was published for tmux, the security
> > impact is disputable, but just filling this bug for tracking a future
> > fix.
> 
> Thanks for the report. Do you know who assigned the CVE id and what
> their reasons were? Also, who noted that there is no security impact
> in the tracker (if that is really the case I'd rather just close this
> bug).

The CVE was assigned by the MITRE CNA itself, but unclear who
requested it.

Regarding the tracker: that was me and Moritz, but I filled this bug
explicitly for trackability of the commit[1] so I can update the fixed
version once it will land in a release. This is as well the reason why
it is marked 'unimportant' to indicate there is no realy (or there is
a negligable) security impact (as well why it is just as minor
severity). So the bug can just be closed as soon [1] lands in an
update.

The "attack" scenario described as follows, that an attacker can cause
a denial of service (tmux crash) by "by arranging for a malloc
failure" triggering the issue in format_cb_pane_tabs in format.c 

Does this helps?

Regards,
Salvatore

 [1] 
https://github.com/tmux/tmux/commit/749f67b7d801eed03345fef9c04206fbd079c3cb

Bug#914386: fritzing FTBFS: arch-only build

[Helmut Grohne]

Source: fritzing
Version: 0.9.3b+dfsg-6
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

While trying to cross build fritzing, I noticed that it fails to build
from source natively. An arch-only build fails:

| find /<>/fritzing-0.9.3b+dfsg/debian/fritzing-data/ -type d -empty 
-delete
| find: '/<>/fritzing-0.9.3b+dfsg/debian/fritzing-data/': No such 
file or directory
| make[1]: *** [debian/rules:28: override_dh_install] Error 1
| make[1]: Leaving directory '/<>/fritzing-0.9.3b+dfsg'
| make: *** [debian/rules:12: binary-arch] Error 2

This happens on the official buildds as well:

https://buildd.debian.org/status/fetch.php?pkg=fritzing=arm64=0.9.3b%2Bdfsg-6=1542881203=0
https://buildd.debian.org/status/fetch.php?pkg=fritzing=armel=0.9.3b%2Bdfsg-6=1542884524=0
https://buildd.debian.org/status/fetch.php?pkg=fritzing=armhf=0.9.3b%2Bdfsg-6=1542882060=0

Looks like you need to conditionalize that command to arch:all builds.

Helmut

Bug#914385: nova: [INTL:de] Updated German debconf translation

[Chris Leick]

Package: nova
Version: 18.0.3-3
Severity: wishlist
Tags: l10n patch


Hi,

please find attached the newest German deconf translation.

Kind regards,
Chris


de.po.gz
Description: application/gzip

Bug#914383: debian-policy: re-encode virtual package list in YAML

[Russ Allbery]

Jonathan Dowland  writes:

> Implemented here:
> 
> 

> I repeat the commit log message here. It's worded in terms of absolutes,
> i.e.  "do this, do that", since that's what the commit does, however,
> please consider this a proposal (which I am advocating for), i.e. "I
> propose converting...", "I suggest deleting..." etc.

> I've been thinking of this for a long time and another situation came up
> this week where I thought it would be helpful so I sat down and did it.

I haven't had a chance to review the details yet, but wanted to send a
quick and immediate reply to say *thank you* and I really appreciate you
tackling this!  I think this general idea would go a long way to making
this data more useful.

Does anyone reading the Policy list know of anything that would *break* if
we converted the virtual package list to a structured form?  I think it's
likely we'll accept this if not, so this is a call for any issues that I'm
not thinking of.

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

Bug#914384: sysstat: CVE-2018-19416: the remap_struct function in sa_common.c has an out-of-bounds read during a memmove call

[Salvatore Bonaccorso]

Source: sysstat
Version: 12.0.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/sysstat/sysstat/issues/196

Hi,

The following vulnerability was published for sysstat.

CVE-2018-19416[0]:
| An issue was discovered in sysstat 12.1.1. The remap_struct function in
| sa_common.c has an out-of-bounds read during a memmove call, as
| demonstrated by sadf.

The poc to verify a fix (base64 encoded here):

ltV1ITAwMDBIAQAAMDAwMAEBMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwAgAAADAwMDkA
AAAC/wAkEDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMAAwMDAwMDAwMDAwMDAwMDAwMDAwMDABMDAwMDAwMAAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw

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-2018-19416
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19416
[1] https://github.com/sysstat/sysstat/issues/196
[2] https://bugzilla.novell.com/show_bug.cgi?id=1117001

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#914383: debian-policy: re-encode virtual package list in YAML

[Jonathan Dowland]

Source: debian-policy
Severity: wishlist
Tags: patch

Implemented here:



I repeat the commit log message here. It's worded in terms of absolutes, i.e.
"do this, do that", since that's what the commit does, however, please consider
this a proposal (which I am advocating for), i.e. "I propose converting...",
"I suggest deleting..." etc.

I've been thinking of this for a long time and another situation came up this
week where I thought it would be helpful so I sat down and did it.



Convert the plain-text virtual-package-names-list to a structured,
machine-readable document, encoded in YAML.

Delete the suffixed ChangeLog. From this point forward, changes to the file
should be recorded in the version control system in which Policy is maintained.

With the exception of the ChangeLog, preserve all the information in the text
version of the document, namely the virtual package name, the description, and
whether or not the virtual-package-provider normally provides an alternative.
The preamble and the section headings are preserved in the form of YAML
comments. The structured document should be just as legible for humans as the
prior version.

We expand the encoding of the alternative to include the binary path(s) that is
expected to be provided.

Rationale:

The current list cannot easily be machine-parsed. It's also likely out of date,
containing virtual package names that are not in use, and missing package names
that are in use. The pre-amble seems out-of-place and might better fit in the
policy document text.

By re-encoding in a machine-readable format, it shall be much easier to:

 • automate checking the status of the virtual package names herein against the
   names in use within the archive (e.g. from a UDD query).
 • check that a package which provides a virtual package name also registers
   paths in the alternatives system, if this document suggests it should (in
   e.g. lintian or some other QA tool)

I envisage many future possibilities, too, such as encoding more properties
about the "interface" of a program name registered as an alternative, such
as command-line arguments that should (or must) be accepted, etc.

The YAML schema is as follows (here in "Kwalify" syntax):

seq:
  - map:
  name: {type: str, required: True}
  description: {type: str, required: True}
  alternatives:
seq:
 - {type: str, required: True}
required: True

Future work:

 • simple tooling in the policy source tree to validate this file against
   the schema
 • house-keeping the list based on the names in use in-archive
 • lintian check for virtual package/alternatives correspondence
 • move the preamble out of this document and into a policy section
 • explore extensions to e.g. encode more properties about the nature of
   program names registered as alternatives


-- 
Jonathan Dowland

Bug#914382: xserver-xorg-core: After starting computer the second display cannot be used when rotated.

[patrick]

Package: xserver-xorg-core
Version: 2:1.19.2-1+deb9u5
Severity: important

Dear Maintainer,

The problem has started since two days ago when I issued "apt update" to my 
computer which found there was a new version of xserver-xorg-core along with 
related packages
In addition to the xserver packages there were others totalling around 40.
The newly installed version of this package is xserver-xorg-core:amd64 
(2:1.19.2-1+deb9u4, 2:1.19.2-1+deb9u5)

The outcome of the installation has been that at startup the second display 
which is rotated 90 degrees would be completely blank. The display settings 
would need to be
manipulated to get the display to come online, and it would only work if not 
rotated. Any attempt to rotate would result in an unusable display.

After a lot of manipulation of settings I was able to get a usable display but 
the settings were lost at next reboot so back to square one.

I am planning to test further by removing the Nvidia graphics card and using 
Intel Graphics to see if the problem is with the NVidia driver.

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th 
Gen Core Processor Integrated Graphics Controller [8086:0402] (rev 06)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
210] [10de:0a65] (rev a2)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.9.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.130-2 (2018-10-27)

Xorg X server log files on system:
--
-rw-r--r-- 1 patrick patrick 32345 Apr 30  2017 
/home/patrick/.local/share/xorg/Xorg.2.log
-rw-r--r-- 1 rootroot51995 Nov 23 08:23 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[13.496] (--) Log file renamed from "/var/log/Xorg.pid-945.log" to 
"/var/log/Xorg.0.log"
[13.497] 
X.Org X Server 1.19.2
Release Date: 2017-03-02
[13.497] X Protocol Version 11, Revision 0
[13.497] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[13.497] Current Operating System: Linux mainpc 4.9.0-8-amd64 #1 SMP Debian 
4.9.130-2 (2018-10-27) x86_64
[13.497] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-8-amd64 
root=UUID=ab926965-2480-4983-b3ce-b9a35eeb46ba ro quiet
[13.497] Build Date: 03 November 2018  03:09:11AM
[13.497] xorg-server 2:1.19.2-1+deb9u5 (https://www.debian.org/support) 
[13.497] Current version of pixman: 0.34.0
[13.497]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[13.497] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[13.497] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Nov 22 21:22:01 
2018
[13.497] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[13.498] (==) No Layout section.  Using the first Screen section.
[13.498] (==) No screen section available. Using defaults.
[13.498] (**) |-->Screen "Default Screen Section" (0)
[13.498] (**) |   |-->Monitor ""
[13.499] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[13.499] (==) Automatically adding devices
[13.499] (==) Automatically enabling devices
[13.499] (==) Automatically adding GPU devices
[13.499] (==) Max clients allowed: 256, resource mask: 0x1f
[13.501] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[13.501]Entry deleted from font path.
[13.503] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[13.503] (==) ModulePath set to "/usr/lib/xorg/modules"
[13.503] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[13.503] (II) Loader magic: 0x55b6b8906e00
[13.503] (II) Module ABI versions:
[13.503]X.Org ANSI C Emulation: 0.4
[13.503]X.Org Video Driver: 23.0
[13.503]X.Org XInput driver : 24.1
[13.503]X.Org Server Extension : 10.0
[13.503] (++) using VT number 7

[13.503] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was 

Bug#914381: libsndfile: CVE-2018-19432

[Salvatore Bonaccorso]

Source: libsndfile
Version: 1.0.28-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/erikd/libsndfile/issues/427

Hi,

The following vulnerability was published for libsndfile.

CVE-2018-19432[0]:
| An issue was discovered in libsndfile 1.0.28. There is a NULL pointer
| dereference in the function sf_write_int in sndfile.c, which will lead
| to a denial of service.

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-2018-19432
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19432
[1] https://github.com/erikd/libsndfile/issues/427

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#914267: mesa: [regression] with Mesa 18.2.5-2 the charackter model in Tomb Raider is no longer rendered.

[Andreas Boll]

Control: tag -1 pending

On Thu, Nov 22, 2018 at 05:15:17PM +0100, Michael Biebl wrote:
> Control: severity -1 serious
> 
> Hi mesa maintainers,
> 
> after further contemplating about this, I think this bug is ugly enough
> and hard to diagnose for our users, that the package should not enter
> testing in this state.
> I'm thus raising the severity to RC which will prevent testing migration
> and also make the bug more visible to users.
> 
> Regards,
> Michael

Thank you all for reporting and tracking down this issue!
I'll upload Michael's workaround asap.

Thanks,
Andreas

Bug#912935: botch: the botch autopkgtest fails with Python 3.7

[Michael Hudson-Doyle]

Ah you're right sorry, it took a few rounds to get it to pass in Ubuntu and
I meant to follow up here and drop the ball. Sorry again!

On Fri, 23 Nov 2018 at 03:51, Johannes Schauer  wrote:

> Hi ,
>
> On Mon, 05 Nov 2018 15:23:39 +1300 Michael Hudson-Doyle <
> mwhud...@debian.org> wrote:
> > The botch autopkgtest fails with Python 3.7 as default, which is now the
> > case in Ubuntu. Fortunately the reason is pretty trivial, patch
> > attached.
>
> thanks for reporting this bug!
>
> But please, when supplying a patch, test the patch before you submit it or
> otherwise I will spend time testing a patch even though it still results
> in a
> FTBFS due to the changes made in the patch.
>
> Alternatively, just point out that the patch you attached was not tested.
>
> Thanks!
>
> cheers, josch
>

Bug#890594: salsa script ready to review

[Xavier]

Le 22/11/2018 à 10:19, Xavier a écrit :
> Le 22/11/2018 à 08:46, Raphael Hertzog a écrit :
>> Hi,
>>
>> On Wed, 21 Nov 2018, Xavier wrote:
>>> Sorry, I found a SALSA_TEAM in your conf file. For clarity, SALSA_TEAM
>>> has been replaced by SALSA_GROUP (same for all team commands/options
>>> replaced by *group*).
>>
>> Working much better with SALSA_GROUP ;) But then I got this:
>>
>> wapiti:
>>  bad irc channel: #debian-pkg-security
>>
>> It was really not clear what was wrong. But it seems that you expect:
>> SALSA_IRC_CHANNEL=debian-pkg-security
>>
>> And not the value that I had put initially:
>> SALSA_IRC_CHANNEL=#debian-pkg-security
>>
>> It seems strange to require to strip the leading hash. I would rather
>> be more user-friendly: add the leading hash if it's missing, but otherwise
>> assume that the value is the full name (some channels can start with two
>> leading hashes). Also the documentation should be clear on this.

I updated doc for this (also explanation that "#" is considered as
comment by "sh"). Spelling errors also fixed, thanks !

> Hello,
> 
> this is due to sh. This diff explains more:
> diff --git a/scripts/salsa.pl b/scripts/salsa.pl
> index 52a174bb..d1751ecf 100755
> --- a/scripts/salsa.pl
> +++ b/scripts/salsa.pl
> @@ -567,9 +567,19 @@ C<.devscripts> values: B
> (yes/ignore/no, default: ignore)
> 
>  =item B<--irc-channel>
> 
> -IRC channel for KGB or Irker.
> +IRC channel for KGB or Irker. Can me used more than one time only with
> +B<--irker>.
> 
> -C<.devscript> value: B
> +B: channel must not include the first "#". If salsa find a
> channel
> +starting with "#", it will consider that channel starts with 2 "#"!
> +
> +C<.devscript> value: B.
> +
> +Multiple values must be space separated.
> +
> +Since configuration files are read using B, be careful when using
> "#": you
> +must enclode the channel with quotes, else B will consider it as a
> comment
> +and will ignore this value.
> 
>  =item B<--irker>, B<--no-irker>, B<--disable-irker>
> 
>> Another detail I noticed, the values of SALSA_EMAIL_RECIPIENTS should benefit
>> from the same substitution as SALSA_DESC_PATTERN so that we can include the
>> name of the repo in the generated email addresses.
> 
> OK, I'm going to do this

Done. Hope salsa works fine now ;-)
.deb updated

Cheers,
Xavier

Bug#914360: Bug #914360: tinc: Random segfault after connection drop

[Bernhard Übelacker]

Hello Maximilian Stein,
maybe the package maintainer can get some information out of that
kernel line, but maybe you can install a core dump collector
like e.g. systemd-coredump.
When the next crash happens you can examine the core by:

coredumpctl list
coredumpctl gdb 

Even better if debug symbols could be installed before. [1]


Now I see one thing - you are running 1.0.35-1, is this
a local rebuilt package or the package from testing?

If the latter with some guessing the location *could* be there:
   0x929d :   movslq 0x98c(%rbx),%rdx

And that would point to following line:
   src/meta.c:44  if(!c->outbuflen) {

But this is just based on the offsets and if the used package
was built by debian.


Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace


apt install devscripts dpkg-dev binutils gdb

wget http://ftp.de.debian.org/debian/pool/main/t/tinc/tinc_1.0.35-1_amd64.deb
wget 
http://snapshot.debian.org/archive/debian-debug/20181008T214825Z/pool/main/t/tinc/tinc-dbgsym_1.0.35-1_amd64.deb
dpkg -i *.deb


mkdir tinc/orig -p
cdtinc/orig
dget http://deb.debian.org/debian/pool/main/t/tinc/tinc_1.0.35-1.dsc
cd ../..


# From #914360:
kernel: [52018.886642] tincd[691]: segfault at 98c ip 557ae018e29d sp 
7c40f5b0 error 4 in tincd[557ae0189000+19000]


0x557ae0189000 - 0x557ae018e29d = 0x529D


benutzer@debian:~$ script -a out.txt -c "gdb -q --args /usr/sbin/tincd"
Reading symbols from /usr/sbin/tincd...Reading symbols from 
/usr/lib/debug/.build-id/5b/0adb3822421ae6a87900b011c2b6af3e355be8.debug...done.
done.
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/tinc/orig/tinc-1.0.35/src
Source directories searched: /home/benutzer/tinc/orig/tinc-1.0.35/src:$cdir:$cwd
(gdb) info target
Symbols from "/usr/sbin/tincd".
Local exec file:
`/usr/sbin/tincd', file type elf64-x86-64.
Entry point: 0x5ac0
...
0x4c90 - 0x0001c922 is .text
...
(gdb) disassemble 0x4c90,0x0001c922
(gdb) q

# grep for 29d
benutzer@debian:~$ grep -i "29d " out.txt 
   0x929d :   movslq 0x98c(%rbx),%rdx 
< looks promising as it uses that 98c offset too
   0x93d8 :  jmpq   0x929d 
   0xd29d :   retq   
   0xe29d :  lea0xf1b2(%rip),%rsi
# 0x1d456
   0x0001029d :je 0xff2a 

   0x0001329d :   mov%rax,0x90(%rbx)
   0x0001629d :   mov%r14,%rdi
   0x0001a29d :push   %rax


(gdb) disassemble /m send_meta
Dump of assembler code for function send_meta:
37  bool send_meta(connection_t *c, const char *buffer, int length) {
   0x9270 <+0>: push   %r12
   0x9272 <+2>: mov%rsi,%r12
   0x9275 <+5>: push   %rbp
   0x9276 <+6>: mov%edx,%ebp
   0x9278 <+8>: push   %rbx
   0x9279 <+9>: mov%rdi,%rbx
   0x927c <+12>:sub$0x10,%rsp
   0x9280 <+16>:mov%fs:0x28,%rax
   0x9289 <+25>:mov%rax,0x8(%rsp)
   0x928e <+30>:xor%eax,%eax

38  int outlen;

39  int result;

40
41  ifdebug(META) logger(LOG_DEBUG, "Sending %d bytes of metadata 
to %s (%s)", length,
   0x9290 <+32>:cmpl   $0x3,0x1ef51(%rip)# 0x281e8 

   0x9297 <+39>:ja 0x93c0 
   0x93c0 <+336>:   mov0x28(%rdi),%r8
   0x93c4 <+340>:   mov(%rdi),%rcx
   0x93c7 <+343>:   lea0x14302(%rip),%rsi# 0x1d6d0
   0x93ce <+350>:   mov$0x7,%edi
   0x93d3 <+355>:   callq  0x8fe0 
   0x93d8 <+360>:   jmpq   0x929d 
   0x93dd <+365>:   nopl   (%rax)

42   c->name, c->hostname);
43
44  if(!c->outbuflen) { 
 would be here maybe with c == NULL ?
   0x929d <+45>:movslq 0x98c(%rbx),%rdx
   0x92a4 <+52>:test   %edx,%edx
   0x92a6 <+54>:jne0x92b6 

45  c->last_flushed_time = now;
   0x92a8 <+56>:mov0x1ef81(%rip),%rax# 0x28230 
   0x92af <+63>:mov%rax,0x9a0(%rbx)

46  }







gdb -q --args /usr/sbin/tincd

set width 0
set pagination off
directory /home/benutzer/tinc/orig/tinc-1.0.35/src

Bug#914380: octave-geometry: invalid DESCRIPTION lines generate errors when installing or removing any Octave package

[James Van Zandt]

Package: octave-geometry
Version: 3.0.0-6+b2
Severity: minor
Tags: patch

Dear Maintainer,

The DESCRIPTION file for this package has invalid lines - continued
lines that do not start with a space.  They generate warning messages
when any Octave package (not just this one) is installed or removed,
as follows:

$ sudo apt-get install octave-ltfat-common
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  octave-ltfat-common
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
13 not fully installed or removed.
Need to get 0 B/2,265 kB of archives.
After this operation, 7,263 kB of additional disk space will be used.
/usr/share/apt-listchanges/apt_listchanges.py:540: FutureWarning:
Possible nested set at position 25
  email_re =
re.compile(r'([a-zA-Z0-9_\+\-\.]+)@(([[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)')
N: Ignoring file '50unattended-upgrades.ucftmp' in directory
'/etc/apt/apt.conf.d/' as it has an invalid filename extension
Selecting previously unselected package octave-ltfat-common.
(Reading database ... 1004163 files and directories currently
installed.)
Preparing to unpack .../octave-ltfat-common_2.3.1+dfsg-1_all.deb ...
Unpacking octave-ltfat-common (2.3.1+dfsg-1) ...
Processing triggers for octave (4.4.1-2+b1) ...
warning: pkg: skipping invalid line in DESCRIPTION file
warning: called from
get_description at line 49 column 9
rebuild at line 52 column 12
pkg at line 540 column 25
warning: pkg: skipping invalid line in DESCRIPTION file
warning: called from
get_description at line 49 column 9
rebuild at line 52 column 12
pkg at line 540 column 25
warning: pkg: skipping invalid line in DESCRIPTION file
warning: called from
get_description at line 49 column 9
rebuild at line 52 column 12
pkg at line 540 column 25
warning: pkg: skipping invalid line in DESCRIPTION file
warning: called from
get_description at line 49 column 9
rebuild at line 52 column 12
pkg at line 540 column 25
Setting up python3 (3.7.1-2) ...


Here's a patch:

--- ../DESCRIPTION 2018-11-22 14:45:21.906419837 -0500
+++ DESCRIPTION 2018-11-22 14:44:35.838331755 -0500
@@ -2,13 +2,13 @@
 Version: 3.0.0
 Date: 27-03-2017
 Author: Juan Pablo Carbajal ,
-Philip Neuhius ,
-Simeon Simeonov ,
-David Legland ,
+ Philip Neuhius ,
+ Simeon Simeonov ,
+ David Legland ,
 Maintainer: Juan Pablo Carbajal 
 Title: Computational Geometry
 Description: Library for geometric computing extending MatGeom functions.
-Useful to create, transform, manipulate and display geometric primitives.
+ Useful to create, transform, manipulate and display geometric primitives.
 Depends: octave (>= 4.0.1)
 Autoload: no
 License: GPLv3+, FreeBSD, Boost v1.0


 - Jim Van Zandt


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

Kernel: Linux 4.18.0-2-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)
LSM: AppArmor: enabled

Versions of packages octave-geometry depends on:
ii  libc62.27-8
ii  libgcc1  1:8.2.0-9
ii  libgomp1 8.2.0-9
ii  liboctave6   4.4.1-2+b1
ii  libstdc++6   8.2.0-9
ii  octave   4.4.1-2+b1
ii  python   2.7.15-3
ii  python-lxml  4.2.5-1

octave-geometry recommends no packages.

octave-geometry suggests no packages.

-- no debconf information

Bug#914188: [debian-mysql] Bug#914188: mariadb-server: Upgrade faild due to 'unknown variable': 'server_audit_file_path=/path/to/audit.log'

[Faustin Lammler]

Marc,
I am not able to reproduce this.

Here are my steps:
- installation of mariadb-server-10.1_10.1.26-0+deb9u1;
- load and activation of the audit plugin:
$ cat /etc/mysql/my.cnf | grep -v ^#
[mysqld]

plugin_load=server_audit=server_audit.so
server_audit_file_path=/var/log/mysql/mariadb_server_audit.log
server_audit_logging=ON

[client-server]

!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/
- restart mariadb and check that plugin is loaded and activated;
- upgrade to mariadb-server-10.1_10.1.37-0+deb9u1;
$ sudo apt-get dist-upgrade
- check that audit plugin is still activated;

Can you give me the content of you /etc/mysql/my.cnf file?
Is it possible that on your system a previous version of mariadb/mysql
was installed (before 10.1.26)?

-- 
Faust

Bug#868551: File conflict between redis-server-dbgsym and redis-tools-dbgsym

[Adrian Bunk]

On Tue, Nov 06, 2018 at 05:51:43PM -0500, Chris Lamb wrote:
> Chris Lamb wrote:
> 
> > > File conflict between redis-server-dbgsym and redis-tools-dbgsym
> > 
> > This (still) affects stable but I fear the fix:
> > 
> >  redis (4:4.0.0-2) unstable; urgency=medium
> > 
> >* Make /usr/bin/redis-server in the main redis-server package a symlink 
> > to
> >  /usr/bin/redis-check-rdb in the redis-tools package.
> > 
> >  Whilst this prevents a wasteful duplication of a binary, it moreover
> >  ensures there are no duplicate debug symbols which was preventing the
> >  simultaneous installation of the redis-server-dbgsym and
> >  redis-tools-dbgsym packages.
> > 
> >  Note that this results in the peculiar (and possibily confusing) 
> > situation
> >  where the main package does not have the main binary anymore, or indeed
> >  any binaries whatsoever. See also the previous parallel attempt at a
> >  symlink changes in 3.2.6-3 which was reverted in 3.2.8-3. Thanks to 
> > Adrian
> >  Bunk for the report. (Closes: #868551)
> >   
> > … is too invasive for a stable update. The version in stable is a
> > little outdated anyway, and the backport is recommended anyway…
> > 
> > Thoughts?
> 
> Gentle ping on this Adrian?

No disagreement from me.

> Regards,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#914140: pytango FTBFS with boost 1.67

[Adrian Bunk]

On Tue, Nov 20, 2018 at 08:10:35AM +, PICCA Frederic-Emmanuel wrote:
> Hello Adrian
> 
> If I look at the current boost1.67, I find this in the 
> boost python package
> 
> https://packages.debian.org/sid/amd64/libboost-python1.67.0/filelist
> 
> and
> 
> https://packages.debian.org/sid/amd64/libboost-python1.67-dev/filelist
> 
> We can find these
> 
> /usr/lib/x86_64-linux-gnu/libboost_python3-py36.a
> /usr/lib/x86_64-linux-gnu/libboost_python3-py36.so
> 
> but only for the python3.6 version and not for 2.7 and 3.7
> 
> previously we had for boost 1.62
> 
> https://packages.debian.org/sid/amd64/libboost-python1.62-dev/filelist
> 
> all python version  add these -pyXY.so files.
> 
> Is it an intended change in the new boost_python package, or a mistake ?

I don't know, adding the boost maintainers to Cc for that.

> This logic -pyXY was  coded in the pytango setup.py, in order to deal with 
> boost_python.
> 
> cheers
> 
> Fred

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#872885: netty-tcnative-1.1: Please migrate to openssl1.1 in Buster

[Moritz Mühlenhoff]

On Sat, Oct 13, 2018 at 08:57:27AM +0200, Moritz Mühlenhoff wrote:
> On Sat, Oct 13, 2018 at 12:32:16AM +0200, Emmanuel Bourg wrote:
> > Le 12/10/2018 à 22:33, Moritz Mühlenhoff a écrit :
> > 
> > > src:tcnetty has been fixed wrt OpenSSL 1.1 and netty-tcnative-1.1 has no
> > > reverse dependencies in the archive. Shall we remove it from the archive?
> > 
> > Actually netty-tcnative-1.1 is still needed by netty-3.9.
> > 
> > There are 3 rdeps left for netty-3.9:
> > - maven-indexer (through aether), but it isn't used and could be removed
> > - tycho (through aether again), I'm working on an upgrade no longer
> > depending on it
> > - libgpars-groovy-java which is used by groovy. I don't have a solution
> > for this one yet.

There's one more reverse dependency of netty-3.9:
async-http-client (which is required by aether)

Cheers,
Moritz

Bug#907640: compiz: Migrating to compiz-reloaded?

[Didier Spaier]

Hello,

On 22/11/2018 19:08, Samuel Thibault wrote:
 > For debian-accessibility: a very interesting feature of 0.8.16 is the
> ability of ezoom to track focus events, which makes it a very effective
> screen magnifier.

I did set that in Slint with Mate 1.18, now the window moves when I type
or use the arrow keys so that the cursor stays on the middle of the
screen (as Alex showed me at a Samedi du Libre) if I zoom.

Very nice, thanks Samuel!

I attach my ~/config/compiz/compizconfig/Desktop.ini. I have done some
settings including to allow compiz to manage the windows, but it's still
WIP, so proposals for enhancements are welcome.

Comments:
1. I had to modify the key bindings for Initiate the Magnifier:
Alt+m => Alt+o
else it conflicted with Toggle Window Negative
2. I modified the keybindings of the Switcher to be able to switch
between the panels and the desktop

Best,

Didier
[core]
as_active_plugins = 
core;decoration;colorfilter;resize;neg;glib;mousepoll;matecompat;obs;move;focuspoll;showmouse;ezoom;mag;switcher;

[zoom]
s0_follow_focus = true

[ezoom]
s0_follow_focus = true

[switcher]
as_prev_key = Disabled
as_next_panel_key = Tab

[mag]
as_initiate = o

Bug#914378: with Python 3.7: RuntimeError: generator raised StopIteration

[Johannes Schauer]

Control: affects -1 + botch

This bug currently lets botch FTBFS on all arches with Python 3.7:

https://buildd.debian.org/status/logs.php?pkg=botch=0.21-8


signature.asc
Description: signature

Bug#914379: nmu: mpich_3.3~rc1-2

[Nicholas Breen]

Subject: nmu: mpich_3.3~rc1-2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

Hi,

The recent upload of mpich during the window where the buildds on some
architectures had a /usr-merged chroot, and the mpich build created
scripts (e.g.  /usr/bin/mpicc.mpich) with shebang lines pointing to
"/usr/bin/bash".  Naturally, this then fails to run on non-/usr-merged
systems.  Now that the buildds have that change reverted, a binNMU
should fix it up.

nmu mpich_3.3~rc1-2 . arm64 armel armhf i386 mips mips64el ppc64el s390x . 
unstable . -m 'Rebuild without usrmerge'

I'm not the mpich maintainer, but I noticed this when it broke the build
of my recent gromacs upload on those architectures - I think this is the
right syntax to additionally request a dep-wait on the rebuilt mpich?

dw gromacs . arm64 armel armhf i386 mips mips64el ppc64el s390x .  unstable . 
-m 'mpich (>= 3.3~rc1-2+b1)'

Thank you.



-- 
Nicholas Breen
nbr...@debian.org

Bug#893319: Emoji crashes

[Ian Eure]

This looks like a dupe of #892611.  Both were reported around the 
same

time, March 2018.

I don’t think this is a GTK bug.  I purged emacs25-gtk and 
installed

emacs25-lucid, and Emacs crashes exactly the same.

Bug#914378: with Python 3.7: RuntimeError: generator raised StopIteration

[Johannes 'josch' Schauer]

Source: python-pygraphviz
Version: 1.4~rc1-1+b2
Severity: grave
Tags: patch
Justification: renders package unusable

Hi,

steps to reproduce:

$ python3 --version
Python 3.7.1
$ python3 -c 'import pygraphviz; A=pygraphviz.AGraph(); A.graph_attr.keys()'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pygraphviz/agraph.py", line 1743, in 
iteritems
ah = gv.agnxtattr(self.handle, self.type, ah)
StopIteration: agnxtattr

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pygraphviz/agraph.py", line 1733, in keys
return list(self.__iter__())
  File "/usr/lib/python3/dist-packages/pygraphviz/agraph.py", line 1736, in 
__iter__
for (k, v) in self.iteritems():
RuntimeError: generator raised StopIteration

This problem does not happen with snapshot 20181121T102052Z but does
happen with snapshot 20181121T232318Z. There is only one change between
chroots made from these two snapshots, the following packages have been
upgraded from version 3.6.7-1 to 3.7.1-1:

libpython3-stdlib, libpython3.6-minimal, libpython3.6-stdlib, python3,
python3-minimal, python3.6, python3.6-minimal

Thus I conclude that this problem was introduced because of the upgrade
of Python from 3.6 to 3.7.

Upstream has a fix here:

https://github.com/pygraphviz/pygraphviz/commit/b5df022700669ae496f65d20dd9cd387d6af948e

I backported that commit on top of the version of python-pygraphviz from
Debian unstable. Please find the patch attached.

I see that this package did not see an upload since January 2017. If you
are okay with me NMU-ing the package for this fix, then please tell me.

Alternatively, this bug can also be fixed by packaging the latest
upstream version 1.5 of pygraphviz which includes the above commit.

Thanks!

cheers, josch
diff -Nru python-pygraphviz-1.4~rc1/debian/changelog 
python-pygraphviz-1.4~rc1/debian/changelog
--- python-pygraphviz-1.4~rc1/debian/changelog  2017-01-08 21:03:20.0 
+0100
+++ python-pygraphviz-1.4~rc1/debian/changelog  2018-11-22 19:31:03.0 
+0100
@@ -1,3 +1,10 @@
+python-pygraphviz (1.4~rc1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix StopIteration with Python 3.7
+
+ -- Johannes 'josch' Schauer   Thu, 22 Nov 2018 19:31:03 
+0100
+
 python-pygraphviz (1.4~rc1-1) unstable; urgency=medium
 
   * New upstream release candidate
diff -Nru 
python-pygraphviz-1.4~rc1/debian/patches/catch_stopiterations_created_by_c_code 
python-pygraphviz-1.4~rc1/debian/patches/catch_stopiterations_created_by_c_code
--- 
python-pygraphviz-1.4~rc1/debian/patches/catch_stopiterations_created_by_c_code 
1970-01-01 01:00:00.0 +0100
+++ 
python-pygraphviz-1.4~rc1/debian/patches/catch_stopiterations_created_by_c_code 
2018-11-22 19:30:55.0 +0100
@@ -0,0 +1,174 @@
+From b5df022700669ae496f65d20dd9cd387d6af948e Mon Sep 17 00:00:00 2001
+From: Dan Schult 
+Date: Thu, 2 Aug 2018 21:32:47 -0400
+Subject: [PATCH] catch StopIterations created by C code
+
+--- a/pygraphviz/agraph.py
 b/pygraphviz/agraph.py
+@@ -374,8 +374,10 @@ class AGraph(object):
+ nh = gv.agfstnode(self.handle)
+ while nh is not None:
+ yield Node(self, nh=nh)
+-nh = gv.agnxtnode(self.handle, nh)
+-raise StopIteration
++try:
++nh = gv.agnxtnode(self.handle, nh)
++except StopIteration:
++return
+ 
+ iternodes = nodes_iter
+ 
+@@ -597,8 +599,10 @@ class AGraph(object):
+ yield Node(self, t)
+ else:
+ yield Node(self, s)
+-eh = gv.agnxtedge(self.handle, eh, nh)
+-raise StopIteration
++try:
++eh = gv.agnxtedge(self.handle, eh, nh)
++except StopIteration:
++return
+ 
+ def neighbors(self, n):
+ """Return a list of the nodes attached to n."""
+@@ -627,8 +631,14 @@ class AGraph(object):
+ yield (e[0], e[1], e.name)
+ else:
+ yield e
+-eh = gv.agnxtout(self.handle, eh)
+-nh = gv.agnxtnode(self.handle, nh)
++try:
++eh = gv.agnxtout(self.handle, eh)
++except StopIteration:
++break
++try:
++nh = gv.agnxtnode(self.handle, nh)
++except StopIteration:
++return
+ elif nbunch in self: # if nbunch is a single node
+ n = Node(self, nbunch)
+ nh = n.handle
+@@ -639,7 +649,10 @@ class AGraph(object):
+ yield (e[0], e[1], e.name)
+ else:
+ yield e
+-eh = gv.agnxtout(self.handle, eh)
++try:
++eh = gv.agnxtout(self.handle, eh)
++

Bug#914377: python3: syntax error in rtupdate hook prevents configuration

[James Van Zandt]

Package: python3
Version: 3.7.1-2
Severity: normal

Dear Maintainer,

python3 fails to configure, as follows:

  $ sudo dpkg --configure python3
  Setting up python3 (3.7.1-2) ...
  running python rtupdate hooks for python3.7...
File "/usr/share/pyzo/pyzo/yoton/clientserver.py", line 81
  def __init__(self, address, async=False, verbose=0):
  ^
  SyntaxError: invalid syntax

  error running python rtupdate hook pyzo
  dpkg: error processing package python3 (--configure):
   installed python3 package post-installation script subprocess returned
error exit status 4
  Errors were encountered while processing:
   python3

This failure may also be the reason I'm getting this warning from dpkg:

N: Ignoring file '50unattended-upgrades.ucftmp' in directory
'/etc/apt/apt.conf.d/' as it has an invalid filename extension

There are actually two such files in that directory, with identical content:

$ ls -l 50*
-rw-r--r-- 1 root root 5407 Oct 17 18:58 50unattended-upgrades.dpkg-backup
-rw-r--r-- 1 root root 5407 Nov 22 08:56 50unattended-upgrades.ucftmp

 - Jim Van Zandt

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

Kernel: Linux 4.18.0-2-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)
LSM: AppArmor: enabled

Versions of packages python3 depends on:
ii  libpython3-stdlib  3.7.1-2
ii  python3-minimal3.7.1-2
ii  python3.7  3.7.1-1

python3 recommends no packages.

Versions of packages python3 suggests:
ii  python3-doc   3.7.1-2
ii  python3-tk3.7.1-1
pn  python3-venv  

-- no debconf information

Bug#914376: kmc: should install to /usr/bin, not /bin

[Ansgar Burchardt]

Source: kmc
Version: 2.3+dfsg-6
Severity: normal

kmc installs programs to /bin.  For a bioinformatics tool this seems
not correct; the programs should be installed to /usr/bin instead.

Ansgar

Bug#907105: Bug#909105: consider switching asciidoctor to Architecture: all

[Joseph Herlant]

Hi Jeremy,

On Thu, Nov 22, 2018 at 6:11 AM Jeremy Bicha  wrote:
> Could you go ahead and do this upload now?

Sorry but I've been waiting for 2 months for the debian-keyring to be
uploaded to be able to upload my packages.
As long as it's not been released with my key I believe I can't upload
my packages.

Good catch on the new upstream release, I'll package it and see if
someone in the ruby team is available to upload the package.

Thanks,
Joseph

Bug#914375: canlock FTCBFS: AC_RUN_IFELSE

[Helmut Grohne]

Source: canlock
Version: 3.0.2-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

canlock fails to cross build from source, because it uses AC_RUN_IFELSE
to determine whether memset_s is available. For simply checking
availability and checking whether the prototype matches,
AC_COMPILE_IFELSE is sufficient. The attached patch adapts the check and
thus makes canlock work with cross compilation. Please consider applying
it.

Helmut
--- canlock-3.0.2.orig/configure.ac
+++ canlock-3.0.2/configure.ac
@@ -161,17 +161,18 @@
 dnl Check whether 'memset_s()' from C11 Annex K is usable
 dnl (Double quoting is used to protect square brackets of source code)
 AC_MSG_CHECKING([for memset_s])
-AC_RUN_IFELSE([AC_LANG_PROGRAM([[
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
   /* Request C11 Annex K */
   #define __STDC_WANT_LIB_EXT1__ 1
   #include 
   char buf[10] = { 1 };
-  errno_t rv;
]],
[
-  rv = memset_s((void*) buf, (size_t) 100,
-0, (size_t) 1);
-  if (rv)  return(-1);
+  #ifndef __STDC_LIB_EXT1__
+  # error memset_s unavailable
+  #endif
+  memset_s((void*) buf, (size_t) 100,
+   0, (size_t) 1);
])],
   [
  AC_MSG_RESULT([yes])

Bug#914374: function gevrnd mistakenly claimed to be "not yet implemented"

[James Van Zandt]

Package: octave
Version: 4.4.1-2+b1
Severity: normal

Dear Maintainer,

Octave claims this function has not yet been implemented for Octave:

octave:4> help gevrnd
error: help: the 'gevrnd' function belongs to the statistics package
from Octave
Forge but has not yet been implemented.

Please read  to learn how you can
contribute missing functionality.

Actually there is an implementation available:

octave:4> addpath /usr/share/octave/packages/statistics-1.4.0
octave:5> help gevrnd
'gevrnd' is a function from the file
/usr/share/octave/packages/statistics-1.4.0/gevrnd.m

 -- Function File: gevrnd (K, SIGMA, MU)
 -- Function File: gevrnd (K, SIGMA, MU, R)
 -- Function File: gevrnd (K, SIGMA, MU, R, C, ...)
 -- Function File: gevrnd (K, SIGMA, MU, [SZ])
 Return a matrix of random samples from the generalized extreme
 value (GEV) distribution with parameters K, SIGMA, MU.
...

The user should be asked to install the octave-statistics package,
then type  "pkg load statistics" at the Octave command line.


 - Jim Van Zandt



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

Kernel: Linux 4.18.0-2-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)
LSM: AppArmor: enabled

Versions of packages octave depends on:
ii  libamd2  1:5.3.0+dfsg-1
ii  libarpack2   3.6.3-1
ii  libasound2   1.1.7-1
ii  libatlas3-base [liblapack.so.3]  3.10.3-7+b1
ii  libblas3 [libblas.so.3]  3.8.0-1+b1
ii  libbz2-1.0   1.0.6-9
ii  libc62.27-8
ii  libcamd2 1:5.3.0+dfsg-1
ii  libccolamd2  1:5.3.0+dfsg-1
ii  libcholmod3  1:5.3.0+dfsg-1
ii  libcolamd2   1:5.3.0+dfsg-1
ii  libcxsparse3 1:5.3.0+dfsg-1
ii  libfftw3-double3 3.3.8-2
ii  libfftw3-single3 3.3.8-2
ii  libfltk-gl1.31.3.4-7
ii  libfltk1.3   1.3.4-7
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8.2.0-9
ii  libglpk404.65-2
ii  libgomp1 8.2.0-9
ii  libklu1  1:5.3.0+dfsg-1
ii  liblapack3 [liblapack.so.3]  3.8.0-1+b1
ii  liboctave6   4.4.1-2+b1
ii  libportaudio219.6.0-1
ii  libqhull72015.2-4
ii  libqrupdate1 1.1.2-3
ii  libqscintilla2-qt5-132.10.4+dfsg-1+b1
ii  libqt5core5a 5.11.2+dfsg-7
ii  libqt5gui5   5.11.2+dfsg-7
ii  libqt5help5  5.11.2-5
ii  libqt5network5   5.11.2+dfsg-7
ii  libqt5opengl55.11.2+dfsg-7
ii  libqt5printsupport5  5.11.2+dfsg-7
ii  libqt5sql5   5.11.2+dfsg-7
ii  libqt5widgets5   5.11.2+dfsg-7
ii  libsndfile1  1.0.28-4
ii  libstdc++6   8.2.0-9
ii  libsuitesparseconfig51:5.3.0+dfsg-1
ii  libumfpack5  1:5.3.0+dfsg-1
ii  libx11-6 2:1.6.7-1
ii  octave-common4.4.1-2
ii  texinfo  6.5.0.dfsg.1-4+b1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages octave recommends:
ii  default-jre-headless   2:1.11-70
ii  epstool3.09-1
ii  gnuplot-x11 [gnuplot-nox]  5.2.5+dfsg1-1
ii  libatlas3-base 3.10.3-7+b1
ii  octave-doc 4.4.1-2
ii  pstoedit   3.73-1+b1

Versions of packages octave suggests:
pn  liboctave-dev  

-- no debconf information

Bug#914373: octave-statistics: accessing installed functions is needlessly obscure

[James Van Zandt]

Package: octave-statistics
Version: 1.4.0-4
Severity: normal

Dear Maintainer,

I'm a long-time user of Matlab.  One of the things that's always
annoyed me is that they put so many functions into toolkits that cost
extra.  I've appreciated that Octave made the statistics functions
available with no extra effort.  So I was disappointed by this:

octave:1> help chi2inv
error: help: 'chi2inv' not found

...even after I had installed the octave-statistics package, which
does include that function:

$dpkg -L octave-statistics | grep chi2inv
/usr/share/octave/packages/statistics-1.4.0/distributions/chi2inv.m

I'm also a long-time user of Debian, so I checked in
/usr/share/doc/octave-statistics/, but found nothing useful.

The Octave info file mentioned chi2inv, without saying how to access
it.

Matlab has a single namespace, so any function for which a license is
available is immediately available.  Eventually I discovered that
Octave has chosen to make functions in extra packages visible only if
explicitly loaded.  This does reduce namespace pollution - but it's a
new concept to people used to Matlab.

Please provide a file /usr/share/doc/octave-statistics/README.Debian
with a note something like

By default installed packages are not available from the Octave
prompt.  The functions from this package can be added to the Octave
path by typing

 pkg load statistics

at the Octave command line.


Please add a similar note for each of the extra packages:

octave-bsltl
octave-communications
octave-control
octave-geometry
octave-gsl
octave-image
octave-image-acquisition
octave-instrument-control
octave-io
octave-ltfat-common
octave-miscellaneous
octave-netcdf
octave-ocs
octave-odepkg
octave-optim
octave-parallel
octave-secs2d
octave-secs3d
octave-sockets
octave-statistics
octave-stk
octave-vibes
octave-zeromq

(determined via "apt-file search PKG_ADD|grep packages")

  - Jim Van Zandt



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

Kernel: Linux 4.18.0-2-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)
LSM: AppArmor: enabled

Versions of packages octave-statistics depends on:
ii  octave 4.4.1-2+b1
ii  octave-io  2.4.12-1

octave-statistics recommends no packages.

octave-statistics suggests no packages.

-- no debconf information

Bug#914372: ttygif: ttygif should be installed to /usr/bin

[Ansgar Burchardt]

Package: ttygif
Version: 1.4.0-1
Severity: normal

The ttygif program is installed as /bin/ttygif.  From the description
it should be installed as /usr/bin/ttygif instead.

Ansgar

PS: The Build-Depends: gcc-8 also looks incorrect as only `gcc` is
called by the Makefile.

Bug#914371: gaffitter: gaffitter should be installed to /usr/bin

[Ansgar Burchardt]

Package: gaffitter
Version: 0.6.0-2
Severity: normal

The package install gaffitter to /bin, but it should be installed to
/usr/bin.  From looking at the Makefile, passing prefix=/usr when
calling `make install` might be enough for this.

Ansgar