Bug#914537: openmw: segfault at start

[psi29a]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Markus,

as it turns out, we're about to have another release 0.45 that has been in
'the-works' for the past month. It's been ready for awhile, we've just been
waiting on PR to make a release video and finish up a write-up.

I'll ask the team if they feel comfortable with a release on Debian (and
eventually Ubuntu) before it's made official.

What is my drop-dead date for getting this in?

Cheers,
Bret
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 6.6.1 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCAAGBQJcWD6TAAoJEMI3e31YTLkwpUYP/2sXgb1p46eRXz0lJVh0
uYfEYnnxUtpsO0WAs1nR5YIytIrC5LtqseQllRbT4VuIFkEyYPuSAVOrDnS/
Pi8KEdxsAGcjuQr/yoidwbWu/cBsIz62JGx9xIjnUi+dyasuPjdPKUOL+WeF
X9j1PnRm06B0Yt8331rA5KiYpNybg1sqwReD7a/BH+4E8+iSkL3lECrb9FHs
bllA4jjqFy+EYEHkCOpbfgoBhGCwkzoayqxGrFb48by7eFF7KnxJR7Kw0su8
K2SNSOJWt0UN2NqQTKPrpr7eCwkDvG6EJwmazarHyqwDlCpS19IOQWPORNnE
qclwwfBQUtDZpsTJS+EI+hhOt0xp06PK5fdSj274pYFrsHsiHlj4n1nGv0Gt
fTNX3SpwAl3sKn9dmlAWDBd3RuF9y4+u9UwATwJzD3CuH/4S6AxDqfD5CLqb
228t8d5Si2RzC095W5PZFsGziKUe3EL79Rmwoj3RSWu7cWT8WKvBCR4xJyeD
DyX/iaL70h85F59dGigqaYcH+yGa1BNtUkeocvihpr2qeDsDgHzZi1olqNyw
Gs97YagH6sOgW8yZErwT0e7C7EKckJ/xfrHTMj0hAuQdXSudFgpmgvlfelUW
UNO/ewKkmv/4D1njejL3Fsp9JVzDVmq5yqMPV2SURt+DjI6nK44k/Q2x1qFm
oxb3
=eEHN
-END PGP SIGNATURE-

Bug#900761: please separate passwd manipulation from the library package, together with expect et al

[Markus Wanner]

On 2/3/19 10:51 PM, Josip Rodin wrote:
> If it's an upstream issue that can't be fixed with packaging, then
> tag it upstream and forward it, as the fine manual teaches you to.

Well, I think of it as a feature, not a bug, so I see no reason to
forward anything.  Think of authlib as a general abstraction layer over
several different ways to manage user accounts.  This certainly includes
the ability to change a users password.

> (I'm not sure why people are so anxious to close bug reports these days...)

The former courier maintainer was blamed to have closed issues too
quickly without really taking care.  I'm trying to avoid that.

Can I take that question as an okay to close the issue, then?

Kind Regards

Markus Wanner



signature.asc
Description: OpenPGP digital signature

Bug#911604: haveged start up fails due to apparmor denying write access to /run/haveged.pid

[Dean Hamstead]

I have having the same issue with sysvinit-core

On Sat, 1 Dec 2018 23:56:10 +0100 Gert  wrote:

> > What helped was adding the line
> > /run/haveged.pid w,
> > to /etc/apparmor.d/local/usr.sbin.haveged
>
> That works, thank you.
> FWIW, I did not have this problem when I used systemd as init.
> I just switched to openrc-init, and then I did.
> I don't know why that would make a difference.
>
> Buster, i386, /bin/sh -> dash, init=/sbin/openrc-init
> haveged 1.9.1-6
> init-system-helpers 1.56
> initscripts 2.92~beta-2
> libc6:i386 2.27-8
> libhavege1:i386 1.9.1-6
> linux-image-4.18.0-2-686-pae 4.18.10-2+b1
> lsb-base 9.20170808
> apparmor-profiles 2.13.1-3
> openrc 0.39-1
> initscripts 2.92~beta-2
>
>

Bug#914537: openmw: segfault at start

[Markus Koschany]

On Sun, 25 Nov 2018 20:15:08 +0100 bret curtis  wrote:
> Thanks Fred!
> 
> We're tracking it upstream. Will keep this bug posted with results.
> 
> https://gitlab.com/OpenMW/openmw/issues/4737

Hello Bret,

we are running out of time for Debian 10 "Buster" because the soft
freeze starts next week. Do you think you can prepare an update in the
next few days to get this fixed? I could sponsor the upload.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#920900: libicu-dev: Command icu-config disappeared from libicu-dev

[Vlastimil Zíma]

Hi guys,

thanks for the responses, I missed the bug in the PyICU itself. But my
problem can't be solved by debian package. I use virtualenv (and tox) to
separate development environment from my system, so the ability to install
pyicu using pip is crucial and can't be bypassed by a debian package.

I'll try to bypass it with environment variables, but that's not going to
be easy way out.

Regards,
Vlastimil

ne 3. 2. 2019 v 15:18 odesílatel László Böszörményi (GCS) 
napsal:

> Control: tags -1 +wontfix
> Control: severity -1 wishlist
>
> Hi Vlastimil,
>
> On Wed, Jan 30, 2019 at 1:45 PM Vlastimil Zima 
> wrote:
> > after upgrading libicu-dev, I can't install PyICU using pip, due to an
> error:
> >
> > FileNotFoundError: [Errno 2] No such file or directory:
> 'icu-config': 'icu-config'
> >
> > I found no replacement of the icu-config, hence I assume the file
> disappeared by an accident.
>  As others pointed out, this is documented at several places. In the
> changelog of the package (build without icu-config)[1], ICU upstream
> (the icu-config tool has been deprecated)[2] and in a bug report of
> PyICU (please use pkg-config to detect icu)[3]. The latter also
> reveals its the PyICU developer who don't want to use the new ICU
> development location method (pkg-config).
> On the other hand, PyICU is packaged and up-to date - you don't have
> to install it via pip. But if you do, according to the PyICU
> maintainer can use environmental variables to help its installation.
>
> Regards,
> Laszlo/GCS
> [1] https://packages.qa.debian.org/i/icu/news/20190124T064926Z.html
> [2] http://site.icu-project.org/download/63
> [3] https://github.com/ovalhub/pyicu/issues/92
> [4] https://packages.qa.debian.org/p/pyicu.html
>

Bug#921345: ITP: python-miio -- Python library for interfacing with Xiaomi smart appliances

[Johannes 'josch' Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes 'josch' Schauer 

* Package name: python-miio
  Version : 0.4.4
  Upstream Author : Teemu Rytilahti 
* URL : https://python-miio.readthedocs.io/
* License : GPL3
  Programming Lang: Python
  Description : Python library for interfacing with Xiaomi smart appliances

This library (and its accompanying cli tool) is used to interface with
devices using Xiaomi’s miIO protocol:

 * Xiaomi Mi Robot Vacuum (miio.vacuum)
 * Xiaomi Mi Home Air Conditioner Companion (miio.airconditioningcompanion)
 * Xiaomi Mi Air Purifier (miio.airpurifier)
 * Xiaomi Aqara Camera (miia.aqaracamera)
 * Xiaomi Mi Smart WiFi Socket (miio.chuangmi_plug)
 * Xiaomi Chuangmi Plug V1 (1 Socket, 1 USB Port) (miio.chuangmi_plug)
 * Xiaomi Chuangmi Plug V3 (1 Socket, 2 USB Ports) (miio.chuangmi_plug)
 * Xiaomi Smart Power Strip V1 and V2 (WiFi, 6 Ports) (miio.powerstrip)
 * Xiaomi Philips Eyecare Smart Lamp 2 (miio.philips_eyecare)
 * Xiaomi Philips LED Ceiling Lamp (miio.ceil)
 * Xiaomi Philips LED Ball Lamp (miio.philips_bulb)
 * Xiaomi Philips Zhirui Smart LED Bulb E14 Candle Lamp (miio.philips_bulb)
 * Xiaomi Philips Zhirui Bedroom Smart Lamp (miio.philips_moonlight)
 * Xiaomi Universal IR Remote Controller (Chuangmi IR) (miio.chuangmi_ir)
 * Xiaomi Mi Smart Pedestal Fan V2, V3, SA1 and ZA1 (miio.fan)
 * Xiaomi Mi Air Humidifier (miio.airhumidifier)
 * Xiaomi Mi Water Purifier (Basic support: Turn on & off) (miio.waterpurifier)
 * Xiaomi PM2.5 Air Quality Monitor (miio.airqualitymonitor)
 * Xiaomi Smart WiFi Speaker (miio.wifispeaker)
 * Xiaomi Mi WiFi Repeater 2 (miio.wifirepeater)
 * Xiaomi Mi Smart Rice Cooker (miio.cooker)
 * Xiaomi Smartmi Fresh Air System (miio.airfresh)
 * Yeelight light bulbs (miio.yeelight)

Bug#920691: lintian gets stuck collecting info after failed objdump-info

[Raphael Hertzog]

On Sat, 02 Feb 2019, Niko Tyni wrote:
> On Mon, Jan 28, 2019 at 07:01:52PM -0800, Felix Lechner wrote:
> > Maybe the pending Perl commit 672eb451 will help? Details in #916313.
> 
> FYI I've just uploaded perl/5.28.1-4 which fixes #916313.

Thanks for the notice, I tried with that version of Perl but the problem I
reported is still present. So it seems unrelated.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#898060: Stall NFS clients: RPC request reserved 84 but used 272

[Salvatore Bonaccorso]

Hi,

These are possibly related to
https://bugzilla.kernel.org/show_bug.cgi?id=202435 mentioning in
https://bugzilla.kernel.org/show_bug.cgi?id=202435#c3 that upstream
commits 53da6a53e1d4 "nfsd4: catch some false session retries" (may
also need preceding 085def3ade52 "nfsd4: fix cached replies to solo
SEQUENCE compounds") likely fix the issue.

Salvatore

Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Didier 'OdyX' Raboud]

Le mardi, 15 janvier 2019, 17.39:00 h CET Bernhard Übelacker a écrit :
> Therefore I raise the question if win32-loader is really supposed
> to work on a secure boot EFI system?

No. This was never implemented. win32-loader needs a new maintainer who is 
willing to tackle exactly these types of problems, and I'm not that person. 
:-/

> If such a system is detected, maybe a warning could be added?

Sure. I suggest this would be done very early, but have no clue how to detect 
such a system. This would also make sense in time for buster. Could you work 
on a patch? Thomas; an idea?

Cheers,
OdyX

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

Bug#921344: No man page

[Louis-Philippe Véronneau]

Package: nextcloud-desktop
Severity: whislist

Dear maintainers,

There is currently no man page for '/usr/bin/nextcloud', although
upstream does publish one.

Cheers!

-- 
  ,''`.
 : :'  : Louis-Philippe Véronneau
 `. `'`  po...@debian.org / veronneau.org
   `-



signature.asc
Description: OpenPGP digital signature

Bug#921015: kamailio 5.2 invalid permissions at run dir cuases several issues

[Victor Seva]

On Fri, 1 Feb 2019 at 14:25, PICCORO McKAY Lenz 
wrote:

> Hi victor, you didnt noted tha i mentiones that i use buster, and i
> mention that only happened when kamailio need to comunicate
> internally.. this means with many modules enables and asterisk in the
> game... and i noted that build from upstream already happened in 5.1
> and 5.2 so seems its a kamailio bug
>

Please, provide a test bed in order to reproduce.

In your bugreport you are claiming that /var/run/kamailio has the wrong
permissions. This is done on sysv or systemd level nothing to do with
kamailio itself.
As I said before, both scripts that the package provides are taking care of
it.

Please, provide detailed info since the default installation works as
expected.

Cheers,
Victor

Bug#920915: outdated docs

[Glenn Strauss]

Yes, you are right that the doc is outdated.  The debian package
installs docs from the lighttpd source tree path doc/outdated/*.txt

We are aware of this issue, but it is non-trivial to correct.

Updated lighttpd SSL doc can be found at:
https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL

Updated lighttpd doc in general can be found at:
https://redmine.lighttpd.net/projects/lighttpd/wiki

Bug#920250: python-pysam ftbfs from source (test failures)

[Andreas Tille]

Hi Michael,

are you aware that it seems that your latest change


htslib (1.9-10) unstable; urgency=medium

  * Bring the libdeflate, GCS, and S3 updates back to unstable.

 -- Michael R. Crusoe   Wed, 16 Jan 2019 05:23:22 
-0800


seems to have broken python-pysam?  I have reported this to upstream[1]
but I have no idea whether your change might be responsible for the
break or not.

Kind regards

  Andreas.


[1] https://github.com/pysam-developers/pysam/issues/761

On Wed, Jan 23, 2019 at 10:44:51AM +0100, Matthias Klose wrote:
> Package: src:python-pysam
> Version: 0.15.2+ds-1
> Severity: serious
> Tags: sid buster
> 
> === FAILURES 
> ===
> _ TestIndexing.test_indexing_to_custom_location_works 
> __
> 
> self =  testMethod=test_indexing_to_custom_location_works>
> 
> def test_indexing_to_custom_location_works(self):
> '''test indexing a file with a non-default location.'''
> 
> index_path = get_temp_filename(suffix='custom.tbi')
> pysam.tabix_index(self.tmpfilename, preset="gff",
>   index=index_path, force=True)
> >   self.assertTrue(checkBinaryEqual(index_path, self.filename_idx))
> E   AssertionError: False is not true
> 
> tests/tabix_test.py:89: AssertionError
>  TestIndexing.test_indexing_with_explict_columns_works 
> _
> 
> self =  testMethod=test_indexing_with_explict_columns_works>
> 
> def test_indexing_with_explict_columns_works(self):
> '''test indexing via preset.'''
> 
> pysam.tabix_index(self.tmpfilename,
>   seq_col=0,
>   start_col=3,
>   end_col=4,
>   line_skip=0,
>   zerobased=False)
> self.assertTrue(checkBinaryEqual(
> >   self.tmpfilename + ".tbi", self.filename_idx))
> E   AssertionError: False is not true
> 
> tests/tabix_test.py:102: AssertionError
> _ TestIndexing.test_indexing_with_preset_works 
> _
> 
> self = 
> 
> def test_indexing_with_preset_works(self):
> '''test indexing via preset.'''
> 
> pysam.tabix_index(self.tmpfilename, preset="gff")
> self.assertTrue(checkBinaryEqual(
> >   self.tmpfilename + ".tbi", self.filename_idx))
> E   AssertionError: False is not true
> 
> tests/tabix_test.py:81: AssertionError
> === warnings summary 
> ===
> /usr/lib/python2.7/dist-packages/Cython/Compiler/Main.py:367
>   /usr/lib/python2.7/dist-packages/Cython/Compiler/Main.py:367: FutureWarning:
> Cython directive 'language_level' not set, using 2 for now (Py2). This will
> change in a later release! File:
> /<>/python-pysam-0.15.2+ds/.pybuild/cpython2_2.7_pysam/build/tests/_compile_test.pyx
> tree = Parsing.p_module(s, pxd, full_module_name)
> 
> .pybuild/cpython2_2.7_pysam/build/tests/AlignmentFile_test.py::TestTruncatedBAM::testTruncatedBamIterator
> 
> /<>/python-pysam-0.15.2+ds/.pybuild/cpython2_2.7_pysam/build/tests/AlignmentFile_test.py:1459:
> UserWarning: no BGZF EOF marker; file may be truncated
> ignore_truncation=True)
> 
> -- Docs: https://docs.pytest.org/en/latest/warnings.html
>  3 failed, 906 passed, 17 skipped, 2 warnings in 60.36 seconds 
> =
> E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd
> /<>/python-pysam-0.15.2+ds/.pybuild/cpython2_2.7_pysam/build;
> python2.7 -m pytest tests
> dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 returned
> exit code 13
> make[1]: *** [debian/rules:32: override_dh_auto_test] Error 25
> make[1]: Leaving directory '/<>/python-pysam-0.15.2+ds'
> make: *** [debian/rules:24: build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#921342: Should recommend liblockfile-bin instead of liblockfile1 for dotlockfile

[Jakob Haufe]

Package: cron-apt
Version: 0.10.0
Severity: normal

dotlockfile moved to liblockfile-bin with 1.09-1, so this should be
adjusted.

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

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

Versions of packages cron-apt depends on:
ii  apt  1.4.9

Versions of packages cron-apt recommends:
ii  cron [cron-daemon]  3.0pl1-128+deb9u1
ii  liblockfile11.14-1+b1
ii  postfix [mail-transport-agent]  3.1.8-0+deb9u1

cron-apt suggests no packages.

-- no debconf information

Bug#921341: systemd: several errors at shutdown, 2-minute timeout

[Vincent Lefevre]

Package: systemd
Version: 240-5
Severity: important

When rebooting after an upgrade, I got several error messages,
with a 2-minute timeout:

Feb 04 13:00:31 cventin systemd[1]: Stopping User Manager for UID 1000...
Feb 04 13:00:31 cventin systemd[1]: Stopping Disk Manager...
Feb 04 13:00:31 cventin systemd[1201]: 
/usr/lib/systemd/user/systemd-exit.service:16: Failed to parse failure action 
specifier, ignoring: exit-force
Feb 04 13:00:31 cventin systemd[1]: Stopping Modem Manager...
Feb 04 13:00:31 cventin systemd[1]: anacron.timer: Succeeded.
Feb 04 13:00:31 cventin systemd[1]: Stopped Trigger anacron every hour.
Feb 04 13:00:31 cventin systemd[1201]: systemd-exit.service: Service lacks both 
ExecStart= and ExecStop= setting. Refusing.
Feb 04 13:00:31 cventin systemd[1201]: Failed to enqueue exit.target job: Unit 
systemd-exit.service has a bad unit file setting.
[...]
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: State 'stop-sigterm' 
timed out. Killing.
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: Killing process 1201 
(systemd) with signal SIGKILL.
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: Killing process 8480 
(pulseaudio) with signal SIGKILL.
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: Killing process 1439 
(gvfsd) with signal SIGKILL.
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: Killing process 1444 
(gvfsd-fuse) with signal SIGKILL.
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: Killing process 22747 
(gpg-agent) with signal SIGKILL.
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: Killing process 19393 
(dirmngr) with signal SIGKILL.
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: Killing process 2206 
(at-spi-bus-laun) with signal SIGKILL.
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: Killing process 2211 
(dbus-daemon) with signal SIGKILL.
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: Killing process 1326 
(dbus-daemon) with signal SIGKILL.
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: Killing process 1436 
(dconf-service) with signal SIGKILL.
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: Killing process 22757 
(gnome-keyring-d) with signal SIGKILL.
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: Main process exited, 
code=killed, status=9/KILL
Feb 04 13:02:31 cventin systemd[1]: user@1000.service: Failed with result 
'timeout'.
Feb 04 13:02:31 cventin systemd[1]: Stopped User Manager for UID 1000.
Feb 04 13:02:31 cventin systemd[1]: Stopping User Runtime Directory 
/run/user/1000...
Feb 04 13:02:31 cventin systemd[28798]: user-runtime-dir@1000.service: Failed 
to attach to cgroup 
/system.slice/system-user\x2druntime\x2ddir.slice/user-runtime-dir@1000.service:
 No such file or directory
Feb 04 13:02:31 cventin systemd[28798]: user-runtime-dir@1000.service: Failed 
at step CGROUP spawning /lib/systemd/systemd-user-runtime-dir: No such file or 
directory
Feb 04 13:02:31 cventin systemd[1]: user-runtime-dir@1000.service: Control 
process exited, code=exited, status=219/CGROUP
Feb 04 13:02:31 cventin systemd[1]: user-runtime-dir@1000.service: Failed with 
result 'exit-code'.
Feb 04 13:02:31 cventin systemd[1]: Stopped User Runtime Directory 
/run/user/1000.
Feb 04 13:02:31 cventin systemd[1]: Removed slice User Slice of UID 1000.
Feb 04 13:02:31 cventin systemd[1]: Stopping Permit User Sessions...
Feb 04 13:02:31 cventin systemd[1]: systemd-user-sessions.service: Succeeded.
Feb 04 13:02:31 cventin systemd[1]: Stopped Permit User Sessions.
Feb 04 13:02:31 cventin systemd[1]: Stopped target Remote File Systems.
Feb 04 13:02:31 cventin systemd[1]: Stopped target Network.
Feb 04 13:02:31 cventin systemd[1]: Stopping Network Manager...
[...]

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.13.2-7
ii  libaudit11:2.8.4-2
ii  libblkid12.33.1-0.1
ii  libc62.28-5
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.6-1
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.6-2
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-3
ii  libkmod2 25-2
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.1.8-4
ii  libseccomp2  2.3.3-3
ii  libselinux1  2.8-1+b1
ii  l

Bug#921340: RM: olive/20181223-1

[Gürkan Myczko]

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

(explain the reason for the removal here)

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

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

Bug#902525: Restoring old title, not really related to chroot being minimal or not

[Santiago Vila]

retitle 902525 FTBFS in buster/sid (failing tests)
thanks

Note: I can offer ssh access to a machine where this happens all the
time using sbuild if you like (please contact me privately for details).

Thanks.

Bug#920250: python-pysam ftbfs from source (test failures)

[Andreas Tille]

Control: forwarded -1 https://github.com/pysam-developers/pysam/issues/761
COntrol: tags -1 upstream help

Bug#921339: Please switch to Ayatana AppIndicator

[Ozzyboshi]

Package: psensor
Version: 1.1.5-1
Severity: wishlist
Tags: patch
User: pkg-ayatana-de...@lists.alioth.debian.org
Usertags: ayatana-appindicator

Dear maintainer(s) of psensor,

find attached a .debdiff that ports your package from building against
Ubuntu's AppIndicator
to building against Ayatana AppIndicator API.

This contribution is part of the Ayatana Indicators shift in Debian.

For more info, see
https://lists.debian.org/debian-devel/2018/03/msg00506.html

Thanks,
Alessio



--
ZE-Light e ZE-Pro: servizi zimbra per caselle con dominio email.it, per tutti i dettagli 
Clicca qui http://posta.email.it/caselle-di-posta-z-email-it/?utm_campaign=email_Zimbra_102014=main_footer/f


Sponsor:
Registra i domini che desideri ed inizia a creare il tuo sito web
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=13323&d=4-2diff -Nru psensor-1.1.5/debian/changelog psensor-1.1.5/debian/changelog
--- psensor-1.1.5/debian/changelog  2016-06-06 20:25:02.0 +0200
+++ psensor-1.1.5/debian/changelog  2019-02-04 10:40:31.0 +0100
@@ -1,3 +1,12 @@
+psensor (1.1.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Switch B-D from libappindicator to libayatana
+  * debian/patches
+   + Add aytana-appindicator.patch. Switch to ayatana3-appindicator
+
+ -- Alessio Garzi   Mon, 04 Feb 2019 10:40:31 +0100
+
 psensor (1.1.5-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru psensor-1.1.5/debian/control psensor-1.1.5/debian/control
--- psensor-1.1.5/debian/control2016-06-06 20:24:39.0 +0200
+++ psensor-1.1.5/debian/control2019-02-04 10:40:31.0 +0100
@@ -11,7 +11,7 @@
debhelper (>= 9),
gettext,
help2man,
-   libappindicator3-dev,
+   libayatana-appindicator3-dev,
libatasmart-dev [!hurd-any !kfreebsd-any],
libcurl4-gnutls-dev,
libgtk-3-dev,
diff -Nru psensor-1.1.5/debian/patches/ayatana-appindicator.patch 
psensor-1.1.5/debian/patches/ayatana-appindicator.patch
--- psensor-1.1.5/debian/patches/ayatana-appindicator.patch 1970-01-01 
01:00:00.0 +0100
+++ psensor-1.1.5/debian/patches/ayatana-appindicator.patch 2019-02-04 
10:40:31.0 +0100
@@ -0,0 +1,42 @@
+Index: psensor-1.1.5/configure.ac
+===
+--- psensor-1.1.5.orig/configure.ac
 psensor-1.1.5/configure.ac
+@@ -106,9 +106,9 @@ AC_SUBST(LIBNOTIFY_LIBS)
+ # Checks AppIndicator 
+ APPINDICATOR_LIBS=
+ 
+-PKG_CHECK_MODULES(APPINDICATOR, appindicator3-0.1,
++PKG_CHECK_MODULES(APPINDICATOR, ayatana-appindicator3-0.1,
+  [AC_DEFINE([HAVE_APPINDICATOR],[1],[Use AppIndicator3-0.1])],
+- [AC_MSG_WARN(AppIndicator 3-0.1 not present")])
++ [AC_MSG_WARN(Ayatana AppIndicator 3-0.1 not present")])
+ 
+ if test "$APPINDICATOR_LIBS" == ""; then
+PKG_CHECK_MODULES(APPINDICATOR, 
+Index: psensor-1.1.5/src/ui_appindicator.c
+===
+--- psensor-1.1.5.orig/src/ui_appindicator.c
 psensor-1.1.5/src/ui_appindicator.c
+@@ -21,7 +21,7 @@
+ #include 
+ 
+ #include 
+-#include 
++#include 
+ 
+ #include "cfg.h"
+ #include "psensor.h"
+Index: psensor-1.1.5/src/ui.h
+===
+--- psensor-1.1.5.orig/src/ui.h
 psensor-1.1.5/src/ui.h
+@@ -27,7 +27,7 @@
+ #include 
+ 
+ #if defined(HAVE_APPINDICATOR) || defined(HAVE_APPINDICATOR_029)
+-#include 
++#include 
+ #endif
+ 
+ #include "psensor.h"
diff -Nru psensor-1.1.5/debian/patches/series 
psensor-1.1.5/debian/patches/series
--- psensor-1.1.5/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ psensor-1.1.5/debian/patches/series 2019-02-04 10:40:31.0 +0100
@@ -0,0 +1 @@
+ayatana-appindicator.patch

Bug#921338: r-cran-taxize: autopkgtest regression

[Graham Inggs]

Source: r-cran-taxize
Version: 0.9.5+dfsg-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Since the upload of 0.9.5+dfsg-1 to unstable, r-cran-taxize has been 
failing its own autopkgtests [1] with the following error:


> library("taxize")
> test_check("taxize")
Error in library("vcr") : there is no package called 'vcr'
Calls: test_check ... source_dir -> lapply -> FUN -> eval -> eval -> library
Execution halted

This appears to be a missing test dependency on r-cran-vcr, however a 
similar error occurred in r-cran-natserv (#921211) and perhaps the 
solution is for r-cran-natserv to depend on r-cran-vcr.


Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-taxize/unstable/amd64/

Bug#912696: emacs: default emacs X11 window is very small

[Matthias Scheler]

Hello,

this is not a Debian specific bug. The same happens under Fedora
(see https://bugzilla.redhat.com/show_bug.cgi?id=1353063) and
with Emacs built from "pkgrsc". It seems to be related to GTK+ 3
because building Emacs 26.1 using GTK+ 2 avoids the problem.

Kind regards

-- 
Matthias Scheler https://zhadum.org.uk/

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Andreas Tille]

Another comment: For libsmithwaterman I added a patch for automake including
pkg-config input.  I'd consider it more flexible than a fixed Makefile.

On Mon, Feb 04, 2019 at 12:02:37PM +0100, Fabian Klötzl wrote:
> As promised, I pushed my packaging attempt. However, I didn't manage to
> create a repository under med-team, thus it is under my account [1].
> 
> Best
> Fabian
> 
> 1: https://salsa.debian.org/kloetzl-guest/libmurmurhash
> 
> 
> 

-- 
http://fam-tille.de

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Andreas Tille]

Hi Fabian,

thanks a lot.  I've moved it to med-team and fixed Vcs fields.
If you issue an ITP I can sponsor the package immediately.

Thanks for your work on this

  Andreas.

On Mon, Feb 04, 2019 at 12:02:37PM +0100, Fabian Klötzl wrote:
> As promised, I pushed my packaging attempt. However, I didn't manage to
> create a repository under med-team, thus it is under my account [1].
> 
> Best
> Fabian
> 
> 1: https://salsa.debian.org/kloetzl-guest/libmurmurhash
> 
> 
> 

-- 
http://fam-tille.de

Bug#921291: openhft-chronicle-bytes: FTBFS on i386

[Andreas Beckmann]

On 2019-02-04 11:13, Adrian Bunk wrote:
>> openhft-chronicle-bytes FTBFS in a i386 pbuilder chroot, while it builds
>> successfully in an amd64 pbuilder chroot.
> 
> Why is FTBFS on a binary-all package on !amd64 itself an RC bug?

I haven looked in detail in the FTBFS. It just smells fishy ...
Feel free to downgrade ...


Andreas

Bug#921337: RFP: python-akismet -- client for the Wordpress Akismet spam-detection service

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

Package name: python-akismet
Version : 1.0.1
Upstream Author : Michael Foord and James Bennett
URL : https://github.com/ubernostrum/akismet
License : BSD-3-clause
Programming Lang: Python
Description : client for the Wordpress Akismet spam-detection service

Python library wrapping the Wordpress Akismet spam-detection service.
All methods of the Akismet API are supported:
 - Checking comments for spam
 - Reporting comments incorrectly classified as not spam
 - Reporting comments incorrectly classified as spam
Use of this module requires an Akismet API key (which must be obtained
from the Akismet service).

This is an optional dependency for Weblate.

Bug#921336: RFP: python-bidi -- bi-directional layout implementation

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

Package name: python-bidi
Version : 0.4.0
Upstream Author : Meir Kriheli 
URL : https://github.com/MeirKriheli/python-bidi
License : LGPL3
Programming Lang: Python
Description : bi-directional layout implementation

Bi-directional (BiDi) layout implementation in pure python.

This is an optional dependency for Weblate.

Bug#916758: Accepted emacs 1:26.1+1-3.2 (source amd64 all) into unstable, unstable

[Holger Levsen]

Hi Andreas,

On Mon, Feb 04, 2019 at 01:00:13AM +, Andreas Beckmann wrote:
> Source: emacs
> Version: 1:26.1+1-3.2
> Closes: 916758
> Changes:
>  emacs (1:26.1+1-3.2) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>  .
>* Add more transitional packages for ancient versioned packages
>  emacs21{,-nox}, emacs22{,-gtk,-nox}.  (Closes: #916758)

in #916758 you wrote:

--- begin ---
These were additional emacs variants available in lenny that may have
survived upgrading on a long-grown system.

I'm doing piuparts tests simulating such long grown systems locally and
would expect to find some ancient packages that break once a modern
emacs gets installed. So we would generate a list of Breaks against
cruft packages that would need to be added to the appropriate modern
emacs package.
--- end ---

in other words - and please correct me if I'm wrong - you added
long gone transitional packages back only to make some (more or less)
pointless upgrades from lenny behave better today?

I'm really not sure this is a sensible approach. Usually we try to get
rid off transitional packages, not to add new ones???!

lenny was released almost exactly 10 years ago. We should let it go.


-- 
tschüß,
Holger

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


signature.asc
Description: PGP signature

Bug#921047: netdata: mysql plugin requires further post-install work

[Daniel Baumann]

retitle 921047 mysql plugin needs configuration
priority 921047 minor
thanks

Hi,

thank you for reporting this. Yes, the db plugins generally need 
configuration to properly work. This is not just the case for mysql, but 
also for postgresql.


At work we always create a 'dummy' read-only user for this, using any 
privileged accounts is out of the question (as you rightly pointed out).


I'm not sure we can do anything about this other than documenting it in 
README.Debian or so. The "right thing" to do here would be to have a 
common read-only, unprivileded user for this on all DBs in debian.. but 
that would require much work/not sure everyone would want that.


I'll leave the bug open for now, think about it some more.. and probably 
end up putting a note in README.Debian.. or do you have any better 
suggestions?


Regards,
Daniel

Bug#921279: netdata: systemd service file contains ExecReload but upstream does not support reloading

[Daniel Baumann]

tag 921279 + pending
thanks

Hi,

thanks for reporting this.. yes, the systemd unit is on my todo[0] to 
work out the differences between upstream and the debian package (which 
for historical reasons provides its own service unit at the moment).


Regards,
Daniel

[0] https://salsa.debian.org/debian/netdata/blob/experimental/debian/TODO

Bug#921333: sysv-rc: move README files out of /etc

[Dmitry Bogatov]

Package: initscripts
Version: 2.93-5
Severity: wishlist

Dear Maintainer,

please consider moving README files out of /etc. Presence of README
files in /etc requires unneeded corner-cases in regard of conffiles and
dh_fixperms.


Probably (not sure, they are needed) compatibilty symbolic links could
be added.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=eo.utf8, LC_CTYPE=eo.utf8 (charmap=UTF-8), LANGUAGE=eo.utf8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages initscripts depends on:
ii  coreutils   8.30-1
ii  debianutils 4.8.6.1
ii  lsb-base10.2018112800
ii  mount   2.33.1-0.1
ii  sysv-rc 2.93-5
ii  sysvinit-utils  2.93-5

Versions of packages initscripts recommends:
ii  e2fsprogs  1.44.5-1
pn  psmisc 

initscripts suggests no packages.

-- Configuration Files:
/etc/default/rcS changed:
VERBOSE=yes

/etc/default/tmpfs changed:
TMPFS_SIZE=512m


-- no debconf information


pgphIDrpYwjCe.pgp
Description: PGP signature

Bug#921335: RFP: celery-batches -- task class that buffers messages and processes them as a list

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

Package name: celery-batches
Version : 0.2
Upstream Author : Ask Solem & contributors
URL : https://github.com/percipient/celery-batches
License : BSD-3-Clause
Programming Lang: Python
Description : task class that buffers messages and processes them  
as a list


Celery Batches provides a Task class that allows processing of multiple Celery
task calls together as a list. The buffer of tasks calls is flushed on a timer
and based on the number of queued tasks.

This is a dependency for Weblate.

Bug#917086: [debian-mysql] Bug#917086: Bug#917086: mariadb-client-10.3: Can't locate Term/ReadKey.pm in @INC

[Otto Kekäläinen]

Hello!

ma 4. helmik. 2019 klo 12.31 Olaf van der Spek (olafvds...@gmail.com) kirjoitti:
>
> Op vr 1 feb. 2019 om 11:09 schreef Otto Kekäläinen :
> >
> > I agree that having mytop (or mariadbtop) in a separate package would
> > make sense. I am not even fully familiar what the original upstream
> > story is and who is maintaining the "most upstream" version of it
> > currently.
>
> Great. Do you know what's missing from
> https://salsa.debian.org/olafvdspek-guest/mariadb-10.3/commit/55d06886f5a81c10a00822078aac3ea0090c1b7f
> to split mytop?

hmm, no comments comes to my mind. Did you research the state of
https://tracker.debian.org/pkg/mytop - should mytop be a completely
different package as it was?

> BTW, have you seen
> https://salsa.debian.org/mariadb-team/mariadb-10.3/merge_requests/12 ?

Sorry, was busy in FOSDEM. Reviewed now.

Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Pierre Ynard]

> > udev (not even original systemd software) [...] (and unlike init,
> > there's no alternative to it)
>
> The Devuan people would like to introduce you to vdev
> .
>
> Laurent Bercot would like to introduce you to mdevd
> .
>
> I have service bundles for four different Linux plug-and-play managers
> 
> in the nosh toolset.

Yes, thank you for clarifying this!

Personally I really don't have much of a use case for plug-and-play.
Rather, the way I look at it is how to avoid unwanted components that
get pulled on my system. And unfortunately as far as I can see, none
of these alternatives are packaged in Debian, and more importantly,
packages like xserver-xorg-core for example declare a hard dependency on
udev with no alternative mechanism.

If you want to know, these alternatives are something I suggested in my
udev rant: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827704 You
can see where that went.

> Almost everything in *lots* of pseudo-user directories under /usr was
> the actual classical Unix way.

And there's also the pattern of packages installing their files into
their own private hierarchy under /opt/// ... much
like what happens under \Program Files\ on Microsoft Windows, the
rationale being, it's well-suited to avoid collisions without central
coordination.

Regards,

-- 
Pierre Ynard

Bug#909510: [PATCH] New tag: script-uses-unversioned-python-in-shebang

[Dmitry Bogatov]

  * checks/python.desc: Add description for new tag
  * checks/python.pm: check shebang of script for references
to unversioned python, either directly or via /usr/bin/env.
  * t/tags/tests/python-script-uses-unversioned-python-in-shebang: new
test directory.
---
 checks/python.desc | 18 ++
 checks/python.pm   | 12 
 .../debian/control.in  | 16 
 .../debian/install |  1 +
 .../debian/rules   |  4 
 .../debian/script-bad1 |  1 +
 .../debian/script-bad2 |  1 +
 .../debian/script-good1|  1 +
 .../debian/script-good2|  1 +
 .../desc   |  6 ++
 .../tags   |  6 ++
 11 files changed, 67 insertions(+)
 create mode 100644 
t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/control.in
 create mode 100644 
t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/install
 create mode 100755 
t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/rules
 create mode 100644 
t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/script-bad1
 create mode 100644 
t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/script-bad2
 create mode 100644 
t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/script-good1
 create mode 100644 
t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/script-good2
 create mode 100644 
t/tags/tests/python-script-uses-unversioned-python-in-shebang/desc
 create mode 100644 
t/tags/tests/python-script-uses-unversioned-python-in-shebang/tags

diff --git a/checks/python.desc b/checks/python.desc
index f8d73e4fd..2837aedb9 100644
--- a/checks/python.desc
+++ b/checks/python.desc
@@ -198,3 +198,21 @@ Info: This source package encodes a Python version in its 
name such
  .
  Please override this tag with a suitably-commented override if
  there is no single upstream codebase that supports both versions.
+
+Tag: script-uses-unversioned-python-in-shebang
+Severity: wishlist
+Certainty: certain
+Info: The package contain script with unversion python shebang.
+ There is discussion in python community to recommend soft-linking
+ python to python3 on newer distributions.
+ .
+ If and when Debian start following this recommendation, the script
+ will be broken.
+ .
+ The 2.x series of Python is due for deprecation and will not be maintained
+ by upstream past 2020 and will likely be dropped after the release of
+ Debian "buster".
+ .
+ If upstream have not moved or have no intention to move to Python 3, please
+ be certain that Debian would benefit from the continued inclusion of this
+ package and, if not, consider removing it.
diff --git a/checks/python.pm b/checks/python.pm
index ea1545254..0a6a2eb6d 100644
--- a/checks/python.pm
+++ b/checks/python.pm
@@ -246,6 +246,18 @@ sub _run_binary {
 }
 }
 
+# Check for unversioned python shebang (#909510).
+for my $file ($info->sorted_index) {
+next unless $file->is_file;
+next unless $file->is_open_ok;
+next unless $file =~ m,(usr/)?bin/[^/]+,;
+my $fd = $file->open();
+my $line = <$fd>;
+tag 'script-uses-unversioned-python-in-shebang', $file
+if $line =~ m,^#!\s*(/usr/bin/env\s*)?(/usr/bin/)?python$,;
+close($fd);
+}
+
 return;
 }
 
diff --git 
a/t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/control.in
 
b/t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/control.in
new file mode 100644
index 0..6bae81f3e
--- /dev/null
+++ 
b/t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/control.in
@@ -0,0 +1,16 @@
+Source: {$source}
+Priority: optional
+Section: mail
+Maintainer: {$author}
+Standards-Version: {$standards_version}
+Build-Depends: {$build_depends}
+Rules-Requires-Root: no
+
+Package: prog-{$source}
+Architecture: {$package_architecture}
+Depends: $\{misc:Depends\}, python, python2.7
+Description: Package with Python script with bad shebang
+ This is a test package designed to exercise some feature or tag of
+ Lintian.  It is part of the Lintian test suite and may do very odd
+ things.  It should not be installed like a regular package.  It may
+ be an empty package.
diff --git 
a/t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/install 
b/t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/install
new file mode 100644
index 0..05e2b7892
--- /dev/null
+++ 
b/t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/install
@@ -0,0 +1 @@
+debian/script-* /usr/bin
diff --git 
a/t/tags/tests/python-script-uses-unversioned-python-in-shebang/debian/rules 
b/t/tags/tests/python-

Bug#601054: add comments to /etc/init.d/.depend.* saying what program put them there

[Dmitry Bogatov]

[2019-02-02 11:38] Jesse Smith 
> On 2/2/19 6:26 AM, Dmitry Bogatov wrote:
> > I believe we already discussed this issue and came to conclusion, that
> > the right thing to do would be to generate .depends files in
> > /var/lib/insserv and adjust `startpar' accordingly.
>
> Someone suggested doing this, it was an option on the table. But no
> agreement has been come to so far as I know.

I take off my Debian hat, and as regular user ask you, upstream
maintainer, can you please .depends files from /etc/ to /var, to improve
compliance with FHS.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#921334: devscripts: git checkout FTBFS

[Dmitry Bogatov]

Package: devscripts
Version: 2.19.2
Severity: normal
Control: blocks 841270 by -1

While working on patch to include debrequest into devscripts (#841270),
I discovered that I can't proceed due failing test suite.

What is more interesting, test suite from v2.19.2 tag can fail on my
machine for multitude reasons:

 * commit.gpgsign = True in ~/.gitconfig breaks test suite
 * core.fsmonitor = fsmonitor-watchman in ~/.gitconfig breaks test suite
 * unshare -rn dpkg-buildpackage -us -uc fails (see attached log)
 * dpkg-buildpackage -us -uc seems to perform online tests (on my very
   poor connection) and fails too (10 minutes after, no log, sorry)

Can you please provided guidance, how can I add debrequest script
without dealing with complexities (and overhead) of test suites of other
scripts?

dpkg-buildpackage: info: source package devscripts
dpkg-buildpackage: info: source version 2.19.2
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Mattia Rizzolo 

dpkg-buildpackage: info: host architecture amd64
dh clean --with python3
   dh_auto_clean
make -j4 clean
make[1]: Entering directory '/home/iu/devel/salsa/debian/devscripts'
# Update the POT/POs and remove the translated man pages
make -C po4a/ clean
make[2]: Entering directory '/home/iu/devel/salsa/debian/devscripts/po4a'
# po4a translate and clean need ../doc/devscripts.1, rebuild it
make -C ../doc devscripts.1
make[3]: Entering directory '/home/iu/devel/salsa/debian/devscripts/doc'
cat devscripts.1.in > devscripts.1.tmp.29213-29212
cat ../README | \
awk '/^- annotate-output/,/^  mailing lists./'|sed -e 
'/^[[:space:]]*$/d' -e 's/^/ /g' | \
perl genmanpage.pl \
>> devscripts.1.tmp.29213-29212
mv devscripts.1.tmp.29213-29212 devscripts.1
make[3]: Leaving directory '/home/iu/devel/salsa/debian/devscripts/doc'
po4a --previous --rm-translations --no-backups devscripts-po4a.conf
 (3445 elementoj)
rm -f fr/bts.fr.1 fr/build-rdeps.fr.1 fr/chdist.fr.1 fr/dcontrol.fr.1 
fr/debcheckout.fr.1 fr/debcommit.fr.1 fr/deb-reversion.fr.1 
fr/desktop2menu.fr.1 fr/dget.fr.1 fr/mass-bug.fr.1 fr/mk-build-deps.fr.1 
fr/mk-origtargz.fr.1 fr/namecheck.fr.1 fr/rmadison.fr.1 fr/sadt.fr.1 
fr/svnpath.fr.1 fr/tagpending.fr.1 fr/origtargz.fr.1 fr/transition-check.fr.1 
fr/who-permits-upload.fr.1 fr/git-deborig.fr.1 fr/hardening-check.fr.1 
de/bts.de.1 de/build-rdeps.de.1 de/chdist.de.1 de/dcontrol.de.1 
de/debcheckout.de.1 de/debcommit.de.1 de/deb-reversion.de.1 
de/desktop2menu.de.1 de/dget.de.1 de/mass-bug.de.1 de/mk-build-deps.de.1 
de/mk-origtargz.de.1 de/namecheck.de.1 de/rmadison.de.1 de/sadt.de.1 
de/svnpath.de.1 de/tagpending.de.1 de/origtargz.de.1 de/transition-check.de.1 
de/who-permits-upload.de.1 de/git-deborig.de.1 de/hardening-check.de.1 translate
rm -rf de fr
make[2]: Leaving directory '/home/iu/devel/salsa/debian/devscripts/po4a'
rm -f translated_manpages
make -C scripts/ clean
make -C doc clean
make[2]: Entering directory '/home/iu/devel/salsa/debian/devscripts/doc'
rm -f devscripts.1 devscripts.1.tmp.*
make[2]: Entering directory '/home/iu/devel/salsa/debian/devscripts/scripts'
make[2]: Leaving directory '/home/iu/devel/salsa/debian/devscripts/doc'
python3 setup.py clean -a
running clean
find -name '*.pyc' -delete
find -name __pycache__ -delete
rm -rf devscripts.egg-info bash_completion .pylint.d
rm -f bts cvs-debuild transition-check dpkg-depcheck debuild build-rdeps 
rmadison grep-excuses dget dep3changelog salsa debc rc-alert checkbashisms 
origtargz debi mk-origtargz uscan chdist who-permits-upload mk-build-deps 
desktop2menu debsnap debchange dscverify dcontrol svnpath plotchangelog dd-list 
debcommit git-deborig tagpending debdiff debpkg mass-bug namecheck 
hardening-check debcheckout who-uploads debclean list-unreleased debrepro dcmd 
what-patch wnpp-check cvs-debrelease whodepends manpage-alert nmudiff debrsign 
debsign dpkg-genbuilddeps edit-patch mergechanges debrelease ltnu archpath 
dscextract getbuildlog pts-subscribe wnpp-alert uupdate annotate-output cowpoke 
cvs-debi diff2patches deb-reversion bts.tmp cvs-debuild.tmp 
transition-check.tmp dpkg-depcheck.tmp debuild.tmp build-rdeps.tmp rmadison.tmp 
grep-excuses.tmp dget.tmp dep3changelog.tmp salsa.tmp debc.tmp rc-alert.tmp 
checkbashisms.tmp origtargz.tmp debi.tmp mk-origtargz.tmp uscan.tmp chdist.tmp 
who-permits-upload.tmp mk-build-deps.tmp desktop2menu.tmp debsnap.tmp 
debchange.tmp dscverify.tmp dcontrol.tmp svnpath.tmp plotchangelog.tmp 
dd-list.tmp debcommit.tmp git-deborig.tmp tagpending.tmp debdiff.tmp debpkg.tmp 
mass-bug.tmp namecheck.tmp hardening-check.tmp debcheckout.tmp who-uploads.tmp 
debclean.tmp list-unreleased.tmp debrepro.tmp dcmd.tmp what-patch.tmp 
wnpp-check.tmp cvs-debrelease.tmp whodepends.tmp manpage-alert.tmp nmudiff.tmp 
debrsign.tmp debsign.tmp dpkg-genbuilddeps.tmp edit-patch.tmp mergechanges.tmp 
debrelease.tmp

Bug#921332: RFP: translation-finder -- translation file finder for Weblate

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

Package name: translation-finder
Version : 1.0
Upstream Author : Michal Čihař 
URL : http://weblate.org/
License : GPL3+
Programming Lang: Python
Description : translation file finder for Weblate

This library is used by Weblate to discover translation
files in a cloned repository.

Bug#920984: [Pkg-owncloud-maintainers] Bug#920984: nextcloud-desktop: Client forgets credentials

[Sandro Knauß]

Control: reassign -1 libqt5keychain1 0.9.0-2
Control: affects -1 nextcloud-desktop
Control: affects -1 owncloud-client

Hey,

> I can confirm this with XFCE. That is the same issue I filed against the
> owncloud-client.
> Building the package with libsecret installed, solved it. I know, there is
> no dependency
> on libsecret, but it worked.

I don't understand why this should help:
1. libsecret-1-0 and libsecret-common are already available at build time see, 
so your solution does not help:
https://buildd.debian.org/status/fetch.php?pkg=nextcloud-desktop&arch=i386&ver=2.5.1-1&stamp=1548676710&raw=0

2. there is no dependency of libsecrect in nextcloud-destop nor owncloud-
client (for owncloud-client, there is a copy of qtkeyking in the sources, so 
you may triggered by your own build to use this one). But please beleave me, 
the whole logic is inside qtkeychain. 

hefee


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

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Fabian Klötzl]

As promised, I pushed my packaging attempt. However, I didn't manage to 
create a repository under med-team, thus it is under my account [1].


Best
Fabian

1: https://salsa.debian.org/kloetzl-guest/libmurmurhash

Bug#900164: aspell: Please use XDG basedir paths for user config and data files

[Agustin Martin]

Control: forwarded 900164 
http://lists.gnu.org/archive/html/aspell-devel/2019-01/msg0.html

On Sun, May 27, 2018 at 12:33:29AM +0200, Guillem Jover wrote:
> Package: aspell
> Version: 0.60.7~20110707-5
> Severity: wishlist
> User: guardi...@namespace.hadrons.org
> Usertags: homespace-rift
> 
> Hi!
> 
> The aspell config ~/.aspell.conf and user personal word and replace
> files ~/.aspell.LL.prepl and ~/.aspell.LL.pws are read directly from
> the user home directory. This makes for an untify home. :)
> 
> It would be nice if aspell would support the XDG basedir standard [X]
> and those would be looked up first under something like:
> 
>   ${XDG_CONFIG_HOME:-~/.config}/aspell/aspell.conf
>   ${XDG_DATA_HOME:-~/.local/share}/aspell/aspell.LL.prepl
>   ${XDG_DATA_HOME:-~/.local/share}/aspell/aspell.LL.pws
> 
> [X] 
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Mark as forwarded upstream.

-- 
Agustin

Bug#921176: redis-server service is failing to start in buster lxc container

[Pirate Praveen]

On തി, ഫെബ്രു 4, 2019 at 1:26 വൈകു, Pirate 
Praveen  wrote:



On 2019, ഫെബ്രുവരി 4 1:20:11 PM IST, Chris Lamb 
 wrote:

Hi,


 redis-server service is failing to start in buster lxc container


Any update on this? :)


I'm traveling. hopefully tonight or tomorrow night I can try.

Adding Raju, and Abhijith, who may be able to try this before.


I found some time to test. With the changes you suggested, the error 
message is gone, but it still fails to start. I tried updating kernel 
from 4.16 to 4.19 and lxc version from 2.x to 3.x. I also tried to 
create a fresh buster chroot, but in all cases it failed. Though 
Abhijith was not able to reproduce it in another machine.




Regards,


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#917086: [debian-mysql] Bug#917086: Bug#917086: mariadb-client-10.3: Can't locate Term/ReadKey.pm in @INC

[Olaf van der Spek]

Op vr 1 feb. 2019 om 11:09 schreef Otto Kekäläinen :
>
> I agree that having mytop (or mariadbtop) in a separate package would
> make sense. I am not even fully familiar what the original upstream
> story is and who is maintaining the "most upstream" version of it
> currently.

Great. Do you know what's missing from
https://salsa.debian.org/olafvdspek-guest/mariadb-10.3/commit/55d06886f5a81c10a00822078aac3ea0090c1b7f
to split mytop?

BTW, have you seen
https://salsa.debian.org/mariadb-team/mariadb-10.3/merge_requests/12 ?

Greetings,

-- 
Olaf

Bug#921329: dehydrated: Update to version 0.6.2 to get ACME V02 and wildcard support

[Mattia Rizzolo]

Control: found -1 0.3.1-3
Control: notfound -1 0.3.1-3+deb9u2
Control: close -1 0.6.1-1

On Mon, Feb 04, 2019 at 11:10:28AM +0100, Luc Maisonobe wrote:
> Let's Encrypt has made wildcard support available since marh 2018. It implies 
> using
> version 2 of the ACME protocol.
> 
> Dehydrated has published support for these features as of 0.6.2, published in
> april 2018 (see https://github.com/lukas2511/dehydrated/releases/tag/v0.6.2).

They were actually added in 0.6.1, not 0.6.2.

> Debian only ships version 0.3.1 and hence cannot use these features.

Debian stable doesn't usually update their software unless there are
really important bugs in them.

0.6.2 is available in stretch-backports (and has been since the day
0.6.x was released), for those who need the newest features like ACMEv2.

I'm therefore closing this bug, as everything is already in place.

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

And I assume you used a different computer to report this bug, in which
case I recommend you just remove these faulty data :)

-- 
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#921331: [signing-party] gpglist: a bug politely introduces itself and demands to be reported

[Giovanni Mascellani]

Package: signing-party
Version: 2.8-1
Severity: normal

If I try to run gpglist on my keys, the following happens:

$ gpglist 82D119A840C6EFCA6F5AF9459EDCC991D9AB457E
hi, i'm a bug. please report me to my owner
input: sig:::1:9EDCC991D9AB457E:1267054423Giovanni Mascellani
:1fx:8:
, key: 82D119A840C6EFCA6F5AF9459EDCC991D9AB457E at /usr/bin/gpglist line
159, <$fh> line 8.

I am not usually very sympathetic towards bugs, but this one is really
polite, and I think it would be really petty not to acquiesce its
demand. So here it is. I am sorry I am not able to provide further
information, because I have no idea what gpglist is not liking about my
key. But I will happily provide more information if someone explains me
how to do so. Also, I would really like to use gpglist on my key! :-)

Thanks, Giovanni.


--- System information. ---
Architecture: Kernel:   Linux 4.19.0-2-amd64

Debian Release: buster/sid
  500 xenial  updates.signal.org   500 unstable-debug
debug.mirrors.debian.org   500 unstableftp.be.debian.org   500
testing ftp.be.debian.org   500 stable  repo.skype.com
 500 stable  dl.google.com 1 experimentalftp.be.debian.org
--- Package information. ---
Depends(Version) | Installed
-+-===
perl:any | python3:any
| libc6  (>= 2.14) | libmd0
   (>= 0.0.0) | gnupg|
libclass-methodmaker-perl| libgnupg-interface-perl
| libmailtools-perl|
libmime-tools-perl   | libnet-idn-encode-perl
| libterm-readkey-perl |
libtext-template-perl| qprint
|

Recommends(Version) | Installed
===-+-===
default-mta |  OR mail-transport-agent
  | dialog  | 1.3-20181022-1
 OR whiptail| 0.52.20-8
libgd-gd2-noxpm-perl|  OR libgd-gd2-perl
  | libpaper-utils  | 1.1.26


Suggests   (Version) | Installed
-+-===
fonts-noto-cjk   | 1:20170601+repack1-3
fonts-noto-mono  | 20181227-1
imagemagick  | 8:6.9.10.23+dfsg-2
 OR graphicsmagick-imagemagick-compat| mutt
| 1.10.1-2
 OR neomutt  | qrencode
| 4.0.2-1
texlive-font-utils   | 2018.20190131-1
texlive-latex-extra  | 2018.20190131-1
texlive-latex-recommended| 2018.20190131-1
texlive-xetex| 2018.20190131-1
wipe | 0.24-4
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#555620: install-info: ginstall-info produces somehow broken utf-8 output

[Jens Thiele]

Hilmar Preuße  writes:

> I did a test w/ Debian unstable and my result is that the issue was
> fixed between 6.3.0 and 6.5.0.
>
> @Jens: do you have an unstable system at hand for double checking?

tested with: 6.5.0.dfsg.1-4+b1
output looks good (dir file after install-info run)

jens

PS: "valgrind install-info maplev.gz dir" still reports some
"Invalid read of size 1"


signature.asc
Description: PGP signature

Bug#921291: openhft-chronicle-bytes: FTBFS on i386

[Adrian Bunk]

On Mon, Feb 04, 2019 at 12:37:03AM +0100, Andreas Beckmann wrote:
> Package: openhft-chronicle-bytes
> Version: 1.16.25-1
> Severity: serious
> Justification: fails to build from source
> 
> Hi,
> 
> openhft-chronicle-bytes FTBFS in a i386 pbuilder chroot, while it builds
> successfully in an amd64 pbuilder chroot.

Why is FTBFS on a binary-all package on !amd64 itself an RC bug?

I see the point that it might be considered RC if the package is 
completely broken.

> Andreas

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#921330: libmbim: please package new version 1.18.0 for buster

[W. Martin Borgert]

Source: libmbim
Version: 1.16.0-1

Please package a new version of libmbim.
See #920765 and #921321. Thanks!

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Javier M DAW]

Would the attached patch do the trick? (/etc/init.d/bootlogs)

--- a2019-02-04 11:01:02.0 +0100
+++ b2019-02-04 11:03:45.0 +0100
@@ -15,20 +15,62 @@
 [ "$DELAYLOGIN" ] || DELAYLOGIN=yes
 . /lib/init/vars.sh

+# Source options
+if [ -f /etc/default/bootlogs ]
+then
+. /etc/default/bootlogs
+fi
+[ "$LOGFILE_GROUP" ] || LOGFILE_GROUP="adm"
+[ "$LOGFILE_MODE" ] || LOGFILE_MODE="640"
+[ "$OBEY_DMESG_RESTRICT" ] || OBEY_DMESG_RESTRICT=no
+[ "$LOGFILE_RESTRICT_MODE" ] || LOGFILE_RESTRICT_MODE="640"
+
+check_dmesg_restrict()
+{
+if [ `uname -s` = Linux ]
+then
+if which sysctl > /dev/null 2>&1
+then
+DMESG_RESTRICT=`sysctl -n kernel.dmesg_restrict`
+else
+DMESG_RESTRICT=`cat /proc/sys/kernel/dmesg_restrict`
+fi
+fi
+
+}
+
+update_logfile_perms () {
+if  [ "$OBEY_DMESG_RESTRICT" = yes ]
+then
+check_dmesg_restrict
+if [ "$DMESG_RESTRICT" = 1 ]
+then
+TARGET_MODE="$LOGFILE_RESTRICT_MODE"
+else
+TARGET_MODE="$LOGFILE_MODE"
+fi
+else
+TARGET_MODE="$LOGFILE_MODE"
+fi
+
+chmod "$TARGET_MODE" /var/log/dmesg || :
+chgrp "$LOGFILE_GROUP" /var/log/dmesg || :
+}
+
 do_start () {
 # Save kernel messages in /var/log/dmesg
 if which dmesg >/dev/null 2>&1
 then
 [ -f /var/log/dmesg ] && savelog -q -p -c 5 /var/log/dmesg
 dmesg -s 524288 > /var/log/dmesg
-chgrp adm /var/log/dmesg || :
+update_logfile_perms
 elif [ -c /dev/klog ]
 then
 [ -f /var/log/dmesg ] && savelog -q -p -c 5 /var/log/dmesg
 dd if=/dev/klog of=/var/log/dmesg &
 sleep 1
 kill $!
-[ -f /var/log/dmesg ] && { chgrp adm /var/log/dmesg || : ; }
+[ -f /var/log/dmesg ] && update_logfile_perms
 fi
 }

Bug#921329: dehydrated: Update to version 0.6.2 to get ACME V02 and wildcard support

[Luc Maisonobe]

Package: dehydrated
Version: 0.3.1-3+deb9u2
Severity: wishlist

Dear Maintainer,

Let's Encrypt has made wildcard support available since marh 2018. It implies 
using
version 2 of the ACME protocol.

Dehydrated has published support for these features as of 0.6.2, published in
april 2018 (see https://github.com/lukas2511/dehydrated/releases/tag/v0.6.2).

Debian only ships version 0.3.1 and hence cannot use these features.

It would be nice to update the version shipped with Debian.

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

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

Versions of packages dehydrated depends on:
ii  ca-certificates  20170717
ii  curl 7.63.0-1
ii  openssl  1.1.1a-1

dehydrated recommends no packages.

dehydrated suggests no packages.

Bug#917143: t-coffee autopkgtest regression

[Liubov Chuprikova]

Hi Andreas,

On Sun, 27 Jan 2019 at 16:23, Andreas Tille  wrote:

> Control: tags -1 help upstream
> Control: forwarded -1 https://github.com/cbcrg/tcoffee/issues/13
>
> Hi Liubov,
>
> On Sun, Jan 27, 2019 at 04:06:51PM +0100, Liubov Chuprikova wrote:
> > I was trying to figure out the reason for the failure but without any
> > success. It appeared that the error is reproducible with the upstream's
> > source version, so I have just opened an issue [1] to inform the upstream
> > about this bug.
> >
> > [1] https://github.com/cbcrg/tcoffee/issues/13
>
> Thanks a lot,
>
>   Andreas.
>

I have just pushed a fix of this! The problem was with two processes
competing for the same temporary file, as the tempfile names were defined
static.

With regards,
Liubov

Bug#921326: exim4-daemon-light: old exim4 daemon did not stop; socket bind() to port 25 for address 127.0.0.1 failed: Address already in use: daemon abandoned

[Vincent Lefevre]

On 2019-02-04 10:22:29 +0100, Vincent Lefevre wrote:
> The following daemon is running:
> 
> Debian-+  1194 1  0 Jan25 ?00:00:01 /usr/sbin/exim4 -bd -q5m
[...]
> journalctl excerpt (concerning exim):
> 
> [...]
> Feb 01 11:10:50 cventin systemd[1]: Reloading.
> Feb 01 11:10:50 cventin systemd[1]: Stopping LSB: exim Mail Transport Agent...
> Feb 01 11:10:50 cventin exim4[31423]: Stopping MTA:/sbin/start-stop-daemon: 
> matching only on non-root pidfile /run/exim4/exim.pid is insecure
> Feb 01 11:10:50 cventin exim4[31423]:  exim4_listener.
> Feb 01 11:10:50 cventin systemd[1]: Stopped LSB: exim Mail Transport Agent.
> [...]
> Feb 01 11:11:07 cventin systemd[1]: Reloading.
> Feb 01 11:11:09 cventin systemd[1]: Reloading.
> Feb 01 11:11:10 cventin systemd[1]: exim4.service: Found left-over process 
> 1194 (exim4) in control group while starting unit. Ignoring.
> Feb 01 11:11:10 cventin systemd[1]: This usually indicates unclean 
> termination of a previous run, or service implementation deficiencies.
> Feb 01 11:11:10 cventin systemd[1]: Starting LSB: exim Mail Transport Agent...
> Feb 01 11:11:10 cventin exim4[32215]: Starting MTA: exim4.
> Feb 01 11:11:10 cventin systemd[1]: Started LSB: exim Mail Transport Agent.
> [...]

cventin:~> systemctl status exim4.service
● exim4.service - LSB: exim Mail Transport Agent
   Loaded: loaded (/etc/init.d/exim4; generated)
   Active: active (running) since Fri 2019-02-01 11:11:10 CET; 2 days ago
 Docs: man:systemd-sysv-generator(8)
Tasks: 1 (limit: 4915)
   Memory: 12.7M
   CGroup: /system.slice/exim4.service
   └─1194 /usr/sbin/exim4 -bd -q5m

Feb 01 11:11:10 cventin systemd[1]: Starting LSB: exim Mail Transport Agent...
Feb 01 11:11:10 cventin exim4[32215]: Starting MTA: exim4.
Feb 01 11:11:10 cventin systemd[1]: Started LSB: exim Mail Transport Agent.

This is strange, because it says "active (running) since Fri
2019-02-01 11:11:10 CET; 2 days ago", but the daemon was started
on 2019-01-25.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#921319: stretch-pu: package iptables-persistent/1.0.4+nmu2

[Adam D. Barratt]

Control: tags -1 + moreinfo

On 2019-02-04 08:11, gustavo panizzo wrote:

I'd like to fix the bug #921186 in stable, only adding a dependency to
iptables-persistent the bug can be closed


The metadata for that bug suggests that the bug also affects the package 
in unstable, and is not yet fixed there - is that correct? If so, please 
fix the bug in unstable first; if not, please fix the metadata.


Regards,

Adam

Bug#921296: ccfits: FTBFS with upcoming doxygen 1.8.15

[Aurelien Jarno]

On 2019-02-04 01:04, Paolo Greppi wrote:
> Source: ccfits
> Severity: serious
> 
> Dear Maintainer,
> 
> I tested your package against a draft package for doxygen 1.8.15:
> https://bugs.debian.org/919413
> 
> and it FTBFS with this error:
> make[2]: *** [Makefile:8: refman.pdf] Error 1
> 

That actually looks like a bug in doxygen. CCfits depends on
doxygen-latex, which according to its description should provide
everything needed:

| Package: doxygen-latex
| ...
| Description-en: Documentation system for C, C++, Java, Python and other 
languages
|  Doxygen is a documentation system for C, C++, Java, Objective-C, Python, IDL
|  and to some extent PHP, C#, and D.  It can generate an on-line class browser
|  (in HTML) and/or an off-line reference manual (in LaTeX) from a set of
|  documented source files.
|  .
|  This dependency package adds dependencies for all LaTeX packages required
|  to build documents using the default stylesheet.

ccfits doesn't do anything fancy, it just generates the latex file using
doxygen and then run pdflatex on it. If a dependency is missing for
that, it should be added to doxygen-latex.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#902633: php-mode

[Eugen Dedu]

On 02/02/2019 13:21, Eugen Dedu wrote:

Ok, I add in CC bug 902633.


Thank you, Nicholas, for having packaged yesterday the new release of 
php-mode.


One more remark (perhaps out of topic): it seems to me that Debian 
recommends to use NEWS.gz instead of changelog.gz for the upstream 
changelog file name.


Best regards,
--
Eugen

Bug#921225: Acknowledgement ([L10N,DE] courier: updated german debconf translation)

[Holger Wansing]

Control: tags -1 + pending


"Debian Bug Tracking System"  wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 921225: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921225.

Committed into git.
Tagging this bug as pending


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

Bug#921328: auctex: please generate and install auto-loads.el (upstream Makefile target)

[Nicholas D Steeves]

Package: auctex
Version: 11.91-2
Severity: normal
Control: block 906259 by -1

Dear Auctex maintainers,

While doing packaging smartparens I discovered that our AUCTeX does not 
generate or install auto-loads.el.  Smartparens' self-tests fail as a result.

I believe the solution is probably as simple as just adding "$(MAKE) 
auto-loads.el" to debian/rules:L57, because this is an existing upstream 
Makefile target, and then installing the file.


Regards,
Nicholas

Bug#916210: ITP: rauc -- Robust Auto-Update Controller

[Arnaud Rebillout]

On 2/4/19 4:33 PM, Uwe Kleine-König wrote:
> Hello Arnaud,
>
> On Mon, Feb 04, 2019 at 04:17:41PM +0700, Arnaud Rebillout wrote:
>> On 2/4/19 4:14 PM, Uwe Kleine-König wrote:
>>> On Tue, Dec 11, 2018 at 02:22:53PM +, Arnaud Rebillout wrote:
 I would need a sponsor to upload this package, as I'm only a Debian
 Maintainer.
>>> I can sponsor the package.
>> Great! Actually I have an update package for RAUC v1.0, however I didn't
>> upload it to mentors yet. Give me a few minutes and I'll upload it.
> I'd prefer to look at it in a git checkout. So if you want to share
> that instead of a link to mentors, this would be great. If you want, I
> can create a repository on salsa for you.

Great, I also prefer to work with git.

I pushed it all at: https://salsa.debian.org/arnaudr-guest/rauc

Thanks!

  Arnaud

Bug#916210: ITP: rauc -- Robust Auto-Update Controller

[Uwe Kleine-König]

Hello Arnaud,

On Mon, Feb 04, 2019 at 04:17:41PM +0700, Arnaud Rebillout wrote:
> On 2/4/19 4:14 PM, Uwe Kleine-König wrote:
> > On Tue, Dec 11, 2018 at 02:22:53PM +, Arnaud Rebillout wrote:
> >> I would need a sponsor to upload this package, as I'm only a Debian
> >> Maintainer.
> > I can sponsor the package.
> 
> Great! Actually I have an update package for RAUC v1.0, however I didn't
> upload it to mentors yet. Give me a few minutes and I'll upload it.

I'd prefer to look at it in a git checkout. So if you want to share
that instead of a link to mentors, this would be great. If you want, I
can create a repository on salsa for you.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Bug#921327: grml2usb doesn't recognize a fat16 filesytem

[Elimar Riesebieter]

Package: grml2usb
Version: 0.16.2
Severity: important

Dear maintainer,

root@pippin>pts/0 ~ # mkfs.vfat -F 16 -v /dev/sdf2
mkfs.fat 4.1 (2017-01-24)
/dev/sdf2 has 64 heads and 32 sectors per track,
hidden sectors 0x3800800;
logical sector size is 512,
using 0xf8 media descriptor, with 2097152 sectors;
drive number 0x80;
filesystem has 2 16-bit FATs and 32 sectors per cluster.
FAT size is 256 sectors, and provides 65518 clusters.
There are 32 reserved sectors.
Root directory contains 512 slots and uses 32 sectors.
Volume ID is 5c940374, no volume label.

root@pippin>pts/0 ~ # grml2usb --bootoptions=%lang=de 
--bootoptions=%persistence grml64-full_2018.12.iso /dev/sdf2
Executing grml2usb version 0.16.2
Execution failed: Partition /dev/sdf2 does not contain a FAT16 filesystem. (Use 
--fat16 or run mkfs.vfat /dev/sdf2)

/dev/sdf2 is a partition on a stick. I tried both gpt and msdos
partitiontables, though.

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

Kernel: Linux 4.20.6-pippin-lxtec-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages grml2usb depends on:
ii  coreutils   8.30-1
ii  grub-efi-amd64  2.02+dfsg1-10
ii  mtools  4.0.23-1
ii  python  2.7.15-4
ii  python-parted   3.11.1-13
ii  rsync   3.1.3-5
ii  syslinux3:6.04~git20171011.af7e95c3+dfsg1-6

Versions of packages grml2usb recommends:
ii  genisoimage 9:1.1.11-3+b2
ii  syslinux3:6.04~git20171011.af7e95c3+dfsg1-6
pn  syslinux-utils  

grml2usb suggests no packages.

-- no debconf information

Bug#916210: ITP: rauc -- Robust Auto-Update Controller

[Uwe Kleine-König]

Hello Arnaud,

On Tue, Dec 11, 2018 at 02:22:53PM +, Arnaud Rebillout wrote:
> I would need a sponsor to upload this package, as I'm only a Debian
> Maintainer.

I can sponsor the package.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#921244: comp/send: strange error and undocumented behaviour when using Bcc-header

[Harald Geyer]

Alexander Zangerl writes:

> On Sun, 03 Feb 2019 14:13:24 +, Harald Geyer writes:
> >I get the following error:
> >| What now? send
> >| sendmail: No recipients specified although -t option used
> >| exit 1
> 
> could you please provide (possibly sanitised) copies
> of your ~/.mh_profile and /etc/nmh/mts.conf?

I actually installed nmh from scratch to reproduce the bug before
writing up the report, so there shouldn't be anything special in there,
but sure:

lambda@hdev:~$ cat .mh_profile
MH-Profile-Version: 1.0
Path: Mail

lambda@hdev:~$ cat .mh_profile
MH-Profile-Version: 1.0
Path: Mail
lambda@hdev:~$ cat /etc/nmh/mts.conf
# nmh mail transport interface customization file.
#
# Check the mh-tailor(5) man page for descriptions of available options.
#

# The delivery method to use, which must be one of the following:
# smtp:  nmh opens a socket connection to the appropriate port
#on the servers listed below and speaks SMTP to the
#first one that responds.  This is the default.
# sendmail/smtp: nmh pipes messages directly to the sendmail program,
#speaking SMTP.  Can be abbreviated to "sendmail".
# sendmail/pipe: nmh pipes messages directly to the sendmail program,
#using the -t option so that addresses are retrieved
#from the message.
mts: sendmail/pipe

# Name that nmh considers `local'.  If not set, nmh will
# query the system for this value (gethostname, etc...).
#localname: foo.bar.com

# Default location of mail drops.  If this option is
# set, but empty, the user's home directory is used.
mmdfldir: /var/mail

# The name of the maildrop file in the directory where maildrops
# are kept.  If this is empty, the user's login name is used.
mmdflfil:

#
# The locking algorithm to use on the spool file.  Valid settings are:
#
#   fcntl   Locking using the fcntl() function
#   dot "Dot" locking using an external lock file
#   flock   Locking using the flock() function (if supported by OS)
#   lockf   Locking using the lockf() function (if supported by OS)
#
# Locking algorithms supported on this installation are:
#
#   fcntl dot flock lockf
#
# The default spool locking configured on this system is fcntl;
# change the line below to get a different value
#spoollocking: fcntl

# Hardcoded POP server name (prevents inc'ing from local mail spool).
#pophost: localhost

# A SINGLE SMTP server to use when using SMTP support
servers: localhost


> >Both recipients get messages with different Message-Ids, but the
> >content seems to be exactly the same.
> ...
> >I believe this is in conflict
> >with the man page of send(1), which states that Bcc-recipients will
> >receive a message with a clear indication in the body, warning them
> >not to disclose their status as recipients by replying.
> 
> i don't see any indication in the send manpage that supports your reasoning.

It is implied in the description of the dcc header.

> but looking closely at the FAQ, the post manpage and the actual
> code i do see that nmh tries to reformat bcc's under some/many/most
> circumstances (and offers a weird nonstandard dcc header to create the
> 'normal'/classic behaviour of identical copies).
> 
> i can confirm that nmh 1.7 has buggy bcc handling, at least
> when sendmail/pipe is used as transport:
> using a shim program instead of actual sendmail/postfix/whatever i could see
> that the sequence of comp-whatnow-post creates TWO messages to transmit,
> 
> * one that contains the original body, complete with to: and bcc:,
>   ie. leaving sendmail/postfix/whatever to handle that bcc:,
>   which causes normal mail transfer agents to produce the
>   'normal'/classic bcc: behaviour,
> * and one that has the warning-encrusted body but no to: at all and only a 
> blank
>   bcc: header. that one is clearly untransmittable, which is what causes
>   the error message you saw.
> 
> i'll get in touch with upstream and have a deeper look at the problem myself
> as well.
> 
> you might try switching to 'smtp' or 'sendmail/smtp' in /etc/nmh/mts.conf
> as a potential workaround until that bug is sorted;

Thanks for the info. I guess this explains why I vaguely remember bcc
working in the past.

> note that
> according to the mts.conf manpage dcc: is NOT supported if 'sendmail/pipe'
> is the transport.

Thanks again, I'd have totally missed that. Sometimes it is hard to
know which man pages to read ... :)

Thanks for your help,
Harald

Bug#921326: exim4-daemon-light: old exim4 daemon did not stop; socket bind() to port 25 for address 127.0.0.1 failed: Address already in use: daemon abandoned

[Vincent Lefevre]

Package: exim4-daemon-light
Version: 4.92~RC5-1
Severity: important

After the latest upgrade, I got in /var/log/exim4/paniclog:

2019-02-01 11:15:40 socket bind() to port 25 for address 127.0.0.1 failed: 
Address already in use: daemon abandoned

and Cron em-mail messages:

exim paniclog /var/log/exim4/paniclog on cventin.lip.ens-lyon.fr has non-zero 
size, mail system might be broken. The last 10 lines are quoted below.

2019-02-01 11:15:40 socket bind() to port 25 for address 127.0.0.1 failed: 
Address already in use: daemon abandoned

This seems similar to bug 921205, but for IPv4.

The following daemon is running:

Debian-+  1194 1  0 Jan25 ?00:00:01 /usr/sbin/exim4 -bd -q5m

January 25 is before the upgrade (when the machine was last rebooted).

/var/log/dpkg.log excerpt (concerning exim):

2019-02-01 11:10:49 upgrade exim4-config:all 4.92~RC4-3 4.92~RC5-1
2019-02-01 11:10:49 status half-configured exim4-config:all 4.92~RC4-3
2019-02-01 11:10:49 status unpacked exim4-config:all 4.92~RC4-3
2019-02-01 11:10:49 status half-installed exim4-config:all 4.92~RC4-3
2019-02-01 11:10:49 status unpacked exim4-config:all 4.92~RC5-1
2019-02-01 11:10:49 upgrade exim4:all 4.92~RC4-3 4.92~RC5-1
2019-02-01 11:10:49 status half-configured exim4:all 4.92~RC4-3
2019-02-01 11:10:49 status unpacked exim4:all 4.92~RC4-3
2019-02-01 11:10:49 status half-installed exim4:all 4.92~RC4-3
2019-02-01 11:10:49 status unpacked exim4:all 4.92~RC5-1
2019-02-01 11:10:50 upgrade exim4-daemon-light:amd64 4.92~RC4-3 4.92~RC5-1
2019-02-01 11:10:50 status half-configured exim4-daemon-light:amd64 4.92~RC4-3
2019-02-01 11:10:50 status unpacked exim4-daemon-light:amd64 4.92~RC4-3
2019-02-01 11:10:50 status half-installed exim4-daemon-light:amd64 4.92~RC4-3
2019-02-01 11:10:50 status unpacked exim4-daemon-light:amd64 4.92~RC5-1
2019-02-01 11:10:50 upgrade exim4-base:amd64 4.92~RC4-3 4.92~RC5-1
2019-02-01 11:10:50 status half-configured exim4-base:amd64 4.92~RC4-3
2019-02-01 11:10:50 status unpacked exim4-base:amd64 4.92~RC4-3
2019-02-01 11:10:50 status half-installed exim4-base:amd64 4.92~RC4-3
2019-02-01 11:10:51 status unpacked exim4-base:amd64 4.92~RC5-1
[...]
2019-02-01 11:10:55 startup packages configure
2019-02-01 11:10:55 configure exim4-config:all 4.92~RC5-1 
2019-02-01 11:10:55 status unpacked exim4-config:all 4.92~RC5-1
2019-02-01 11:10:55 status half-configured exim4-config:all 4.92~RC5-1
2019-02-01 11:10:57 status installed exim4-config:all 4.92~RC5-1
[...]
2019-02-01 11:11:07 configure exim4-base:amd64 4.92~RC5-1 
2019-02-01 11:11:07 status unpacked exim4-base:amd64 4.92~RC5-1
2019-02-01 11:11:07 status half-configured exim4-base:amd64 4.92~RC5-1
2019-02-01 11:11:07 status installed exim4-base:amd64 4.92~RC5-1
[...]
2019-02-01 11:11:09 configure exim4-daemon-light:amd64 4.92~RC5-1 
2019-02-01 11:11:09 status unpacked exim4-daemon-light:amd64 4.92~RC5-1
2019-02-01 11:11:09 status half-configured exim4-daemon-light:amd64 4.92~RC5-1
2019-02-01 11:11:11 status installed exim4-daemon-light:amd64 4.92~RC5-1
[...]
2019-02-01 11:11:15 configure exim4:all 4.92~RC5-1 
2019-02-01 11:11:15 status unpacked exim4:all 4.92~RC5-1
2019-02-01 11:11:15 status half-configured exim4:all 4.92~RC5-1
2019-02-01 11:11:16 status installed exim4:all 4.92~RC5-1
[...]

/var/log/apt/term.log excerpt (concerning exim):

Preparing to unpack .../79-exim4-config_4.92~RC5-1_all.deb ...
Unpacking exim4-config (4.92~RC5-1) over (4.92~RC4-3) ...
Preparing to unpack .../80-exim4_4.92~RC5-1_all.deb ...
Unpacking exim4 (4.92~RC5-1) over (4.92~RC4-3) ...
Preparing to unpack .../81-exim4-daemon-light_4.92~RC5-1_amd64.deb ...
Unpacking exim4-daemon-light (4.92~RC5-1) over (4.92~RC4-3) ...
Preparing to unpack .../82-exim4-base_4.92~RC5-1_amd64.deb ...
Unpacking exim4-base (4.92~RC5-1) over (4.92~RC4-3) ...
[...]
Setting up exim4-config (4.92~RC5-1) ...
[...]
Setting up exim4-base (4.92~RC5-1) ...
[...]
Setting up exim4-daemon-light (4.92~RC5-1) ...
Updating GnuTLS DH parameter file
[...]
Setting up exim4 (4.92~RC5-1) ...
[...]

journalctl excerpt (concerning exim):

[...]
Feb 01 11:10:50 cventin systemd[1]: Reloading.
Feb 01 11:10:50 cventin systemd[1]: Stopping LSB: exim Mail Transport Agent...
Feb 01 11:10:50 cventin exim4[31423]: Stopping MTA:/sbin/start-stop-daemon: 
matching only on non-root pidfile /run/exim4/exim.pid is insecure
Feb 01 11:10:50 cventin exim4[31423]:  exim4_listener.
Feb 01 11:10:50 cventin systemd[1]: Stopped LSB: exim Mail Transport Agent.
[...]
Feb 01 11:11:07 cventin systemd[1]: Reloading.
Feb 01 11:11:09 cventin systemd[1]: Reloading.
Feb 01 11:11:10 cventin systemd[1]: exim4.service: Found left-over process 1194 
(exim4) in control group while starting unit. Ignoring.
Feb 01 11:11:10 cventin systemd[1]: This usually indicates unclean termination 
of a previous run, or service implementation deficiencies.
Feb 01 11:11:10 cventin systemd[1]: Starting LSB: exim Mail Transport Agent...
Feb 01 11:11:10 cventin exim4[32215]: Starting MTA: ex

Bug#921325: atril reports a segmentation fault when running by itself and trying to change parameters

[shirish शिरीष]

Package: atril
Version: 1.20.3-1
Severity: normal

Dear Maintainer,

Thank you for maintaining atril. I was trying to set up default
settings so that atril could show me documents at some fixed focus.

How to recreate it -

1. $ atril
2. Click on View > Zoom in

Just there, it puts a segmentation fault.

I am sharing the debugging session.


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

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

Versions of packages atril depends on:
ii  atril-common 1.20.3-1
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libatk1.0-0  2.30.0-2
ii  libatrildocument31.20.3-1
ii  libatrilview31.20.3-1
ii  libc62.28-5
ii  libcairo-gobject21.16.0-2
ii  libcairo21.16.0-2
ii  libcaja-extension1   1.20.3-1+b1
ii  libgail-3-0  3.24.4-1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.2-3
ii  libgtk-3-0   3.24.4-1
ii  libice6  2:1.0.9-2
ii  libjavascriptcoregtk-4.0-18  2.22.5-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libsecret-1-00.18.7-1
ii  libsm6   2:1.2.2-1+b3
ii  libsoup2.4-1 2.64.2-2
ii  libwebkit2gtk-4.0-37 2.22.5-1
ii  libx11-6 2:1.6.7-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  shared-mime-info 1.10-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages atril recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.12-1
ii  dbus-x11 [dbus-session-bus]   1.12.12-1
ii  gvfs  1.38.1-2+b1

Versions of packages atril suggests:
ii  caja  1.20.3-1+b1
ii  poppler-data  0.4.9-2
pn  unrar 

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8
Starting program: /usr/bin/atril 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffec372700 (LWP 12842)]
[New Thread 0x7fffebb71700 (LWP 12843)]
[New Thread 0x7fffeb30e700 (LWP 12844)]
[New Thread 0x7fffea52d700 (LWP 12845)]
[New Thread 0x7fffe9d1b700 (LWP 12846)]
[New Thread 0x7fffe91ff700 (LWP 12847)]
[New Thread 0x7fffe89fe700 (LWP 12848)]
[New Thread 0x7fff93ffd700 (LWP 12849)]
[Detaching after fork from child process 12850]
[Detaching after fork from child process 12852]
[New Thread 0x7fff935ff700 (LWP 12863)]
[New Thread 0x7fff92dfe700 (LWP 12864)]

Thread 1 "atril" received signal SIGSEGV, Segmentation fault.
0x5558b2aa in ev_window_cmd_view_zoom_in (action=, 
ev_window=) at ev-window.c:4798
4798ev-window.c: No such file or directory.
#0  0x5558b2aa in ev_window_cmd_view_zoom_in (action=, 
ev_window=) at ev-window.c:4798
#4  0x72e8c90f in  (instance=instance@entry=0x55879df0, signal_id=, detail=detail@entry=0) at ../../../gobject/gsignal.c:3447
#1  0x72e6fc7d in g_closure_invoke (closure=0x55766cc0, 
return_value=0x0, n_param_values=1, param_values=0x7fffd3f0, 
invocation_hint=0x7fffd370) at ../../../gobject/gclosure.c:810
#2  0x72e8 in signal_emit_unlocked_R 
(node=node@entry=0x55746900, detail=detail@entry=0, 
instance=instance@entry=0x55879df0, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffd3f0) at 
../../../gobject/gsignal.c:3635
#3  0x72e8c2c2 in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffd5a0) at ../../../gobject/gsignal.c:3391
#5  0x73591840 in _gtk_action_emit_activate (action=0x55879df0 
[GtkAction]) at ../../../../gtk/deprecated/gtkaction.c:909
#6  0x72e6feb6 in _g_closure_invoke_va (closure=0x5564b8a0, 
return_value=0x0, instance=0x55913780, args=0x7fffd8c0, n_params=0, 
param_types=0

Bug#921324: astropy-healpix FTBFS on i386: test filure

[Adrian Bunk]

Source: astropy-healpix
Version: 0.4-4
Severity: serious
Tags: ftbfs patch

https://buildd.debian.org/status/fetch.php?pkg=astropy-healpix&arch=i386&ver=0.4-4&stamp=1548693347&raw=0

...
=== FAILURES ===
___ test_boundaries 

@given(nside_pow=integers(0, 29), step=integers(1, 10), nest=booleans(),
>  frac=floats(0, 1, allow_nan=False, 
> allow_infinity=False).filter(lambda x: x < 1))

astropy_healpix/tests/test_healpy.py:185: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/hypothesis/core.py:519: in execute
result = self.test_runner(data, run)
/usr/lib/python3/dist-packages/hypothesis/executors.py:58: in 
default_new_style_executor
return function(data)
/usr/lib/python3/dist-packages/hypothesis/core.py:517: in run
return test(*args, **kwargs)
astropy_healpix/tests/test_healpy.py:185: in test_boundaries
frac=floats(0, 1, allow_nan=False, allow_infinity=False).filter(lambda x: x 
< 1))
/usr/lib/python3/dist-packages/hypothesis/core.py:464: in test
result = self.test(*args, **kwargs)
astropy_healpix/tests/test_healpy.py:190: in test_boundaries
b1 = hp_compat.boundaries(nside, pix, step=step, nest=nest)
astropy_healpix/healpy.py:152: in boundaries
lon, lat = boundaries_lonlat(pix, step, nside, order='nested' if nest else 
'ring')
astropy_healpix/core.py:673: in boundaries_lonlat
lon, lat = healpix_to_lonlat(healpix_index.ravel(), nside, dx.ravel(), 
dy.ravel(), order=order)
astropy_healpix/core.py:393: in healpix_to_lonlat
lat = Latitude(lat, unit=u.rad, copy=False)
/usr/lib/python3/dist-packages/astropy/coordinates/angles.py:514: in __new__
self._validate_angles()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 
angles = 

def _validate_angles(self, angles=None):
"""Check that angles are between -90 and 90 degrees.
If not given, the check is done on the object itself"""
# Convert the lower and upper bounds to the "native" unit of
# this angle.  This limits multiplication to two values,
# rather than the N values in `self.value`.  Also, the
# comparison is performed on raw arrays, rather than Quantity
# objects, for speed.
if angles is None:
angles = self
lower = u.degree.to(angles.unit, -90.0)
upper = u.degree.to(angles.unit, 90.0)
if np.any(angles.value < lower) or np.any(angles.value > upper):
raise ValueError('Latitude angle(s) must be within -90 deg <= angle 
<= 90 deg, '
>'got {0}'.format(angles.to(u.degree)))
E   ValueError: Latitude angle(s) must be within -90 deg <= angle <= 90 
deg, got [  0.-41.8103149 -90.-41.8103149] deg

/usr/lib/python3/dist-packages/astropy/coordinates/angles.py:531: ValueError
-- Hypothesis --
Falsifying example: test_boundaries(nside_pow=0, frac=0., 
step=1, nest=False)
 1 failed, 124 passed in 24.30 seconds =
/usr/lib/python3/dist-packages/astropy/config/configuration.py:536: 
ConfigurationMissingWarning: Configuration defaults will be used due to 
FileNotFoundError:2 on None
  warn(ConfigurationMissingWarning(msg))
make[1]: *** [debian/rules:17: test-python3.7] Error 1



Fix:

--- debian/rules.old2019-02-04 09:12:02.674701984 +
+++ debian/rules2019-02-04 09:13:52.286700939 +
@@ -9,6 +9,10 @@
 # Astropy-affiliated packages do.
 export PYBUILD_AFTER_INSTALL := find {destdir} -name '*.c' -delete
 
+ifeq ($(DEB_HOST_ARCH),i386)
+  export DEB_CFLAGS_MAINT_APPEND=-ffloat-store
+endif
+
 %:
dh $@ --with python3 --buildsystem=pybuild
 

Bug#916210: ITP: rauc -- Robust Auto-Update Controller

[Arnaud Rebillout]

On 2/4/19 4:14 PM, Uwe Kleine-König wrote:
> Hello Arnaud,
>
> On Tue, Dec 11, 2018 at 02:22:53PM +, Arnaud Rebillout wrote:
>> I would need a sponsor to upload this package, as I'm only a Debian
>> Maintainer.
> I can sponsor the package.
>
> Best regards
> Uwe

Great! Actually I have an update package for RAUC v1.0, however I didn't
upload it to mentors yet. Give me a few minutes and I'll upload it.

Thanks!

  Arnaud

Bug#918984: fuse3 still not co-installable with fuse

[Fabio Pedretti]

Commenting on 918984.
Thank you. Someone else with admin privileges could do this.


Il giorno sab 2 feb 2019 alle ore 09:46  ha scritto:

> Hey folks, and sorry for late response.
> I'm currently totally out of time so Fabio feel free to upload new
> sshfs.
>
> regards
> Bartosz Feński
>
>
> On 2019-01-11 15:08, Fabio Pedretti wrote:
> > Source: fuse3
> > Version: 3.4.1-1
> > Severity: important
> >
> > (Original message follows, apparently something went wrong and no bug
> > was created)
> >
> > -- Forwarded message -
> > From: Mo Zhou 
> > Date: mer 9 gen 2019 alle ore 16:17
> > Subject: Re: Bug#871019: sshfs: Please update to 3.x
> > To: 
> > Cc: <871...@bugs.debian.org>, Bartosz Fenski , Fabio
> > Pedretti 
> >
> > Package: fuse3
> > Version: 3.4.1-1
> > Severity: important
> >
> > Dear maintainer,
> >
> > I still cannot co-install fuse3/3.4.1-1 and fuse/2.9.9-1 .
> >
> > gnome-core (depends on ?gvfs? (depends on fuse)) got removed when I'm
> > trying to install fuse3.
> >
> > I packaged sshfs 3.5.1 for myself and used it for a while. The
> > performance improvement compared to 2.X is significant. I hope
> > the co-install problem could be solved so that we'll still have
> > a chance to get sshfs 3.X into Buster.
> >
> > @Bartosz: Do you have plan to upload sshfs 3.X to Buster? If you need
> > help, I volunteer to do it.
> >
> > On Wed, Jan 09, 2019 at 02:32:59PM +0100, Fabio Pedretti wrote:
> >> Il giorno lun 7 gen 2019 alle ore 14:26 Mo Zhou  ha
> >> scritto:
> >>
> >> On Mon, Jan 07, 2019 at 12:48:32PM +0100, Fabio Pedretti wrote:
> >> > ~ ❯❯❯ sudo apt install fuse
> >> > Reading package lists... Done
> >> > Building dependency tree
> >> > Reading state information... Done
> >> > The following packages were automatically installed and are
> >> no longer
> >> > required:
> >> > [...]
> >> > Use 'sudo apt autoremove' to remove them.
> >> > The following packages will be REMOVED:
> >> >   fuse3 sshfs sshfs-dbgsym
> >> > The following NEW packages will be installed:
> >> >   fuse
> >> > 0 upgraded, 1 newly installed, 3 to remove and 2 not
> >> upgraded.
> >> > Need to get 0 B/72.0 kB of archives.
> >> > After this operation, 243 kB disk space will be freed.
> >> > Do you want to continue? [Y/n]
> >> >
> >> > How are they "co-installable"???
> >> >
> >> > Thanks for the feedback. Since recently released fuse3 3.4.1-1
> >> this issue
> >> > should be fixed, this bug has more info:
> >> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912528
> >> >
> >> > Are you using 3.4.1-1? If so maybe this issue was not entirely
> >> addressed.
> >>
> >> Yes. The sshfs package as shown above is built by myself[1]
> >>
> >>
> >> I think this is unexpected, given 912528 was supposed to fix this.
> >>
> >> Maybe you could add these info on 912528, or opening a new bug against
> >> fuse3,
> >> so that the maintainer has a chance to fix it.
> >>
> >> Thanks.
> >>
> >>
> >> ~ ❯❯❯ apt list libfuse\* --installed
> >> Listing... Done
> >> libfuse2/unstable,unstable,unstable,now 2.9.8-2 amd64
> >> [installed,automatic]
> >> libfuse3-3/unstable,unstable,unstable,now 3.4.1-1 amd64
> >> [installed,automatic]
> >> libfuse3-dev/unstable,unstable,unstable,now 3.4.1-1 amd64
> >> [installed]
> >> ~ ❯❯❯ apt list fuse\* --installed
> >> Listing... Done
> >> fuse3/unstable,unstable,unstable,now 3.4.1-1 amd64
> >> [installed,automatic]
> >> ~ ❯❯❯ apt list sshfs\* --installed
> >> Listing... Done
> >> sshfs-dbgsym/now 3.5.1-1 amd64 [installed,local]
> >> sshfs/now 3.5.1-1 amd64 [installed,local]
> >>
> >> [1] https://salsa.debian.org/lumin/sshfs-fuse
>


-- 
ing. Fabio Pedretti
Responsabile U.O.C. "Reti, Sistemi e Sicurezza Informatica"
https://www.unibs.it/node/4305
Università degli Studi di Brescia
Via Valotti, 9 - 25121 Brescia
E-mail: fabio.pedre...@unibs.it

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 

Bug#921323: gdm3 ignores external monitors

[-]

Package: gdm3
Version: 3.30.2-1
Severity: important

Device: Thinkpad T470

Debian Version: Buster with latest updates

gdm3 ignores file /var/lib/gdm3/.config/monitors.xml.

This leads to a weird situation where the laptop is in the
dockingstation with lid closed and two or one external monitors
connected but the login screen is not visible after boot or reboot.
Therefore, the laptop goes to suspend because lid is closed and no log
in screen is outputed on the external monitors.

Interestingly grub is displayed on the external monitors but as soon as
gdm3 kicks in the screens go blank and the laptop supsends. So its not
a general problem, because once booted with lid open and all settings
made in GUI and then lid close the laptop is properly working, just
gdm3 has problems.

After reading https://manpages.debian.org/testing/gdm3/gdm3.8.en.html
/var/lib/gdm3 seems to be the correct destination and also other wikis
point to log in in a Wayland GNOME-Shell session, create via GUI a
~/.config/monitors.xml and then copy this file over to
/var/lib/gdm3/.config/ so that gdm3 is handling the setup the same way.
Because both are running in Wayland this should be fine.

But in my case the monitors.xml is ignored and I am not able to login
or boot properly when laptop is in Thinkpad Pro Dock or Thinkpad Ultra
Dock.

Thinkpad and both docks have all firmware updates installed.

Bug#921322: ITP: node-solid-jose -- JSON Object Signing and Encryption for Node.js

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-solid-jose
  Version : 0.4.0
  Upstream Author : Anvil Research, Inc. 
* URL : https://github.com/solid/jose
* License : Expat
  Programming Lang: JavaScript
  Description : JSON Object Signing and Encryption for Node.js

 The JOSE suite of specifications standardizes various mechanisms
 required for integrity protection and encryption
 of data structured and serialized as JSON.
 This package implements JWT, JWD, JWS, JWE (in progress),
 JWA, JWK, and JWK Set for use in JavaScript applications.

This package will be maintained in the JavaScript team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxX+tMACgkQLHwxRsGg
ASFSNA/6A2sKWSQkZTDf7DEKefGSCAlPWcg8v2Obt3fAPukYMfp973DROqVJHpBg
+dYXJNGLtvTQHmvtCAmq2mBKMEERYg2IiwQ7bJNOysutqv42tcHUL7oKX058fuRd
2vFXdFzJMTjC9Jd7m0CnQOO0fRPjhiDDNABp+7lRUiDo75uRj/cfr3TG+vPycoqD
PhvsFu1ZkObZm6H+t2QXHM4uofo7+ti2+btRZxClSH2q95UsyGQsd2KnWSbZhx1m
/IKdISGA8/8w80+fnot1tgD1TropTccUgV66Lpquo+0Y0cN+iNFfx4l1G7q82crx
xqezyfpTccjT8EjlTtfY7tRS534YEjR5fT1TEjXFrEXR1YLiVzPHaKIVLMFqoWH5
sKPRgyGW6BOOV8jwo5LZ3dK6ue+FsqsylqjXkaiMKs/XdKSrjCYELTqoQ4XRHJI7
Iv2eW4llakuckX8iEyOwKn8/ubM95owo5ZqrlOsyz8NI+R0rKDpDda/kcI2FnM1C
OqBZvDcC1sMS6BelnesIjvAyfLMTQ2/tiS+aTOzttmjVkGrfqxoN7ugXXjycT4tw
ynGFPpyPpDSaqlXl0TSabsvMAK7XtWzglVVdW1LG7wV0xl1K1Z4lB7i7RwV/xaxq
H1BaIQjhoyEp1haPA/eD9lxXXGAUyPRXXzakGC0SdMIUCB+zKUc=
=PNL2
-END PGP SIGNATURE-

Bug#919189: Fwd: probabel FTBFS on arm64, likely due to Eigen 3 NEON code

[L.C. Karssen]

Dear all,

As one of the developers of ProbABEL I can confirm this is a rounding
error. We have had similar problems in the past. The test run by make is
simply diff-ing the output of a test run with  a 'known good' file. Back
when ProbABEL was still actively developed, I tried my best to maintain
accuracy across the platforms I knew were being actively used by our
users. ARM and PPC where never among those, neither did I have access to
machines with that architecture.

All in all I think either of Andreas' proposed solutions is fine.


Best regards,

Lennart.

On 02-02-19 12:19, Andreas Tille wrote:
> On Sat, Feb 02, 2019 at 11:56:50AM +0100, Thierry fa...@linux.ibm.com wrote:
>> Hi,
>>
>> Thanks for pointing out that my analysis wasn't good - the arm patch
>> doesn't change anything for ppc64el (which make sense whatsoever) - the
>> problem on ppc64el is similar to the one on arm except the test value
>> are opposite ! ( which was confusing).
>> So what do we need to do ? expect that someone with a better expertise
>> help going though it  ? ( can you confirm we stay with that bug for both
>> arch or do we need to open one for ppc64el ?)
> 
> As long as we are sure that its just a rounding error I think an apropriate
> solution would be to ignore the error for ppc64el (either exclude the test
> or run
> 
> dh_auto_test || true
> 
> to be able to inspect the log.
> 
> Do you think that's in your interest?
> 
> Kind regards
> 
>   Andreas.
> 

-- 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
's-Hertogenbosch
The Netherlands

lenn...@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-



signature.asc
Description: OpenPGP digital signature

Bug#921312: libsaxonhe-java: description says XSLT 3.0 is unsupported but upstream websites disagree

[Eugene Zhukov]

Hi Paul,

Thanks for the bug report. Have you actually tried if XSLT 3.0 is supported by
libsaxonhe-java and it's just package description that needs updating?

Eugene


signature.asc
Description: PGP signature

Bug#921272: texlive-latex-extra: package tabu broken when xcolor is used

[Hilmar Preuße]

reassign 920621 texlive-latex-extra
forcemerge 920621 921272
stop

On 03.02.19 21:23, Thomas Schiex wrote:


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

   * What led up to the situation?

   Compiling the LaTeX doxygen-generated documentation for debian package 
toulbar2 fails.

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

 A minimal latex file does not compile anymore on texlive (did previously)


Already reported, merging. Upstream is working, for workarounds see
upstream bug.

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

Bug#919272: Is multiple-layers of alternatives a good thing to users?

[Mo Zhou]

Hi Guus,

On Mon, Feb 04, 2019 at 07:55:41AM +0100, Guus Sliepen wrote:
> >  libblis.so.2 libblis2 #MINVER#
> 
> If the ABI and API are the same for all variants, a much better
> solutions seems to me to have a single libblis2 that can switch at
> runtime between the different variants, perhaps using an environment
> variable to decide. That would require some support from upstream
> though.

Yes, I agree that such support is better. Actually the libmkl-rt library
from intel-mkl (non-free) supports the feature you said[1], and its
quite convenient. However for the BLIS upstream I think they don't have
enough fund and energy to develop such a feature. Based on that,
the current solution looks good enough.

[1] Env var MKL_THREADING_LAYER={intel,gnu,tbb,sequential}
allows to to switch threading model among libiomp5, libgomp,
libtbb2, and none.

Bug#921321: New upstream version libqmi 1.22

[Guido Günther]

Source: libqmi
Severity: wishlist

Hi,
there's a new upstream version 1.22 available. Can we have that in
Buster, that would be great? I can help with the update or even handle
it completely.
Cheers,
 -- Guido


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

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

Bug#920774: closed by Matteo Cypriani (Re: Bug#920774: pacpl: Unescaped left brace in regex...)

[Matteo Cypriani]

Hi Michel,

On Sun, 3 Feb 2019 15:08:40 -0500
Michel  wrote:
> Sorry, did not know notice the separate package.

No worry.


> Was just trying to help. Informing the maintainer about this warning,
> in case they would not see it in time.

Thank you, and sorry if I sounded harsh, that was not my intent :-)


> Will do if decide to re-open the bug report.

Maybe check upstream repository and see if it's fixed there, if not
report directly upstream (and/or send a patch if you speak some Perl).

Cheers,
  Matteo


pgpF_yAyzDtFM.pgp
Description: PGP signature

Bug#921315: samtools: baseline violation on i386

[Michael Crusoe]

On Mon, 04 Feb 2019 08:43:08 +0200 Adrian Bunk  wrote:
> Source: samtools
> Version: 1.9-2
> Severity: serious
> Tags: patch
>
> SSE is not part of the i386 baseline, fix:
>
> --- debian/rules.old 2019-02-03 20:43:51.747130097 +
> +++ debian/rules 2019-02-03 20:44:04.383129977 +
> @@ -5,7 +5,7 @@
>
>  export DEB_BUILD_MAINT_OPTIONS=hardening=+all
>  ifneq (,$(filter $(DEB_HOST_ARCH),i386 kfreebsd-i386 hurd-i386))
> -  export DEB_CFLAGS_MAINT_APPEND=-msse -mfpmath=sse
> +  export DEB_CFLAGS_MAINT_APPEND=-ffloat-store

Very cool, I did not know about this option; thank you!

>  endif
>
>  %:
>
>

Bug#921316: python3-sqt: Depends: python3 (< 3.6) but 3.7.2-1 is to be installed

[Andreas Tille]

Hi Adrian,

On Mon, Feb 04, 2019 at 09:01:55AM +0200, Adrian Bunk wrote:
> The following packages have unmet dependencies:
>  python3-sqt : Depends: python3 (< 3.6) but 3.7.2-1 is to be installed
> 
> Was this binary built in an old/outdated chroot with Python 3.6
> as default?

I'm always using up to date chroot.  The only reason might be that I
accidentally have build for stretch backport?  Just re-uploading.

Thanks a lot for your extremely valuable QA work

   Andreas.

-- 
http://fam-tille.de

Bug#921320: ruby-rspec-rails build depends on ruby-capybara (>= 2.15~) that is currently not in buster

[Adrian Bunk]

Source: ruby-rspec-rails
Version: 3.8.1-2
Severity: serious
Tags: ftbfs
Control: block -1 by 900156

ruby-rspec-rails build depends on ruby-capybara (>= 2.15~)
that is currently not in buster due to #900156.

Bug#918623: dizzy: Your vendor has not defined OpenGL macro GL_FRAMEBUFFER_EXT

[Andreas Tille]

Hi Florian,

> It's probably a bit late in the release cycle to "just find out" by
> uploading a -2 with that modified patch.

... but its even worse to do nothing since this is an RC bug and this
package as well as its rdepends would be excluded from next release if
the bug is not fixed.

Kind regards

  Andreas.


-- 
http://fam-tille.de

Bug#919272: Is multiple-layers of alternatives a good thing to users?

[Guus Sliepen]

On Mon, Feb 04, 2019 at 06:07:55AM +, Mo Zhou wrote:

> My updated version, all variants are co-installable now:
> 
>  Package: libblis2-openmp,  Provides: libblas.so.3, libblis.so.2
>  Package: libblis2-pthread, Provides: libblas.so.3, libblis.so.2
>  Package: libblis2-serial,  Provides: libblas.so.3, libblis.so.2
>  Package: libblis2 (meta),
>  Package: python3-numpy,Depends: libblas.so.3
> 
> The meta package is still necessary because of symbols/shlibdeps.
> Different threading variants have the same ABI/API, so the
> dependency template is written as
> 
>  libblis.so.2 libblis2 #MINVER#

If the ABI and API are the same for all variants, a much better
solutions seems to me to have a single libblis2 that can switch at
runtime between the different variants, perhaps using an environment
variable to decide. That would require some support from upstream
though.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#921293: hwloc: FTBFS with upcoming doxygen 1.8.15

[Samuel Thibault]

Paolo Greppi, le lun. 04 févr. 2019 07:51:45 +0100, a ecrit:
> Yes we patched doxygen.sty:
> https://salsa.debian.org/paolog-guest/doxygen/blob/master/debian/patches/longtabu.diff
> in a way that works for hundreds of packages except 9.
> 
> I lack the latex skills to understand what is going on in your case.

Perhaps we just happen to use some doxygen commands which require this.
You can simply make doxygen-latex depend on the package that provides
listofitems.sty, texlive-plain-generic.

Samuel

Bug#921312: libsaxonhe-java: description says XSLT 3.0 is unsupported but upstream websites disagree

[Paul Wise]

On Mon, 2019-02-04 at 09:24 +0200, Eugene Zhukov wrote:

> Thanks for the bug report. Have you actually tried if XSLT 3.0 is supported by
> libsaxonhe-java and it's just package description that needs updating?

I don't really have much experience with this stuff but I've attempted
to test it and as far as I can tell it does work, but not with higher
order functions and other features from the proprietary version.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#921278: bibtex2html: Lacks several math-related translations

[Ralf Treinen]

Dear James,

On Sun, Feb 03, 2019 at 04:26:03PM -0500, James Van Zandt wrote:

> I maintain several large bibtex files, including one devoted to
> numerical analysis papers, with abstracts that use a lot of math
> notation.  I have collected some of the required translations
> into a latex macro file that I can load with the -m switch.
> However, it would be more convenient to have those translations
> built into bibtex2html tool.

thanks a lot for your patch which I have forwarded to the upstream
authors.

-Ralf.

Bug#921319: stretch-pu: package iptables-persistent/1.0.4+nmu2

[gustavo panizzo]

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

Hello release team

I'd like to fix the bug #921186 in stable, only adding a dependency to
iptables-persistent the bug can be closed

debdiff attached

thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-1-arm64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru iptables-persistent-1.0.4+nmu2/debian/changelog 
iptables-persistent-1.0.4+nmu3/debian/changelog
--- iptables-persistent-1.0.4+nmu2/debian/changelog 2017-03-18 
21:11:49.0 +0800
+++ iptables-persistent-1.0.4+nmu3/debian/changelog 2019-02-03 
19:18:27.0 +0800
@@ -1,3 +1,11 @@
+iptables-persistent (1.0.4+nmu3) stable; urgency=medium
+
+  * Non-maintainer upload
+  * Depend on kmod as /sbin/modprobe is called unconditionally
+Thanks Hugo, Closes (#921186)
+
+ -- gustavo panizzo   Sun, 03 Feb 2019 19:18:27 +0800
+
 iptables-persistent (1.0.4+nmu2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru iptables-persistent-1.0.4+nmu2/debian/control 
iptables-persistent-1.0.4+nmu3/debian/control
--- iptables-persistent-1.0.4+nmu2/debian/control   2017-03-17 
12:50:20.0 +0800
+++ iptables-persistent-1.0.4+nmu3/debian/control   2019-02-03 
19:18:17.0 +0800
@@ -21,7 +21,7 @@
 
 Package: iptables-persistent
 Architecture: all
-Depends: netfilter-persistent (= ${source:Version}), iptables, ${misc:Depends}
+Depends: netfilter-persistent (= ${source:Version}), iptables, kmod, 
${misc:Depends}
 Description: boot-time loader for netfilter rules, iptables plugin
  netfilter-persistent is a loader for netfilter configuration using a
  plugin-based architecture.

Bug#921205: socket bind() to port 25 for address (any IPv6) failed: Address already in use: daemon abandoned

[Marc Haber]

On Sun, Feb 03, 2019 at 01:20:53PM +0100, Andreas Metzler wrote:
> That usually is a local configuration error, starting the daemon both
> via initscript and other means, or having another program running that
> is bound to 25. The timestamp only shows that the issue was present
> after the latest installation/upgrade, it does not imply causality.  :-(

I see similiar behavior in latest sid, after the upgrade to 4.92~RC5-1.
Have not yet investigated in depth. Just mailing quickly to add my +1.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#921318: package-update-indicator: does not stop running instances on purge

[Julian Gilbey]

Source: package-update-indicator
Version: 2.0-1
Severity: important

Hmmm,

I purged the package-update-indicator package because it was filling
my /var/log/daemon.log (see other bug report), and discovered this
morning that it was still running :-(

It should probably execute a killall package-update-indicator in the
prerm.

Best wishes,

   Julian

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

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

Bug#920664: unable to decrypt drive from grub after alpha4 setup)

[Ross Boylan]

The debian package cryptsetup-initramfs does not seem present on the main
system, judging from its absence from /usr/share/doc/.
I'm not sure I've understood the question, however.  I'm using this
somewhat indirect indicator of the package because of the difficulty of
getting into the system live.  /var/cache/apt/archives/ has no packages
with "crypt" in the name. /sbin/cryptsetup is present on the main system
and the initrd

I did create the encrypted partition through the installer's partition
manager, so the installer should be aware of the encryption.  I am using
the standard kernel.  But if the initrd doesn't have all the modules it
needs, that might explain the problem.

Ross

On Sun, Feb 3, 2019 at 5:24 AM Ben Hutchings  wrote:

> On Sat, 2019-02-02 at 22:56 -0800, Ross Boylan wrote:
> > I am able to decrypt the partition outside of a VM without the rescue
> > "CD".  Since I can also decrypt using the installer CD as rescue, this
> > means the failure is specific to booting via grub and initrd.
> >
> > This seems to indicate the installer created the encrypted partition
> > properly but the boot environment it created is either handling the
> > pass-phrase incorrectly (e.g., include \n) or is missing some other part
> of
> > the machinery necessary.  The most obvious candidate is from the error
> > message
> > > Check  that kernel supports aes-xts-plain64 cipher
> >
> > I don't know how to check that, but looking in config-4.19.0-1-amd64 on
> the
> > boot partition, I see some partial matches that might be relevant:
> > CONFIG_CRYPTO_AES=y
> > # CONFIG_CRYPTO_AES_TI is not set
> > CONFIG_CRYPTO_AES_X86_64=m
> > CONFIG_CRYPTO_AES_NI_INTEL=m
> >
> > CONFIG_CRYPTO_XTS=m
> >
> > I don't see anything that looks like plain.
>
> You can't easily map crypto modes to config options like this.  But if
> you are using the standard kernel, I can assure that it supports full
> disk encryption.
>
> > The buster system created by the installer includes aesni-intel.ko, but
> the
> > initrd does not.
>
> cryptsetup-initramfs should have been installed, and it would add the
> crypto modules (and other necessary files) to the initramfs.  Is it
> installed?
>
> Ben.
>
> --
> Ben Hutchings
> Horngren's Observation:
>   Among economists, the real world is often a special case.
>
>
>

Bug#921246: llvm-toolchain-7: FTBFS on kfreebsd-any

[Sylvestre Ledru]

Le 03/02/2019 à 23:55, Svante Signell a écrit :

On Sun, 2019-02-03 at 23:39 +0100, Sylvestre Ledru wrote:

Le 03/02/2019 à 17:21, Sylvestre Ledru a écrit :

Le 03/02/2019 à 15:28, Svante Signell a écrit :

Source: llvm-toolchain-7
Version: 7_7.0.1-4
Severity: important
Tags: ftbfs, patch
User: debian-k...@lists.debian.org
Usertags: kfreebsd

Hello,

Currently llvm-toolchain-7 FTBFS on GNU/kFreeBSD dues to a missing
port to that
architecture. Attached are 14 patches...
clang_lib_Basic_Targets.diff
CMakeLists.txt.diff
compiler-rt_lib.diff
include_llvm_ADT_Triple.h.diff
kfreebsd-libcxx-threads-detection.diff
kfreebsd-openmp.diff
kfreebsd-threads-build.diff
kfreebsd-triple-clang.diff
kfreebsd-triple.diff
lib_Support.diff
lib_Target_X86.diff
lldb_source_Host_freebsd_Host.cpp.diff
lldb_source_Plugins_Process_FreeBSD.diff
tools_llvm-shlib_CMakeLists.txt.diff

Additionally, the install file for liblldb-7 needs a separate file:
liblldb-
7.install.kfreebsd. Adding [!kfreebsd-any] to the last row of
liblldb-7.install
(or liblldb-X.Y.install.in) did not work.

I will submit these patches to upstream too, in due time.

Wahou, impressive!

Don't hesitate to submit a MR next time!

S


I tried to build it on amd64 but it fails with

/build/llvm-toolchain-7-7.0.1/projects/compiler-
rt/lib/fuzzer/FuzzerUtilPosix.cpp:122:28:
error:
use of undeclared identifier 'LIBFUZZER_KFREEBSD'
LIBFUZZER_OPENBSD || LIBFUZZER_KFREEBSD) {


Index: llvm-toolchain-7-7.0.1/compiler-rt/lib/fuzzer/FuzzerDefs.h
===
--- llvm-toolchain-7-7.0.1.orig/compiler-rt/lib/fuzzer/FuzzerDefs.h
+++ llvm-toolchain-7-7.0.1/compiler-rt/lib/fuzzer/FuzzerDefs.h
@@ -28,6 +28,7 @@
   #define LIBFUZZER_LINUX 1
   #define LIBFUZZER_NETBSD 0
   #define LIBFUZZER_FREEBSD 0
+#define LIBFUZZER_KFREEBSD 0
   #define LIBFUZZER_OPENBSD 0
   #define LIBFUZZER_WINDOWS 0
   #elif __APPLE__


It fixed it (and it has to be replicated for the other archs)

Sorry, I was a little sloppy defining LIBFUZZER_KFREEBSD. Do you want an updated
patch?


No need, I fixed it, thanks!

S

Bug#916298: steam: should depend on steam-devices

[Simon McVittie]

On Wed, 12 Dec 2018 at 20:18:15 +, Simon McVittie wrote:
> Steam developers at Valve consider it to be a bug that the Debian/Ubuntu
> steam package can be installed without also installing the udev rules in
> the steam-devices package: I'm told it's generating a noticeable support
> burden for them.
> 
> Please upgrade the Suggests to a hard dependency, or at least a
> Recommends.

This was reduced from Depends to Recommends in 1.0.0.59-4. Michael:
why this change?

On Sun, 27 Jan 2019 at 20:50:24 +0300, Alexey Morsov wrote:
> I have steam package installed from debian non-free repo. But after
> steam-launcher removed due to conflict with steam-devices i have no
> .desktop file to launch steam client. 

In version 1.0.0.59-3 I added versioned Breaks that should make sure
you can't have a mixture of Valve and Debian packages that doesn't work
together.

smcv

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Pierre Ynard]

> Why are you skeptical? I do not see, how syncing /var/log/dmesg
> permissions with kernel.dmesg_restrict could break things. Or am I
> missing something?

Well, /var/log/dmesg only covers bootup kernel logs, so maybe some admin
set it up for unprivileged use of bootup logs, but still wants kernel
logs in general and after bootup to be restricted, to help deter local
exploits for example.

/var/log/kern.log permissions don't depend on kernel.dmesg_restrict.
Also rsyslog seems to capture to kern.log just as many early logs as
/var/log/dmesg ?

So it seems to me like introducing a behavior that's variable on a
sysctl parameter doesn't really rationalize things.

Either way, considering the original cause of the bug here, setting log
permissions once in postinst is probably too brittle, confusing and
error-prone. It seems better to set them when the logs are written and
rotated in /etc/init.d/bootlogs; whatever default permissions are used,
that's something that admins can better understand and edit too.

/var/log/dmesg isn't the only log file whose permissions are set in that
brittle way in postinst. Others are /var/log/fsck/{checkroot,checkfs}
(the two logsave ones), and /var/log/boot (bootlogd). The same logic
applies so it could make sense to change these too. Or any others making
use of logsave like was suggested in #901289. Except that there isn't a
relevant sysctl variable for those.

The way I look at it is as a whole, how initscripts provides logging
functionality outside of syslog while it may not be available or suited,
and how to manage that and log permissions. I agree that looking
at kernel.dmesg_restrict can be a cool tradeoff, but that's very
specialized.

-- 
Pierre Ynard

Bug#919413: RFS: doxygen/1.8.15-1 [ITA]

[Ole Streicher]

Control: severity 921295 important
Control: severity -1 normal

(setting severity of RFS back to normal)

https://release.debian.org/buster/freeze_policy.html

> Transition Freeze
> Starting 2019-01-12, new transitions and large/disruptive changes are no 
> longer acceptable for buster.

I am wondering whether this applies here, given the large number of
packages which don't compile.

Best

Ole

Bug#921176: redis-server service is failing to start in buster lxc container

[Pirate Praveen]

On 2019, ഫെബ്രുവരി 4 1:20:11 PM IST, Chris Lamb  wrote:
>Hi,
>
>> redis-server service is failing to start in buster lxc container
>
>Any update on this? :)

I'm traveling. hopefully tonight or tomorrow night I can try.

Adding Raju, and Abhijith, who may be able to try this before.
>
>Regards,

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.