Bug#848890: [Pkg-swan-devel] Bug#848890: Bug#848890: Revisiting "Ubuntu strongSwan changes"

[Christian Ehrhardt]

On Mon, Jan 16, 2017 at 4:16 PM, Yves-Alexis Perez 
wrote:

>
> In the end, I didn't really have time to work more on this, so I've
> uploaded
> the current situation in order to not miss the freezes. It still lacks some
> bits but it should reduce the diff a little.
>

Thanks a lot for your work on this already!


> Once things have settled down we can revisite some of the changes left.
>

I understand the release rush and that bigger changes like this might be
better right after than right before it.
My "personal" timing is fine with that to be postponed the further cleanup
for another one or two months - so no hurry as long as we do not forget
about it.

Bug#851641: linux-image-3.16.0-4-amd64 panic:double fault

[张永肃]

Package:linux-image-3.16.0-4-amd64
Version:3.16.36-1+deb8u1

3.16.36-1+deb8u1 (debian stable package) kernel panic,double fault.

[952650.981869] PANIC: double fault, error_code: 0x0
[952650.981909] CPU: 4 PID: 14945 Comm: parameter_serve Not tainted
3.16.0-4-amd64 #1 Debian 3.16.36-1+deb8u1
[952650.981911] Hardware name: Powerleader PR2760TG/X10DRT-PT, BIOS
2.0 12/18/2015
[952650.981912] task: 883ea55a4c20 ti: 88256f728000 task.ti:
88256f728000
[952650.981914] RIP: 0010:[]  []
sysret_check+0x1/0x4e
[952650.981921] RSP: 0018:ffd8  EFLAGS: 00010217
[952650.981923] RAX:  RBX: 4272a640 RCX:

[952650.981924] RDX: 88256f72bfd8 RSI: 88256f72bd88 RDI:
883ea3027400
[952650.981926] RBP:  R08: 88256f728000 R09:

[952650.981928] R10: 00010e3476ec R11:  R12:
622c05f8
[952650.981929] R13: 622c0540 R14: 0001 R15:

[952650.981932] FS:  7fbcd0587700() GS:88407f90()
knlGS:
[952650.981934] CS:  0010 DS:  ES:  CR0: 80050033
[952650.981936] CR2: ffc8 CR3: 003ea86f6000 CR4:
003407e0
[952650.981938] DR0:  DR1:  DR2:

[952650.981939] DR3:  DR6: fffe0ff0 DR7:
0400
[952650.981941] Stack:
[952650.981967] BUG: unable to handle kernel paging request at ffd8
[952650.982017] IP: [] show_stack_log_lvl+0x108/0x170
[952650.982064] PGD 1816067 PUD 1818067 PMD 0
[952650.982103] Oops:  [#1] SMP
[952650.982123] Modules linked in: 8021q garp stp mrp llc
ipmi_watchdog iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal
coretemp kvm_intel kvm crc32_pclmul aesni_intel aes_x86_64 lrw
gf128mul glue_helper ablk_helper cryptd ast ttm pcspkr drm_kms_helper
evdev joydev drm i2c_algo_bit lpc_ich mei_me i2c_i801 mfd_core mei
shpchp i2c_core wmi tpm_tis tpm processor thermal_sys acpi_power_meter
acpi_pad button ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler
autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid hid sg sd_mod
crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common
crc32c_intel ahci libahci ehci_pci libata xhci_hcd ehci_hcd ixgbe dca
usbcore ptp scsi_mod pps_core usb_common mdio
[952650.982583] CPU: 4 PID: 14945 Comm: parameter_serve Not tainted
3.16.0-4-amd64 #1 Debian 3.16.36-1+deb8u1
[952650.982621] Hardware name: Powerleader PR2760TG/X10DRT-PT, BIOS
2.0 12/18/2015
[952650.982651] task: 883ea55a4c20 ti: 88256f728000 task.ti:
88256f728000
[952650.982682] RIP: 0010:[]  []
show_stack_log_lvl+0x108/0x170
[952650.982720] RSP: 0018:88407f904e98  EFLAGS: 00010046
[952650.982743] RAX: ffe0 RBX: ffd8 RCX:
88407f8fffc0
[952650.982772] RDX:  RSI: 88407f904f58 RDI:

[952650.982802] RBP: 88407f903fc0 R08: 81706753 R09:
5f64
[952650.982831] R10:  R11: 88407f904c2e R12:
88407f904f58
[952650.982872] R13:  R14: 81706753 R15:

[952650.982918] FS:  7fbcd0587700() GS:88407f90()
knlGS:
[952650.982968] CS:  0010 DS:  ES:  CR0: 80050033
[952650.982994] CR2: ffd8 CR3: 003ea86f6000 CR4:
003407e0
[952650.983035] DR0:  DR1:  DR2:

[952650.983082] DR3:  DR6: fffe0ff0 DR7:
0400
[952650.983125] Stack:
[952650.983136]  0008 88407f904ef0 88407f904eb0
ffd8
[952650.983176]  88407f904f58 ffd8 883ea55a4c20
0040
[952650.983210]  0001  810165fe
88407f904f58
[952650.983245] Call Trace:
[952650.983257]  <#DF>
[952650.983268]
[952650.983280]  [] ? show_regs+0x7e/0x1f0
[952650.983300]  [] ? df_debug+0x1f/0x30
[952650.98]  [] ? do_double_fault+0x78/0xf0
[952650.983358]  [] ? double_fault+0x28/0x30
[952650.983384]  [] ? sysret_check+0x1/0x4e
[952650.983406]  <>
[952650.983418]  
[952650.983429] Code: 67 70 81 31 c0 89 54 24 08 48 89 0c 24 48 8b 5b
f8 e8 5b 93 4f 00 48 8b 0c 24 8b 54 24 08 85 d2 74 05 f6 c2 03 74 48
48 8d 43 08 <48> 8b 33 48 c7 c7 4b 67 70 81 89 54 24 14 48 89 4c 24 08
48 89
[952650.983565] RIP  [] show_stack_log_lvl+0x108/0x170
[952650.983596]  RSP 
[952650.983612] CR2: ffd8

the crash bt -f :
crash> bt -f
PID: 14945  TASK: 883ea55a4c20  CPU: 4   COMMAND: "parameter_serve"
 #0 [88407f904b78] machine_kexec at 8104d3d2
88407f904b80: 8104e3fa 8800
88407f904b90: 26001000 880026001000
88407f904ba0: 2600 88407f904bd0
88407f904bb0: 88407f904de8 88407f904bd0
88407f904bc0: 0046 810e146a
PID: 14945  TASK: 883ea55a4c20  CPU: 4   COMMAND: "parameter_ser

Bug#851642: perl: FTBFS on mips64el: dist/threads/t/join.t failure

[Niko Tyni]

Package: perl
Version: 5.24.1-1
Severity: serious
X-Debbugs-Cc: debian-m...@lists.debian.org

This package failed to build on mips64el:

 dist/threads/t/join ... Died at 
t/join.t line 134.
 FAILED--expected 20 tests, saw 10

This has now happened twice on different buildds so it doesn't seem to be 
transient.

 https://buildd.debian.org/status/logs.php?pkg=perl&arch=mips64el

5.24.1~rc5-1 built fine in experimental a couple of weeks ago, and there
were no thread-related source changes between the versions (and a minimal
set of changes overall as the debian/cross/ ones don't affect native
builds).

So either something changed in the toolchain / platform or this was a
latent undeterministic bug and we're just unlucky now.

Needs investigation. Cc'ing the mips porters; any help would be welcome.
-- 
Niko Tyni   nt...@debian.org

Bug#845380:

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2017-01-16 at 19:05 +, Aigars Mahinovs wrote:
> I am having the same problem. Let me know if I can do something to help debug
> the issue. I am not very familiar with QT and their Python bindings, however.

I hadn't paid attention that the submitter hinted it could be a HiDPI issue. But
I just verified calibre on a normal display machine and it is working fine.

But the versions on Sid now are:

2.75.1+dfsg-1 - Calibre
5.7+dfsg-4 - PyQT5

- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlh9ydQACgkQpjpYo/Lh
dWmZ7A/+Jtz86LYEkHp57Gd4CHa3Jp0lnan9F2+WYkvgtECvDVMGNrNrAI+Am78d
5qEAULSdfNmVcLu4lOrw1DJeFCs2kdEtaFtlYIT+Znr/8m3+uIKw3HtFHyJcGN0e
24Pc4afaYYKWlzftehOJFvrZJ1oYgHNdCgai0EVmGxKKZkjNnHufyyuZMc+wLQnx
lMtA1sb2b0B30rjJy8er9K3QHmFHL3/9IGq/H2AEDAVmH/MPQbDZiSwTQwUhA78r
MMOrINNl/3Hoa8WTui/EPcVrYrOl+z//I2YXMdScvftX6rXagzJG49F1AteInkyZ
xInJtOYRBLqkrT7HhxRlzwNJ+0zZLgiIxLdM+9buyPfotpLiI9JampvrUzusUeDS
ES1BtHmN4FwdO3IkTgEC7ZngVb43FGdjxM+ki7TFW+N68Hk/tuK1hEkx96KjCU0X
M/PIjGjuyuFSbwhBhHFxSnQqCCB2keGiC4qL7UPtG/aQOfnI2wE+WQBbFlKsewe6
fRiTu4QL4u9rrQdXDgSwdu17hqaw098Qmgr9TsjtwKasoyhaBqalbpp3W80/HTOj
wuyZegkju1bj7N1NQmBuZE0wrSTsOADlq6wRAjI/uJtupki/tVskEX8HT5IjGlSR
+ThS53nhSW2TMndbIEI+aOXV9F/osa5GgQryWk9vyaeEenKlvrA=
=Dq0o
-END PGP SIGNATURE-

Bug#606639: X mouse event problems after updating squeeze on 2010-12-09 – still happening ?

[Aurélien COUDERC]

Hi Peter,

is this bug still happening on recent Debian versions.

If yes I'll assign the bug to kernel or Xorg as it's probably where the problem 
is coming from.
If no I propose closing this bug.


Thank you !
--Aurélien

Bug#850083: libgl1-mesa-glx: Driver radeonsi_dri not in expected directory /usr/lib32/dri/tls/

[Michel Dänzer]

[ Re-adding the bug report to Cc ]

On 14/01/17 08:17 AM, Andy Johnstone wrote:
> On Thu, 2017-01-05 at 17:02 +0900, Michel Dänzer wrote:
>> On 04/01/17 08:00 AM, Andy Johnstone wrote:
>>> Package: libgl1-mesa-glx
>>> Version: 13.0.2-3
>>> Severity: important
>>> Tags: d-i
>>>
>>> Dear Maintainer,
>>>
>>> After installing all required dependencies for 3D graphics (Radeon
>>> RX480) on debian stretch amd64, no applications requiring 3D would
>>> start.
>>>
>>> I am struggling to determine where/to whom this bug should be
>>> reported, please forward as necessary.
>>>
>>> Running LIBGL_DEBUG=verbose glxinfo
>>> Revealed the following:
>>>
>>> name of display: :0
>>> libGL: Can't open configuration file /home/tux/.drirc: No such file
>>> or directory.
>>> libGL: pci id for fd 4: 1002:67df, driver radeonsi
>>> libGL: OpenDriver: trying /usr/lib32/dri/tls/radeonsi_dri.so
>>> libGL: OpenDriver: trying /usr/lib32/dri/radeonsi_dri.so
>>> libGL: dlopen /usr/lib32/dri/radeonsi_dri.so failed
>>> (/usr/lib32/dri/radeonsi_dri.so: cannot open shared object file: No
>>> such file or directory)
>>>
>>> The driver is installed, but at location:
>>> /usr/lib/x86_64-linux-gnu/dri/
>>>
>>> Creating a symlink at /usr/lib32/dri/tls/ allows all 3D
>>> applications to run normally:
>>> ln -s /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so radeonsi_dri.so
>>
>> What does
>>
>>  env | grep PATH
>>
>> say in a shell which is affected by the problem?
>>
> Good morning Michael, thank you for your interest. 
> 
> tux@tuxbox:~$ env | grep PATH
> LIBGL_DRIVERS_PATH=/usr/lib32/dri:/usr/lib/dri

You need to find out where this environment variable gets set (probably
somewhere in /etc/?), and get rid of it. This isn't a libgl1-mesa-glx
package bug.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#851640: --debbuildopts not propagated anymore to cowbuilder

[Vincent Bernat]

 ❦ 17 janvier 2017 07:57 +0100, Vincent Bernat  :

> It seems the same as #618959 but it worked just fine for me until the
> latest update. Just downgrading to 0.227 fixes the problem for me.

But, then, I am hit but the /dev/shm change.
-- 
Terminate input by end-of-file or marker, not by count.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#848236: Remaining issue with gbrowse - any help (Was: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: ...)

[Andreas Tille]

Hi Lincoln,

On Mon, Jan 16, 2017 at 06:14:34PM -0500, Lincoln Stein wrote:
> I need a little help to reproduce Gregor's failed tests, given that I'm a
> complete newbie wrt the Debian packaging system. I have cloned gbrowse
> 2.56+dfsg-1 from the Debian Med repository, but I don't know what command
> line to use to attempt the build. What is the next step? I'm guessing it is
> some form of dpkg-buildpackage, but the number of options is pretty
> overwhelming!

If you have installed the devscripts package you can try

debuild

which is a wrapper around dpkg-buildpackage and in principle needs no
options to reproduce the issue.  Debuild will inform you about missing
Build-Dependencies you need to install - simply use apt-get install what
is listed if anything is missing.  When doing so I get

...
Test Summary Report
---
t/00.compile.t  (Wstat: 3840 Tests: 90 Failed: 15)
  Failed tests:  1, 3, 5, 7, 10, 15, 17-18, 29, 31, 33, 35
41, 45, 47
  Non-zero exit status: 15
t/02.rearchitecture.t   (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 90 tests but ran 0.
t/03.render.t   (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 150 tests but ran 0.
t/04.remoteserver.t (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 43 tests but ran 0.
t/05.deferredrendering.t (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 19 tests but ran 0.
t/06.featuresearch.t(Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 26 tests but ran 0.
t/07.karyotype.t(Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 3 tests but ran 0.
Files=10, Tests=103,  5 wallclock secs ( 0.05 usr  0.01 sys +  4.19 cusr  0.30 
csys =  4.55 CPU)
Result: FAIL
Failed 7/10 test programs. 15/103 subtests failed.
dh_auto_test: perl Build test --verbose 1 TEST_FILES=t/02.rearchitecture.t 
t/05.deferredrendering.t t/00.compile.t t/01.yeast.t t/07.balancer.t 
t/08.calign.t returned exit code 255


Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#851640: --debbuildopts not propagated anymore to cowbuilder

[Vincent Bernat]

Package: pbuilder
Version: 0.228
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

Since the latest update of pbuilder, options passed to pdebuild
through --debbuildopts are not passed to cowbuilder anymore.

bernat   11433  0.0  0.0   4284   784 pts/1S+   07:50   0:00 /bin/sh -c 
git-pbuilder -sa
bernat   11434  0.0  0.0  11192  3032 pts/1S+   07:50   0:00 /bin/bash 
/usr/bin/git-pbuilder -sa
bernat   11440  0.0  0.0  11732  3504 pts/1S+   07:50   0:00 /bin/bash 
/usr/bin/pdebuild --buildresult ../ --pbuilder cowbuilder --debbuildopts  '-sa' 
-- --basepath /var/cache/pbuilder/base-jessie-backports.cow
bernat   11466  0.0  0.0  11732  2664 pts/1S+   07:50   0:00 /bin/bash 
/usr/bin/pdebuild --buildresult ../ --pbuilder cowbuilder --debbuildopts  '-sa' 
-- --basepath /var/cache/pbuilder/base-jessie-backports.cow
root 11791  0.0  0.0  68368  3868 pts/1S+   07:50   0:00 sudo -E 
cowbuilder --build --buildresult /home/bernat/code/debian/build-area 
--debbuildopts  --debbuildopts  --basepath 
/var/cache/pbuilder/base-jessie-backports.cow ../haproxy_1.7.2-1~bpo8+1.dsc
root 11792  0.0  0.0  10676  1832 pts/1S+   07:50   0:00 cowbuilder 
--build --buildresult /home/bernat/code/debian/build-area --debbuildopts  
--debbuildopts  --basepath /var/cache/pbuilder/base-jessie-backports.cow 
../haproxy_1.7.2-1~bpo8+1.dsc

It seems the same as #618959 but it worked just fine for me until the
latest update. Just downgrading to 0.227 fixes the problem for me.

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

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

Versions of packages pbuilder depends on:
ii  cdebootstrap   0.7.6
ii  debconf [debconf-2.0]  1.5.59
ii  debootstrap1.0.87
ii  dpkg-dev   1.18.18
ii  wget   1.18-4

Versions of packages pbuilder recommends:
ii  devscripts  2.17.0
ii  eatmydata   105-5
ii  fakeroot1.21-3
ii  iproute24.9.0-1
ii  net-tools   1.60+git20161116.90da8a0-1
ii  sudo1.8.19p1-1

Versions of packages pbuilder suggests:
ii  cowdancer   0.83
ii  gdebi-core  0.9.5.7+nmu1

- -- Configuration Files:
/etc/pbuilderrc changed [not included]

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAlh9wG8SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5kzIQAIji6JI14YDQ4RO3GJlkqRY9Kmsr2sbX
6m3WnpI8p+LI8z2MfNUQgW9X0zTkW33ZQn7VQmxrV1K9z9gSujQlNNEUZET0j9aC
ZpZOWbS3MqNp3aheB7AoL/HGNrfY2Zam8aYPlELf3li5KztRC0/SKqgVFiT6gJxl
tuVsIJV2EIG5VYfUy8Ee4ZYp+5VBt5AYmYz0pOO5Z7evE5nSYL5sod8pUqBXf9hy
uEwH12Q166njUllwRsK6udiQr6TgAb1/urr/kI78Yo0tSygmsdzSujyO6DXifiS4
zrFQ0rnPjjpBXO1a4WHdGQTZ4yHAGih9MLBpywyhv7zNuvdXoVDNeCIIgLLJbamA
xi5Oh4ieEXXx2ZMvttToehYr56ucFA4HNM9EqJWASzP1gHB3YJI4ealCyO7o/19Z
v0Hpl+2Ag607fETEiYRRvBIh2j6ymjniAqi+CYQ9xaedxV6AY+4L1MQl1u9smOw5
SIJLtn0egsbeGOXYlsk4JJjTPVuWJ8QMAl3Dpgd5R4Czi6TnhYkL/BXDpk67dmjH
tSMDk5B8xzN8sS1ywOnUHGZEz+GxyGkfJ1VBegJG9lsFHF6b9MnhoO1YJMw4xnDH
DHRbCSQA1fUwMMfCcEiKJ472jLyTIlTMc7S+Rz7MhdTdSv/4MUBMsIeGgEkxmvJ5
R/fCNAX3fCoK
=nNl7
-END PGP SIGNATURE-

Bug#851508: Russian translation for apt-listbugs/ru.po

[Sergey Alyoshin]

Updated translation.


ru.po.gz
Description: GNU Zip compressed data

Bug#851612: CVE-2017-0381

[Jean-Marc Valin]

Hi,

CVE-2017-0381 states that:
"A remote code execution vulnerability in silk/NLSF_stabilize.c in
libopus in Mediaserver could enable an attacker using a specially
crafted file to cause memory corruption during media file and data
processing."

Now I'm not sure who did the analysis of this bug, but the analysis we
did concluded that the very worst that could happen was a slightly out
of bounds *read* 256 bytes before a constant table. What this means in
practice is that the value is read from another table and the decoded
data audio will sound bad (which was already going to happen if you're
decoding garbage data).

The worst case that could happen is a plain crash. This would happen if
the code is compiled with assertions (the code would assert before
making the read), or -- if you're really unlucky -- if the table is
placed just after some unreadable memory.

So while the bug definitely needed to be fixed -- and was fixed back in
July -- we don't consider it to be a severe security issue. If you
disagree with our analysis, could you point out what we missed?

Cheers,

Jean-Marc

Bug#851637: Baffling assword gui error without gir1.2-gtk-3.0 installed

[Jameson Graef Rollins]

On Mon, Jan 16 2017, Russ Allbery  wrote:
>> I wonder though if this is a Gtk packaging issue instead of an assword
>> one.  assword includes a dependency on the python gtk package it
>> utilizes (python3-gi).  If that package is non-functional without other
>> packages installed, doesn't that mean that pytho3-gi is missing a
>> dependency?  Seems like we should forward this to python3-gi.
>
> I tried to figure out if that's the case.  I think the problem may be that
> python3-gi is intended to support a very wide variety of different
> packages that use GObject, and therefore doesn't depend on any of them
> explicitly (since they may not be used in a particular use case).  Once I
> finally thought about the long description of that package, I noticed it
> says:
>
>  This package contains the Python 3 binding generator for libraries that
>  support gobject-introspection, i. e. which ship a gir1.2--
>  package.

Do you know how to determine which gir package is required for the
desired interface?

> So if it can work with any of those packages, I understand why they don't
> depend on any of them.

Shouldn't python3-gi therefore have a dependency on the logical OR of
all the gir packages?  If it won't work without any of them installed,
then it seems like there is some sort of logical dependency there.  The
trick is how to encode it.  Seems like dpkg should be able to represent
that somehow.

I worry that other people attempting to use python3-gi will run into the
same problem, without any explanation as to why.

jamie.


signature.asc
Description: PGP signature

Bug#851637: Baffling assword gui error without gir1.2-gtk-3.0 installed

[Russ Allbery]

Jameson Graef Rollins  writes:

> Hi, Russ.  Thanks for the bug report, and I'm very sorry about the
> trouble.

No worries.  I'm more bemused than anything, since the required package
was so obscure.  :)

> I wonder though if this is a Gtk packaging issue instead of an assword
> one.  assword includes a dependency on the python gtk package it
> utilizes (python3-gi).  If that package is non-functional without other
> packages installed, doesn't that mean that pytho3-gi is missing a
> dependency?  Seems like we should forward this to python3-gi.

I tried to figure out if that's the case.  I think the problem may be that
python3-gi is intended to support a very wide variety of different
packages that use GObject, and therefore doesn't depend on any of them
explicitly (since they may not be used in a particular use case).  Once I
finally thought about the long description of that package, I noticed it
says:

 This package contains the Python 3 binding generator for libraries that
 support gobject-introspection, i. e. which ship a gir1.2--
 package.

(which is how I finally figured out the right package).  There are *tons*
of those packages in the archive:

$ apt-cache search ^gir1.2- | wc -l
201

So if it can work with any of those packages, I understand why they don't
depend on any of them.

I do agree that there should be some kind of warning somewhere in the
python3-gi package (and I couldn't find anything in
/usr/share/doc/python3-gi) that packages that depend on it need to also
depend on the gir1.2-* packages corresponding to the interfaces that they
use.

I suspect most people haven't run into this problem because they're using
assword on their laptop where they have GNOME or something installed,
which ends up pulling in these packages anyway.  (I have a somewhat
unusual use case where I'm running assword on a remote server over a
forwarded X connection.)

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

Bug#851639: ITP: alacritty -- A cross-platform, GPU-accelerated terminal emulator

[Eric Dorland]

Package: wnpp
Severity: wishlist
Owner: Eric Dorland 

* Package name: alacritty
  Upstream Author : Joe Wilm  
* URL : https://github.com/jwilm/alacritty
* License : Apache 2.0
  Programming Lang: Rust
  Description : A cross-platform, GPU-accelerated terminal emulator

Alacritty is the fastest terminal emulator in existence. Using the GPU for
rendering enables optimizations that simply aren't possible in other emulators.

Bug#851637: Baffling assword gui error without gir1.2-gtk-3.0 installed

[Jameson Graef Rollins]

On Mon, Jan 16 2017, Russ Allbery  wrote:
> If one runs assword gui with its dependencies installed but without a
> full Gtk environment, it produces the following baffling error message:
>
> $ assword gui ''
> Traceback (most recent call last):
>   File "/usr/bin/assword", line 11, in 
> load_entry_point('assword==0.10', 'console_scripts', 'assword')()
>   File "/usr/lib/python3/dist-packages/assword/__main__.py", line 553, in main
> func(args)
>   File "/usr/lib/python3/dist-packages/assword/__main__.py", line 327, in gui
> from assword.gui import Gui
>   File "/usr/lib/python3/dist-packages/assword/gui.py", line 2, in 
> gi.require_version('Gtk', '3.0')
>   File "/usr/lib/python3/dist-packages/gi/__init__.py", line 118, in 
> require_version
> raise ValueError('Namespace %s not available' % namespace)
> ValueError: Namespace Gtk not available
>
> Installing gir1.2-gtk-3.0 resolves this error, but it's very difficult to
> discover that this is the fix, since there's no mention of this package
> anywhere in the assword package metadata.  I'm both an experienced Debian
> developer and use Python regularly, and it took me several months to
> finally hit on the right clues to track down this package, after lots of
> wasted time installing random Python Gtk packages and comparing all the
> Python libraries I had installed with another system where it was working.
>
> Could this please be listed in Recommends or in a README.Debian file or
> *somewhere* where people might be able to find it?

Hi, Russ.  Thanks for the bug report, and I'm very sorry about the
trouble.

I wonder though if this is a Gtk packaging issue instead of an assword
one.  assword includes a dependency on the python gtk package it
utilizes (python3-gi).  If that package is non-functional without other
packages installed, doesn't that mean that pytho3-gi is missing a
dependency?  Seems like we should forward this to python3-gi.

jamie.


signature.asc
Description: PGP signature

Bug#850513: Fwd: Bug#850513: epiphany-browser: Epiphany locks up system when visiting https://exoplanets.nasa.gov/newworldsatlas/582/ or the like

[Vince Barwinski]

-- Forwarded message --
From: Vince Barwinski 
Date: 10 January 2017 at 22:41
Subject: Re: Bug#850513: epiphany-browser: Epiphany locks up system when
visiting https://exoplanets.nasa.gov/newworldsatlas/582/ or the like
To: "Matteo F. Vescovi" 


Hi there

I am extremely reluctant to pollute my system with the unstable Sid. I will
at some stage install Sid in Virtual Box and see if the bug still exists
there. Epiphany is not the only browser over the last three or so weeks to
be acting strangely. Chromium/Chrome crash constantly although they don't
crash my system, and Opera, (I know, it is not an official Debian package)
which runs beautifully on my Debian stable partition, randomly crashes in
testing, although without locking up my system. The only reliable browser
for me in testing right now is Firefox.

Cheers




On 7 January 2017 at 23:23, Matteo F. Vescovi  wrote:

> Hi!
>
> On 2017-01-07 at 21:58 (+1000), Vince Barwinski wrote:
> > Version: 3.22.3-1
>
> [...]
>
> I must admit that I tagged this as unreproducible on my side while using
> Epiphany 3.22.4-1 from unstable/sid.
> Vince, please try to upgrade to unstable version and test again.
>
> Cheers.
>
> --
> Matteo F. Vescovi
>

Bug#850513: Fwd: Bug#850513: epiphany-browser: Epiphany locks up system when visiting https://exoplanets.nasa.gov/newworldsatlas/582/ or the like

[Vince Barwinski]

-- Forwarded message --
From: Vince Barwinski 
Date: 13 January 2017 at 21:22
Subject: Re: Bug#850513: epiphany-browser: Epiphany locks up system when
visiting https://exoplanets.nasa.gov/newworldsatlas/582/ or the like
To: "Matteo F. Vescovi" 


Hi Matteo

In Virtual Box, I installed Debian Testing, then upgraded it to Sid and ran
epiphany-browser 3.22.4-1. While it did not crash the system, no web pages
at all will load. On my host OS of Debian Testing, I did my weekly upgrade
and epiphany was upgraded to  3.22.4-1. When I loaded the NASA exoplanet
sim link, (eg https://exoplanets.nasa.gov/newworldsatlas/191/) I first got
the message:

Oops!
Something went wrong while displaying this page.
Please reload or visit a different page to continue.

So I reloaded the page. Bad Idea--my system locked up again! The output
from my logs being as follows:

[root@debiantesting vince]# check_for_segfaults
Fri 13 Jan 21:13:19 AEST 2017



cat /var/log/messages | grep -ia segfault


Jan 13 20:55:13 debiantesting kernel: [ 8977.754847] WebKitWebProces[3988]:
segfault at 153 ip 7f9f421d8f16 sp 7f9f43bfc1a0 error 4 in
nouveau_dri.so[7f9f41c79000+93b000] (Most recent lock-up)



cat /var/log/messages.1 | grep -ia segfault


Jan  7 15:06:36 debiantesting kernel: [17995.243137] WebKitWebProces[6922]:
segfault at 7fd203ed9000 ip 7fd17f7ede37 sp 7ffe10d59f88 error 4 in
nouveau_dri.so[7fd17f288000+93b000]
Jan  7 21:33:29 debiantesting kernel: [41208.319112] reportbug[3966]:
segfault at 38 ip 7fdb2b4ebaf2 sp 7fdb2912e1e0 error 4 in
libgtk-3.so.0.2200.5[7fdb2b1e+6fe000]



cat /var/log/kern.log | grep -ia segfault


Jan 13 20:55:13 debiantesting kernel: [ 8977.754847] WebKitWebProces[3988]:
segfault at 153 ip 7f9f421d8f16 sp 7f9f43bfc1a0 error 4 in
nouveau_dri.so[7f9f41c79000+93b000]



cat /var/log/kern.log.1 | grep -ia segfault


Jan  7 15:06:36 debiantesting kernel: [17995.243137] WebKitWebProces[6922]:
segfault at 7fd203ed9000 ip 7fd17f7ede37 sp 7ffe10d59f88 error 4 in
nouveau_dri.so[7fd17f288000+93b000]
Jan  7 21:33:29 debiantesting kernel: [41208.319112] reportbug[3966]:
segfault at 38 ip 7fdb2b4ebaf2 sp 7fdb2912e1e0 error 4 in
libgtk-3.so.0.2200.5[7fdb2b1e+6fe000]

Just as before

Epiphany is far from being my main browser, but Chromium locks up (although
at least not my whole system) when I just leave it to idle for ten or so
minutes on the espncricinfo.com site. The only reliable browsers in testing
for me are Firefox and Qupzilla. In regards to epiphany, I have purged my
host debian testing system of it.

All the best

Vince



On 7 January 2017 at 23:23, Matteo F. Vescovi  wrote:

> Hi!
>
> On 2017-01-07 at 21:58 (+1000), Vince Barwinski wrote:
> > Version: 3.22.3-1
>
> [...]
>
> I must admit that I tagged this as unreproducible on my side while using
> Epiphany 3.22.4-1 from unstable/sid.
> Vince, please try to upgrade to unstable version and test again.
>
> Cheers.
>
> --
> Matteo F. Vescovi
>

Bug#848982: [pkg-wpa-devel] Bug#848982: wpasupplicant fails to connect to WPA Enterprise network with 2.6-2

[Kan-Ru Chen]

I'm also using network manager and have a Qualcomm Atheros QCA6174 (Dell
XPS 9360) and cannot connect to PEAP network recently.

I've tried downgrading wpasupplicant, network-manager and even linux
kernel but none of them fixes the problem.

>From log and code it looks like network-manager already send all
uppercase auth=MSCHAPV2 to wpasupplicant.

My unsuccessful logs look like:

Jan 17 11:45:26 foo wpa_supplicant[1025]: wlp58s0: SME: Trying to
authenticate with 78:19:f7:75:6f:81 (SSID='Baz' freq=5320 MHz)
Jan 17 11:45:26 foo kernel: [ 1220.206224] wlp58s0: authenticate with
78:19:f7:75:6f:81
Jan 17 11:45:26 foo kernel: [ 1220.251155] wlp58s0: send auth to
78:19:f7:75:6f:81 (try 1/3)
Jan 17 11:45:26 foo kernel: [ 1220.251862] wlp58s0: authenticated
Jan 17 11:45:26 foo wpa_supplicant[1025]: wlp58s0: Trying to associate
with 78:19:f7:75:6f:81 (SSID='Baz' freq=5320 MHz)
Jan 17 11:45:26 foo NetworkManager[650]:   [1484624726.9616]
device (wlp58s0): supplicant interface state: scanning -> authenticating
Jan 17 11:45:26 foo kernel: [ 1220.259636] wlp58s0: associate with
78:19:f7:75:6f:81 (try 1/3)
Jan 17 11:45:26 foo kernel: [ 1220.260877] wlp58s0: RX AssocResp from
78:19:f7:75:6f:81 (capab=0x511 status=0 aid=8)
Jan 17 11:45:26 foo kernel: [ 1220.263589] wlp58s0: associated
Jan 17 11:45:26 foo wpa_supplicant[1025]: wlp58s0: Associated with
78:19:f7:75:6f:81
Jan 17 11:45:26 foo wpa_supplicant[1025]: wlp58s0:
CTRL-EVENT-EAP-STARTED EAP authentication started
Jan 17 11:45:26 foo wpa_supplicant[1025]: wlp58s0:
CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Jan 17 11:45:26 foo wpa_supplicant[1025]: wlp58s0:
CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
Jan 17 11:45:26 foo wpa_supplicant[1025]: wlp58s0: CTRL-EVENT-EAP-METHOD
EAP vendor 0 method 25 (PEAP) selected
Jan 17 11:45:26 foo wpa_supplicant[1025]: wlp58s0:
CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=TW
Jan 17 11:45:26 foo kernel: [ 1220.272467] wlp58s0: deauthenticated from
78:19:f7:75:6f:81 (Reason: 1=UNSPECIFIED)
Jan 17 11:45:26 foo kernel: [ 1220.272842] ath: EEPROM regdomain: 0x809e
Jan 17 11:45:26 foo kernel: [ 1220.272843] ath: EEPROM indicates we
should expect a country code
Jan 17 11:45:26 foo kernel: [ 1220.272844] ath: doing EEPROM
country->regdmn map search
Jan 17 11:45:26 foo kernel: [ 1220.272844] ath: country maps to regdmn
code: 0x50
Jan 17 11:45:26 foo kernel: [ 1220.272845] ath: Country alpha2 being
used: TW
Jan 17 11:45:26 foo kernel: [ 1220.272845] ath: Regpair used: 0x50
Jan 17 11:45:26 foo kernel: [ 1220.272846] ath: regdomain 0x809e
dynamically updated by country IE
Jan 17 11:45:27 foo wpa_supplicant[1025]: wlp58s0:
CTRL-EVENT-DISCONNECTED bssid=78:19:f7:75:6f:81 reason=1
Jan 17 11:45:27 foo wpa_supplicant[1025]: wlp58s0:
CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Jan 17 11:45:27 foo NetworkManager[650]:   [1484624727.0250]
device (wlp58s0): supplicant interface state: authenticating ->
associating
Jan 17 11:45:27 foo NetworkManager[650]:   [1484624727.0265]
device (wlp58s0): supplicant interface state: associating -> associated
Jan 17 11:45:27 foo NetworkManager[650]:   [1484624727.0269]
sup-iface[0x558eaae0aa20,wlp58s0]: connection disconnected (reason 1)
Jan 17 11:45:27 foo NetworkManager[650]:   [1484624727.0269]
device (wlp58s0): supplicant interface state: associated -> disconnected
Jan 17 11:45:27 foo wpa_supplicant[1025]: wlp58s0:
CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=TW
Jan 17 11:45:27 foo NetworkManager[650]:   [1484624727.1257]
device (wlp58s0): supplicant interface state: disconnected -> scanning

Boot with a Ubuntu 16.04 live cd with proper firmware can connect to the
network successfully. I only has this live cd handy but I can test with
Debian later.

Kanru

Bug#850513: epiphany-browser: Epiphany locks up system when visiting https://exoplanets.nasa.gov/newworldsatlas/582/ or the like

[Vince Barwinski]

On Sat, 07 Jan 2017 14:23:11 +0100 "Matteo F. Vescovi" 
wrote:
> Hi!
>
> On 2017-01-07 at 21:58 (+1000), Vince Barwinski wrote:
> > Version: 3.22.3-1
>
> [...]
>
> I must admit that I tagged this as unreproducible on my side while using
> Epiphany 3.22.4-1 from unstable/sid.
> Vince, please try to upgrade to unstable version and test again.
>
> Cheers.
>
> --
> Matteo F. Vescovi

Hi Matteo

In Virtual Box, I installed Debian Testing, then upgraded it to Sid and ran
epiphany-browser 3.22.4-1. While it did not crash the system, no web pages
at all will load. On my host OS of Debian Testing, I did my weekly upgrade
and epiphany was upgraded to  3.22.4-1. When I loaded the NASA exoplanet
sim link, (eg https://exoplanets.nasa.gov/newworldsatlas/191/) I first got
the message:

Oops!
Something went wrong while displaying this page.
Please reload or visit a different page to continue.

So I reloaded the page. Bad Idea--my system locked up again! The output
from my logs being as follows:

[root@debiantesting vince]# check_for_segfaults
Fri 13 Jan 21:13:19 AEST 2017



cat /var/log/messages | grep -ia segfault


Jan 13 20:55:13 debiantesting kernel: [ 8977.754847] WebKitWebProces[3988]:
segfault at 153 ip 7f9f421d8f16 sp 7f9f43bfc1a0 error 4 in
nouveau_dri.so[7f9f41c79000+93b000] (Most recent lock-up)



cat /var/log/messages.1 | grep -ia segfault


Jan  7 15:06:36 debiantesting kernel: [17995.243137] WebKitWebProces[6922]:
segfault at 7fd203ed9000 ip 7fd17f7ede37 sp 7ffe10d59f88 error 4 in
nouveau_dri.so[7fd17f288000+93b000]
Jan  7 21:33:29 debiantesting kernel: [41208.319112] reportbug[3966]:
segfault at 38 ip 7fdb2b4ebaf2 sp 7fdb2912e1e0 error 4 in
libgtk-3.so.0.2200.5[7fdb2b1e+6fe000]



cat /var/log/kern.log | grep -ia segfault


Jan 13 20:55:13 debiantesting kernel: [ 8977.754847] WebKitWebProces[3988]:
segfault at 153 ip 7f9f421d8f16 sp 7f9f43bfc1a0 error 4 in
nouveau_dri.so[7f9f41c79000+93b000]



cat /var/log/kern.log.1 | grep -ia segfault


Jan  7 15:06:36 debiantesting kernel: [17995.243137] WebKitWebProces[6922]:
segfault at 7fd203ed9000 ip 7fd17f7ede37 sp 7ffe10d59f88 error 4 in
nouveau_dri.so[7fd17f288000+93b000]
Jan  7 21:33:29 debiantesting kernel: [41208.319112] reportbug[3966]:
segfault at 38 ip 7fdb2b4ebaf2 sp 7fdb2912e1e0 error 4 in
libgtk-3.so.0.2200.5[7fdb2b1e+6fe000]

Just as before

Epiphany is far from being my main browser, but Chromium locks up (although
at least not my whole system) when I just leave it to idle for ten or so
minutes on the espncricinfo.com site. The only reliable browsers in testing
for me are Firefox and Qupzilla. In regards to epiphany, I have purged my
host debian testing system of it.

All the best

Bug#835274: bcron

[Dmitry Bogatov]

[2017-01-12 20:00] Gianfranco Costamagna 
> >I consider disabling mentioned three tests (exec-fds,
> >spool-list-perms,sched_dump). WDYT?
>
> probably the best solution right now

Did it. New revision is on mentors, hash commit in git is fbd6d60.

--
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.

Bug#851638: beets: bpd plugin unintentionally returns floats for status.time

[Carl Suster]

Package: beets
Version: 1.3.19-2
Severity: minor
Tags: upstream
Control: affects -1 + mpdris2
Control: forwarded -1 https://github.com/beetbox/beets/issues/2394

Dear Maintainer,

There is a minor bug in upstream beets which affects the bpd plugin. This
plugin implements an mpd server but the bug causes it to return non-integer
values in the time field of the status command.

This doesn't seem to affect a lot of mpd clients which manage to cope with the
values anyway, but at least mpDris2 crashes immediately when launched connected
to an instance of beet bpm (ValueError: invalid literal for int() with base
10). There is also an upstream issue open against mpDris2 about making it more
robust to server responses (https://github.com/eonpatapon/mpDris2/issues/84).

Hopefully this bug report will save someone else the debugging effort until the
problems are sorted out upstream.

Bug#819811: ITP: leiningen -- simple build system for Clojure

[Elana Hashman]

Hello!

Finally following up with some conversations I had at Clojure/conj, I'd 
like to help get the ball rolling on this again. Based on leiningen 
2.7.1's dependencies, here's what we'll need to package/upgrade to make 
this happen.



Packages that have a higher version in Debian unstable than in leiningen 
2.7.1:


libdynapath-clojure aka org.tcrawley/dynapath (2.5.1 > 2.4.1)
libmaven-indexer-java aka org.apache.maven.indexer/indexer-core (5.1.1 > 
4.1.3)

libcommons-io-java aka commons-io (2.5 > 2.4)

All but libmaven-indexer-java have been upgraded to the correct versions 
on upstream leiningen master. I've submitted a pull request to upgrade 
that dependency: https://github.com/technomancy/leiningen/pull/2234



Packages that are in Debian with the right versions:

librobert-hooke-clojure aka robert/hooke (1.3.0)
libwagon2-java aka org.apache.maven.wagon/wagon-http (2.10)
libcom-hypirion-io-clojure aka com.hypirion/io (0.3.1)
libdata-xml-clojure aka org.clojure/data.xml (0.0.8)
libcomplete-clojure aka clojure-complete (0.2.4)


Packages that are in Debian, but need updates:

libbultitude-clojure aka bultitude (0.2.7 < 0.2.8)
libpomegranate-clojure aka com.cemerick/pomegranate (0.2.0 < 0.3.1)
libslingshot-clojure aka slingshot (0.10.3 < 0.12.2)


Here's the full dependency chains of all the missing packages (per `lein 
deps :tree`):


 [cheshire "5.6.3"]
   [com.fasterxml.jackson.core/jackson-core "2.7.5"]
   [com.fasterxml.jackson.dataformat/jackson-dataformat-cbor "2.7.5"]
   [com.fasterxml.jackson.dataformat/jackson-dataformat-smile "2.7.5"]
   [tigris "0.1.1"]
 [classlojure "0.6.6"]
   [useful "0.8.3-alpha8"]
 [org.clojure/tools.macro "0.1.1"]
 [clj-http "2.0.1"]
   [commons-codec "1.10" :exclusions [[org.clojure/clojure]]]
   [org.apache.httpcomponents/httpclient "4.5" :exclusions 
[[org.clojure/clojure]]]
   [org.apache.httpcomponents/httpcore "4.4.1" :exclusions 
[[org.clojure/clojure]]]
   [org.apache.httpcomponents/httpmime "4.5" :exclusions 
[[org.clojure/clojure]]]

   [potemkin "0.4.1" :exclusions [[org.clojure/clojure]]]
 [clj-tuple "0.2.2"]
 [riddley "0.1.10"]
 [pedantic "0.2.0"]
 [net.cgrand/parsley "0.9.3" :exclusions [[org.clojure/clojure]]]
   [net.cgrand/regex "1.1.0"]
 [org.clojure/tools.nrepl "0.2.12"]
 [reply "0.3.7" :exclusions [[ring/ring-core] [org.thnetos/cd-client]]]
   [clj-stacktrace "0.2.7"]
   [com.cemerick/drawbridge "0.0.6" :exclusions 
[[org.clojure/tools.nrepl]]]

   [jline "2.12.1"]
   [net.cgrand/sjacket "0.1.1" :exclusions [[org.clojure/clojure]]]
   [org.clojure/tools.cli "0.3.1"]
   [trptcolin/versioneer "0.1.1"]
 [stencil "0.5.0" :exclusions [[org.clojure/core.cache]]]
   [quoin "0.1.2"]
   [scout "0.1.0"]


To make that slightly more legible, here are the (grand-)dependencies we 
need in Debian:


libtools-macro-clojure (0.1.5 > 0.1.1)
libcommons-codec-java (1.10)
libhttpclient-java (4.5)
libhttpcore-java (4.4.6 > 4.4.1)
libhttpmime-java (4.5.2 > 4.5)
libversioneer-clojure (0.1.1)
libscout-clojure (0.1.1 > 0.1.0)


Here are the ones that are in Debian but need upgrades:

libclj-stacktrace-clojure (0.2.6 < 0.2.7)
libtools-cli-clojure (0.2.4 < 0.3.1)
libjline2-java (2.11 < 2.12.1)


And last, here are all the missing ones, preserving dependency chains:

 [cheshire "5.6.3"]
   [com.fasterxml.jackson.core/jackson-core "2.7.5"]
   [com.fasterxml.jackson.dataformat/jackson-dataformat-cbor "2.7.5"]
   [com.fasterxml.jackson.dataformat/jackson-dataformat-smile "2.7.5"]
   [tigris "0.1.1"]

 [classlojure "0.6.6"]
   [useful "0.8.3-alpha8"]

 [clj-http "2.0.1"]
   [potemkin "0.4.1" :exclusions [[org.clojure/clojure]]]
 [clj-tuple "0.2.2"]
 [riddley "0.1.10"]

 [pedantic "0.2.0"]

 [net.cgrand/parsley "0.9.3" :exclusions [[org.clojure/clojure]]]
   [net.cgrand/regex "1.1.0"]

 [org.clojure/tools.nrepl "0.2.12"]

 [reply "0.3.7" :exclusions [[ring/ring-core] [org.thnetos/cd-client]]]
   [com.cemerick/drawbridge "0.0.6" :exclusions 
[[org.clojure/tools.nrepl]]]

   [net.cgrand/sjacket "0.1.1" :exclusions [[org.clojure/clojure]]]

 [stencil "0.5.0" :exclusions [[org.clojure/core.cache]]]
   [quoin "0.1.2"]


Hope everyone finds this helpful.

- e

Bug#823180: SSO certificates for tracker.debian.org broken

[Russ Allbery]

Hi Enrico,

Is there any way that I or someone can help with the current issue with
enrolling on sso.debian.org?  It looks like this was originally reported
in May of last year on this bug.

There are two problems: one is that if one goes to tracker.debian.org and
selects Login and then follows the bold link to sso.debian.org, that link
(https://sso.debian.org/spkac/enroll/) is 404.

If one goes directly to sso.debian.org, clicks on Debian account
certificates, and logs in, clicks on Get new certificate, and then
submits, it just produces "/usr/bin/openssl failed" as an error message at
the top of the page.

I'd be happy to try to help out with a fix if the problem is just that
you're swamped, although I'm not sure where all the pieces are and
probably don't have access, so it may require a bit of poking around.

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

Bug#851637: Baffling assword gui error without gir1.2-gtk-3.0 installed

[Russ Allbery]

Package: assword
Version: 0.10-1
Severity: normal

If one runs assword gui with its dependencies installed but without a
full Gtk environment, it produces the following baffling error message:

$ assword gui ''
Traceback (most recent call last):
  File "/usr/bin/assword", line 11, in 
load_entry_point('assword==0.10', 'console_scripts', 'assword')()
  File "/usr/lib/python3/dist-packages/assword/__main__.py", line 553, in main
func(args)
  File "/usr/lib/python3/dist-packages/assword/__main__.py", line 327, in gui
from assword.gui import Gui
  File "/usr/lib/python3/dist-packages/assword/gui.py", line 2, in 
gi.require_version('Gtk', '3.0')
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 118, in 
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Gtk not available

Installing gir1.2-gtk-3.0 resolves this error, but it's very difficult to
discover that this is the fix, since there's no mention of this package
anywhere in the assword package metadata.  I'm both an experienced Debian
developer and use Python regularly, and it took me several months to
finally hit on the right clues to track down this package, after lots of
wasted time installing random Python Gtk packages and comparing all the
Python libraries I had installed with another system where it was working.

Could this please be listed in Recommends or in a README.Debian file or
*somewhere* where people might be able to find it?

Thanks!

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

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

Versions of packages assword depends on:
ii  python3-gi   3.22.0-2
ii  python3-gpg  1.8.0-3
pn  python3:any  

Versions of packages assword recommends:
pn  python3-xdo  
ii  xclip0.12+svn84-4

assword suggests no packages.

-- no debconf information

Bug#851508: Russian translation for apt-listbugs/ru.po

[Sergey Alyoshin]

On Tue, Jan 17, 2017 at 1:14 AM, Francesco Poli
 wrote:
> On Mon, 16 Jan 2017 08:07:01 +0300 Sergey Alyoshin wrote:
>
>> On Mon, Jan 16, 2017 at 1:20 AM, Francesco Poli
>>  wrote:
>> > On Sun, 15 Jan 2017 22:22:18 +0300 Sergey Alyoshin wrote:
>> >
>> >> Package: apt-listbugs
>> >> Version: 0.1.22
>> >> Priority: wishlist
>> >> Tags: l10n
>> >
>> > Hello Sergey,
>> > thanks for sending me a new translation!
>> > I'll take a look at it very soon (hopefully).
>>
>>
>> Thanks for quick reply and you work.
>
> I have a couple of questions.
>
> First of all:
>
>   "Plural-Forms: nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n"
>   "%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 && n%10<=9) || 
> (n"
>   "%100>=11 && n%100<=14)? 2 : 3);\n"
>
> Is this the correct plural rule for the Russian language?
> According to
> https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html
> it should be
>
>   "Plural-Forms: nplurals=3;"
>   "plural=n%10==1 && n%100!=11 ? 0 :"
>   "n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n"
>
> And this is indeed the plural rule that you seem to have used in your
> translation for postfix debconf templates (see bug #851489).
>
> Could you please clarify why you used a different rule for the
> apt-listbugs translation?

Transifex is using nplurals=4 for Russian, and this is conform to
http://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html#ru

But as plural form 4 is for floating point numbers, I can change it to
nplurals=3.


> Secondly:
>
>   #: ../lib/aptlistbugs/logic.rb:83
>   msgid "Outstanding"
>   msgstr "Исключительных"
>
> Please note that, here, "Outstanding" means "unresolved", not
> "exceptional"...
> Is the above translation correct? Or should another Russian word be
> used?
>

In such case it will be "нерешённые" (ошибки).


> Please note that, although I studied a little bit of Russian in the
> past, my knowledge has never been too detailed and my memories are
> definitely rusty now... Hence I may well be completely off-track.

Bug#765180: python3-argcomplete: Add binary helpers

[Jeremy Bicha]

Control: tags -1 +patch

Ubuntu has been shipping the scripts in python3-argcomplete instead of
in python-argcomplete for a while.

Thanks,
Jeremy Bicha

diff -pruN 0.8.1-1/debian/rules 0.8.1-1ubuntu2/debian/rules
--- 0.8.1-1/debian/rules2014-10-09 00:01:18.0 +
+++ 0.8.1-1ubuntu2/debian/rules2016-01-10 12:12:41.0 +
@@ -4,11 +4,22 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 export PYBUILD_NAME=argcomplete
-export PYBUILD_AFTER_INSTALL_python3=rm -rf {destdir}/usr/bin

 %:
 dh $@ --with python2,python3 --buildsystem=pybuild

+override_dh_auto_install:
+dh_auto_install -O--buildsystem=pybuild
+mkdir -p debian/python3-argcomplete/usr/share/man/man1
+for i in \
+  activate-global-python-argcomplete \
+  python-argcomplete-check-easy-install-script \
+  register-python-argcomplete; \
+do \
+  mv debian/python3-argcomplete/usr/bin/$$i
debian/python3-argcomplete/usr/bin/$${i}3; \
+  cp debian/$$i.1 debian/python3-argcomplete/usr/share/man/man1/$${i}3.1; \
+done
+
 generate_manpages:
 VERSION=$$(./setup.py -V) ; \
 for file in activate-global-python-argcomplete
python-argcomplete-check-easy-install-script
register-python-argcomplete ; do \

Bug#851635: Acknowledgement (possible addition, script to find the common ancestor version of two changelogs.)

[peter green]

It was brought to my attention on irc that I screwed up the copyright year and 
I also realised that I left some crap at the bottom of the file (both of these 
were the result of using a previous script of mine as a template).

Here is a cleaned up version.

#!/usr/bin/python3
#(C) 2017 Peter Michael Green 
#This software is provided 'as-is', without any express or implied warranty. In
#no event will the authors be held liable for any damages arising from the use
#of this software.
#
#Permission is granted to anyone to use this software for any purpose, including
#commercial applications, and to alter it and redistribute it freely, subject to
#the following restrictions:
#
#1. The origin of this software must not be misrepresented; you must not claim.
#that you wrote the original software. If you use this software in a product,
#an acknowledgment in the product documentation would be appreciated but is.
#not required.
#
#2. Altered source versions must be plainly marked as such, and must not be
#misrepresented as being the original software.
#
#3. This notice may not be removed or altered from any source distribution.

from debian import changelog
import sys
changelog1 = sys.argv[1]
changelog2 = sys.argv[2]

f1 = open(changelog1,'rb')
f2 = open(changelog2,'rb')

c1 = changelog.Changelog(f1)
c2 = changelog.Changelog(f2)

s = set()

for entry in c1:
s.add(entry.version)
#print(repr(entry.version))

for entry in c2:
if entry.version in s:
commonparent = entry.version
break

print(commonparent)

Bug#851635: possible addition, script to find the common ancestor version of two changelogs.

[peter green]

Package: devscripts
Severity: wishlist

I needed to find the common ancestor version from two changelogs.

I asked about it on irc and after not getting a quick response decided to 
implement it myself. The implementation I came up with was a small python3 
script using python3-debian

The script takes two changelogs c1 and c2 and finds the first version in c2 
that is also in c1.

pabs suggested it might be useful to put it in devscripts and that I should 
file a bugreport.


#!/usr/bin/python3
#(C) 2015 Peter Michael Green 
#This software is provided 'as-is', without any express or implied warranty. In
#no event will the authors be held liable for any damages arising from the use
#of this software.
#
#Permission is granted to anyone to use this software for any purpose, including
#commercial applications, and to alter it and redistribute it freely, subject to
#the following restrictions:
#
#1. The origin of this software must not be misrepresented; you must not claim.
#that you wrote the original software. If you use this software in a product,
#an acknowledgment in the product documentation would be appreciated but is.
#not required.
#
#2. Altered source versions must be plainly marked as such, and must not be
#misrepresented as being the original software.
#
#3. This notice may not be removed or altered from any source distribution.

from debian import changelog
import sys
changelog1 = sys.argv[1]
changelog2 = sys.argv[2]

f1 = open(changelog1,'rb')
f2 = open(changelog2,'rb')

c1 = changelog.Changelog(f1)
c2 = changelog.Changelog(f2)

s = set()

for entry in c1:
s.add(entry.version)
#print(repr(entry.version))

for entry in c2:
if entry.version in s:
commonparent = entry.version
break

print(commonparent)

#for entry in c2:



sys.exit(0)

f=open(filetofix,'wb')

f.write((package+' ('+newversion+') '+distribution+'; 
urgency=medium\n').encode('utf-8'))
f.write(('\n').encode('utf-8'))
for entry in reversed(entries):
lines = entry.changes()[:] #copy this so we don't modify the libraries
   #version of it.
while (lines[0] == ''):
 del lines[0]
if ((lines[0].strip().upper())[0:8] != '[CHANGES'):
f.write(('  [changes brought forward from 
'+str(entry.version)+' by '+entry.author+' at 
'+entry.date+']\n').encode('utf-8'))
for line in lines:
f.write((line+'\n').encode('utf-8'))

f.write((' -- Raspbian forward porter   
'+date+'\n').encode('utf-8'))
f.write(('\n').encode('utf-8'))

for line in upstreamchangelog:
f.write(line)

f.close()

Bug#851636: polygen: fix seriuos → serious typo

[Chris Lamb]

Source: polygen
Version: 1.0.6.ds2-15
Severity: wishlist
Tags: patch

Hi,

The manpage grammar has a typo. Alas it's a shame I cannot file this bug as
"Severity: seriuos"...

Patch attached. 


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/man.grm b/debian/man.grm
index e54770f..2e909e4 100644
--- a/debian/man.grm
+++ b/debian/man.grm
@@ -55,7 +55,7 @@ Description ::=   ShortDesc "\n.PP\n"
^ "\n.PP\n"
^ "Here a source program is a grammar definition, the execution 
consists in the exploration of such grammar by selecting a random path and the 
result is the sentence built on the way."
^ "\n.PP\n"
-   ^ "Though PolyGen is quite a seriuos piece of software then, 
what else would be more noble for it than being used as a parody tool for 
linguistical habits, stereotypes and trends of this foolish era?"
+   ^ "Though PolyGen is quite a serious piece of software then, 
what else would be more noble for it than being used as a parody tool for 
linguistical habits, stereotypes and trends of this foolish era?"
^ "\n.PP\n"
^ "Principles of parody are focusing a ridiculous topic and 
eventually abstracting its rules and schemes (here in terms of a grammar 
definition) by which reproducing it through the variatio device."
^ "\n.PP\n"
diff --git a/debian/patches/06-typo-fix.diff b/debian/patches/06-typo-fix.diff
index 9e4e24d..b34cf9f 100644
--- a/debian/patches/06-typo-fix.diff
+++ b/debian/patches/06-typo-fix.diff
@@ -4,7 +4,7 @@
^ "\n.PP\n"
^ "Here a source program is a grammar definition, the execution 
consists in the exploration of such grammar by selecting a random path and the 
result is the sentence built on the way."
^ "\n.PP\n"
--  ^ "Though PolyGen is quite a seriuos piece of software then, 
what else would be more noble for it than being used as a parody tool for 
linguistical habits, stereotypes and trends of this foolish era?"
+-  ^ "Though PolyGen is quite a serious piece of software then, 
what else would be more noble for it than being used as a parody tool for 
linguistical habits, stereotypes and trends of this foolish era?"
 +  ^ "Though PolyGen is quite a serious piece of software then, 
what else would be more noble for it than being used as a parody tool for 
linguistical habits, stereotypes and trends of this foolish era?"
^ "\n.PP\n"
^ "Principles of parody are focusing a ridiculous topic and 
eventually abstracting its rules and schemes (here in terms of a grammar 
definition) by which reproducing it through the variatio device."
@@ -15,7 +15,7 @@
^ "\n.PP\n"
^ "Here a source program is a grammar definition, the execution 
consists in the exploration of such grammar by selecting a random path and the 
result is the sentence built on the way."
^ "\n.PP\n"
--  ^ "Though PolyGen is quite a seriuos piece of software then, 
what else would be more noble for it than being used as a parody tool for 
linguistical habits, stereotypes and trends of this foolish era?"
+-  ^ "Though PolyGen is quite a serious piece of software then, 
what else would be more noble for it than being used as a parody tool for 
linguistical habits, stereotypes and trends of this foolish era?"
 +  ^ "Though PolyGen is quite a serious piece of software then, 
what else would be more noble for it than being used as a parody tool for 
linguistical habits, stereotypes and trends of this foolish era?"
^ "\n.PP\n"
^ "Principles of parody are focusing a ridiculous topic and 
eventually abstracting its rules and schemes (here in terms of a grammar 
definition) by which reproducing it through the variatio device."
@@ -26,7 +26,7 @@
^ "\n.PP\n"
^ "Here a source program is a grammar definition, the execution 
consists in the exploration of such grammar by selecting a random path and the 
result is the sentence built on the way."
^ "\n.PP\n"
--  ^ "Though PolyGen is quite a seriuos piece of software then, 
what else would be more noble for it than being used as a parody tool for 
linguistical habits, stereotypes and trends of this foolish era?"
+-  ^ "Though PolyGen is quite a serious piece of software then, 
what else would be more noble for it than being used as a parody tool for 
linguistical habits, stereotypes and trends of this foolish era?"
 +  ^ "Though PolyGen is quite a serious piece of software then, 
what else would be more noble for it than being used as a parody tool for 
linguistical habits, stereotypes and trends of this foolish era?"
^ "\n.PP\n"
^ "Principles of parody ar

Bug#851598: tex-common: fails to upgrade jessie->stretch (recommends enabled) with cadabra installed

[Norbert Preining]

> That worked.

Thanks for testing.

> I'll now check the other failures with this new package, but that will
> take more time - some larger metapackages like med-bio are involved here.

Do you have a time frame when it will be ready? If it is reasonable I'll
wait with the upload just in case more things pop up.

All the best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#841143: False assumptions about nPth (was: Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup)

[NIIBE Yutaka]

Ian Jackson  wrote:
> I think that at least my patch
>   [PATCH 4/4] gpg agent lockup fix: Interrupt main loop when 
> active_connections_value==0
> is very likely a fix to an actual race.
[...]
> I would like this bug fixed in stretch.

I think that this issue is a bug in the patches of
debian/patches/gpg-agent-idling/.

I confirmed the possibility where the main thread might block at
npth_pselect forever.  There are connections, shutdown_pending is set by
signal, npth_pselect is called, then connections are finished.  The main
thread keeps staying at npth_pselect.

For me, it is a bit difficult to apply the fourth patch only.  So, I
seek the update of the patch:

0003-agent-Avoid-tight-timer-tick-when-possible.patch

How about changing the need_tick function, instead?  My intention is to
make the behavior of gpg-agent as similar as upstream version.

I mean, changing the first hunk of the patch of gnupg/agent/gpg-agent.c,
like this (adding the check against shutdown_pending).

--- gnupg.orig/agent/gpg-agent.c
+++ gnupg/agent/gpg-agent.c
@@ -2267,6 +2267,29 @@ create_directories (void)
 }
 
 
+static int
+need_tick (void)
+{
+#ifdef HAVE_W32_SYSTEM
+  /* We do not know how to interrupt the select loop on Windows, so we
+ always need a short tick there. */
+  return 1;
+#else
+  /* if we were invoked like "gpg-agent cmd arg1 arg2" then we need to
+ watch our parent. */
+  if (parent_pid != (pid_t)(-1))
+return 1;
+  /* if scdaemon is running, we need to check that it's alive */
+  if (agent_scd_check_running ())
+return 1;
+  /* if a shutdown was requested, we wait all connections closing.  */
+  if (shutdown_pending)
+return 1;
+  /* otherwise, nothing fine-grained to do. */
+  return 0;
+#endif /*HAVE_W32_SYSTEM*/
+}
+
 
 /* This is the worker for the ticker.  It is called every few seconds
and may only do fast operations. */
-- 

Bug#835816: rt-extension-customfieldsonupdate: please make the build (mostly) reproducible

[Satoru KURASHIKI]

hi,

On Mon, Jan 16, 2017 at 3:14 PM, Chris Lamb  wrote:
>> Would you consider applying this patch and uploading?
>
> Friendly ping on this :)

Thanks for tracking this.

I acked the patch, and stucked merging with other changes.
(and now archive freezed, so hesitating upload packages...)

regards,
-- 
KURASHIKI Satoru

Bug#851634: chromium: Chromium does not start after update

[Benjamin FRANCOIS]

Package: chromium
Version: 55.0.2883.75-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Starting chromium since latest upgrade ends up with the following message:
/usr/bin/chromium: 122: /usr/bin/chromium: Syntax error: "fi" unexpected 
(expecting "}")

It looks like it's related to a missing double-quote at the end of line 21 and 
it's fixed by the following patch:

21c21
<   echo "--enable-remote-extensions Allow extensions from remote sites
---
>   echo "--enable-remote-extensions Allow extensions from remote sites"


Best regards,


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

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

Versions of packages chromium depends on:
ii  libasound2   1.1.2-1
ii  libatk1.0-0  2.22.0-1
ii  libavcodec57 7:3.2.2-1
ii  libavformat577:3.2.2-1
ii  libavutil55  7:3.2.2-1
ii  libc62.24-9
ii  libcairo21.14.8-1
ii  libcups2 2.2.1-5
ii  libdbus-1-3  1.10.14-1
ii  libevent-2.0-5   2.0.21-stable-2.1
ii  libexpat12.2.0-2
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.3.0-2
ii  libgdk-pixbuf2.0-0   2.36.4-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk2.0-0  2.24.31-1
ii  libharfbuzz0b1.2.7-1+b1
ii  libicu57 57.1-5
ii  libjpeg62-turbo  1:1.5.1-2
ii  libminizip1  1.1-8
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpng16-16  1.6.28-1
ii  libpulse09.0-5
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.3-3
ii  libstdc++6   6.3.0-2
ii  libvpx4  1.6.0-3
ii  libwebp6 0.5.2-1
ii  libwebpdemux20.5.2-1
ii  libx11-6 2:1.6.4-2
ii  libx11-xcb1  2:1.6.4-2
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.8-2
ii  libxml2  2.9.4+dfsg1-2.1
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-2
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.3-1
ii  x11-utils7.7+3
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-4

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages chromium suggests:
pn  chromium-driver
ii  chromium-l10n  55.0.2883.75-4
pn  chromium-shell 
pn  chromium-widevine  

-- no debconf information

Bug#851633: anacron: run anacron hourly

[Nathan Schulte]

Package: anacron
Version: 2.3-23
Severity: wishlist
Tags: patch

Content-Type: multipart/mixed; boundary="===2253939264364133980=="
MIME-Version: 1.0
From: Nathan Schulte 
To: Debian Bug Tracking System 
Subject: anacron: run anacron hourly
Message-ID: <148462476233.23089.5447684752014803815.reportbug@desmas-l>
X-Mailer: reportbug 7.1.2
Date: Mon, 16 Jan 2017 21:46:02 -0600

This is a multi-part MIME message sent by reportbug.


--===2253939264364133980==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Package: anacron
Version: 2.3-23
Severity: wishlist
Tags: patch

Currently, Anacron is setup to run once daily.  While this configuration works
fine, it ends up only supporting longer-duration power-cycles; that is, cycles
greater than a day.  This is probably good for some server configurations, but
this is not good for desktop and mobile (laptop) systems that are powered off
daily or even more periodically.

In these cases, running Anacron hourly allows the daily scripts to be serviced
by Anacron as a user expects.  I believe this will resolve these two bug
reports:

  1) #619648  cron.daily doesn't execute scheduled scripts
  2) #672061  [anacron] Daily cronjobs in crontabs of users aren't ran by
  anacron.

I believe other distributions provide this hourly hook for Anacron, and it may
even be in the Anacron source.  I can dig up references if needed.  I have
supplied a patch w/ my proposed changes.

Thanks,

--
Nathan Schulte

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

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

Versions of packages anacron depends on:
ii  debianutils  4.8.1
ii  init-system-helpers  1.46
ii  libc62.24-8
ii  lsb-base 9.20161125

Versions of packages anacron recommends:
ii  cron [cron-daemon]   3.0pl1-128
ii  rsyslog [system-log-daemon]  8.23.0-2

Versions of packages anacron suggests:
ii  powermgmt-base   1.31+nmu1
ii  sendmail-bin [mail-transport-agent]  8.15.2-8

-- Configuration Files:
/etc/cron.d/anacron changed [not included]

-- no debconf information

--===2253939264364133980==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; 
filename="0001-run-anacron-hourly-at-27-minutes.patch"

>From 831b95d00dc235ed1c34fba0abc831395901226a Mon Sep 17 00:00:00 2001
From: Nathan Schulte 
Date: Mon, 16 Jan 2017 21:33:24 -0600
Subject: [PATCH] run anacron hourly, at 27 minutes

---
 debian/cron.d | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/cron.d b/debian/cron.d
index 1691ffe..cf95568 100644
--- a/debian/cron.d
+++ b/debian/cron.d
@@ -3,4 +3,5 @@
 SHELL=/bin/sh
 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 
-30 7* * *   root   test -x /etc/init.d/anacron && /usr/sbin/invoke-rc.d 
anacron start >/dev/null
+# run anacron every hour
+27 0* * *   root   test -x /etc/init.d/anacron && /usr/sbin/invoke-rc.d 
anacron start >/dev/null
-- 
2.11.0


--===2253939264364133980==--

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

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

Versions of packages anacron depends on:
ii  debianutils  4.8.1
ii  init-system-helpers  1.46
ii  libc62.24-8
ii  lsb-base 9.20161125

Versions of packages anacron recommends:
ii  cron [cron-daemon]   3.0pl1-128
ii  rsyslog [system-log-daemon]  8.23.0-2

Versions of packages anacron suggests:
ii  powermgmt-base   1.31+nmu1
ii  sendmail-bin [mail-transport-agent]  8.15.2-8

-- Configuration Files:
/etc/cron.d/anacron changed:
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
27 ** * *   roottest -x /etc/init.d/anacron && /usr/sbin/invoke-rc.d 
anacron start >/dev/null


-- no debconf information
>From 831b95d00dc235ed1c34fba0abc831395901226a Mon Sep 17 00:00:00 2001
From: Nathan Schulte 
Date: Mon, 16 Jan 2017 21:33:24 -0600
Subject: [PATCH] run anacron hourly, at 27 minutes

---
 debian/cron.d | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/cron.d b/debian/cron.d
index 1691ffe..cf95568 100644
--- a/debian/cron.d
+++ b/debian/cron.d
@@ -3,4 +3,5 @@
 SHELL=/bin/sh
 PATH=/usr/local/sbin:/usr/local/bi

Bug#851621: ath9k: NULL pointer dereference

[Ben Hutchings]

Control: tag -1 upstream fixed-upstream patch pending

On Mon, 2017-01-16 at 22:10 +0100, Wojciech Nizinski wrote:
> Package: src:linux
> Version: 4.8.11-1~bpo8+1
> Severity: important
> Tags: newcomer
> 
> Sorry for format, but I have to use netconsole to catch reason of hangs.
> Similar problem was decribed and solved here:
> https://patchwork.kernel.org/patch/9431163/
[...]

I agree, this matches the crash described there.  I've queued up the
patch for the next upload to unstable, but it will take a while for te
fix to get into jessie-backports.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert
Camus



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

Bug#851632: cpio: Crashes when extracting tar file containing '.'

[Ben Hutchings]

On Tue, 17 Jan 2017 03:30:00 + Ben Hutchings  wrote:
> Package: cpio
> Version: 2.11+dfsg-6
> Severity: important
> Tags: patch
> 
> I mistakenly tried to extract a tar file using cpio, and it crashed.
> cpio does support tar files for some reason, but this feature seems to
> have regressed.
> 
> Reproducer: tar --no-recursion -c . | cpio -i
> 
> Patch:
> 
> --- a/src/copyin.c
> +++ b/src/copyin.c
> @@ -1431,8 +1431,9 @@ process_copy_in ()
>     break;
>   }
>  
> -  if (file_hdr.c_namesize <= 1)
> -file_hdr.c_name = xrealloc(file_hdr.c_name, 2);
> +  if (archive_format != arf_tar && archive_format != arf_ustar
> +   && file_hdr.c_namesize <= 1)
> + file_hdr.c_name = xrealloc(file_hdr.c_name, 2);
>cpio_safer_name_suffix (file_hdr.c_name, false, !no_abs_paths_flag,
>     false);
>
> --- END ---

By the way, this is related to the comment beginning 'Debian hack:'
further up in the file... a comment that is part of the upstream code,
not any Debian patch!

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert
Camus



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

Bug#851632: cpio: Crashes when extracting tar file containing '.'

[Ben Hutchings]

Package: cpio
Version: 2.11+dfsg-6
Severity: important
Tags: patch

I mistakenly tried to extract a tar file using cpio, and it crashed.
cpio does support tar files for some reason, but this feature seems to
have regressed.

Reproducer: tar --no-recursion -c . | cpio -i

Patch:

--- a/src/copyin.c
+++ b/src/copyin.c
@@ -1431,8 +1431,9 @@ process_copy_in ()
  break;
}
 
-  if (file_hdr.c_namesize <= 1)
-file_hdr.c_name = xrealloc(file_hdr.c_name, 2);
+  if (archive_format != arf_tar && archive_format != arf_ustar
+ && file_hdr.c_namesize <= 1)
+   file_hdr.c_name = xrealloc(file_hdr.c_name, 2);
   cpio_safer_name_suffix (file_hdr.c_name, false, !no_abs_paths_flag,
  false);
   
--- END ---

Ben.

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

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

Versions of packages cpio depends on:
ii  libc6  2.24-8

cpio recommends no packages.

Versions of packages cpio suggests:
pn  libarchive1  

-- no debconf information

Bug#851598: tex-common: fails to upgrade jessie->stretch (recommends enabled) with cadabra installed

[Andreas Beckmann]

On 2017-01-17 03:48, Norbert Preining wrote:
> I attach a new tex-common package (deb), or you can for testing just

That worked.

I'll now check the other failures with this new package, but that will
take more time - some larger metapackages like med-bio are involved here.


Andreas

Bug#851631: cpio: No debug symbols package

[Ben Hutchings]

On Tue, 17 Jan 2017 03:00:20 + Ben Hutchings 
wrote:
> Package: cpio
> Version: 2.11+dfsg-6
> Severity: normal
> 
> I'm trying to investigate a crash in cpio, but found that it doesn't
> build a debug symbols package.  This should be really easy to add
> using dh_strip now.

...or it would be if you used debhelper (why don't you?).

Here's an example of how to create build-id links and an 'automatic'
dbgsym package the hard way:
https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/rules.real?id=99d37f9b167059eff67405745834e6921ce12424#n454

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert
Camus


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

Bug#851631: cpio: No debug symbols package

[Ben Hutchings]

Package: cpio
Version: 2.11+dfsg-6
Severity: normal

I'm trying to investigate a crash in cpio, but found that it doesn't
build a debug symbols package.  This should be really easy to add
using dh_strip now.

Ben.

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

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

Versions of packages cpio depends on:
ii  libc6  2.24-8

cpio recommends no packages.

Versions of packages cpio suggests:
pn  libarchive1  

-- no debconf information

Bug#841144: kernel BUG at /build/linux-Wgpe2M/linux-4.8.11/fs/ocfs2/alloc.c:1514!

[Ben Hutchings]

On Mon, 2017-01-16 at 13:12 -0600, Russell Mosemann wrote:
[...]
> Jan 15 17:31:03 vhost032 kernel: [ cut here ]
> Jan 15 17:31:03 vhost032 kernel: kernel BUG at 
> /build/linux-Wgpe2M/linux-4.8.11/fs/ocfs2/alloc.c:1514!

This is:

static int ocfs2_grow_tree(handle_t *handle, struct ocfs2_extent_tree *et,
   int *final_depth, struct buffer_head **last_eb_bh,
   struct ocfs2_alloc_context *meta_ac)
{
...
BUG_ON(meta_ac == NULL);

> Jan 15 17:31:03 vhost032 kernel: invalid opcode:  [#1] SMP
> Jan 15 17:31:03 vhost032 kernel: Modules linked in: vhost_net(E) vhost(E) 
> macvtap(E) macvlan(E) tun(E) ocfs2(E) quota_tree(E) hmac(E) veth(E) 
> iptable_filter(E) ip_tables(E) x_tables(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) 
> nfs(E) lockd(E) grace(E) fscache(E) sunrpc(E) ocfs2_dlmfs(E) 
> ocfs2_stack_o2cb(E) ocfs2_dlm(E) ocfs2_nodemanager(E) ocfs2_stackglue(E) 
> configfs(E) bridge(E) stp(E) llc(E) bonding(E) intel_rapl(E) sb_edac(E) 
> edac_core(E) x86_pkg_temp_thermal(E) coretemp(E) ast(E) kvm_intel(E) ttm(E) 
> drm_kms_helper(E) mxm_wmi(E) iTCO_wdt(E) kvm(E) iTCO_vendor_support(E) igb(E) 
> evdev(E) irqbypass(E) drm(E) xhci_pci(E) dca(E) ehci_pci(E) xhci_hcd(E) 
> crct10dif_pclmul(E) ehci_hcd(E) crc32_pclmul(E) i2c_algo_bit(E) e1000e(E) 
> usbcore(E) ptp(E) mei_me(E) lpc_ich(E) ghash_clmulni_intel(E) i2c_i801(E) 
> pcspkr(E) usb_common(E) sg(E)
> Jan 15 17:31:03 vhost032 kernel:  mei(E) shpchp(E) i2c_smbus(E) pps_core(E) 
> mfd_core(E) ipmi_si(E) wmi(E) fjes(E) ipmi_msghandler(E) tpm_tis(E) 
> tpm_tis_core(E) tpm(E) acpi_power_meter(E) acpi_pad(E) button(E) fuse(E) 
> drbd(E) lru_cache(E) libcrc32c(E) crc32c_generic(E) autofs4(E) ext4(E) 
> crc16(E) jbd2(E) fscrypto(E) mbcache(E) dm_mod(E) md_mod(E) sd_mod(E) 
> crc32c_intel(E) aesni_intel(E) aes_x86_64(E) glue_helper(E) lrw(E) 
> gf128mul(E) ablk_helper(E) cryptd(E) ahci(E) libahci(E) libata(E) scsi_mod(E)
> Jan 15 17:31:03 vhost032 kernel: CPU: 5 PID: 28586 Comm: qemu-system-x86 
> Tainted: GE   4.8.0-0.bpo.2-amd64 #1 Debian 4.8.11-1~bpo8+1
> Jan 15 17:31:03 vhost032 kernel: Hardware name: To Be Filled By O.E.M. To Be 
> Filled By O.E.M./EPC612D4I, BIOS P2.10 03/31/2016
> Jan 15 17:31:03 vhost032 kernel: task: 8e6e8584d000 task.stack: 
> 8e6d8079
> Jan 15 17:31:03 vhost032 kernel: RIP: 0010:[]  
> [] ocfs2_grow_tree+0x6f2/0x780 [ocfs2]
> Jan 15 17:31:03 vhost032 kernel: RSP: 0018:8e6d80793618  EFLAGS: 00010246
> Jan 15 17:31:03 vhost032 kernel: RAX:  RBX: 0004 
> RCX: 8e6d80793790
> Jan 15 17:31:03 vhost032 kernel: RDX: 8e6d807936bc RSI: 8e6d80793968 
> RDI: 8e6ea5012690
> Jan 15 17:31:03 vhost032 kernel: RBP: 8e6d80793678 R08:  
> R09: 00141d0b
> Jan 15 17:31:03 vhost032 kernel: R10: 01586960 R11: 8e6e36ab30c0 
> R12: 0001
> Jan 15 17:31:03 vhost032 kernel: R13: 8e6d80793828 R14: 8e6e36ab30c0 
> R15: 0001
> Jan 15 17:31:03 vhost032 kernel: FS:  7f578affd700() 
> GS:8e7cbf34() knlGS:
> Jan 15 17:31:03 vhost032 kernel: CS:  0010 DS:  ES:  CR0: 
> 80050033
> Jan 15 17:31:03 vhost032 kernel: CR2: b0015a300238 CR3: 0001f5579000 
> CR4: 001426e0
> Jan 15 17:31:03 vhost032 kernel: Stack:
> Jan 15 17:31:03 vhost032 kernel:  8e6d80793728 8e6d80793728 
> c092aa75 8e6cb1fc0c30
> Jan 15 17:31:03 vhost032 kernel:  8e6e81ddb548 9e63ba27 
> ab4b7e2a 0004
> Jan 15 17:31:03 vhost032 kernel:  0001 8e6d80793828 
> 8e6d80793968 8e6e78de1700
> Jan 15 17:31:03 vhost032 kernel: Call Trace:
> Jan 15 17:31:03 vhost032 kernel:  [] ? 
> ocfs2_set_buffer_uptodate+0x35/0x4a0 [ocfs2]
> Jan 15 17:31:03 vhost032 kernel:  [] ? 
> __find_get_block+0xa7/0x110
> Jan 15 17:31:03 vhost032 kernel:  [] ? 
> ocfs2_split_and_insert+0x307/0x490 [ocfs2]
> Jan 15 17:31:03 vhost032 kernel:  [] ? 
> ocfs2_split_extent+0x3ee/0x560 [ocfs2]
> Jan 15 17:31:03 vhost032 kernel:  [] ? 
> ocfs2_change_extent_flag+0x273/0x450 [ocfs2]
> Jan 15 17:31:03 vhost032 kernel:  [] ? 
> ocfs2_mark_extent_written+0x110/0x1d0 [ocfs2]
> Jan 15 17:31:03 vhost032 kernel:  [] ? 
> ocfs2_dio_end_io_write+0x44d/0x600 [ocfs2]

meta_ac is passed down from ocfs2_dio_end_io_write(), which allocates
it using ocfs2_lock_allocators()... but the latter only allocates it
conditionally.  It seems like the condition is wrong somehow.

I didn't see any relevant changes post-4.8 (though I did see a number
of unrelated bug fixes that maybe ought to go to stable).

The rest of the traceback is below; the whole bug report can be found
at https://bugs.debian.org/841144

Ben.

> Jan 15 17:31:03 vhost032 kernel:  [] ? 
> ocfs2_allocate_extend_trans+0x180/0x180 [ocfs2]
> Jan 15 17:31:03 vhost032 kernel:  [] ? 
> ocfs2_dio_end_io+0x3b/0x60 [ocfs2]
> Jan 15 17:31:03 vhost032 kernel:  [] ? 
>

Bug#851598: tex-common: fails to upgrade jessie->stretch (recommends enabled) with cadabra installed

[Andreas Beckmann]

Hi Norbert,

On 2017-01-17 02:20, Norbert Preining wrote:

> Hmmm, strange. In this chroot did the failure occur? I don't see

at least some failure happened (and to me it looked like the same)

I had the fmtutil logfile included as well in the tarball, in case of 
discrepancies

> amstex in any of the fmtutil files so it should not happen ...
> 
> wait ...
> fmtutil:   /var/lib/texmf/web2c/fmtutil.cnf
> fmtutil:   /usr/share/texmf/web2c/fmtutil.cnf
> fmtutil:   /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
> 
> The last two are links to the above you send me, but to be sure:
> * ls -l /usr/share/texmf/web2c/fmtutil.cnf 
> /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf

lrwxrwxrwx 1 root root 38 Nov 30 04:18 
/usr/share/texlive/texmf-dist/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-TEXLIVEDIST
lrwxrwxrwx 1 root root 33 Nov 30 04:18 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN

> * the file /var/lib/texmf/web2c/fmtutil.cnf

-rw-r--r-- 1 root root 3229 Jan 17 00:18 /var/lib/texmf/web2c/fmtutil.cnf

# ## This file was automatically generated by update-fmtutil.
#
# Please do not edit it directly. If you want to add or change
# anything here, please have a look at the files in:
#
#/etc/texmf/fmt.d/
#
# and invoke update-fmtutil.
#
# ##

# ## From file: /etc/texmf/fmt.d/00tex.cnf
# 00tex.cnf: header of the configuration file for fmtutil.
#
# In Debian, fmtutil.cnf is a file that is generated from
# configuration files in /etc/texmf/fmt.d/.  This file, 00tex.cnf, 
# contains only some comments on how to edit these files.
#
# The text of the comments is Copyright 1998, 1999 by Thomas Esser, it
# is in the Public domain.


# You Customize these file to your needs, e.g.
#   - remove or uncomment formats that you don't need
#   - add your own formats
#   - change default engine / flags for standard formats

# Some notes:
#   1) tex and amstex just load hyphen.tex. No customization.
#   You can have you own customized (via babel's hyphen.cfg)
#   formats on top of plain by using "bplain.tex" instead of
#   plain.tex (see e.g. bplain.ini file for bplain format).
#
#   2) etex loads language.def, not language.dat.
#
#   3) The symbolic link to the right engines (e.g. bplain -> tex)
#  will be generated by the "texlinks" script. So, if you call
#  fmtutil "by hand" and not via texconfig, please also call
#  texlinks afterwards.
# 
#   4) usual comments start with "# ", whereas disabled configurations
#  start with "#! " in this file.

# The format of the table is:

# formatengine  pattern-filearguments

# The last part of "arguments" must be the name of the file to run
# initex (or another "ini"-engine) on.

# End of file: /etc/texmf/fmt.d/00tex.cnf

# ## From file: /etc/texmf/fmt.d/10texlive-base.cnf
# 10texlive-base.cnf
# You can change/add entries to this file and changes will be preserved
# over upgrades, even if you have removed the main package prior
# (not if you purged it). You should leave the following pseudo comment
# present in the file!
# -_- DebPkgProvidedMaps -_-
# 
luatex luatex language.def,language.dat.lua luatex.ini
tex tex - tex.ini
pdfetex pdftex language.def -translate-file=cp227.tcx *pdfetex.ini
mf mf-nowin - -translate-file=cp227.tcx mf.ini
dviluatex luatex language.def,language.dat.lua dviluatex.ini
pdftex pdftex language.def -translate-file=cp227.tcx *pdfetex.ini
etex pdftex language.def -translate-file=cp227.tcx *etex.ini
#! luajittex luajittex language.def,language.dat.lua luatex.ini
# End of file: /etc/texmf/fmt.d/10texlive-base.cnf

#
# /etc/texmf/fmt.d/10texlive-latex-base.cnf not included because either it 
wasn't
# up-to-date (conffile update pending) or the package shipping it was
# apparently removed (no corresponding .list file in
# /var/lib/tex-common/fmtutil-cnf/).
#

# ## From file: /etc/texmf/fmt.d/10texlive-math-extra.cnf
# 10texlive-math-extra.cnf
# You can change/add entries to this file and changes will be preserved
# over upgrades, even if you have removed the main package prior
# (not if you purged it). You should leave the following pseudo comment
# present in the file!
# -_- DebPkgProvidedMaps -_-
# 
amstex pdftex - -translate-file=cp227.tcx *amstex.ini
# End of file: /etc/texmf/fmt.d/10texlive-math-extra.cnf

> 
> please.
> 
> My "high confidence" was wrong ;-)
> 
>> Or if there is only a subset of these packages, tex-common could "take
>> over" their conffiles in order to dpkg-maintscript-helper rm_conffile
>> them (again with appropriate Breaks in place)
> 
> You mean by replacing the file, and at the same time rm_conffile?
> Would that work?


tex-common wants
1) to become the owner of the path /etc/texmf/fmt.d/10texlive-math-extra.cnf
2) that nothing exists at that location

* tex-common will not ship /etc/texmf/fmt.d/10texlive-math-extra.cnf
* tex-common will Breaks: texlive-math-extra (<< 2017)
* tex-common.maintscript will have
rm_conffile /etc/texmf/fmt.d/10texlive-math-extra.cnf texliv

Bug#851630: beets: UnicodeDecodeError: 'utf8' codec can't decode

[Jameson Graef Rollins]

Package: beets
Version: 1.3.19-2
Severity: normal

Hello.  I haven't yet figured out what's causing it, but I'm getting
the followin exceptions during import:

Traceback (most recent call last):
  File "/usr/bin/beet", line 11, in 
load_entry_point('beets==1.3.19', 'console_scripts', 'beet')()
  File "/usr/share/beets/beets/ui/__init__.py", line 1266, in main
_raw_main(args)
  File "/usr/share/beets/beets/ui/__init__.py", line 1253, in _raw_main
subcommand.func(lib, suboptions, subargs)
  File "/usr/share/beets/beets/ui/commands.py", line 967, in import_func
import_files(lib, paths, query)
  File "/usr/share/beets/beets/ui/commands.py", line 944, in import_files
session.run()
  File "/usr/share/beets/beets/importer.py", line 320, in run
pl.run_parallel(QUEUE_SIZE)
  File "/usr/share/beets/beets/util/pipeline.py", line 251, in run
msg = next(self.coro)
  File "/usr/share/beets/beets/importer.py", line 1202, in read_tasks
for t in task_factory.tasks():
  File "/usr/share/beets/beets/importer.py", line 1038, in tasks
for dirs, paths in self.paths():
  File "/usr/share/beets/beets/importer.py", line 1090, in paths
for dirs, paths in albums_in_dir(self.toppath):
  File "/usr/share/beets/beets/importer.py", line 1480, in albums_in_dir
logger=log):
  File "/usr/share/beets/beets/util/__init__.py", line 205, in sorted_walk
for res in sorted_walk(cur, ignore, ignore_hidden, logger):
  File "/usr/share/beets/beets/util/__init__.py", line 205, in sorted_walk
for res in sorted_walk(cur, ignore, ignore_hidden, logger):
  File "/usr/share/beets/beets/util/__init__.py", line 190, in sorted_walk
if (ignore_hidden and not hidden.is_hidden(cur)) or not ignore_hidden:
  File "/usr/share/beets/beets/util/hidden.py", line 78, in is_hidden
path = path.decode('utf-8')
  File "/usr/lib/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xfc in position 80: invalid 
start byte

This causes the import to crash.

I'll try to see if I can narrow down what's exposing the bug.

Thanks for maintaining such a great program.

jamie.

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

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

Versions of packages beets depends on:
ii  libjs-backbone 1.3.3~dfsg-1
ii  libjs-jquery   3.1.1-2
ii  libjs-underscore   1.8.3~dfsg-1
ii  python-enum34  1.1.6-1
ii  python-munkres 1.0.8-1
ii  python-musicbrainzngs  0.6-2
ii  python-mutagen 1.36-1
ii  python-pkg-resources   32.0.0-1
ii  python-unidecode   0.04.19-1
ii  python-yaml3.12-1
pn  python:any 

beets recommends no packages.

Versions of packages beets suggests:
pn  beets-doc 
pn  libav-tools   
pn  mp3gain   
pn  python-acoustid   
ii  python-bs44.5.1-1
ii  python-dbus   1.2.4-1
ii  python-flask  0.12-1
ii  python-gst-1.01.10.2-1
ii  python-imaging3.4.2-1
ii  python-mpd0.5.5-2
pn  python-pathlib
pn  python-pylast 
pn  python-rarfile
ii  python-requests   2.12.4-1
pn  python-requests-oauthlib  
ii  python-xdg0.25-4

-- no debconf information

Bug#851629: neovim-runtime: Translation files in wrong path

[Boyuan Yang]

Package: neovim-runtime
Version: 0.1.7-3
Severity: normal
Tags: l10n

.mo files are placed in wrong directories and is not working correctly.

Examples:

Bad: /usr/share/locale/zh_TW.UTF-8/LC_MESSAGES/nvim.mo
Good: /usr/share/locale/zh_TW/LC_MESSAGES/nvim.mo

Bad: /usr/share/locale/zh_CN.UTF-8/LC_MESSAGES/nvim.mo
Good: /usr/share/locale/zh_CN/LC_MESSAGES/nvim.mo

Similar problems apply for other translations.



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

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

-- no debconf information

Bug#851628: Bugs on First CD/DVD for Jessie 8.5, 8.6, 8.7

[shirish शिरीष]

at bottom :-

On 17/01/2017, schatzclan  wrote:
> Package: cdimage.debian.org
>
> I have two PC boxes:
>
> 1997-vintage - i586-200Mhz/128M/6.3G. I have given up installing Debian
> due to performance issues and a problem with “i386 8.x.0 LXDE CD#1”, as
> the hybrid iso images on versions 8.5.0, 8.6.0 and 8.7.0 seem to be
> damaged. The MD5 checksums all showed a valid download using two
> different download methods: direct d/l and bitorrent - identical results
> in unexpectedly larger actual file size (642M) vs reported size (613M)
> for the “i386 8.x.0 LXDE CD#1” iso. The “i386 8.5.0 XFCE CD#1” ISO image
> mounted cleanly on the mac laptop and cleanly installed but took 3 1/2
> hours to install on the system and still had serious performance issues.
> I gave up and put a slightly older version of Vector Linux on this
> machine which more or less works.
>
> i686-2.8GHz/1.2G/40G (Hewlett-Packard d330 uTower). I tried to load it
> with "i386 8.6.0 DVD 1" ISO image - iso was damaged although checked OK
> via MD5, nor would it mount on a Mac Laptop (used to download and check
> all ISO images). The “bad” ISO image was placed on a bootable 32G USB
> which booted to the graphical installation screen - installation was
> completely performed, but post installation reboot failed to launch the
> GUI. Post-install, there appear be missing XF86 utils and config files
> due to the bad image, unless this revision has removed them as part of
> the release. To get something fully working on this box I installed
> Slackware 14.1.
>
> I have downloaded and validated “i386 8.7.0 LXDE CD #1” and it has the
> same mounting problems on the Mac laptop as the previous two revisions
> (8.5.0, 8.6.0), thus I’m reticent about loading onto any machine.
>
> I have jigdo d/l'd "debian-8.7.0-amd64-DVD-1.iso", MD5'd it (checked
> OK). It has the same inability to be opened on the mac laptop as all the
> other 1st cd's.
>
> You may want to check the 1st disk ISO images to make sure they are
> valid.
>
> Could it be that the hybrid CD/USB iso is causing problems? This doesn’t
> seem to be the case for “i386 8.5.0 XFCE CD #1”, which cleanly mounted
> on the mac laptop and loaded (very slowly) on the i586 box.
>
> Cheers, Charles F. Schatz
>
>

Dear Charles,

While only the experts can help you out, I would suggest to use
sha1sum or sha224sum instead of md5sum when trying to check signatures
of the image you downloaded.

The second thing, although not exactly relevant to your situation is,
i586 support was taken out about a year ago -

https://lists.debian.org/debian-devel-announce/2016/05/msg1.html

But as can be seen this is for stretch and beyond. With jessie you
shouldn't have problems.

https://tracker.debian.org/pkg/linux shows that the release you are
using should not effect you.

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

Bug#662718: cpio: Suggests libarchive1, which is gone due to SONAME bump

[Michael Biebl]

Hi

Am 17.01.2017 um 01:25 schrieb Guillem Jover:
> In any case, I'm attaching a patch fixing this, because I also tripped
> over this, as the Suggests on a shared library tend to trigger my
> bogosity alarms. :)

> + A cpio(5) man page can be found in the libarchive-dev package.


I was confused for a second, seeing that we already ship a cpio binary
including a cpio man page until I realized that the cpio (and tar) man
page provided by libarchive-dev describe the formats and not the command
line utilities.

I know this is bike-shedding, but maybe phrasing it like this makes this
even more obvious?

"Man pages describing the cpio, tar and various other achive formats can
be found in the libarchive-dev package."

(I know that section 5 is for formats and conventions, it still took me
a second to notice that)

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



signature.asc
Description: OpenPGP digital signature

Bug#848289: ruby-riddle: (build-)depends on mysql-{client,server}

[李健秋]

Package: ruby-riddle
Followup-For: Bug #848289

Got confirm from IRC that the MariaDB fail tests cannot be reproduced
on one of our porterbox:
  18:03 < zumbi> AndrewLee: I tried to reproduce, but git built fine in
  a porterbox

I'd roll a new upload from git shortly.

Best regards,
-Andrew

Bug#850686: npth can make reentrant calls to sigaddset

[NIIBE Yutaka]

Hello,

I am reading GNU C library manual.

24.7.2 Signal Sets:
https://www.gnu.org/software/libc/manual/html_node/Signal-Sets.html

All functions have MT-Safe | AS-Safe | AC-Safe attributes.

So, I wonder what your problem is, and what you are suggesting.

> This code is not properly reentrant, but it can be reentered if
> another one of the trapped signals occurs

I think that there is no problem that another signal occurs when
_sigev_handler is called, provided the sigaddset function is safe.
(1) Different signals are recorded properly in sigev_pending.
(2) When they are same signal (two or occurrences), it is marked
properly as occurred.  (Signal handling should be done with the
assumption that it might be multiple occurrences.)

Reading the __sigaddset implementation:


https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/bits/sigset.h;hb=b040e1b0842c35ab444e8502db6ae59389d1e3d5#l117

For me, it is not clear if it can be done atomically.  If the bit
handling is not atomic, I think that it's not MT-Safe.  But, this is the
issue of C library.

Well, npth_sigev_get_pending should be used by a single thread (with the
current nPth implementation); Or else, there is a race between
sigismember and sigdel call.  An event of signal (that might be multiple
signals of SIGNUM) can be handled multiple times by different threads.
-- 

Bug#851598: tex-common: fails to upgrade jessie->stretch (recommends enabled) with cadabra installed

[Norbert Preining]

Hi Andreas,

> > * all files in /etc/texmf/fmt.d/
> > * /var/lib/texmf/fmtutil.cnf-DEBIAN
> > * /var/lib/texmf/fmtutil.cnf-TEXLIVEDIST
> 
> see attached tarball, this is from an amd64 chroot, took only 11

Hmmm, strange. In this chroot did the failure occur? I don't see
amstex in any of the fmtutil files so it should not happen ...

wait ...
fmtutil:   /var/lib/texmf/web2c/fmtutil.cnf
fmtutil:   /usr/share/texmf/web2c/fmtutil.cnf
fmtutil:   /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf

The last two are links to the above you send me, but to be sure:
* ls -l /usr/share/texmf/web2c/fmtutil.cnf 
/usr/share/texlive/texmf-dist/web2c/fmtutil.cnf

* the file /var/lib/texmf/web2c/fmtutil.cnf

please.

My "high confidence" was wrong ;-)

> Or if there is only a subset of these packages, tex-common could "take
> over" their conffiles in order to dpkg-maintscript-helper rm_conffile
> them (again with appropriate Breaks in place)

You mean by replacing the file, and at the same time rm_conffile?
Would that work?

> PS: if you need some new package to be tested in this upgrade path, I
> could inject it in the stretch side of that upgrade test

That sounds good, I guess I need to test a new tex-common, but first
want to find the reason for the error.

Thanks

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#845829: cfengine3: switch to build depend on the metapackage default-libmysqlclient-dev

[Andreas Beckmann]

Followup-For: Bug #845829
Control: tag -1 patch

Hi,

attached is a patch to fix this (and another) issue.
If you need help, I could also upload this as a NMU.


Andreas
diff -Nru cfengine3-3.9.1/debian/changelog cfengine3-3.9.1/debian/changelog
--- cfengine3-3.9.1/debian/changelog	2016-12-01 21:55:30.0 +0100
+++ cfengine3-3.9.1/debian/changelog	2017-01-17 01:37:38.0 +0100
@@ -1,3 +1,11 @@
+cfengine3 (3.9.1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch Build-Depends to default-libmysqlclient-dev.  (Closes: #845829)
+  * cfengine3: Add dependency on lsb-base, thanks to lintian.
+
+ -- Andreas Beckmann   Tue, 17 Jan 2017 01:37:38 +0100
+
 cfengine3 (3.9.1-4) unstable; urgency=medium
 
   * Uploading the experimental package to unstable (Closes: 828263).
diff -Nru cfengine3-3.9.1/debian/control cfengine3-3.9.1/debian/control
--- cfengine3-3.9.1/debian/control	2016-12-01 21:55:30.0 +0100
+++ cfengine3-3.9.1/debian/control	2017-01-17 01:37:38.0 +0100
@@ -4,7 +4,7 @@
 Maintainer: Antonio Radici 
 Build-Depends: debhelper (>= 7.0.50), autotools-dev, libssl-dev (>= 1.1),
  flex, bison, libpcre3-dev, dh-autoreconf, libvirt-dev, libacl1-dev,
- liblmdb-dev, libmysqlclient-dev, libxml2-dev, quilt, libpam0g-dev
+ liblmdb-dev, default-libmysqlclient-dev, libxml2-dev, quilt, libpam0g-dev
 Standards-Version: 3.9.8
 Homepage: http://www.cfengine.org/
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/cfengine3.git
@@ -12,7 +12,7 @@
 
 Package: cfengine3
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: lsb-base (>= 3.0-6), ${shlibs:Depends}, ${misc:Depends}
 Recommends: python
 Description: tool for configuring and maintaining network machines
  Cfengine is a suite of programs for integrated autonomic management

Bug#851628: Bugs on First CD/DVD for Jessie 8.5, 8.6, 8.7

[schatzclan]

Package: cdimage.debian.org

I have two PC boxes:

1997-vintage - i586-200Mhz/128M/6.3G. I have given up installing Debian 
due to performance issues and a problem with “i386 8.x.0 LXDE CD#1”, as 
the hybrid iso images on versions 8.5.0, 8.6.0 and 8.7.0 seem to be 
damaged. The MD5 checksums all showed a valid download using two 
different download methods: direct d/l and bitorrent - identical results 
in unexpectedly larger actual file size (642M) vs reported size (613M) 
for the “i386 8.x.0 LXDE CD#1” iso. The “i386 8.5.0 XFCE CD#1” ISO image 
mounted cleanly on the mac laptop and cleanly installed but took 3 1/2 
hours to install on the system and still had serious performance issues. 
I gave up and put a slightly older version of Vector Linux on this 
machine which more or less works.


i686-2.8GHz/1.2G/40G (Hewlett-Packard d330 uTower). I tried to load it 
with "i386 8.6.0 DVD 1" ISO image - iso was damaged although checked OK 
via MD5, nor would it mount on a Mac Laptop (used to download and check 
all ISO images). The “bad” ISO image was placed on a bootable 32G USB 
which booted to the graphical installation screen - installation was 
completely performed, but post installation reboot failed to launch the 
GUI. Post-install, there appear be missing XF86 utils and config files 
due to the bad image, unless this revision has removed them as part of 
the release. To get something fully working on this box I installed 
Slackware 14.1.


I have downloaded and validated “i386 8.7.0 LXDE CD #1” and it has the 
same mounting problems on the Mac laptop as the previous two revisions 
(8.5.0, 8.6.0), thus I’m reticent about loading onto any machine.


I have jigdo d/l'd "debian-8.7.0-amd64-DVD-1.iso", MD5'd it (checked 
OK). It has the same inability to be opened on the mac laptop as all the 
other 1st cd's.


You may want to check the 1st disk ISO images to make sure they are 
valid.


Could it be that the hybrid CD/USB iso is causing problems? This doesn’t 
seem to be the case for “i386 8.5.0 XFCE CD #1”, which cleanly mounted 
on the mac laptop and loaded (very slowly) on the i586 box.


Cheers, Charles F. Schatz

Bug#850961: unblock nvidia-settings/375.26-3 (was: Re: RM: nvidia-settings/unstable-debug -- ROM; source in both main and contrib)

[Andreas Beckmann]

Control: reassign -1 release.debian.org
Control: retitle -1 unblock nvidia-settings/375.26-3

On 2017-01-11 17:30, Andreas Beckmann wrote:
> For whatever reason, nvidia-settings has its source package
> listed in both main and contrib, breaking the archive tools
> (see #824169 for the similar problem in chocolate-doom) and
> is therefore blocked from migrating to testing.
> 
> nvidia-settings | 375.26-1 | unstable | source
> nvidia-settings | 375.26-1 | unstable-debug/contrib   | source
> nvidia-settings | 375.26-2 | buildd-unstable  | source
> nvidia-settings | 375.26-2 | unstable | source
> nvidia-settings | 375.26-2 | unstable-debug/contrib   | source
> 
> I will upload a new version that does no longer build
> the nvidia-settings-dbgsym/contrib binary package, which
> should hopefully fix this issue. (Something similar seems
> to work for boinc, which builds binary packages in both
> main and contrib, but -dbgsym packages only in main.)

That upload seems to have worked and it didn't need the RM from
unstable-debug first:

nvidia-settings | 375.26-3 | buildd-unstable  | source
nvidia-settings | 375.26-3 | unstable | source
nvidia-settings | 375.26-3 | unstable-debug   | source

Julian, please lift your block s.t. nvidia-settings can again migrate to
testing (and I wouldn't mind some aging as well ...).

Thanks


Andreas

Bug#851113: manaplus: violates font license

[Paul Wise]

On Mon, 2017-01-16 at 16:25 +0300, Andrei Karas wrote:

> I will add dejavu and liberation fonts sources from debian source
> packages into data/fonts/src/

It would be better to remove the embedded font copies from the upstream
source. You can then distribute the font source tarball and the source
for any other GPL software in separate tarballs, alongside any binary
packages for Windows or macOS. If you aren't distributing any binary
packages you wouldn't need to distribute any extra source tarballs.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#835189: python-pyrax: FTBFS (failing tests)

[Santiago Vila]

retitle 835189 python-pyrax: FTBFS (failing tests)
thanks

Hi.

After building this package many times today, it always fail
and not just sometimes, so I'm retitling accordingly.

As a summary, I see that the following tests always fail:

ERROR: test_set_http_debug (tests.unit.test_module.PyraxInitTest)
ERROR: test_connect_to_cloudservers (tests.unit.test_module.PyraxInitTest)

and the following one fails approximately 70% of the time:

ERROR: test_rax_endpoints (tests.unit.test_identity.IdentityTest)

[ The first two failing tests are the ones reported by Lucas Nussbaum
  in Bug #841623 ].

Thanks.

Bug#849401: restart silently fails

[Christian Hofstaedtler]

* Francesco Poli  [170115 17:39]:
> Christian, have you decided which strategy should be adopted for the
> ISCONFIGURED handling?

I'm going to set the default UPSTYPE to usb, so there will be no
activity on /dev/ttyS0 caused by the default configuration, and then
ignoring ISCONFIGURED under systemd should be okay.

-- 
christian hofstaedtler 

Bug#851598: tex-common: fails to upgrade jessie->stretch (recommends enabled) with cadabra installed

[Andreas Beckmann]

On 2017-01-17 01:05, Norbert Preining wrote:
> Hi Andreas,
> 
> thanks for the report, if you have the chroot still available, can

No, but it just takes 15 minutes to recreate the failure ... and with a
brand-new piuparts option I get a shell in the chroot upon failure :-)

> you please send me:
> * all files in /etc/texmf/fmt.d/
> * /var/lib/texmf/fmtutil.cnf-DEBIAN
> * /var/lib/texmf/fmtutil.cnf-TEXLIVEDIST

see attached tarball, this is from an amd64 chroot, took only 11
minutes, not enough time for another NMU inbetween :-)

> I have a pretty high confidence that the problem comes from:
> - upgrade removes (but not purges) texlive-math-extra
> - thus the cfg file in /etc/texmf/fmt.d/ remains
> - it is included in fmtutil.cnf(-DEBIAN)
> - but the necessary package (texlive-science) is not installed
> 
> I think the only way around that is dropping support for old
> packages that ship formats in /etc/texmf/fmt.d, afais there
> is none in sid.

and add a list of Breaks to e.g. tex-common

Or if there is only a subset of these packages, tex-common could "take
over" their conffiles in order to dpkg-maintscript-helper rm_conffile
them (again with appropriate Breaks in place)

Andreas

PS: if you need some new package to be tested in this upgrade path, I
could inject it in the stretch side of that upgrade test



851598.tar.gz
Description: application/gzip

Bug#850713: linux-image-4.8.0-0.bpo.2-amd64: can't mount NFS shares via nfs referrals

[Jose R R]

Niltze [Hello]-

'just my 2 cents':


On Mon, Jan 16, 2017 at 6:39 AM, Christoph Martin  wrote:
>
> Some more analysis:
>
> attached are two syslogs of gssd in verbose mode.
>
> You can see that in both servers the user acl directory gets mounted
> from fs02 within user context:
>
> rpc.gssd[6528]: handle_gssd_upcall: 'mech=krb5 uid=4015 enctypes
> ...
> rpc.gssd[6528]: creating context using fsuid 4015 (save_uid 0)
>
> When trying to mount the group acl share from fsgroups 4.8 server logs:
>
> rpc.gssd[27548]: handle_gssd_upcall: 'mech=krb5 uid=0 service=*
> ...
> rpc.gssd[27548]: creating context using fsuid 0 (save_uid 0)
>
> the 4.7 server logs:
>
> rpc.gssd[6528]: handle_gssd_upcall: 'mech=krb5 uid=4015
> ...
> rpc.gssd[6528]: creating context using fsuid 4015
>
>
> As a result of this difference the nfs tries to mount the directory on
> 4.7 with a user kerberos ticket and gets NFS4_OK in line 265 of
> linux-4.7-nfsrefer.dump while 4.8 tries with machine kerberos ticket and
> gets NFS4ERR_ACCESS in line 231 of linux-4.8-nfsrefer.dump.
>
> Christoph


I experienced issues installing nfs-common package from official
maintainers jessie repositories during my jessie-backport reiser4
-patched Linux kernel efforts. Accordingly I jessie-backport'ed
nfs-common and nfs-kernel-server packages that you will find at:

https://sourceforge.net/projects/debian-reiser4/files/nfs-common-reiser4-bp/

As a matter of fact just uploaded jessie-backport'ed (kerberos)
krb5-1.15-1 package that I had built priorly -- as part of my initial
efforts building first 2 packages mentioned above.

https://sourceforge.net/projects/debian-reiser4/files/jessie-krb5-1.15-1_bp/

By the way none of those packages have *any dependencies* on reiser4
other than being built in a machine with that file system ;-)

You are welcomed to give those a try but I offer no guarantees whatsoever.


Best Professional Regards.


P.S. you may need krb5-config from Sid (Unstable) -- as the above are backports.
-- 
Jose R R
http://metztli.it
-
Download Debian-Reiser4 for AMD64 https://sf.net/projects/debian-reiser4/
-
Try at no charge http://b2evolution.net for http://OpenShift.com PaaS
-
from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way!
-

Bug#662718: cpio: Suggests libarchive1, which is gone due to SONAME bump

[Guillem Jover]

Control: tags -1 = patch

On Sat, 2012-03-10 at 14:04:42 -0500, Samuel Bronson wrote:
> So, if I'm correct about the reason for the Suggests:, it looks like it
> should be changed to "Suggests: libarchive-dev", and a note about the
> reason added to the Description: field and/or README.Debian (so that no
> one has to puzzle it out again).

Yes, and the reason should be clear from the cpio changelog:

,---
cpio (2.11-7) unstable; urgency=low

[…]
  * Add a 'See Also' section to manpages mentioning cpio(5), and
Add a 'Suggests: libarchive1' for cpio(5). Closes: #588020.

 -- Ruben Molina   Thu, 10 Feb 2011 23:16:52 -0500
`---

In any case, I'm attaching a patch fixing this, because I also tripped
over this, as the Suggests on a shared library tend to trigger my
bogosity alarms. :)

Thanks,
Guillem
From 022b3601a3364cfb90b89eb8e8aaef3def0b0b14 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 17 Jan 2017 01:19:07 +0100
Subject: [PATCH] Update libarchive Suggests for cpio(5) man page

Add an explanation in the package Description.
---
 debian/control | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index ae3ae5d..dd0410a 100644
--- a/debian/control
+++ b/debian/control
@@ -16,11 +16,13 @@ Depends: ${shlibs:Depends}
 Replaces: cpio-mt
 Conflicts: mt-st (<< 0.6), cpio-mt
 Multi-Arch: foreign
-Suggests: libarchive1
+Suggests: libarchive-dev
 Description: GNU cpio -- a program to manage archives of files
  GNU cpio is a tool for creating and extracting archives, or copying
  files from one place to another.  It handles a number of cpio formats
  as well as reading and writing tar files.
+ .
+ A cpio(5) man page can be found in the libarchive-dev package.
 
 Package: cpio-win32
 Architecture: all
-- 
2.11.0

Bug#849995: [Qa-jenkins-dev] Bug#849995: Bug#849995: [j.d.n] Store coverage report of diffoscope builds

[Holger Levsen]

On Mon, Jan 16, 2017 at 07:30:29AM +0100, Mattia Rizzolo wrote:
> Yes, this is possible and easy (we already have the plot plugin
> installed for an eventual graphin of something, even if I believe
> storing the .html files of the report is already a good start).

it's used already too:
https://jenkins.debian.net/view/haskell/job/haskell-package-plan/plot/


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#773245: git-p4 package?

[Sean Whitton]

Dear Luke,

On Mon, Jan 16, 2017 at 11:27:22PM +, Luke Diamand wrote:
> I put in a patch to add a git-p4 package, here:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773245
> 
> I was wondering what I need to do next for this to be merged? Or if
> I've done it wrong somehow?

I haven't looked at the patch, but you haven't done anything wrong with
regard to Debian procedures.  It's simply a matter of waiting for a
response from the maintainers of the git package.

You could prepare an NMU of the git package and submit a request for
sponsorship to DEFERRED, but that would be unusual for a bug of wishlist
severity.  Please read up on NMUs in the Debian Developer's Reference,
so that you are properly informed of your options.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#851574: ITP: clickhouse -- ClickHouse is an open-source column-oriented database management system

[Joerg Jaspert]

On 14554 March 1977, Jean Baptiste Favre wrote:
> * Package name: clickhouse
>   Version : 1.1.54133
>   Upstream Author : Alexey Milovidov
> * URL : https://clickhouse.yandex/* License : Apache
>   Programming Lang: C++
>   Description : open-source column-oriented database management system
> Yandex ClickHouse is an open-source column-oriented database management system
> that allows generating analytical data reports in real time.

Please drop the "open-source" from the description, short and long. It
is plain wasted space and redundant, as *obviously* it must be
open-source, or it wouldn't enter Debian...

-- 
bye, Joerg

Bug#851598: tex-common: fails to upgrade jessie->stretch (recommends enabled) with cadabra installed

[Norbert Preining]

Hi Andreas,

thanks for the report, if you have the chroot still available, can
you please send me:
* all files in /etc/texmf/fmt.d/
* /var/lib/texmf/fmtutil.cnf-DEBIAN
* /var/lib/texmf/fmtutil.cnf-TEXLIVEDIST

I have a pretty high confidence that the problem comes from:
- upgrade removes (but not purges) texlive-math-extra
- thus the cfg file in /etc/texmf/fmt.d/ remains
- it is included in fmtutil.cnf(-DEBIAN)
- but the necessary package (texlive-science) is not installed

I think the only way around that is dropping support for old
packages that ship formats in /etc/texmf/fmt.d, afais there
is none in sid.

Thanks

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#850970: pvpgn: switch to build depend on the metapackage default-libmysqlclient-dev

[Andreas Beckmann]

Followup-For: Bug #850970
Control: tag -1 pending

Hi,

I just uploaded a NMU to DELAYED/2, fixing these issues. Please let me
know if I should delay it longer.

 pvpgn (1.8.5-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Switch Build-Depends to default-libmysqlclient-dev.  (Closes: #850970)
   * Switch Suggests to default-mysql-* | virtual-mysql-*.  (Closes: #848482)
   * Use secure, canonical Vcs-* URLs.

Will push commits and tag to the git repo after the upload was accepted
in the archive.


Andreas

Bug#851627: imagemagick-6-common: Adequate reports multiple obsolete-conffile for imagemagick-6-common

[shirish शिरीष]

Package: imagemagick-6-common
Version: 8:6.9.7.0+dfsg-2
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

Dear Maintainer,

Adequate reported multiple obsolete-conffiles in imagemagick-6-common

└─[$] adequate imagemagick-6-common

imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/delegates.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/type-windows.xml
imagemagick-6-common: obsolete-conffile
/etc/etc/ImageMagick-6/type-ghostscript.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/type-dejavu.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/type.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/thresholds.xml
imagemagick-6-common: obsolete-conffile
/etc/etc/ImageMagick-6/quantization-table.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/policy.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/mime.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/magic.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/log.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/colors.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/coder.xml

Maybe you could use what pabs (Paul Wise) did in #815563, in that the
proper thing to do would be -

Use the dpkg-maintscript-helper support provided by dh_installdeb to
remove such similar obsolete conffiles on upgrade

Also https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files

You can also see manpage of dh_installdeb vid debhelper package which
is the same thing.

I ran the same command as he did -

[$] pkg=imagemagick-6-common ; adequate $pkg ; dpkg-query -W
-f='${Conffiles}\n' $pkg | grep obsolete
[4:02:47]
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/delegates.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/type-windows.xml
imagemagick-6-common: obsolete-conffile
/etc/etc/ImageMagick-6/type-ghostscript.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/type-dejavu.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/type.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/thresholds.xml
imagemagick-6-common: obsolete-conffile
/etc/etc/ImageMagick-6/quantization-table.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/policy.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/mime.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/magic.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/log.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/colors.xml
imagemagick-6-common: obsolete-conffile /etc/etc/ImageMagick-6/coder.xml
 /etc/etc/ImageMagick-6/delegates.xml a8e5fb9a7ed691c6d15369d926be8516 obsolete
 /etc/etc/ImageMagick-6/type-windows.xml
21d3ea0e2b51ded4e3870d401897a9d8 obsolete
 /etc/etc/ImageMagick-6/type-ghostscript.xml
d7fdef0a5e8ff7446600ede4e04f6acf obsolete
 /etc/etc/ImageMagick-6/type-dejavu.xml
09bd5cf793568d2a5e185d475bc45b96 obsolete
 /etc/etc/ImageMagick-6/type.xml d0caa5ce47ac32e40980d1ee7bf882eb obsolete
 /etc/etc/ImageMagick-6/thresholds.xml 04d4a80687f7073ae81c91907889db42 obsolete
 /etc/etc/ImageMagick-6/quantization-table.xml
0bc6653bd4f56e8a8f108c72c612c8b6 obsolete
 /etc/etc/ImageMagick-6/policy.xml 74837542f73a97b02148150aa00121ad obsolete
 /etc/etc/ImageMagick-6/mime.xml 7691ca051247d9da165f154a1c41b411 obsolete
 /etc/etc/ImageMagick-6/magic.xml 04b219d820811a6cb1bc7af03b52b626 obsolete
 /etc/etc/ImageMagick-6/log.xml 63b78f245752f5332d587e8f0917a085 obsolete
 /etc/etc/ImageMagick-6/colors.xml 27d44e4d5e96d3db5a8cf834b44b69a5 obsolete
 /etc/etc/ImageMagick-6/coder.xml 184715fdf06bd9fc835dc62929e8d36f obsolete

You could potentially use

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;tag=obsolete-conffile;users=debian...@lists.debian.org#_4_3_5

OR/and

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;tag=obsolete-conffile;users=debian...@lists.debian.org#_4_4_5

All of the bugs which are resolved therein are the same obsolete
conffile issues.

Hope the above helps in getting the above fixed.

-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
compare:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
convert:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
composite:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
conjure:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
display:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
identify:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
import:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www.imagemagick.org
mogrify:  ImageMagick 6.9.7-0 Q16 x86_64 20161210 http://www

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

[sorry, this got stuck in my drafts folder]

Dear Nicholas,

On Sun, Jan 15, 2017 at 10:26:44PM -0700, Nicholas D Steeves wrote:
> Thank you again for your patience and extra help!

No problem.  I hope that this was educational for you as a new DM --
that's probably more important than the updated package.

> > > Ah!  Yes, this is the spec that addresses my question to #3.  That
> > > said, in the past some of my other work on d/copyright has been said
> > > to be "worse than useless" even though it adhered to the spec, and
> > > even though it seemed to reflect what I saw reading the packages
> > > COPYING file, in addition to spending a while reading VCS commits for
> > > stuff I wasn't sure about.  This has led me to wonder about the tribal
> > > rules that are not in the spec...
> > 
> > Could you give me an example of a rule like that?
> 
> It'll take time to dig up examples from my backups, so I'll need to
> defer concrete examples until something like mid February.  It might
> be stuff like my failure to identify a package that is following DEP-5
> vs SPDX, but because of comments like "worst than useless" I figured
> there must have been some rule I didn't understand...because that's
> way too strong of a reaction for something that is a question of
> style. :-)  At this point, however, I don't think further discussion
> fits into this thread, because it is too tangential to muse-el.

Okay.  Probably best to address you question to the d-mentors list.

> By the way, is one space indentation for copyright definition blocks
> what should now be used (commit
> 5ba94789a7f35d5938d88226c6ea35fd98635a5b)?  I noticed the packaging
> guide's example uses one space, but most of the copyright-format/1.0
> packages I've looked at use four.  Just a convention?

I've only seen it done with a single space.  If it works with more than
one, fine.

> > > Would you please check to see if my latest commit to d/copyright
> > > is ok?  It's what makes the most sense to me.  As far as I can
> > > tell, it might be problematic because it infers that Eric Marsden
> > > changed cgi.el in 2003.  If it's problematic I'll revert it, then
> > > dch -r.
> > 
> > No, it doesn't actually imply that Marsden changed that file in 2004
> > (the spec does explain this!).
> 
> Ah, from packaging-manuals/copyright-format/1.0 "Not all copyright
> notices may apply to every individual file, and years of publication
> for one copyright holder may be gathered together" [1].  So short form
> rules I misunderstood are:
> 
> * Wildcards are hungry globs.
> * Lists of files are white-space, tab, or newline separated strings.
> * Years may be specified as either a comma-separated list of discrete
>   years, or a year-to-year range.
> * Refer to individual files or VCS for specific dates when multiple
>   files are grouped, because [1].

I don't know whether this list is an accurate list of what you
misunderstood, but the four bullet points are true of the format :)

> I also wonder how many contributors there must be to justify a
> "Primary copyright holder, and others" statement, and also if one
> needs to do VCS archaeology to find and list all of the potential
> one-off contributors.

That's beyond my knowledge, I'm afraid.  You might want to ask d-legal.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#851626: sogo.service specifies wrong RuntimeDirectory

[nemo Inis]

Package: sogo
Version: 3.2.5-2
Severity: important

(also affects 3.2.4 in testing)

sogo.service specifies /run/sogo as the RuntimeDirectory. The service fails to 
start because
systemd expects a simple name not a path. See man 5 systemd.exec

Bug#845830: cl-sql: switch to build depend on the metapackage default-libmysqlclient-dev

[Andreas Beckmann]

Followup-For: Bug #845830
Control: tag -1 pending

Hi,

I just uploaded a NMU to DELAYED/2 fixing this issue. Please let me know
if I should delay it longer.

 cl-sql (6.7.0-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Switch (Build-)Depends to default-libmysqlclient-dev.  (Closes: #845830)


Andreas

Bug#773245: git-p4 package?

[Luke Diamand]

Hi!

I put in a patch to add a git-p4 package, here:

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

I was wondering what I need to do next for this to be merged? Or if
I've done it wrong somehow?

Thanks
Luke

Bug#851625: README.Debian seemingly only mentions a different package

[積丹尼 Dan Jacobson]

Package: wodim
Version: 9:1.1.11-3
Severity: wishlist

# grep -ic wodim /usr/share/doc/wodim/README.Debian 
0

Bug#835522: closed by Héctor Orón Martínez (Bug#835522: fixed in gdb 7.12-2)

[James McCoy]

Control: found -1 7.12-4

On Wed, Dec 14, 2016 at 11:57:14AM +, Debian Bug Tracking System wrote:
> Changes:
>  gdb (7.12-2) unstable; urgency=medium
>  .
>* debian/control*:
>  - add mipsel64 arch to gdbserver.

This is actually spelled mips64el, so the bug isn't fixed.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#851613: src:bottleneck: Tests fail if enabled

[Pietro Battiston]

Thanks for your report. Tests run fine in my install, which is a bit
out of date (e.g. python3-numpy version 1:1.11.2-1).
I will try to understand what update broke them. In the meanwhile, I
filed the bug upstream.

Pietro

Bug#848236: Remaining issue with gbrowse - any help (Was: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: ...)

[Lincoln Stein]

Hi,

I need a little help to reproduce Gregor's failed tests, given that I'm a
complete newbie wrt the Debian packaging system. I have cloned gbrowse
2.56+dfsg-1 from the Debian Med repository, but I don't know what command
line to use to attempt the build. What is the next step? I'm guessing it is
some form of dpkg-buildpackage, but the number of options is pretty
overwhelming!



Lincoln

On Mon, Jan 16, 2017 at 3:01 PM, gregor herrmann  wrote:

> On Mon, 16 Jan 2017 16:45:52 +0100, Andreas Tille wrote:
>
> > > If you want to use the same list of tests to skip during build, you
> > > can do something like
> > > https://sources.debian.net/src/libipc-sharelite-perl/0.
> 17-4/debian/rules
> > Ahhh, OK.  I wrongly assumed that would be some magic since in the
> > bioperl case it worked without this extra means.
>
> The magic there worked because it was only needed for autopkgtest and
> not at build time :)
>
> > > I migt be able to try a build later today.
> >
> > After safely landing in Berlin (from Debian Med sprint in Bukarest) I
> > tried with your hints and the only remaining issue seems to be:
> >
> > t/00.compile.t  (Wstat: 3840 Tests: 90 Failed: 15)
> >   Failed tests:  1, 3, 5, 7, 10, 15, 17-18, 29, 31, 33, 35
> > 41, 45, 47
> >   Non-zero exit status: 15
>
> Lucky you :)
> When I try to build the package from git, I get:
>
> Test Summary Report
> ---
> t/00.compile.t  (Wstat: 3840 Tests: 90 Failed: 15)
>   Failed tests:  1, 3, 5, 7, 10, 15, 17-18, 29, 31, 33, 35
> 41, 45, 47
>   Non-zero exit status: 15
> t/02.rearchitecture.t   (Wstat: 65280 Tests: 0 Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 90 tests but ran 0.
> t/03.render.t   (Wstat: 65280 Tests: 0 Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 150 tests but ran 0.
> t/04.remoteserver.t (Wstat: 65280 Tests: 0 Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 43 tests but ran 0.
> t/05.deferredrendering.t (Wstat: 65280 Tests: 0 Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 19 tests but ran 0.
> t/06.featuresearch.t(Wstat: 65280 Tests: 0 Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 26 tests but ran 0.
> t/07.karyotype.t(Wstat: 65280 Tests: 0 Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 3 tests but ran 0.
> Files=10, Tests=103,  5 wallclock secs ( 0.03 usr  0.03 sys +  4.19 cusr
> 0.36 csys =  4.61 CPU)
> Result: FAIL
> Failed 7/10 test programs. 15/103 subtests failed.
>
>
> Ah, found it:
>
> #   Failed test 'cgi-bin/das compiled ok'
> #   at t/00.compile.t line 47.
> # stdout:
> # stderr: Backslash found where operator expected at
> /build/gbrowse-2.56+dfsg/blib/lib/Bio/Graphics/Browser2/DataSource.pm
> line 963, near "$ENV\"
> #   (Missing operator before \?)
> # Backslash found where operator expected at /build/gbrowse-2.56+dfsg/blib/
> lib/Bio/Graphics/Browser2/DataSource.pm line 963, near "$1\"
> #   (Missing operator before \?)
> # Variable "$semantic_label" is not imported at
> /build/gbrowse-2.56+dfsg/blib/lib/Bio/Graphics/Browser2/DataSource.pm
> line 984,  line 192.
> #   (Did you mean &semantic_label instead?)
> # syntax error at 
> /build/gbrowse-2.56+dfsg/blib/lib/Bio/Graphics/Browser2/DataSource.pm
> line 963, near "$ENV\"
> # syntax error at 
> /build/gbrowse-2.56+dfsg/blib/lib/Bio/Graphics/Browser2/DataSource.pm
> line 963, near "''}"
>
> This seems to come from debian/patches/fix_perl_deprecation.
>
> *a bit later*
>
> Yes, this patch is wrong now and can be dropped, as the original
> issue was fixed in the 2.56 release. (Attached)
>
> This brings me to:
>
> Test Summary Report
> ---
> t/03.render.t   (Wstat: 65280 Tests: 41 Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 150 tests but ran 41.
> t/04.remoteserver.t (Wstat: 0 Tests: 41 Failed: 4)
>   Failed tests:  11, 23, 35, 39
>   Parse errors: Bad plan.  You planned 43 tests but ran 41.
> t/05.deferredrendering.t (Wstat: 0 Tests: 19 Failed: 2)
>   Failed tests:  5, 14
>
> So t/00.compile.t just works. But I still have other issues.
>
> Seems they all fail with something like
> "Can't locate testdata/conf/../../../conf/plugins/Aligner.pm in @INC ..."
> which is quite weird path ... -- But it's fine, so we probably have a
> ". removed from @INC" problem here somewhere.
>
> I guess that's it:
>
> lib/Bio/Graphics/Browser2/PluginSet.pm
>
> my $class = "Bio\:\:Graphics\:\:Browser2\:\:Plugin\:\:$plugin";
> for my $search_path (@search_path) {
>   my $plugin_with_path = "$search_path/$plugin.pm";
>   if (eval {require $plugin_with_path}) {
>
> Ok, changing this to "./$plugin_with_path" gets rid of this error but
> later we still get something similar:
>
> # prove --blib --verbose t/05.deferredren

Bug#851524: Building armhf image fwith qemu fails at bootstrapping stage if firmware section enabled

[Daniel Reichelt]

> Incidentally, if anyone *has* a link to the old deb package
> for 1:20151215 so I could verify this, that'd help.

Jason,

have a look at http://snapshot.debian.org/



Cheers
Daniel





signature.asc
Description: OpenPGP digital signature

Bug#851624: spurious .gitattributes warning on clone

[Ian Jackson]

Package: dgit
Version: 3.4

zealot:d> dgit clone glibc
...
dpkg-source: info: extracting glibc in glibc-2.24
dpkg-source: info: unpacking glibc_2.24.orig.tar.xz
dpkg-source: info: unpacking glibc_2.24-9.debian.tar.xz
warning: gbp pq import failed: subprocess failed with error exit status 1
dgit: trying slow absurd-git-apply...
synthesised git commit from .dsc 2.24-9
dgit: warning: fetched source tree contains .gitattributes
dgit: .gitattributes have not been defused.  Recommended: dgit setup-new-tree.
HEAD is now at 28770e0 cvs-resolv-internal-qtype
dgit ok: ready for work in glibc

This is probably wrong, and if so, silly.

-- 
Ian JacksonThese opinions are my own.

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

Bug#851613: src:bottleneck: Tests fail if enabled

[Pietro Battiston]

Il giorno lun, 16/01/2017 alle 20.50 +, Ghislain Antony Vaillant ha
scritto:
> [...]
> Input array:
> [[ inf   7. -inf  -9.]
>  [-10.  nan  nan   5.]
>  [  4.  nan  nan  inf]]
> 
> x and y +inf location mismatch:
>  x: array([-1. , -2.5,  inf], dtype=float32)
>  y: array([-1. , -2.5,  2. ], dtype=float32)

See kwgoodman's comment...
https://github.com/kwgoodman/bottleneck/issues/160#issuecomment-2729794
74

Pietro

Bug#837992: Bugs in my jailbreak

[Foxx Neo]

Sent from my iPhone

Bug#844785: "not authorised" doing various desktoppy things [and 1 more messages]

[Martín Ferrari]

On 15/01/17 13:43, Ian Jackson wrote:
> Ian Jackson writes ("Re: "not authorised" doing various desktoppy things [and 
> 1 more messages]"):
>> More news later today.
> 
> I have just uploaded systemd-shim 10-3~exp1 to experimental.  I seems
> to fix the problem for me.  Depending on feedback, I will upload this
> to sid in the next few days.

This seems to solve the problem for me, thank you very much! (And I hope
you can get this in for stretch!)


-- 
Martín Ferrari (Tincho)

Bug#851613: src:bottleneck: Tests fail if enabled

[Pietro Battiston]

Il giorno lun, 16/01/2017 alle 22.32 +, Ghislain Vaillant ha
scritto:
> [...]
> Just out of curiosity, may I ask why the package is not team-
> maintained 
> by the Python modules team or the Debian Science team?

No specific reason, except that I don't know how it works and don't
have much time to learn (and last time I had time, the DPMT was still
using svn so I gave up!).

I would be happy to have the migration to a team happening if it means
less work for me, and I would not be happy if it means more work for me
:-)

Pietro

Bug#721763: brltty grabs tty from CP2102/CP2109 device disconnecting default kernel driver

[Samuel Thibault]

Hello,

Tjeerd Pinkert, on Tue 03 Sep 2013 22:30:18 +0200, wrote:
> On connecting a CERN SPEC board (see www.ohwr.org White Rabbit
> project) through it's USB to serial convertor (CP2102/CP2109,
> vid=10C4h, pid=EA60h) to the system, expecting a ttyUSB device to be
> installed using the default kernel driver, brltty unexpectedly
> replaced the default kernel driver with it's own USB Braille terminal
> driver. Since the Seika Braille reader uses the CP2102/CP2109 default
> vid/pid, brltty addressed the SPEC board as such.

Do you still have this board for testing?  What values does it show in
the idVendor field of lsusb -v?

As explained in the bug report, we are wary of breaking users' support
for their only way to access their computer.  But recently version 5.4-3
of brltty was fixed into only taking control of devices with the right
idVendor field.  Unfortunately again the identifiers used by the actual
devices are the main product ones, in the case of the current bugreport
"Silicon Labs". Is that what your device has? Usually even if they
didn't modify vid/pid the vendor field is modified, and thus brltty now
avoids grabbing these.

Samuel

Bug#851524: Building armhf image fwith qemu fails at bootstrapping stage if firmware section enabled

[Jason Heeris]

Okay, after clearing caches, cleaning up env vars, etc. I'm able to
reliably reproduce the problem.

I've attached two makefiles, one that works (in that, it builds an image, I
don't care about running the image yet). The other fails to build with the
aforementioned error. In the last version of live-build, I'm pretty sure
the same command worked. The only difference between the two are the
archive areas used; "firmware" should be a valid archive for Raspbian.

Incidentally, if anyone *has* a link to the old deb package for 1:20151215
so I could verify this, that'd help.

Thanks,
Jason


Makefile-that-fails
Description: Binary data


Makefile-that-works
Description: Binary data

Bug#851228: [Pkg-alsa-devel] Bug#851228: README.Debian should mention systemd methods too

[積丹尼 Dan Jacobson]

ER> As you now know how the systemd environment works with alsa

I don't.

Bug#851623: Process spawned by package constantly causes traffic on loopback network device

[Andreas Ackermann]

Package: xbrlapi
Version: 5.4-4

After installing Debian Stretch last week, I noticed constant network 
activity which shouldn't be there on lo and which looks like this:


root@breizh:/home/acki# nethogs -a -t
Adding local address: x
Adding local address: x
Ethernet link detected
Adding local address: 127.0.0.1
Ethernet link detected
Waiting for first packet to arrive (see sourceforge.net bug 1019381)

Refreshing:
unknown TCP/0/0 0   0

Refreshing:
127.0.0.1:43580-127.0.0.1:4101/0/0  0.0144531   0
127.0.0.1:4101-127.0.0.1:43578/0/0  0.0210938   0
127.0.0.1:43578-127.0.0.1:4101/0/0  0.0144531   0
unknown TCP/0/0 0   0

Refreshing:
127.0.0.1:43584-127.0.0.1:4101/0/0  0.0144531   0
127.0.0.1:43582-127.0.0.1:4101/0/0  0.0144531   0
127.0.0.1:43580-127.0.0.1:4101/0/0  0.0144531   0
127.0.0.1:4101-127.0.0.1:43578/0/0  0.0421875   0
127.0.0.1:43578-127.0.0.1:4101/0/0  0.0144531   0
unknown TCP/0/0 0   0
...

After some research I found out that uninstalling xbrlapi,
which got installed as a recommended package by gnome-orca
solves the issue.

I believe a package that can't find its hardware shouldn't
do such aggressive polling and thus this should be fixed.

Note: For the network activity on lo to end, a reboot was
necessary, just logging off and on again from the X-Session
didn't solve the issue.

I haven't got any braille-related hardware and I didn't select
intentionally any braille-related package.

Here's someone from France who had the same issue and whose
advice I followed:

https://debian-facile.org/viewtopic.php?pid=200466#p200466

My architecture is amd64.

Sorry for any inconvenience, this is my first bug report ever
for Debian.

-Acki

Bug#851613: src:bottleneck: Tests fail if enabled

[Ghislain Vaillant]

On Mon, 2017-01-16 at 23:17 +0100, Pietro Battiston wrote:
> Thanks for your report. Tests run fine in my install, which is a bit
> out of date (e.g. python3-numpy version 1:1.11.2-1).

Mine has 1:1.12.0~rc2.

> I will try to understand what update broke them. In the meanwhile, I
> filed the bug upstream.

Thanks for looking it up.

Just out of curiosity, may I ask why the package is not team-maintained 
by the Python modules team or the Debian Science team? There would have
been a few fixes that I would have been able to push if that were the
case.

Cheers,
Ghis

Bug#851622: mate-control-center: No inicia correctamente (System -> Preferences -> Appearance)

[jonatanpc8]

Package: mate-control-center
Version: 1.8.3+dfsg1-2
Severity: normal

Dear Maintainer,

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

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

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



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

Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mate-control-center depends on:
ii  caja-common 1.8.2-3+deb8u1
ii  desktop-file-utils  0.22-1
ii  gsettings-desktop-schemas   3.14.1-1
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-18+deb8u7
ii  libcairo2   1.14.0-2.1+deb8u2
ii  libcanberra-gtk00.30-2.1
ii  libcanberra00.30-2.1
ii  libdbus-1-3 1.8.22-0+deb8u1
ii  libdbus-glib-1-20.102-1
ii  libdconf1   0.22.0-1
ii  libfontconfig1  2.11.0-6.3+deb8u1
ii  libfreetype62.5.2-3+deb8u1
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u5
ii  libglib2.0-02.42.1-1+b1
ii  libglib2.0-bin  2.42.1-1+b1
ii  libgtk2.0-0 2.24.25-3+deb8u1
ii  libice6 2:1.0.9-1+b1
ii  libmarco-private0   1.8.2+dfsg1-6
ii  libmate-desktop-2-171.8.1+dfsg1-3+deb8u1
ii  libmate-menu2   1.8.0-5
ii  libmate-slab0   1.8.3+dfsg1-2
ii  libmate-window-settings11.8.3+dfsg1-2
ii  libmatekbd4 1.8.0-2
ii  libpango-1.0-0  1.36.8-3
ii  libpangocairo-1.0-0 1.36.8-3
ii  libpangoft2-1.0-0   1.36.8-3
ii  libsm6  2:1.2.2-1+b1
ii  libstartup-notification00.12-4
ii  libunique-1.0-0 1.1.6-5
ii  libx11-62:1.6.2-3
ii  libxcursor1 1:1.1.14-1+b1
ii  libxext62:1.3.3-1
ii  libxft2 2.3.2-1
ii  libxi6  2:1.7.4-1+b2
ii  libxklavier16   5.2.1-1
ii  libxml2 2.9.1+dfsg1-5+deb8u4
ii  libxss1 1:1.2.2-1
ii  marco-common1.8.2+dfsg1-6
ii  mate-control-center-common  1.8.3+dfsg1-2
ii  mate-desktop1.8.1+dfsg1-3+deb8u1
ii  mate-icon-theme 1.8.0-1
ii  mate-menus  1.8.0-5
ii  mate-settings-daemon1.8.2-4

mate-control-center recommends no packages.

Versions of packages mate-control-center suggests:
ii  gconf2  3.2.6-3

-- no debconf information

Bug#851620: partman-md: doesn't warn about not being able to embed in the end

[Lennart Sorensen]

On Mon, Jan 16, 2017 at 10:46:44PM +0100, Samuel Thibault wrote:
> Package: partman-md
> Version: 77
> Severity: wishlist
> 
> Hello,
> 
> partman-md doesn't warn when disks to be used for RAID are partitioned
> with GPT without a bios boot partition for embedding (and I haven't seen
> documentation about the issue in the installer manual).

I suspect it might be a case of using gpt when not running in UEFI mode
is not normally done.

Normally people are either running UEFI mode and hence use GPT, or
they are using legacy BIOS and hence stick to DOS MBR partition table.
Given you don't have to go to GPT until your disk is 2TB or larger,
it has been OK for most people on legacy systems.

Of course since lilo is also a boot loader option in the installer,
one could argue whether there ought to be grub specific checks in the
partitioning tool.  I believe the warning you saw only came when the
grub install part did its checks much later, which is of course when
the grub code would be run.  Yes that's certainly a bit late given you
have to go back and do it all again if you want to use grub.

-- 
Len Sorensen

Bug#851618: lirc: adequate reports multiple obsolete-conffiles for lirc Package: lirc

[Michael Kolmodin]

On Tue, 17 Jan 2017 03:12:49 +0530 
=?UTF-8?B?c2hpcmlzaCDgpLbgpL/gpLDgpYDgpLc=?=  wrote:


> Adequate reported multiple obsolete-conffiles for lirc -
>
> [$] adequate lirc
>
> lirc: obsolete-conffile /etc/lirc/irexec.lircrc
> lirc: obsolete-conffile /etc/lirc/lircmd.conf
> lirc: obsolete-conffile /etc/lirc/hardware.conf
> lirc: obsolete-conffile /etc/lirc/lircd.conf
> lirc: obsolete-conffile /etc/lirc/lirc_options.conf

Hi!

hm... My strongest feeling about the debian configuration handling is 
being on thin ice. That said, all of these files exists for reason.


The hardware.conf is indeed obsolete,  and not really used from 0.9.4+. 
But the upgrade from 0.9.0 to 0.9.4 is  a breaking update requiring 
manual intervention, mostly about moving values from hardware.conf to 
lirc_options.conf. So it needs to around as reference for some cycles.


The other files  are important configuration stuff. On what ground does 
adequate deem them as "obsolete"?


Perhaps is the problem I havn't trusted the conffiles  handlng of 
configuration files but instead just created them in the maintainer 
scripts? This is because lirc has been plagued by multiple upgrade bugs 
based on this stuff, forcing user intervention. The policy here is that 
we ship e. g. lirc_options.conf.dist which is upgraded but not actually 
used. lirc_options.conf is created as a copy if lirc_options.dist if it 
does not exist, but is otherwise left as-is. Does this upset adequate?


--alec

Bug#851619: new upstream release fixes a bag of CVEs

[Toni Mueller]

Hi,

On Mon, Jan 16, 2017 at 10:43:05PM +0100, Toni Mueller wrote:
> there is a new Ansible release, 2.2.1, which was published on 2017-01-11
> on releases.ansible.com, which fixes a bag of security holes, for which
> CVEs should already exist. Please take a look at

sorry, MY BAD.

The final 2.2.1 version was only released today, the packages released
on the 11th were only release candidates.


Cheers,
--Toni++

Bug#851619: new upstream release fixes a bag of CVEs

[Toni Mueller]

Hi Harlan,

On Mon, Jan 16, 2017 at 05:06:36PM -0500, Harlan Lieberman-Berg wrote:
> Happy to report that these have already been fixed through cherry-picks
> over the last five days or so.  2.2.1 has no security fixes not present
> in 2.2.0.0-4.

oh, great. I almost expected as much, but wanted to make really sure
because of the impact.

> We'll probably merge in 2.2.1 in the next couple of days to get the
> other bugfixes that are in there.

Sounds great. I was reading about some and already considered nagging
you about them.


Cheers,
--Toni++

Bug#851508: Russian translation for apt-listbugs/ru.po

[Francesco Poli]

On Mon, 16 Jan 2017 08:07:01 +0300 Sergey Alyoshin wrote:

> On Mon, Jan 16, 2017 at 1:20 AM, Francesco Poli
>  wrote:
> > On Sun, 15 Jan 2017 22:22:18 +0300 Sergey Alyoshin wrote:
> >
> >> Package: apt-listbugs
> >> Version: 0.1.22
> >> Priority: wishlist
> >> Tags: l10n
> >
> > Hello Sergey,
> > thanks for sending me a new translation!
> > I'll take a look at it very soon (hopefully).
> 
> 
> Thanks for quick reply and you work.

I have a couple of questions.

First of all:

  "Plural-Forms: nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n"
  "%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 && n%10<=9) || (n"
  "%100>=11 && n%100<=14)? 2 : 3);\n"

Is this the correct plural rule for the Russian language?
According to
https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html
it should be

  "Plural-Forms: nplurals=3;"
  "plural=n%10==1 && n%100!=11 ? 0 :"
  "n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n"

And this is indeed the plural rule that you seem to have used in your
translation for postfix debconf templates (see bug #851489).

Could you please clarify why you used a different rule for the
apt-listbugs translation?


Secondly:

  #: ../lib/aptlistbugs/logic.rb:83
  msgid "Outstanding"
  msgstr "Исключительных"

Please note that, here, "Outstanding" means "unresolved", not
"exceptional"...
Is the above translation correct? Or should another Russian word be
used?



Please note that, although I studied a little bit of Russian in the
past, my knowledge has never been too detailed and my memories are
definitely rusty now... Hence I may well be completely off-track.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpKQEYGmP4Jx.pgp
Description: PGP signature

Bug#851621: ath9k: NULL pointer dereference

[Wojciech Nizinski]

Package: src:linux
Version: 4.8.11-1~bpo8+1
Severity: important
Tags: newcomer

Sorry for format, but I have to use netconsole to catch reason of hangs.
Similar problem was decribed and solved here:
https://patchwork.kernel.org/patch/9431163/

1,13973,2752665216920,c;BUG: unable to handle kernel
4,13974,2752665220953,+;NULL pointer dereference
4,13975,2752665223069,+; at 0040
1,13976,2752665224999,c;IP:
4,13977,2752665226768,+; [] ath_cmn_process_fft+0xf4/0x5c0
[ath9k_common]
4,13978,2752665232782,c;PGD 0
4,13979,2752665234800,+;
4,13980,2752665235001,-;Oops:  [#1] SMP
4,13981,2752665238329,c;Modules linked in:
4,14190,2752665423179,-;CPU: 1 PID: 0 Comm: swapper/1 Tainted: P   OE
4.7.0-0.bpo.1-amd64 #1 Debian 4.7.8-1~bpo8+1
4,14191,2752665433531,-;Hardware name: Gigabyte Technology Co., Ltd. To be
filled by O.E.M./F2A55-DS3, BIOS F2 09/28/2012
4,14192,2752665443611,-;task: 88042ce2c000 ti: 88042cfbc000 task.ti:
88042cfbc000
4,14193,2752665451270,c;RIP: 0010:[]
4,14194,2752665455465,+; [] ath_cmn_process_fft+0xf4/0x5c0
[ath9k_common]
4,14195,2752665461479,-;RSP: 0018:88043ec83cc0  EFLAGS: 00010202
4,14196,2752665466965,-;RAX: 0008 RBX:  RCX:

4,14197,2752665474271,-;RDX:  RSI: 0200 RDI:
90b1a140
4,14198,2752665481576,-;RBP:  R08:  R09:

4,14199,2752665488890,-;R10: 0280ec59f382 R11: 0400 R12:

4,14200,2752665496203,-;R13: 88025549a580 R14: 88043ec83d39 R15:
880429c48018
4,14201,2752665503520,-;FS:  () GS:88043ec8()
knlGS:
4,14202,2752665511778,-;CS:  0010 DS:  ES:  CR0: 80050033
4,14203,2752665517696,-;CR2: 0040 CR3: 000384ad2000 CR4:
000406e0
4,14204,2752665525002,-;Stack:
4,14205,2752665527192,c; 8804292b04e2
4,14206,2752665530165,+; 0010
4,14207,2752665531665,+; 880429c47a80
4,14208,2752665533163,+; 90346bae
4,14209,2752665534664,+;
4,14210,2752665534862,c; 
4,14211,2752665537834,+; 
4,14212,2752665539343,+; 
4,14213,2752665540850,+; 8804292bc800
4,14214,2752665542350,+;
4,14215,2752665542550,c; 88043ec83e6c
4,14216,2752665545522,+; 0281a0dfe991
4,14217,2752665547020,+; 097693c3
4,14218,2752665548521,+; 
4,14219,2752665550018,+;
4,14220,2752665550219,-;Call Trace:
4,14221,2752665552845,c; 
4,14222,2752665554976,-; [] ? iommu_area_alloc+0x6e/0x80
4,14223,2752665561001,-; [] ? ath_rx_tasklet+0xaf5/0xca0
[ath9k]
4,14224,2752665567705,-; [] ? ath9k_tasklet+0xd7/0x240
[ath9k]
4,14225,2752665574237,-; [] ? tasklet_action+0xf3/0x100
4,14226,2752665580165,-; [] ? __do_softirq+0x106/0x294
4,14227,2752665586003,-; [] ? irq_exit+0x86/0x90
4,14228,2752665591325,-; [] ? do_IRQ+0x4f/0xd0
4,14229,2752665596463,-; [] ? common_interrupt+0x82/0x82
4,14230,2752665602467,c; 
4,14231,2752665604586,-; [] ? cpuidle_enter_state+0x112/0x260
4,14232,2752665611033,-; [] ? cpu_startup_entry+0x2be/0x360
4,14233,2752665617315,-; [] ? start_secondary+0x151/0x190
4,14234,2752665623413,c;Code:
4,14235,2752665625433,+;5e
4,14236,2752665625717,+;41
4,14237,2752665626004,+;5f
4,14238,2752665626289,+;c3
4,14239,2752665626575,+;0f
4,14240,2752665626860,+;b7
4,14241,2752665627147,+;14
4,14242,2752665627432,+;24
4,14243,2752665627718,+;31
4,14244,2752665628006,+;c0
4,14245,2752665628291,+;41
4,14246,2752665628575,+;f6
4,14247,2752665628854,+;44
4,14248,2752665629140,+;15
4,14249,2752665629424,+;ff
4,14250,2752665629712,+;10
4,14251,2752665629998,+;74
4,14252,2752665630283,+;c9
4,14253,2752665630569,+;48
4,14254,2752665630857,+;8b
4,14255,2752665631142,+;44
4,14256,2752665631428,+;24
4,14257,2752665631714,+;10
4,14258,2752665631999,+;31
4,14259,2752665632286,+;db
4,14260,2752665632572,+;41
4,14261,2752665632858,+;bc
4,14262,2752665633144,+;ff
4,14263,2752665633428,+;ff
4,14264,2752665633716,+;ff
4,14265,2752665634001,+;ff
4,14266,2752665634287,+;48
4,14267,2752665634574,+;8b
4,14268,2752665634859,+;68
4,14269,2752665635146,+;08
4,14270,2752665635431,+;eb
4,14271,2752665635718,+;12
4,14272,2752665636002,+;48
4,14273,2752665636288,+;98
4,14274,2752665636575,+;48
4,14275,2752665636870,+;83
4,14276,2752665637156,+;c0
4,14277,2752665637440,+;08
4,14278,2752665637727,+;<48>
4,14279,2752665638188,+;8b
4,14280,2752665638474,+;7c
4,14281,2752665638759,+;c5
4,14282,2752665639044,+;00
4,14283,2752665639330,+;e8
4,14284,2752665639617,+;b2
4,14285,2752665639904,+;e5
4,14286,2752665640190,+;a6
4,14287,2752665640475,+;cf
4,14288,2752665640761,+;01
4,14289,2752665641048,+;c3
4,14290,2752665641331,+;41
4,14291,2752665641619,+;8d
4,14292,2752665641905,+;54
4,14293,2752665642192,+;24
4,14294,2752665642476,+;01
4,14295,2752665642762,+;be
4,14296,2752665643048,+;00
4,14297,2752665643334,+;02
4,14298,2752665643619,+;00
4,14299,2752665643905,+;
1,14300,2752665644

Bug#851619: new upstream release fixes a bag of CVEs

[Harlan Lieberman-Berg]

package ansible
tag 851619 -security -upstream
severity 851619 wishlist
retitle 851619 New ansible upstream version
thanks

Toni Mueller  writes:
> there is a new Ansible release, 2.2.1, which was published on 2017-01-11
> on releases.ansible.com, which fixes a bag of security holes, for which
> CVEs should already exist. Please take a look at

Hi Toni!

Happy to report that these have already been fixed through cherry-picks
over the last five days or so.  2.2.1 has no security fixes not present
in 2.2.0.0-4.

We'll probably merge in 2.2.1 in the next couple of days to get the
other bugfixes that are in there.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#851504: freedombox-setup: debconf prompts during install, and default answers lead to setup failures

[James Valleroy]

On Mon, 16 Jan 2017 16:48:05 +0100 Petter Reinholdtsen 
wrote:
> [James Valleroy]
> > I would like to propose the following change: Don't set policy-rc.d in
> > the setup script in this package.
> 
> Will this affect the autopkgtest script?  What about building freedombox
> in a chroot?  Does it matter?

I'm able to run setup successfully (with this patch) in a chroot (setup
using schroot).

I also tested building images using freedom-maker with the patched
freedombox-setup.



signature.asc
Description: OpenPGP digital signature

Bug#845519: Re : kernel 4.8 can't boot on Dell Optiplex 7040

[Benoît Tonnerre]

Dear Maintener,

I can confirm that everything work now with latest kernel 4.8 updates.

The optiplex 7040 is actually running kernel image :
linux-image-4.8.0-2-amd64 ( version 4.8.15-2 )

Thanks a lot.

Best regards

Benoît Tonnerre

Bug#851615: xz-utils: please upgrade to 5.2.3

[Thorsten Glaser]

Sebastian Andrzej Siewior dixit:

>Please upgrade to 5.2.3 for Stretch. One visible change is the usage of

That’s rather late, I’d not risk it, especially not for a package
that is so low in the stack as xz is.

bye,
//mirabilos
-- 
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”

Bug#851619: new upstream release fixes a bag of CVEs

[Toni Mueller]

Package: ansible
Version: 2.2.0.0-1
Severity: grave
Tags: security upstream


Hi,

there is a new Ansible release, 2.2.1, which was published on 2017-01-11
on releases.ansible.com, which fixes a bag of security holes, for which
CVEs should already exist. Please take a look at

https://www.computest.nl/advisories/CT-2017-0109_Ansible.txt


Cheers,
--Toni++



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

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

Versions of packages ansible depends on:
ii  python-crypto 2.6.1-7
ii  python-httplib2   0.9.2+dfsg-1
ii  python-jinja2 2.8-1
ii  python-netaddr0.7.18-2
ii  python-paramiko   2.0.0-1
ii  python-pkg-resources  32.0.0-1
ii  python-yaml   3.12-1
pn  python:any

Versions of packages ansible recommends:
ii  python-kerberos   1.1.5-2+b2
ii  python-selinux2.6-3
pn  python-winrm  
ii  python-xmltodict  0.10.2-1

Versions of packages ansible suggests:
pn  cowsay   
ii  sshpass  1.06-1

-- Configuration Files:
/etc/ansible/ansible.cfg changed [not included]
/etc/ansible/hosts changed [not included]

-- no debconf information

Bug#851617: Plasma-discover suggests Gnome applications

[Heinrich Schuchardt]

Package: plasma-discover
Version: 5.8.3-1
Severity: minor

Dear Maintainer,

I am running Debian with the KDE windows manager.

On my computer plasma-discover suggested Brasero (as most popular) with these
words:
"Brasero is a application to burn CD/DVD for the Gnome Desktop."

Why should I get suggestions for the Gnome Desktop if I have KDE installed?

I expect plasma-discover to suggest KDE applications, in this case K3B.

And, please, proofread the descriptions.

Best regards

Heinrich Schuchardt

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.UTF-8 (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)

Versions of packages plasma-discover depends on:
ii  appstream0.10.5-1
ii  kio  5.27.0-2
ii  libappstreamqt2  0.10.5-1
ii  libc62.24-8
ii  libkf5archive5   5.27.0-1
ii  libkf5attica55.27.0-1
ii  libkf5configcore55.27.0-1
ii  libkf5configgui5 5.27.0-1
ii  libkf5configwidgets5 5.27.0-1
ii  libkf5coreaddons55.27.0-1
ii  libkf5crash5 5.27.0-1
ii  libkf5dbusaddons55.27.0-1
ii  libkf5declarative5   5.27.0-1+b1
ii  libkf5i18n5  5.27.0-2
ii  libkf5kiocore5   5.27.0-2
ii  libkf5kiowidgets55.27.0-2
ii  libkf5newstuff5  5.27.0-1
ii  libkf5notifications5 5.27.0-1
ii  libkf5widgetsaddons5 5.27.0-1
ii  libkf5xmlgui55.27.0-1
ii  libpackagekitqt5-0   0.9.6-1
ii  libqt5core5a 5.7.1+dfsg-2
ii  libqt5dbus5  5.7.1+dfsg-2
ii  libqt5gui5   5.7.1+dfsg-2
ii  libqt5qml5   5.7.1-2
ii  libqt5quick5 5.7.1-2
ii  libqt5widgets5   5.7.1+dfsg-2
ii  libqt5xml5   5.7.1+dfsg-2
ii  libstdc++6   6.2.1-5
ii  packagekit   1.1.4-3
ii  plasma-discover-common   5.8.3-1
ii  qml-module-org-kde-kirigami  1.1.0-1

Versions of packages plasma-discover recommends:
ii  software-properties-kde  0.96.20.2-1

plasma-discover suggests no packages.

-- no debconf information

Bug#851620: partman-md: doesn't warn about not being able to embed in the end

[Samuel Thibault]

Package: partman-md
Version: 77
Severity: wishlist

Hello,

partman-md doesn't warn when disks to be used for RAID are partitioned
with GPT without a bios boot partition for embedding (and I haven't seen
documentation about the issue in the installer manual).

To reproduce:

dd < /dev/zero > disk1 bs=1M count=1 seek=3000
/sbin/fdisk disk1
g
w
dd < /dev/zero > disk2 bs=1M count=1 seek=3000
/sbin/fdisk disk2
g
w
kvm -drive file=disk1 -drive file=disk2 -m 1G -cdrom 
debian-stretch-DI-rc1-amd64-netinst.iso -boot d

at partitioning step:

- request manual partitioning
- configure software RAID
- keep current partition layout
- create MD device, e.g. RAID1, with the two disks
- write the changes
- finish RAID menu
- set up / partition on the MD device
- install Debian with default options
- let it install grub on sda

This brings an error. syslog shows:

this GPT partition label contains no BIOS Boot Partition: embedding won't be 
possible
grub-install: error:
embedding is not possible, but this is required for RAID and LVM install

That's a bit late for noticing thig. Perhaps this should just be
documented in the manual, but the installer could also warn e.g. at the
"keep current partition layout" stage above that there is no device
which has some place to embed boot (but let the user discard it in case
that's on purpose).

Samuel

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

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

-- 
Samuel
N: beep beep Miam miam? 
y: ++
a: kill -MIAM -1
 -+- #runtime < /dev/miam -+-

Bug#708022: got hit today by debdelta-upgrade : local variable 'url' referenced before assignment

[shirish शिरीष]

Hi all,

Was doing debdelta-upgrade when got hit by the above error -

Downloaded, time 11.16sec, speed 135kB/sec,
emacs24_24.5+1-7.1_24.5+1-7.1+b1_amd64.debdelta
debdelta-upgrade : local variable 'url' referenced before assignment

@Mennucc1, can you comment ?

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

Bug#851618: lirc: adequate reports multiple obsolete-conffiles for lirc Package: lirc

[shirish शिरीष]

Package:lirc
Version: 0.9.4c-7
Severity: normal

Dear Maintainer,
Adequate reported multiple obsolete-conffiles for lirc -

[$] adequate lirc

lirc: obsolete-conffile /etc/lirc/irexec.lircrc
lirc: obsolete-conffile /etc/lirc/lircmd.conf
lirc: obsolete-conffile /etc/lirc/hardware.conf
lirc: obsolete-conffile /etc/lirc/lircd.conf
lirc: obsolete-conffile /etc/lirc/lirc_options.conf

Maybe you could use what pabs (Paul Wise) did in #815563, in that the
proper thing to do would be -

Use the dpkg-maintscript-helper support provided by dh_installdeb to
remove such similar obsolete conffiles on upgrade

Also https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files

You can also see manpage of dh_installdeb vid debhelper package which
is the same thing.

I ran the same command as he did -

[$] pkg=lirc ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg
| grep obsolete
[1:34:10]
lirc: obsolete-conffile /etc/lirc/irexec.lircrc
lirc: obsolete-conffile /etc/lirc/lircmd.conf
lirc: obsolete-conffile /etc/lirc/hardware.conf
lirc: obsolete-conffile /etc/lirc/lircd.conf
lirc: obsolete-conffile /etc/lirc/lirc_options.conf
 /etc/lirc/irexec.lircrc 92df549c82f58ea28b605e5045984e04 obsolete
 /etc/lirc/lircmd.conf eca53bdc53bd5edc63cf06a4cff16b0d obsolete
 /etc/lirc/hardware.conf c07d8ba96f0df23488e1318dd95ff364 obsolete
 /etc/lirc/lircd.conf e5b59f3ea89c5c1fd838e506cec6cba0 obsolete
 /etc/lirc/lirc_options.conf d2664e84bab19f7f36628d1de3f273dd obsolete

You could potentially use

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;tag=obsolete-conffile;users=debian...@lists.debian.org#_4_3_5

OR/and

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;tag=obsolete-conffile;users=debian...@lists.debian.org#_4_4_5

All of the bugs which are resolved therein are the same obsolete
conffile issues.

Hope the above helps in getting the above fixed.

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

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

Versions of packages lirc depends on:
ii  init-system-helpers  1.46
ii  libasound2   1.1.2-1
ii  libc62.24-8
ii  libftdi1-2   1.3-2
ii  libgcc1  1:6.2.1-5
ii  liblirc-client0  0.9.4c-7
ii  liblirc0 0.9.4c-7
ii  libportaudio219.6.0-1
ii  libstdc++6   6.2.1-5
ii  libudev1 232-8
ii  libusb-0.1-4 2:0.1.12-30
ii  libusb-1.0-0 2:1.0.21-1
ii  lsb-base 9.20161125
ii  python3  3.5.1-4

lirc recommends no packages.

Versions of packages lirc suggests:
pn  ir-keytable  
pn  lirc-compat-remotes  
pn  lirc-doc 
pn  lirc-drv-irman   
pn  lirc-x   
pn  setserial

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

Bug#851163: Update

[Marc Fournier]

Thanks for reporting this issue !

According to your config file, you don't have the WriteQueueLimit{Low,High}
global options enabled. In the case where this issue would be caused by one
of the write plugins not being able to keep up with the data collection
rate, collectd would indeed buffer up values forever. So one lead would be
to set both of these options to the same value (for ex 5000) and observe
evolution of memory consumption over the same time range as without.

As you suggested, selectively disabling plugins could help narrowing down
which one is causing trouble *assuming the problem is in a plugin, not in
the core engine*. While doing this, try starting with the write plugins
(network, graphite and rrdtool) and consider setting a much lower global
Interval (such as 0.1 instead of the default 10). This should make the
memory allocation functions run more often, and the leak to happen faster.

The fact that this issue appears after upgrading from 5.6 is clearly
something that warrants investigation, thanks for your help !

Marc