Bug#836162: diversions for linkers need an update

[Niels Thykier]

Moritz Muehlenhoff:
> On Wed, Sep 14, 2016 at 10:03:51PM -0700, Kees Cook wrote:
>> On Thu, Sep 01, 2016 at 05:17:06PM +0200, Moritz Muehlenhoff wrote:
>>> I think we should remove hardening-wrapper for the stretch release? 
>>> dpkg-buildflags/dh
>>> are around for a long time now and we're down to about 50 reverse 
>>> dependencies at
>>> this point. Plus, lintian marks it as deprecated for quite a while now.
>>>
>>> Kees, what do you think?
>>
>> Yeah, it (and hardening-includes) should get removed in favor of
>> the dpkg-buildflags method.  However, this means we need to move the
>> "hardening-check" script from hardening-includes to lintian, probably.
> 
> hardening-wrapper has now been removed, so hardening-check needs a new
> home.
> 
> Adding the Lintian maintainers to CC, what's your opinion on merging it into
> lintian?
> 
> Cheers,
> Moritz
> 

Lintian has embedded the checks, but has not taken over the tool.

There were talk about putting the actual tool in devscritps, but I don't
know what happened with that.  That said, I do not feel the tool fits
into lintian - at least not with lintian current design.

Thanks,
~Niels

Bug#836990: libcamitk4: fails to upgrade from 'jessie' - trying to overwrite /usr/bin/camitk-config

[Emmanuel Promayon]

On 06/10/16 22:53, Adrian Bunk wrote:


Note that coninstallable implies either renaming /usr/bin/camitk-config,
or moving it to a libcamitk-bin package (depending on whether it is
specific for one libcamitk version or usable with all).


Yes, thank you Adrian. This was discussed and explained to me by Mattia 
on the debian-med-packaging mailing list (see [1] for example).
My intention is to add a new package "camitk-config" that just contains 
the binary, the man page and the pixmap.


Everything was just commited to git.
I am testing it at the moment and if everything is alright, I will ask 
for an upload very soon.


Kind regards,
Emmanuel


[1] 
http://lists.alioth.debian.org/pipermail/debian-med-packaging/2016-October/046452.html




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#839985: bluetooth: cannot receive files from android 5.1.1 / no obvious idea how to send

[Fulano Diego Perez]

Package: bluetooth
Version: 5.36-1
Severity: normal




Oct 07 15:10:36 local bluetoothd[23051]: Bluetooth daemon 5.36
Oct 07 15:10:36 local bluetoothd[23051]: Starting SDP server
Oct 07 15:10:36 local bluetoothd[23051]: Bluetooth management interface 1.12
initialized
Oct 07 15:10:36 local bluetoothd[23051]: Failed to obtain handles for
"Service
Changed" characteristic
Oct 07 15:10:36 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:10:36 local bluetoothd[23051]: Error adding Link Loss service
Oct 07 15:10:36 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:10:36 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:10:36 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:10:36 local bluetoothd[23051]: Current Time Service could not be
registered
Oct 07 15:10:36 local bluetoothd[23051]: gatt-time-server: Input/output
error
(5)
Oct 07 15:10:36 local bluetoothd[23051]: Bluetooth daemon 5.36
Oct 07 15:10:36 local bluetoothd[23051]: Starting SDP server
Oct 07 15:10:36 local bluetoothd[23051]: Bluetooth management interface 1.12
initialized
Oct 07 15:10:36 local bluetoothd[23051]: Failed to obtain handles for
"Service
Changed" characteristic
Oct 07 15:10:36 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:10:36 local bluetoothd[23051]: Error adding Link Loss service
Oct 07 15:10:36 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:10:36 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:10:36 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:10:36 local bluetoothd[23051]: Current Time Service could not be
registered
Oct 07 15:10:36 local bluetoothd[23051]: gatt-time-server: Input/output
error
(5)
Oct 07 15:10:36 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:10:36 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:10:36 local bluetoothd[23051]: Sap driver initialization failed.
Oct 07 15:10:36 local bluetoothd[23051]: sap-server: Operation not permitted
(1)
Oct 07 15:10:36 local bluetoothd[23051]: Endpoint registered: sender=:1.27
path=/MediaEndpoint/A2DPSource
Oct 07 15:10:36 local bluetoothd[23051]: Endpoint registered: sender=:1.27
path=/MediaEndpoint/A2DPSink
Oct 07 15:10:40 local bluetoothd[23051]: Failed to set mode: Busy (0x0a)
Oct 07 15:10:40 local bluetoothd[23051]: Failed to set mode: Busy (0x0a)
Oct 07 15:10:40 local bluetoothd[23051]: Failed to set mode: Busy (0x0a)
Oct 07 15:12:11 local bluetoothd[23051]: Failed to set mode: Failed (0x03)
Oct 07 15:14:47 local bluetoothd[23051]: connect error: Connection reset by
peer (104)
Oct 07 15:15:29 local bluetoothd[23051]: connect error: Connection refused
(111)
Oct 07 15:19:03 local bluetoothd[23051]: Unable to get io data for
Object Push:
getpeername: Transport endpoint is not connected (107)
Oct 07 15:20:55 local bluetoothd[23051]: Unable to get io data for
Object Push:
getpeername: Transport endpoint is not connected (107)
Oct 07 15:21:08 local bluetoothd[23051]:  connected
Oct 07 15:22:04 local bluetoothd[23051]: bnep0 disconnected
Oct 07 15:22:53 local bluetoothd[23051]: Unable to get io data for
Object Push:
getpeername: Transport endpoint is not connected (107)
Oct 07 15:29:12 local bluetoothd[23051]: Endpoint unregistered: sender=:1.27
path=/MediaEndpoint/A2DPSource
Oct 07 15:29:12 local bluetoothd[23051]: Endpoint unregistered: sender=:1.27
path=/MediaEndpoint/A2DPSink
Oct 07 15:29:22 local bluetoothd[23051]: Failed to obtain handles for
"Service
Changed" characteristic
Oct 07 15:29:22 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:29:22 local bluetoothd[23051]: Error adding Link Loss service
Oct 07 15:29:22 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:29:22 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:29:22 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:29:22 local bluetoothd[23051]: Current Time Service could not be
registered
Oct 07 15:29:22 local bluetoothd[23051]: gatt-time-server: Input/output
error
(5)
Oct 07 15:29:22 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:29:22 local bluetoothd[23051]: Not enough free handles to register
service
Oct 07 15:29:22 local bluetoothd[23051]: Sap driver initialization failed.
Oct 07 15:29:22 local bluetoothd[23051]: sap-server: Operation not permitted
(1)
Oct 07 15:29:22 local bluetoothd[23051]: Endpoint registered: sender=:1.27
path=/MediaEndpoint/A2DPSource
Oct 07 15:29:22 local bluetoothd[23051]: Endpoint registered: sender=:1.27
path=/MediaEndpoint/A2DPSink
Oct 07 15:37:07 local bluetoothd[23051]: Failed to set mode: Busy (0x0a)
Oct 07 15:37:28 local bluetoothd[23051]: Unable to get io data for
Object Push:
getpeername: Transport endpoint is not 

Bug#838017: closed by Thomas Goirand <z...@debian.org> (This was fixed in version 2.5.0)

[Salvatore Bonaccorso]

Control: fixed -1 2.5.1-0

Hi Thomas,

On Thu, Oct 06, 2016 at 05:15:07PM +, Debian Bug Tracking System wrote:
> This was fixed in version 2.5.0, which I uploaded to Sid.

That's not true AFAICT, since I did check as well 2.5.0-1 when it was
in experimental and it did not contain the patch. The patch though seems
included in 2.5.1 (wich is now as well in unstable).

Regards,
Salvatore

Bug#833893: (network-manager: wifi hot spot w/ dnsmasq conflicts unbound/dns requests)

[Fulano Diego Perez]

still very buggy and not working - tested in gnome 3.22.0

see enclosure for logs

can you confirm hotspot tested and working ?

MACS scrubbed
Oct  7 14:55:53 local kernel: [25123.983038] ath9k_htc 3-2:1.0 : renamed from 
wlan0
Oct  7 14:55:53 local NetworkManager[897]:   [1475812553.8338] device 
(wlan0): interface index 7 renamed iface from 'wlan0' to ''
Oct  7 14:55:53 local NetworkManager[897]:   [1475812553.8400] devices 
added (path: /sys/devices/pci:00/:00:14.0/usb3/3-2/3-2:1.0/net/, iface: 
)
Oct  7 14:55:53 local NetworkManager[897]:   [1475812553.8400] device 
added (path: /sys/devices/pci:00/:00:14.0/usb3/3-2/3-2:1.0/net/, iface: 
): no ifupdown configuration found.
Oct  7 14:55:53 local NetworkManager[897]:   [1475812553.8401] device (): 
state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Oct  7 14:55:53 local NetworkManager[897]:   [1475812553.8406] (): using 
nl80211 for WiFi device control
Oct  7 14:55:53 local NetworkManager[897]:   [1475812553.8409] device (): 
set-hw-addr: set MAC address to  (scanning)
Oct  7 14:55:53 local kernel: [25124.017185] IPv6: ADDRCONF(NETDEV_UP): : link 
is not ready
Oct  7 14:56:04 local kernel: [25135.004049] IPv6: ADDRCONF(NETDEV_UP): : link 
is not ready
Oct  7 14:56:04 local NetworkManager[897]:   [1475812564.8672] 
sup-iface[0x1cbf7a0,]: supports 4 scan SSIDs
Oct  7 14:56:04 local NetworkManager[897]:   [1475812564.8679] device (): 
supplicant interface state: starting -> ready
Oct  7 14:56:04 local NetworkManager[897]:   [1475812564.8680] device (): 
state change: unavailable -> disconnected (reason 'supplicant-available') [20 
30 42]
Oct  7 14:56:04 local kernel: [25135.044220] IPv6: ADDRCONF(NETDEV_UP): : link 
is not ready
Oct  7 14:56:06 local NetworkManager[897]:   [1475812566.0580] device (): 
supplicant interface state: ready -> inactive
Oct  7 14:56:22 local NetworkManager[897]:   [1475812582.6971] device (): 
Activation: starting connection 'Hotspot' (55e423b2-c80c-41ca-a325-b4f8f4b94298)
Oct  7 14:56:22 local NetworkManager[897]:   [1475812582.6976] device (): 
state change: disconnected -> prepare (reason 'none') [30 40 0]
Oct  7 14:56:22 local NetworkManager[897]:   [1475812582.7270] device (): 
set-hw-addr: set-cloned MAC address to  (permanent)
Oct  7 14:56:22 local kernel: [25153.113271] IPv6: ADDRCONF(NETDEV_UP): : link 
is not ready
Oct  7 14:56:22 local NetworkManager[897]:   [1475812582.9419] device (): 
state change: prepare -> config (reason 'none') [40 50 0]
Oct  7 14:56:22 local NetworkManager[897]:   [1475812582.9421] device (): 
Activation: (wifi) access point 'Hotspot' has security, but secrets are 
required.
Oct  7 14:56:22 local NetworkManager[897]:   [1475812582.9422] device (): 
state change: config -> need-auth (reason 'none') [50 60 0]
Oct  7 14:56:22 local NetworkManager[897]:   [1475812582.9474] device (): 
state change: need-auth -> prepare (reason 'none') [60 40 0]
Oct  7 14:56:22 local NetworkManager[897]:   [1475812582.9487] device (): 
state change: prepare -> config (reason 'none') [40 50 0]
Oct  7 14:56:22 local NetworkManager[897]:   [1475812582.9491] device (): 
Activation: (wifi) connection 'Hotspot' has security, and secrets exist.  No 
new secrets needed.
Oct  7 14:56:22 local NetworkManager[897]:   [1475812582.9836] 
sup-iface[0x1cbf7a0,]: config: set interface ap_scan to 2
Oct  7 14:56:23 local kernel: [25153.410747] IPv6: ADDRCONF(NETDEV_UP): : link 
is not ready
Oct  7 14:56:23 local wpa_supplicant[1128]: Using interface  with hwaddr  and 
ssid "local"
Oct  7 14:56:23 local kernel: [25153.620587] IPv6: ADDRCONF(NETDEV_CHANGE): : 
link becomes ready
Oct  7 14:56:23 local wpa_supplicant[1128]: : interface state 
UNINITIALIZED->ENABLED
Oct  7 14:56:23 local wpa_supplicant[1128]: : AP-ENABLED
Oct  7 14:56:23 local wpa_supplicant[1128]: : CTRL-EVENT-CONNECTED - Connection 
to  completed [id=0 id_str=]
Oct  7 14:56:23 local NetworkManager[897]:   [1475812583.4633] device (): 
supplicant interface state: inactive -> completed
Oct  7 14:56:23 local NetworkManager[897]:   [1475812583.4634] device (): 
Activation: (wifi) Stage 2 of 5 (Device Configure) successful.  Started Wi-Fi 
Hotspot 'local'.
Oct  7 14:56:23 local NetworkManager[897]:   [1475812583.4635] device (): 
state change: config -> ip-config (reason 'none') [50 70 0]
Oct  7 14:56:23 local avahi-daemon[886]: Joining mDNS multicast group on 
interface .IPv4 with address 10.42.0.1.
Oct  7 14:56:23 local avahi-daemon[886]: New relevant interface .IPv4 for mDNS.
Oct  7 14:56:23 local avahi-daemon[886]: Registering new address record for 
10.42.0.1 on .IPv4.
Oct  7 14:56:23 local NetworkManager[897]:   [1475812583.4914] Executing: 
/sbin/iptables --table filter --insert INPUT --in-interface  --protocol tcp 
--destination-port 53 --jump ACCEPT
Oct  7 14:56:23 local NetworkManager[897]:   [1475812583.4954] Executing: 
/sbin/iptables --table filter --insert INPUT --in-interface  --protocol udp 
--destination-port 53 --jump 

Bug#839885: developers-reference: reintroducing packages: update security issue metadata

[Salvatore Bonaccorso]

Hi Paul,

On Thu, Oct 06, 2016 at 01:13:34PM +0800, Paul Wise wrote:
> Package: developers-reference
> Severity: wishlist
> X-Debbugs-CC: secur...@debian.org
> 
> I would like to add a paragraph to the section about reintroducing
> packages so that people reintroducing packages check the security
> tracker metadata for the old package and update the metadata once it
> gets reintroduced to Debian.
> 
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs
> 
> I propose the following text, please wait for an ack from the security
> team before adding it to devref.
> 
> Package removals from unstable also trigger marking the package as
> removed in the security tracker. Debian members should [mark removed
> issues as unfixed][1] in the security tracker repository and all others
> should contact[2] the security team to report reintroduced packages.
> 
> 1. https://security-team.debian.org/security_tracker.html#removed-packages
> 2. https://security-tracker.debian.org/tracker/data/report

Thanks a lot for this wording suggestion; sounds good to me to have it
this way.

Regards,
Salvatore

Bug#839984: gunicorn3: Ancient Python code appeared in gunicorn/util.py file

[Russel Winder]

Package: gunicorn3
Version: 19.6.0-7
Severity: important

Dear Maintainer,

In the latest update to the gunicorn3 package there is ancient code that is not 
Python 3 compliant:


 gunicorn3
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up python3-gunicorn (19.6.0-7) ...
  File "/usr/lib/python3/dist-packages/gunicorn/util.py", line 179
except OSError, e:
  ^
SyntaxError: invalid syntax



The code should be:

except OSError as e:

and should be in the Python 2 version as well. The use of comma in this context 
has been removed from Python
for many, many versions.



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

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 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 gunicorn3 depends on:
ih  python3-gunicorn  19.6.0-7
pn  python3:any   

gunicorn3 recommends no packages.

Versions of packages gunicorn3 suggests:
pn  gunicorn-examples 
ii  python3-pastedeploy   1.5.2-4
pn  python3-setproctitle  
ii  python3-tornado   4.4.1-2

-- no debconf information

Bug#839214: missing build flags

[Jacob Adams]

Control: tags -1 + fixed-upstream

On 09/30/2016 04:03 AM, Daniel Pocock wrote:
> Package: sct
> 
> Version: 1.3-1
> 
> 
> I wanted to build the package on jessie but the build failed.
> 
> I had to add the following to the top of debian/rules:
> 
> 
> export CPPFLAGS = -std=c99
> 

I've added this flag to the upstream Makefile as of commit
5d349cdac7aa550920e72db4828f41e3fab6ef0f

I have one other thing I'd like to check before making another upstream
release.

> 
> and then it builds and runs on jessie.
> 
> I believe this package may be suitable for upload to jessie-backports
> after resolving this issue.
> 

I'd be happy to prepare a package for backports. I'll give it a shot
this weekend.

Thanks for using this package! I'm glad to know I'm not the only one :)

-- 
Jacob Adams
GPG Key: AF6B 1C26 E2D0 A988 432B  94F4 24C0 2B85 B59F E5A9



signature.asc
Description: OpenPGP digital signature

Bug#833491: Pending fixes for bugs in the golang-github-hlandau-goutils package

[pkg-go-maintainers]

tag 833491 + pending
thanks

Some bugs in the golang-github-hlandau-goutils package are closed in
revision 8f3e45e67c02aa9125d3bb4165cb2e8fdca1792d in branch 'master'
by Peter Colberg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hlandau-goutils.git/commit/?id=8f3e45e

Commit message:

Initial release

Closes: #833491

Bug#839981: Pending fixes for bugs in the golang-github-hlandau-dexlogconfig package

[pkg-go-maintainers]

tag 839981 + pending
thanks

Some bugs in the golang-github-hlandau-dexlogconfig package are
closed in revision 39fe0283620b28892edb6eaa9a6fb9004d0b7c06 in branch
'master' by Peter Colberg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hlandau-dexlogconfig.git/commit/?id=39fe028

Commit message:

Initial release

Closes: #839981

Bug#839938: [Pkg-utopia-maintainers] Bug#839938: Doesnt connect to server with this version (1.2.6-2, does with 1.2.4-1)

[Michael Biebl]

[please always CC 839...@bugs.debian.org]

Am 07.10.2016 um 03:43 schrieb data cruncher:
> Hi again
> 
> It didnt let me sleep, so i analyzed it further :)
> At last i found out why i didnt get any output, and found out that the
> problem is that
> with version 1.2.6-2 the chroot (/var/lib/openvpn/chroot) works (didnt
> with 1.2.4), so we have the (older) OpenSSL/chroot bug (/dev/urandom?).
> 
> Can be reproduced by removing access to the folder (therefore no chroot
> possible), the connection gets up.
> If we chroot successfully, the connection doesnt get up.
> 

Can you check the permissions via
getent passwd nm-openvpn
getent group nm-openvpn

ls -la /var/lib/openvpn/chroot/

Fwiw, I've tested 1.2.6-2 with a couple of OpenVPN servers and it works
fine here. So suspect something specific to either your system or your
OpenVPN configuration/that particular OpenVPN server.



-- 
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#836885: [Pkg-openldap-devel] Bug#836885: Bug#836885: please stop building against Heimdal

[Ryan Tandy]

Unfortunately, this isn't as easy as just removing the build-dep, 
because after upgrading:


57f71842 olcSmbK5PwdEnable: value #0: smbk5pwd:  module 
"olcSmbK5PwdEnable" only allowed when compiled with -DDO_KRB5.
57f71842 config error processing olcOverlay={0}smbk5pwd,olcDatabase={1}mdb,cn=config: 
 handler exited with 1

Looks like we'll have to remove "olcSmbK5PwdEnable: krb5" during 
upgrades.

Bug#839193: Still happening with 367.44

[Andreas Klöckner]

I just got bitten by this bug with the 367.44 drivers.

Andreas

Bug#839660: [Mlt-devel] Bug#839660: libmlt6: cannot load second LADSPA plugin

[Dan Dennedy]

Yes, thank you. I applied a very slightly modified version of this patch.

Bug#812611: Install on Orange Pi Plus eMMC work but no reboot

[Lennart Sorensen]

On Thu, Oct 06, 2016 at 11:28:07PM +0100, Ben Hutchings wrote:
> Is that actually controlled by straps, though?  For the TI SoC I've
> been working with recently, when the boot device is set to eMMC the ROM
> code will look for the SPL in:
> 
> 1. boot area
> 2. fixed offsets in main area
> 3. file named 'MLO' in first partition (MBR, FAT)
> 
> in that order.

When I read the documentation, that bit was rather incomplete, so I
don't know for sure.  I think you are right that it tries them all.

Certainly the support for GPT and ext2 were not in the documentation
and was determined by giving it a try and being surprised it worked,
which the TI people then confirmed.  So MLO can be on FAT or ext2
partition with that partition being on an MBR or GPT setup.

I prefer the boot area (and is what the product I worked on uses), with
option 3 being my second choice;  I do not like option 2 at all since
it is incompatible with GPT.

-- 
Len Sorensen

Bug#839983: deluged: Deluged can't boot with ssl trackers with python-openssl 16.1.0

[Len Sorensen]

Package: deluged
Version: 1.3.12-1
Severity: normal

When I start deluged and some of my active torrents use https to connect
to the tracker, deluged hangs.  Deleting the torrent from the state
files allows deluged to start, and adding the same torrent after it
starts works fine.

Downgrading python-openssl to version 16.0.0-2 makes the problem go away,
so something incompatible has changed.

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

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

Versions of packages deluged depends on:
ii  adduser3.115
ii  deluge-common  1.3.12-1
ii  lsb-base   9.20160629
ii  python-libtorrent  1.1.0-3
pn  python:any 

deluged recommends no packages.

deluged suggests no packages.

-- debconf-show failed

Bug#839982: axi-cache: xapian.FeatureUnavailableError: Flint backend no longer supported

[Paul Wise]

Package: apt-xapian-index
Version: 0.48
Severity: serious
File: /usr/bin/axi-cache
Justification: broken

axi-cache search no longer works because of the recent python-xapian upgrade:

pabs@chianamo ~ $ axi-cache search test
Traceback (most recent call last):
  File "/usr/bin/axi-cache", line 846, in 
sys.exit(ui.perform())
  File "/usr/bin/axi-cache", line 841, in perform
return f(self.args)
  File "/usr/bin/axi-cache", line 530, in do_search
self.db = DB()
  File "/usr/bin/axi-cache", line 120, in __init__
self.db = xapian.Database(axi.XAPIANINDEX)
  File "/usr/lib/python2.7/dist-packages/xapian/__init__.py", line 7782, in 
__init__
_xapian.Database_swiginit(self, _xapian.new_Database(*args))
xapian.FeatureUnavailableError: Flint backend no longer supported

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages apt-xapian-index depends on:
ii  python-apt 1.1.0~beta5
ii  python-debian  0.1.29
ii  python-xapian  1.4.0-7
pn  python:any 

apt-xapian-index recommends no packages.

Versions of packages apt-xapian-index suggests:
ii  python-xdg  0.25-4

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#839981: Pending fixes for bugs in the golang-github-hlandau-dexlogconfig package

[pkg-go-maintainers]

tag 839981 + pending
thanks

Some bugs in the golang-github-hlandau-dexlogconfig package are
closed in revision 0488ca454333c59b04055e2f938dbba639fd6282 in branch
'master' by Peter Colberg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hlandau-dexlogconfig.git/commit/?id=0488ca4

Commit message:

Initial release

Closes: #839981

Bug#839980: Pending fixes for bugs in the golang-github-hlandau-buildinfo package

[pkg-go-maintainers]

tag 839980 + pending
thanks

Some bugs in the golang-github-hlandau-buildinfo package are closed
in revision dfe303a2abbd6edd105a39110c9e8c4520cafd71 in branch
'master' by Peter Colberg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hlandau-buildinfo.git/commit/?id=dfe303a

Commit message:

Initial release

Closes: #839980

Bug#833491: Pending fixes for bugs in the golang-github-hlandau-goutils package

[pkg-go-maintainers]

tag 833491 + pending
thanks

Some bugs in the golang-github-hlandau-goutils package are closed in
revision d1a32ef75003658f14c8544b3ddfa8ac2af0da39 in branch 'master'
by Peter Colberg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hlandau-goutils.git/commit/?id=d1a32ef

Commit message:

Initial release

Closes: #833491

Bug#839981: ITP: golang-github-hlandau-dexlogconfig -- logging configuration package for Go

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-hlandau-dexlogconfig
  Version : 0.0~git20160722.0.055e2e3
  Upstream Author : Hugo Landau
* URL : https://github.com/hlandau/dexlogconfig
* License : Expat
  Programming Lang: Go
  Description : logging configuration package for Go

This is a policy package to configure the xlog package by the same author.

This package is a prerequisite for acmetool (>= 0.0.58-1).

Bug#839980: ITP: golang-github-hlandau-buildinfo -- Go build information utilities

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-hlandau-buildinfo
  Version : 0.0~git20160722.0.b25d4b0
  Upstream Author : Hugo Landau
* URL : https://github.com/hlandau/buildinfo
* License : Expat
  Programming Lang: Go
  Description : Go build information utilities

This package provides small build information utilities for tracking Go binary
version information. Rather than trying to assign a linear version number to
a binary, the tag names and version control commit hashes of all dependencies
are tracked. This information is embedded into the binary at build time.

This package is a prerequisite for acmetool (>= 0.0.58-1).

Bug#839978: exim4: Potential backdoor'ed D-H groups in use by Exim4?

[Theodore Y. Ts'o]

Source: exim4
Severity: important

>From a recent discussion on IETF's Security Area Advisory Group:

Date: Thu, 6 Oct 2016 08:56:45 -0700
From: Watson Ladd 
To: "s...@ietf.org" 
Subject: [saag] Possible backdoor in RFC 5114

https://tools.ietf.org/html/rfc5114

Let's review some publicly known facts:

1) BBN is a defense contractor

2) The NSA subverts crypto standards

3) It is possible to design primes so the discrete log problem is easy

4) The primes in RFC 5114 are not generated in verifiable manner: it
is possible they are hidden SNFS primes.

At minimum we should obsolete RFC 5114 in favor of primes generated in
a verifiable manner. The fact that there already were primes for IKE
use makes me wonder why this was even needed in the first place.

-

Date: Thu, 6 Oct 2016 17:15:29 +
From: Viktor Dukhovni 
To: s...@ietf.org
Subject: Re: [saag] Possible backdoor in RFC 5114

On Thu, Oct 06, 2016 at 07:28:57PM +0300, Yoav Nir wrote:

> > At minimum we should obsolete RFC 5114 in favor of primes generated in
> > a verifiable manner. The fact that there already were primes for IKE
> > use makes me wonder why this was even needed in the first place.
> > 
>
> RFC 5114 is an Informational document published by two employees (at the
> time) of BBN as individuals. As the boilerplate says, �it does not specify
> an Internet standard of any kind�.
> 
> IANA numbers have been assigned to them for IKE, but they have not seen
> widespread use.  In TLS they are all but unknown, and recent work is
> deprecating the use of DHE with explicit parameters anyway.

Sadly, their use was facilitated by support for these groups being
added in OpenSSL 1.0.2, making it easier for users to stumble into
using them.  Thus, for example, these are in use in Exim, likely
because it seemed more convenient to use "standard" groups, than
to ask users to generate their own DH parameters, and "they're in
an RFC, so they must be better than just random...".


http://www.exim.org/exim-html-current/doc/html/spec_html/ch-main_configuration.html#SECTalomo
[ scroll down to the entry for tls_dhparams ]

If Exim is using OpenSSL and this option is empty or unset,
then Exim will load a default DH prime; the default is the 2048
bit prime described in section 2.2 of RFC 5114, "2048-bit MODP
Group with 224-bit Prime Order Subgroup", which in IKE is
assigned number 23.

Otherwise, the option must expand to the name used by Exim for
any of a number of DH primes specified in RFC 2409, RFC 3526
and RFC 5114. As names, Exim uses "ike" followed by the number
used by IKE, of "default" which corresponds to "ike23".

The available primes are: ike1, ike2, ike5, ike14, ike15, ike16,
ike17, ike18, ike22, ike23 (aka default) and ike24.

Fortunately for some, the Postfix compiled-in default DHE parameters
use SG primes (that I generated in the usual way), but users are
encouraged to use their own.

http://www.postfix.org/FORWARD_SECRECY_README.html



Please consider disabling the Diffie-Hellman primes specified in RFC
5114 in Exim.

Thanks!!



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

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

Bug#839979: evolution: In HTML mode, deleting the sole character of a line via BACKSPACE moves the cursor to the end of the message

[Pavel N. Krivitsky]

Package: evolution
Version: 3.22.0-2
Severity: normal
Tags: upstream

Forwarded-To: https://bugzilla.gnome.org/show_bug.cgi?id=772542

Steps to reproduce:

1. Start Evolution and configure an account.
2. In the E-Mail view, click New to start composing a new message.
3. If not already in HTML mode, switch from Plain Text to HTML mode.
4. Type two lines of text, e.g.,

a
b

5. Move the cursor to the end of the first line (after "a").
6. Delete the contents of the first line either by pressing BACKSPACE or by
pressing CTRL-BACKSPACE.

Expected result:

Contents of the first line ("a") are deleted, with the cursor now at the
beginning of the (now empty) first line.

Observed result:

Contents of the first line ("a") are deleted, with the cursor jumping to the
end of the message (after "b").

Other notes:

The bug is not triggered by DELETE.

It is not triggered if the line still has text on it (after the cursor) either.
For example, starting with text

ab
cd

putting the cursor after "a" and pressing BACKSPACE does not cause it to jump
to the end, nor does putting it before "c" and pressing BACKSPACE. However, the
bug is triggered regardless of whether the line is the first line in the
message. For example, starting with

a
b
c

and BACKSPACE-ing "b" does cause the cursor to jump to after "c".



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

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

Versions of packages evolution depends on:
ii  dbus   1.10.10-1
ii  evolution-common   3.22.0-2
ii  evolution-data-server  3.22.0-2
ii  libc6  2.24-3
ii  libcamel-1.2-593.22.0-2
ii  libclutter-gtk-1.0-0   1.8.2-1
ii  libecal-1.2-19 3.22.0-2
ii  libedataserver-1.2-22  3.22.0-2
ii  libevolution   3.22.0-2
ii  libglib2.0-0   2.50.0-1
ii  libgtk-3-0 3.22.0-1
ii  libical2   2.0.0-0.5+b1
ii  libicu57   57.1-4
ii  libnotify4 0.7.6-2
ii  libsoup2.4-1   2.56.0-1
ii  libwebkit2gtk-4.0-37   2.14.0-1
ii  libxml22.9.4+dfsg1-2
ii  psmisc 22.21-2.1+b1

Versions of packages evolution recommends:
ii  bogofilter 1.2.4+dfsg1-8
ii  evolution-plugins  3.22.0-2
ii  yelp   3.22.0-1

Versions of packages evolution suggests:
pn  evolution-ews   
ii  evolution-plugins-experimental  3.22.0-2
ii  gnupg   2.1.15-3
ii  network-manager 1.4.2-1

Bug#786433: NMU?

[Dan Mick]

Tollef, would NMU help you here?  I have a keen interest in getting this
fixed.

Bug#818232: Not really a Qt5 bug it seems

[Linus Lüssing]

On Sat, Aug 27, 2016 at 12:31:02PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> reassign 818232 src:qtbase-opensource-src
> forcemerge 814959 818232
> thanks
> 
> It seems this bug is solved with a newer version of TightVNC.

Hi Lisandro,

Sorry for the late reply now. Unfortunately, the issue is still
present for me, even with Qt 5.6.1 instead of 5.5.1 and a recent
tightvncserver (1.3.9-8).

As you suggested, I now tried a different VNC viewer. Switching
from xtightvncviewer (1.3.9-6.5) to krdc (4:4.14.1-1) does not
help, the same weird key swapping happens within krdc. 

While Qt5 applications think the "u-key" is an "m" for instance,
it looks correct in xev, here within xtightvncviewer:

~
KeyPress event, serial 26, synthetic NO, window 0x2c1,
root 0x25, subw 0x0, time 2631956143, (573,420), root:(574,421),
state 0x0, keycode 58 (keysym 0x75, u), same_screen YES,
XLookupString gives 1 bytes: (75) "u"
XmbLookupString gives 1 bytes: (75) "u"
XFilterEvent returns: False

KeyRelease event, serial 26, synthetic NO, window 0x2c1,
root 0x25, subw 0x0, time 2631956782, (573,420), root:(574,421),
state 0x0, keycode 58 (keysym 0x75, u), same_screen YES,
XLookupString gives 1 bytes: (75) "u"
XFilterEvent returns: False
~

Regards, Linus

Bug#839627: linux-image-4.7.0-1-amd64: kvm-clock provides unadjusted time

[Gedalya]

On 10/06/2016 08:55 PM, Ben Hutchings wrote:



Presumably you consider the behaviour on 4.6/4.7 to be undesirable.

 From what I can see, the host side may attempt to keep the pvclock
synchronised with its real time but it is not recommended for guests to
rely on this.


It looked like an interesting change in behavior. From what I've read on 
this

topic, I know enough to always run ntpd in virtual machines, including KVM.


check that the host is sending clock updates to the guest.


# cat /sys/module/kvm/parameters/kvmclock_periodic_sync
Y

# cat trace_pipe
kworker/0:47-13195 [000]  387173.146166: kvmclock_update_fn 
<-process_one_work
kworker/0:47-13195 [000]  387173.146174: kvmclock_update_fn 
<-process_one_work
kworker/0:47-13195 [000]  387175.194257: kvmclock_update_fn 
<-process_one_work
   kworker/2:126-13231 [002]  387175.194260: kvmclock_update_fn 
<-process_one_work
kworker/1:45-13244 [001]  387175.194263: kvmclock_update_fn 
<-process_one_work
   kworker/3:151-13105 [003]  387175.194265: kvmclock_update_fn 
<-process_one_work
kworker/0:47-13195 [000]  387474.198723: kvmclock_update_fn 
<-process_one_work
kworker/0:47-13195 [000]  387474.198735: kvmclock_update_fn 
<-process_one_work
kworker/1:45-13244 [001]  387476.246874: kvmclock_update_fn 
<-process_one_work
   kworker/3:151-13105 [003]  387476.246879: kvmclock_update_fn 
<-process_one_work
   kworker/2:126-13231 [002]  387476.246883: kvmclock_update_fn 
<-process_one_work
kworker/0:47-13195 [000]  387476.246884: kvmclock_update_fn 
<-process_one_work


Yet, the guests still seem to be getting the unadjusted time.


Thanks,

Gedalya

Bug#839246: linux-image-4.7.0-1-amd64: Graphic artifacts since upgrade to 4.7.0-1 with Intel HD4600

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 2016-09-30 at 17:51 +0200, helios wrote:
> Package: src:linux
> Version: 4.7.5-1
> Severity: important
> Tags: newcomer
> 
> Dear Maintainer,
> 
> Since upgrading to 4.7.0-1 I have random graphic artifacts.
> Sometimes they appear on the panel, sometimes in the windows. Sometimes they
> dissapear when I take a screenshot, sometimes not.
> 
> GPU: intel HD 4600.
> Example: https://i.imgur.com/ziZrEEK.png
> 
> 
> 
> -- Package-specific info:
> ** Version:
> > Linux version 4.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
> > 5.4.1 20160904 (Debian 5.4.1-2) ) #1 SMP Debian 4.7.5-1 (2016-09-26)
> 
> ** Command line:
> BOOT_IMAGE=/boot/vmlinuz-4.7.0-1-amd64 
> root=UUID=98cdeaa0-c24f-4e3b-b757-651b8caeb8b8 ro i915.enable_ppgtt=2 
> acpi_enforce_resources=lax quiet
[...]

What if you remove the i915.enable_ppgtt parameter?

Ben.

-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug



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

Bug#839627: linux-image-4.7.0-1-amd64: kvm-clock provides unadjusted time

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 2016-10-03 at 04:33 -0400, Gedalya wrote:
> Package: src:linux
> Version: 4.7.5-1
> Severity: normal
> 
> Dear Maintainer,
> 
> When booting the host with linux 3.16, it looks like kvm-clock
> provides guests with time as adjusted by ntpd.
[...]
> When booting with linux 4.6/4.7,
[...]
> ntpd measures on the guest the same drift as on the host.
> This gives me the impression that on the later kernels, kvm-clock
> provides a raw, unadjusted time.
> 
> 
> On this particular setup I have the host running a stratum-1 NTP
> server, hooked up to a GPS device.
> The guests sync against it and other servers.
> However I observe the same behavior on several other servers running
> in various locations.
> On those running linux 3.16, the guests' measured drift hovers around
> zero, and on those running 4.6 or 4.7, the drift is around the same
> as on the host.
[...]

Presumably you consider the behaviour on 4.6/4.7 to be undesirable.

From what I can see, the host side may attempt to keep the pvclock
synchronised with its real time but it is not recommended for guests to
rely on this.  This synchronisation is now optional and controlled by
the kvmclock_periodic_sync module parameter, *but* it defaults to Y so
I don't see why the actual behaviour has changed.

First, check that this module parameter isn't somehow being turned off:

    cat /sys/module/kvm/parameters/kvmclock_periodic_sync

Assuming it's on, check that the host is sending clock updates to the
guest.  You can trace that by running the following commands in the
host as root, while the guest is running:

    cd /sys/kernel/debug/tracing
    echo function > current_tracer 
    echo kvmclock_update_fn > set_ftrace_filter
    echo 1 > tracing_on
    cat trace_pipe

The update interval is 5 minutes so you'll need to wait at least that
long to be sure it's not happening.  On my KVM host running 4.7 I saw
this after a few minutes:

     kworker/3:0-23291 [003]  360386.076593: kvmclock_update_fn 
<-process_one_work

Ben.

-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug


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

Bug#839977: apache2: please make the build reproducible (timestamps/timezones)

[Daniel Shahaf]

Package: apache2
Version: 2.4.23-5
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Dear Maintainer,

Following up on the following change in 2.4.23-5:

  * Tweak creation of .tar.gz embedded in preinst to get reproducible
build.

The build is not yet reproducible; a further tweak is required:

[[[
diff --git a/debian/rules b/debian/rules
index 5a96c95..800686e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -57,7 +57,7 @@ debian/fixup_conffiles.tgz: \
 debian/config-dir/mods-available/imagemap.load
@# mtime/owner/group/mode are for reproducible build
tar \
-   --mtime=2000-01-01T00:00 \
+   --mtime=2000-01-01T00:00Z \
--owner=root:0 \
--group=root:0 \
--mode=0644 \
]]]

Without this, the mtime is interpreted in the build environment's
timezone, causing irreproducibility.  (Another form of irreproducibility
in the package is the -fdebug-prefix-map in config.nice, but we'll fix
that globally in the reproducibility infrastructure.)

Thanks for making the package reproducible!

Cheers,

Daniel
('Z' here stands for the 'Zulu' timezone, i.e., UTC+0)

Bug#839976: O: hupnp

[Mark Purcell]

Package: wnpp
Severity: normal

Bug#838870: RFS: nbsphinx/0.2.9+ds-1 [ITP] -- Jupyter Notebook Tools for Sphinx

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

On 05/10/16 13:26, Frederic Bonnard wrote:
> Thanks Benoit/Ghislain,
> indeed with experimental archive it's much better :)
> 
> Benoit,
> my last point would be about privacy-breach-generic lintian.
> You overrided it with :
> --
> N: The involved links are meant to illustrate URL examples, so it is 
> meaningless
> N: to bring the involved material in a local folder.
> --
> 
> I agree that bringing stuff locally (as it is advised in the lintian
> description) is useless when the goal is to show the code for how to embed
> content of remote images/videos URLs.
> Though I still think there's a breach, as loading the documentation makes your
> browser connect to the internet, load images but also javascripts and so on, 
> which
> is originally the reason of this lintian definition (or let me know if I'm 
> wrong).
> Even if you point to DFSG-free ressources, you'll have your browser that will 
> still
> connect outside, and that's the issue in my understanding.
> 
> I've been thinking about this and reading your discussion with Paul Wise,
> I came to the following idea : why not changing after generation the html 
> (sed...) :
> 
> For images :
> ---
> -https://www.python.org/static/img/python-logo-large.png"/>
> +https://www.python.org/static/img/python-logo-large.png should be displayed, 
> but it got removed because of 
> https://lintian.debian.org/tags/privacy-breach-generic.html.;
> ---
> 
> and for the embedded video :
> 
> ---
>width="400"
>  height="300"
> -src="https://www.youtube.com/embed/WAikxUGbomY;
> +src="about:blank"
>  frameborder="0"
>  allowfullscreen
> +srcdoc="This video : https://www.youtube.com/embed/WAikxUGbomY should be 
> displayed, but it got removed because of 
> https://lintian.debian.org/tags/privacy-breach-generic.html.;
>  >
> ---
> 
> That way, you'll keep the source code example clean, and despite the fact the 
> html
> is modified, the user reading the documentation will still understand the 
> example, what
> it should do, what is displayed and altered and why.
> Ok the documentation html code is modified but the goal of the doc is to get
> the idea of the use (source code) and visual result (rather than html output 
> that got modified)
> I also thought of playing with Content-Security-Policy in  of the 
> document to block
> all outside connections but, I'm not sure all browser implement this 
> correctly.
> It's also less understable for the reader to understand why things 
> disappeared (except
> if this "framework" have information facilities). But it would be very good 
> to fix
> all the privacy-breach-generic in a general manner.


When I wrote the lintian override, I have in mind beside the HTML output the 
ipynb input,
only the former is taken into account by lintian.
Meanwhile, I relized that lintian was not able to point out an audio 
privacy-breatch..

Anyway, I brought the suggested material. The hard part was the refreshment of 
the debian/copyright file:
it is getting large.

I hope the package is fine now.

Thanks,
Jerome



> 
> 
> F.
> 

- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJX9uUQAAoJED+SGaZ/NsaL7W8f/i7CCIYZzleqbHqaCn1Hhz7V
rCfXDVGuIfVsYoRQrFZX/w7DMOX6teiwwlOTiD4kwZc8YcwX+4E+ZkaHx4zCvqii
QqFIXUWiVgJ+Z0+ZMdMi1X+ef708K5M/92iAKWBPFp6F2Kri7qJQsTwkrsVRMt7k
RaldggeFiNTJfKqZFp6kLlh8acSFHOdccQ8/EAnBUT1Uz6xByWRofl1JA09zncZ/
4U7SaOH6p9Cfa3xa9SAN++BFDmOMjJ/J6NlJ6ieXg9+LV213l7WbU/hxD+YANtRu
hICHZhvTNmX66S95nZKuPqCwla+CIEByO9p/973ocrrtQPktdyg+b8AV0vrkkxDA
JmBxKiR3rwQs9oaN7er9zj2H97jMMJhH5THBbdWxXTSAAE645+x9G7M8sIq3CAxB
feTaaXVElye8sKAU4PyI9smJrHs8GBKxmBWzf3hwsc+f11FjT7vgnt3NRTLs5oFH
xN2xy/tvWAucnJXH7he7fJ+M9yh7jDidXlhS5NbzNrB5JeUdWkZL4mUGKS7sloXh
KsGzaQ3OyaILpq4o79KGzl0vvYpxGLngTOlb+IITqsZVEVIwcW9CN4mr9bH7hLKt
vzn9mEteOG3nADvQdUaBmJveuT5TcsHLE87rofCCjyo5LXzdzC0Ydtiph9UfDNX+
pxBoEC/gCDSgEzQXSWGCbpkme3ZOlC1HK6vvp3g9lmoK0PO+a3yXvuxb+L36ixxL
esWs92+kZUjPVcECdj7/cbGQIXxmMwUrBMmDB4qcjvlCt1KX0fyykFRgBGLINK3z
MOtAX/WhLoWbLDiZDSwZQxdq5AafSOQKOV03feOjlTwS2/BHYGEHedRTaHWPI56o
lavs3dlTqsEngb5U5mL6qwMWEJXD3tTDccH72+ZwTzIHtnZ/t0XdcXd4aeMOWXGY
6rwkoGo4xaqDsCCzEeE86gJFWgT4qyOuKtg+Z9TvUg206W+FpGNeHl8UhuRra7dc
e/sZ+lMEo9N8X4VIj/xNzh4JFFxSnjTERXWw64FgyXZwW/PKx2PzTZ2U/mw1yEXz
emsJjnTom+MYCA0lgmx1n5lTSB40I3Z7C0Wyz9sUBXmOA3rXND5GfqiFHnmuoQmV
LBrLscpjQumCjDGkIOy8gw6CUTRsAKYP/8+Co0pxqkKyygM80FG3myOuMsTtox4+
HJ3IKKXMufFFloebFSVOgwt6N5HsmoQP30iz6mLdRWzpJVPP/Fehe4DjoER8XcJK
toICHz2XahUGW2yVtam7BF0AbqtOMEsfW/TN+SGiOTxtcrwV9ANnNwWrn/0m6ssH
F1xkL4M91HwwWl/uPoRF9jUsHgotxWbdvaTamDokMCzxseiDPVHzUPEHPMcsSc8=
=6IoF
-END PGP SIGNATURE-

Bug#839882: amd64-microcode recommends dracut or initramfs-tools only

[Henrique de Moraes Holschuh]

tag 839882 + confirmed
severity 839882 normal
retitle 839882 amd64-microcode: please accept tiny-initramfs for recommends
thanks

On Thu, 06 Oct 2016, Ricardo Fabian Peliquero wrote:
> On Thu, Oct 06, 2016 at 03:21:16PM -0300, Henrique de Moraes Holschuh wrote:
> > On Thu, 06 Oct 2016, Ricardo Fabian Peliquero wrote:
> > > On Thu, Oct 06, 2016 at 08:13:33AM -0300, Henrique de Moraes Holschuh
> > >   wrote:
> > > > On Thu, 06 Oct 2016, Ricardo Fabian Peliquero wrote:
> > > > > amd64-microcode recommends dracut or initramfs-tools. Please
> > > > > consider recommending virtual package linux-initramfs-tool
> > > > > instead. That way, it would include any of these packages: dracut,
> > > > > initramfs-tools or tiny-initramfs.
> > > > 
> > > > Have you checked whether tiny-initramfs works for amd64-microcode?
> > > 
> > > Both packages are installed, and tiny-initramfs is working well on my
> > > system (needless to say that neither dracut nor initramfs-tools are
> > > installed here). Please let me know if there is way to assure you that
> > > amd64-microcode is working as expected also.
> > 
> > Send me a copy of your initramfs image (directly, not ot the bug
> > report), or check in the kernel logs whether it is in fact
> > early-updating the microcode on your AMD processor or not...
> > 
> 
> I will send the image directly to your email address. Anyway, this is my 
> filtered dmesg's output:

I checked it, and it contains the necessary early-initramfs segment, so
it is working.

I will do as you requested and change the recommends line to something
that will also accept tiny-initramfs.  I will look into using the
linux-initramfs-tool virtual package, but alternatively I will add
tiny-initramfs directly to the recommends line.

-- 
  Henrique Holschuh

Bug#839973: O: smstools -- SMS server tools for GSM modems

[Mark Purcell]

Package: wnpp
Severity: normal

Bug#839972: O: mp3rename -- Rename mp3 files based on id3tags

[Mark Purcell]

Package: wnpp
Severity: normal

I intend to orphan the mp3rename package.

The package description is:
 works-with-format::mp3, works-with::audio

Bug#839974: O: twolame -- MPEG Audio Layer 2 encoder (command line frontend)

[Mark Purcell]

Package: wnpp
Severity: normal

I intend to orphan the twolame package.

The package description is:
 use::compressing, use::converting, works-with-format::mp3,
 works-with-format::wav, works-with::audio, works-with::file

Bug#839971: O: ipcheck -- Dyndns.org client to register your dynamic IP address

[Mark Purcell]

Package: wnpp
Severity: normal

I intend to orphan the ipcheck package.

The package description is:
 protocol::dns, protocol::http, protocol::ssl, role::program,
 scope::utility, use::configuring

Bug#839975: O: ivtv-utils -- utilities for use with the ivtv kernel driver

[Mark Purcell]

Package: wnpp
Severity: normal

Bug#839970: O: iog -- network I/O grapher

[Mark Purcell]

Package: wnpp
Severity: normal

I intend to orphan the iog package.

The package description is:
 role::program, scope::utility, use::monitor, works-with::image,
 works-with::image:vector

Bug#839967: O: bing -- Empirical stochastic bandwidth tester

[Mark Purcell]

Package: wnpp
Severity: normal

I intend to orphan the bing package.

The package description is:
 use::monitor, works-with::network-traffic

Bug#839966: O: atanks -- tank-battling game

[Mark Purcell]

Package: wnpp
Severity: normal

I intend to orphan the atanks package.

The package description is:
 uitoolkit::xlib, use::gameplaying, x11::application

Bug#839968: O: dvbstream -- Broadcast a DVB Transport stream over a LAN

[Mark Purcell]

Package: wnpp
Severity: normal

I intend to orphan the dvbstream package.

The package description is:
 use::transmission, works-with::video

Bug#839969: O: dvbtune -- Simple tuning application for DVB cards

[Mark Purcell]

Package: wnpp
Severity: normal

I intend to orphan the dvbtune package.

The package description is:
 scope::utility, use::configuring, use::driver

Bug#829059: php-guzzlehttp-ringphp: FTBFS: LaTeX Error: File `iftex.sty' not found.

[Nishanth Aravamudan]

Package: php-guzzlehttp-ringphp
Version: 1.1.0-2
Followup-For: Bug #829059
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/control: add explicit b-d on texlive-generic-extra for iftex.sty.
LP: #1631194.


Thanks for considering the patch.

*** /tmp/tmpcMI2d2/php-guzzlehttp-ringphp_1.1.0-2ubuntu2.debdiff
diff -Nru php-guzzlehttp-ringphp-1.1.0/debian/control 
php-guzzlehttp-ringphp-1.1.0/debian/control
--- php-guzzlehttp-ringphp-1.1.0/debian/control 2016-03-29 12:47:32.0 
-0700
+++ php-guzzlehttp-ringphp-1.1.0/debian/control 2016-10-06 16:04:21.0 
-0700
@@ -16,6 +15,7 @@
python-sphinx (>= 1.3.1-3~),
python-sphinx-rtd-theme (>= 0.1.8-2~),
texlive-fonts-recommended,
+   texlive-generic-extra,
texlive-latex-base,
texlive-latex-extra,
texlive-latex-recommended


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

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

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Bug#825542: php-arc: FTBFS: Tests: 40, Assertions: 87, Errors: 5.

[Nishanth Aravamudan]

Package: php-arc
Version: 2.2.5-1
Followup-For: Bug #825542
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/pass_variable_by_reference.patch: PHP7 is strict
about passing by reference.  Closes LP: #1631190.


Thanks for considering the patch.

diff -Nru php-arc-2.2.5/debian/patches/pass_variable_by_reference.patch 
php-arc-2.2.5/debian/patches/pass_variable_by_reference.patch
--- php-arc-2.2.5/debian/patches/pass_variable_by_reference.patch   
1969-12-31 16:00:00.0 -0800
+++ php-arc-2.2.5/debian/patches/pass_variable_by_reference.patch   
2016-10-06 15:53:02.0 -0700
@@ -0,0 +1,16 @@
+Description: PHP7 is strict about passing by reference
+Author: Nishanth Aravamudan 
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1631190
+
+--- php-arc-2.2.5.orig/tests/unit/ARC2_ClassTest.php
 php-arc-2.2.5/tests/unit/ARC2_ClassTest.php
+@@ -6,7 +6,8 @@ require_once ARC2_DIR . '/ARC2_Class.php
+ class ARC2_ClassTest extends PHPUnit_Framework_TestCase {
+ 
+ public function setUp() {
+- $this->arc2 = new ARC2_Class(array(), new stdClass);
++ $obj = new stdClass;
++ $this->arc2 = new ARC2_Class(array(), $obj);
+ }
+ 
+ public function testCamelCase() {
diff -Nru php-arc-2.2.5/debian/patches/series 
php-arc-2.2.5/debian/patches/series
--- php-arc-2.2.5/debian/patches/series 1969-12-31 16:00:00.0 -0800
+++ php-arc-2.2.5/debian/patches/series 2016-10-06 15:52:36.0 -0700
@@ -0,0 +1 @@
+pass_variable_by_reference.patch


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

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

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Bug#817738: xsok: Removal of debhelper compat 4

[Markus Koschany]

Control: tags -1 pending

Dear maintainer,

I've uploaded an NMU for xsok versioned as 1.02-17.1. Please find
attached the debdiff.

Regards,

Markus


xsok.debdiff.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#787950: mdadm/checkarray: broken on current debian systems

[Dark Penguin]

The easiest fix for this is changing #!/bin/sh to #!/bin/bash in that 
file. And I believe it's the "correct" fix, because the shebang line is 
invented specifically to tell you which interpreter to use, so it you 
write a script for Bash, you should put Bash there, not Dash or whatever 
sh could be installed on that system. And I think Bash is installed by 
default on almost any system, exactly because a lot of scripts require 
specifically Bash to execute.


Changing only two letters in one file. To fix a grave-level bug that has 
been there for a year. In Debian STABLE. Is it too much to ask?..


By the way, how come this bug report is not "grave", but "normal"?! 
Going on without periodical scrubs is a direct way to lose all your 
data, which is, by definition, "grave", correct? And the bug affects 
100% of the users. All of them. Except maybe the ones who changed their 
default shell to Bash, which is hardly a lot.


Actually, I have a list of similar bugs in Jessie that are around for 
over a year, with extremely simple fixes (if you know about the bug in 
the first place). Because of this tendency to ignore such bugs, Debian 
Stable is now becoming the most unstable distro out there, effectively 
failing its only mission: "The goal of the Debian Project is Debian 
Stable" (I can't find the exact document on the Debian website in which 
I read this only yesterday).



--
darkpenguin

Bug#812611: Install on Orange Pi Plus eMMC work but no reboot

[Ben Hutchings]

On Thu, 2016-10-06 at 16:53 -0400, Lennart Sorensen wrote:
> On Thu, Oct 06, 2016 at 12:29:13PM -0700, Vagrant Cascadian wrote:
> > To make matters more complicated, there are definitely some boards
> > (Firefly, maybe BeagleBoard-X15) which can install the OS to eMMC,
> > but
> > u-boot still has to be loaded from SD card. I don't think we have
> > much
> > information on which boards those are. It may also vary from one u-
> > boot
> > version to the next...
> 
> 
> The BeagleBoard X15 has jumper settings to boot:
> 
> SD if present, otherwise eMMC
> UART
> SATA if present otherwise SD
> 
> I know the CPU for eMMC boot will boot u-boot from partition 1 with a
> given filename from either FAT or EXT2 filesystem, with either MBR or
> GPT partition table.  It will also boot from eMMC boot area.  I am
> not sure which one the X15 happens to be supporting when they say boot
> from eMMC.

Is that actually controlled by straps, though?  For the TI SoC I've
been working with recently, when the boot device is set to eMMC the ROM
code will look for the SPL in:

1. boot area
2. fixed offsets in main area
3. file named 'MLO' in first partition (MBR, FAT)

in that order.

Ben.

> Seems the jumpers are not installed howefver, and it would take
> soldering
> work to make it do anything other than the first option.
> 
> 
-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug

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

Bug#839927: jessie-pu: package rawtherapee/4.2-1+deb8u1

[Philip Rinn]

Sorry, I didn't attach the debdiff, it was only a 'git diff ...' Now I attached
the real debdiff.

Best,
Philip

diff -Nru rawtherapee-4.2/debian/changelog rawtherapee-4.2/debian/changelog
--- rawtherapee-4.2/debian/changelog2015-06-09 20:45:39.0 +0200
+++ rawtherapee-4.2/debian/changelog2016-10-06 12:36:00.0 +0200
@@ -1,3 +1,10 @@
+rawtherapee (4.2-1+deb8u2) jessie; urgency=high
+
+  * Add patch debian/patches/03-fix-overflow-in-dcraw.patch:
+- Fix buffer overflow in dcraw (CVE-2015-8366)
+
+ -- Philip Rinn   Thu, 06 Oct 2016 12:36:00 +0200
+
 rawtherapee (4.2-1+deb8u1) jessie; urgency=high
 
   * Add patch debian/patches/02-fix_CVE-2015-3885.patch:
diff -Nru rawtherapee-4.2/debian/patches/03-fix-overflow-in-dcraw.patch 
rawtherapee-4.2/debian/patches/03-fix-overflow-in-dcraw.patch
--- rawtherapee-4.2/debian/patches/03-fix-overflow-in-dcraw.patch   
1970-01-01 01:00:00.0 +0100
+++ rawtherapee-4.2/debian/patches/03-fix-overflow-in-dcraw.patch   
2016-10-06 12:35:26.0 +0200
@@ -0,0 +1,18 @@
+Author: Hubert Chathi 
+Description: Fix buffer overflow in dcraw (CVE-2015-8366)
+Origin: 
https://vcs.uhoreg.ca/git/cgit/debpkg-ufraw/commit/?id=54688b5896b39003becdfee3c803c58c94f14df3
+Last-update: 2016-10-06
+--- a/rtengine/dcraw.cc
 b/rtengine/dcraw.cc
+@@ -3221,7 +3221,10 @@
+   diff = diff ? -diff : 0x80;
+ if (ftell(ifp) + 12 >= seg[1][1])
+   diff = 0;
+-raw_image[pix] = pred[pix & 1] += diff;
++if(pix>=raw_width*raw_height)
++  derror();
++else
++  raw_image[pix] = pred[pix & 1] += diff;
+ if (!(pix & 1) && HOLE(pix / raw_width)) pix += 2;
+   }
+   maximum = 0xff;
diff -Nru rawtherapee-4.2/debian/patches/series 
rawtherapee-4.2/debian/patches/series
--- rawtherapee-4.2/debian/patches/series   2015-05-14 17:30:07.0 
+0200
+++ rawtherapee-4.2/debian/patches/series   2016-10-06 12:35:47.0 
+0200
@@ -1,2 +1,3 @@
 01-fix_build_race-condition.patch
 02-fix_CVE-2015-3885.patch
+03-fix-overflow-in-dcraw.patch


signature.asc
Description: OpenPGP digital signature

Bug#839686: forked-daapd: does not recreate stuff in /var/cache after deletion

[Bálint Réczey]

Hi Dominik,

2016-10-06 23:15 GMT+02:00 Dominik George :
> Hi,
>
>> IMO it is unreasonable to think that removing the whole
>> /var/cache/forked-daapd directory can be deleted and is expected to be
>> recreated because many services drop root privileges thus can't create
>> dirs in /var/cache:
>
>> In my interpretation of the FHS the _files_ can be removed and are
>> expected to be recreated, while _directory structures_ need to be kept
>> for applications to operate.
>
> I do not quite agree.
>
> The same would be true for /var/run, but there, the application or the
> init system is expected to create the relevant directories before
> dropping privileges.

/var/run is different, see very different wording in FHS.

http://www.pathname.com/fhs/2.2/fhs-5.13.html#FN37

5.13 /var/run : Run-time variable data

5.13.1 Purpose

This directory contains system information data describing the system
since it was booted. Files under this directory must be cleared
(removed or truncated as appropriate) at the beginning of the boot
process. Programs may have a subdirectory of /var/run; this is
encouraged for programs that use more than one run-time file.[footnote
37]

...

[37] /var/run should be unwritable for unprivileged users (root or
users running daemons); it is a major security problem if any user can
write in this directory. Process identifier (PID) files, which were
originally placed in /etc, must be placed in /var/run. The naming
convention for PID files is .pid. For example, the crond
PID file is named /var/run/crond.pid.

Cheers,
Balint

Bug#836772: pinentry fails when used from dedicated account via su -

[W. Martin Borgert]

Ramakrishnan, many thanks for your bug report. I came across the
same problem today, but with "sudo -i -u xxx" and under XFCE4,
not Gnome. So I just used your solution - login via VT.

Interestingly, after using gpg once from the VT (and the
gpg-agent process was still running after logging out from the
VT, not from within X11), gpg worked also in the sudo session
under X11.

Btw, Dan, I don't believe, that this setup is so unusual - or
I'm unusual :~)

Bug#839965: base: Imminent reboot on Sun X4140 servers on boot

[Dima Veselov]

Package: base
Severity: normal

Dear Maintainer,

Problem described here concern Debian Linux on Sun X4140 servers only.
I submit bugreport, because I have 2 of them rebooting on almost every boot and 
don't know how to dig the situation. I wish to help if got some instructions.

>From this side this works like that:

Sun X4140 with Opteron processors, Xen and bridge-utils, serial console. Also 
this server known to have Nvidia NCP55 chipset with forcedeth driver. If I boot 
it up - It reboot on words

Bridge firewalling registered.

The only way to pass this point - unplug network in boot time and plug it back 
after. Additional information about this behaviour:
1. Yesterday server was working fine. After configuring virtual machines and 
enlarging memory from 8 to 20 Gb it keeps rebooting every time. Same was for 
other one.
2. Installing debian 8.5.0 via PXE I got same reboots during kernel loading. 
Current debian installation succeeded.
3. Reboot happens even booting without hypervisor kernel also.
4. Other linuses work well - using these servers with OEL 6 and RHEL 6,7, all 
with forcedeth drivers.
5. There are several servers rebooting (debian 7 and 8), so this is not a 
hardware issue.
6. Firewall is off and i am confused about "Bridge firewalling registered".

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

Kernel: Linux 3.16.0-4-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)

Bug#839711: Updated sv.po for apt-listbugs

[Francesco Poli]

On Thu, 6 Oct 2016 16:28:50 +0200 Martin Bagge / brother wrote:

> On 2016-10-05 23:00, Francesco Poli wrote:
[...]
> > If you agree, I'll modify the translation as:
> > 
> >   msgstr ""
> >   "Ingen av ovanstående fel är relaterade till paket %s\n"
> >   "Är du säker på att du vill nåla det?"
> > 
> > Is this OK?
> 
> Yes please. Probably a fat finger problem. Thanks.

Done, thanks for confirming the correctness of the modification!   :-)

> 
> > Moreover:
[...]
> >   msgstr "taggar"
> > 
> > Is this OK?
> 
> Consistency would improve but it wouldn't make it more correct.
> "taggar" is mostly tech slang.
> 
> Change it to your proposal there.

Done, thanks for the explanation!   :-)

> We'll take the argument for another day and if I win we'll change all
> the occurrences to "etiketter" (more precise translation for "labels",
> could be a reason to have separate wordings for both tags and labels).

That's OK: in case you decide so, please just tell me which strings
have to be modified and how...

Thanks a lot, bye!


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


pgpNhdbo78ugk.pgp
Description: PGP signature

Bug#836162: diversions for linkers need an update

[Moritz Muehlenhoff]

On Wed, Sep 14, 2016 at 10:03:51PM -0700, Kees Cook wrote:
> On Thu, Sep 01, 2016 at 05:17:06PM +0200, Moritz Muehlenhoff wrote:
> > I think we should remove hardening-wrapper for the stretch release? 
> > dpkg-buildflags/dh
> > are around for a long time now and we're down to about 50 reverse 
> > dependencies at
> > this point. Plus, lintian marks it as deprecated for quite a while now.
> > 
> > Kees, what do you think?
> 
> Yeah, it (and hardening-includes) should get removed in favor of
> the dpkg-buildflags method.  However, this means we need to move the
> "hardening-check" script from hardening-includes to lintian, probably.

hardening-wrapper has now been removed, so hardening-check needs a new
home.

Adding the Lintian maintainers to CC, what's your opinion on merging it into
lintian?

Cheers,
Moritz

Bug#126505: reopen, closed by spam, please cleanup (was Re: Bug#126505: marked as done (dpkg-statoverride : add 'recursive', 'dirs', and 'files' options in rules-file))

[Holger Levsen]

control: reopen -1

On Wed, Oct 05, 2016 at 06:33:05PM +, Debian Bug Tracking System wrote:
> Date: Wed, 5 Oct 2016 20:30:35 +0200
> From: "FedEx 2Day A.M." 
> To: 126505-cl...@bugs.debian.org

closed by spam…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#839325: cobbler: FTBFS: dh_installman: failed to read cobbler.1.gz

[Chris Lamb]

tags 839325 + patch
thanks

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/setup.py b/setup.py
index 7c6510b..25eec99 100644
--- a/setup.py
+++ b/setup.py
@@ -307,7 +307,7 @@ class build_man(Command):
 # It is. Configure it
 self.build_one_file(infile, outfile)
 
-_COMMAND = 'pod2man --center="%s" --release="" %s | gzip -c > %s'
+_COMMAND = 'pod2man --center="%s" --release="%s" %s | gzip -c > %s'
 
 def build_one_file(self, infile, outfile):
 man = 
os.path.splitext(os.path.splitext(os.path.basename(infile))[0])[0]
@@ -318,7 +318,7 @@ class build_man(Command):
 if not os.path.exists(outdir):
 os.makedirs(outdir)
 # Now create the manpage
-cmd = build_man._COMMAND % ('man', infile, outfile )
+cmd = build_man._COMMAND % ('man', VERSION, infile, outfile )
 if os.system(cmd):
 log.announce("Creation of %s manpage failed." % man, log.ERROR)
 exit(1)

Bug#839884: [Pkg-utopia-maintainers] Bug#839884: network-manager: Confirmed here

[Michael Biebl]

Am 06.10.2016 um 21:42 schrieb Manuel Bilderbeek:
> Package: network-manager
> Version: 1.4.2-1
> Followup-For: Bug #839884
> 
> Dear Maintainer,
> 
> I also see the hangup:
> 
> Setting up libkf5widgetsaddons-data (5.26.0-1) ...
> Setting up network-manager (1.4.2-1) ...
> 
> and then nothing. ps -Af says:
> 
> root  4897  2663  0 21:35 pts/200:00:00 /usr/bin/dpkg --status-fd 80 
> --configure --pending
> root  4906  4897  0 21:35 pts/200:00:00 /bin/sh 
> /var/lib/dpkg/info/network-manager.postinst configure 1.4.0-4
> root  4972 1  0 21:35 ?00:00:00 /usr/sbin/NetworkManager 
> --no-daemon
> root  5060  4906  0 21:35 pts/200:00:00 /bin/systemctl try-restart 
> NetworkManager-dispatcher.service
> root  5061  5060  0 21:35 pts/200:00:00 
> /bin/systemd-tty-ask-password-agent --watch
> 

What's the output of systemctl status NetworkManager-dispatcher.service


-- 
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#839964: ITP: ace-window -- selecting a window to switch to

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: ace-window
  Version : 0.9.0
  Upstream Author : Oleh Krehel 
* URL : https://github.com/abo-abo/ace-window
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : selecting a window to switch to

The main function, `ace-window' is meant to replace `other-window'. In fact,
when there are only two windows present, `other-window' is called.  If there
are more, each window will have its first character highlighted.  Pressing
that character will switch to that window.

Bug#812611: Install on Orange Pi Plus eMMC work but no reboot

[Jean-Christian de Rivaz]

Le 06. 10. 16 à 21:29, Vagrant Cascadian a écrit :

I don't believe there is any code in debian-installer to install u-boot;
the installer did not install it. I don't believe there is any code
within all of Debian to install u-boot automatically (unless you count
SD image generation). It is at this point a manual process.


And this is the only missing operation still required to fully support 
Debian a board like the Orange Pi Plus.





Installing u-boot from within the debian-installer can be a
rather dangerous operation on many systems which is why the
installer doesn't try to do that yet.  The problem is that u-boot
isn't only a bootloader like GRUB but more like a PC BIOS and
nobody would expect the debian-installer to flash BIOS-updates on
a PC ;-).  There are quite a number of systems where writing
u-boot to internal storage going wrong completely bricks the
system, i.e the system is electronics garbage afterwards. Most
sunxi-based systems still have a way to trigger SD boot or FEL
boot as a way to manually restore the firmware, but not all of
them do, and on many non-sunxi-platforms a broken u-boot write is
completely unrecoverable except by unsoldering the flash or - if
one is lucky - by accessing it via JTAG, but both are methods
that are inaccessible for a normal user.

I understand, but the SD card image of the Debian installer is
specifically targeted for the Orange Pi Plus board so it can take
advantage of it.

While the SD card images can be used for recovery in many cases, it is
also possible that u-boot installed to eMMC fails in such a way that it
doesn't fall back to SD card, requiring a lot of effort to reset the
board. It depends entirely on the boot ROM of the board what order it
searches for the bootloader...


Not on that board. The H3 processor chip integrate a boot ROM that 
always first look at the SD card and then at the eMMC (unless forced 
into the special FEL mode). There is no way to break the ROM integrated 
into the processor chip. Take a look at http://linux-sunxi.org/BROM for 
the details.



Given that experience, I tend to strongly prefer installing u-boot on SD
card when possible, as you can easily remove the SD card and reinstall a
known-good u-boot from another machine.


This is exactly how the H3 boot ROM work already. You can write anything 
you want into the eMMC, there is absolutely no way to break the SD card 
boot from the CPU ROM. So there is no danger in writing the bootloader 
into the eMMC on that board. Writing the bootloader on the eMMC this is 
exactly what a user will expect while installing Debian into the eMMC.





I'll put looking into support for installing u-boot from within
the installer at least on certain systems onto my (unfortunately
already way too long) todo list, but that will surely take quite
some time. I'm also CCing Vagrant Cascadian, the Debian u-boot
maintainer for some further input on this topic.

Basically, it will require much of the same code as upgrading u-boot:

   https://bugs.debian.org/812611

Which has been on my todo list for quite some time with little activity.
Due to the risk of bricking, both fresh installation and upgrading of
u-boot should probably require some sort of opt-in process.


Knowing how to install u-boot on a particular set of boards is another
feature that's needed, although the SD-card image generation in
debian-installer is a good start for several boards.


To make matters more complicated, there are definitely some boards
(Firefly, maybe BeagleBoard-X15) which can install the OS to eMMC, but
u-boot still has to be loaded from SD card. I don't think we have much
information on which boards those are. It may also vary from one u-boot
version to the next...


So, in short, there are quite a few complications to take into
consideration. If someone can propose patches that take into account all
these issues quite soon, it *might* be feasible for stretch.


From a user point of view this would be a major achievement for the 
Debian armhf port that finally make some ARM boards as easy to install 
than a regular PC. Well, maybe even easier than the actual UEFI PC...


Regards,
Jean-Christian

Bug#837007: Fix for the xfce4-radio-plugin FTBFS

[Adrian Bunk]

Control: tags 837007 +patch

A fix for the xfce4-radio-plugin FTBFS is attached.

cu
Adrian

-- 

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

Description: Don't force C99 in panel-plugin/Makefile.am
 This makes timespec available for videodev2.h
Author: Adrian Bunk 
Bug-Debian: https://bugs.debian.org/837007

--- xfce4-radio-plugin-0.5.1.orig/panel-plugin/Makefile.am
+++ xfce4-radio-plugin-0.5.1/panel-plugin/Makefile.am
@@ -9,8 +9,7 @@ xfce4_radio_plugin_SOURCES =		\
 xfce4_radio_plugin_CFLAGS =		\
 	-DPACKAGE_LOCALE_DIR=\"$(localedir)\"\
 	@LIBXFCE4PANEL_CFLAGS@		\
-	@LIBXFCEGUI4_CFLAGS@		\
-	-std=c99
+	@LIBXFCEGUI4_CFLAGS@
 
 xfce4_radio_plugin_LDADD =		\
 	@LIBXFCE4PANEL_LIBS@		\

Bug#821051: [PATCH v2] byhand-code-sign: sign using another user

[Helen Koike]

---

Hi,

Thanks Jakub for your review.
I modified the script to read the .tar.xz from stdin and output the 
-sign.tar.xz to stdout.
It is also available here: https://github.com/helen-fornazier/dak

Changes since last version:
- add quotes around variables
- remove unnecessary chmod 700
- receive tar.xz from stdin in byhand-code-sign-user script
- generate the -sign.tar.xz to stdout in byhand-code-sign-user script

I would appreciate if someone could review this version
Thank you

Helen


 scripts/debian/byhand-code-sign  | 104 +---
 scripts/debian/byhand-code-sign-user | 135 +++
 scripts/debian/byhand-code-sign-user-exp |  17 
 3 files changed, 154 insertions(+), 102 deletions(-)
 create mode 100755 scripts/debian/byhand-code-sign-user
 create mode 100755 scripts/debian/byhand-code-sign-user-exp

diff --git a/scripts/debian/byhand-code-sign b/scripts/debian/byhand-code-sign
index fbd6855..18bd09e 100755
--- a/scripts/debian/byhand-code-sign
+++ b/scripts/debian/byhand-code-sign
@@ -20,8 +20,6 @@ error() {
exit 1
 }
 
-export OPENSSL_CONF=/dev/null
-
 # Read dak configuration for security or main archive.
 # Also determine subdirectory for the suite.
 case "$0" in
@@ -39,14 +37,6 @@ case "$0" in
 esac
 . "$configdir/vars"
 
-# Read and trivially validate our configuration
-. "$configdir/byhand-code-sign.conf"
-for var in EFI_BINARY_PRIVKEY EFI_BINARY_CERT \
-  LINUX_SIGNFILE LINUX_MODULE_PRIVKEY LINUX_MODULE_CERT; do
-   test -v $var || error "$var is not defined in configuration"
-   test -n "${!var}" || error "$var is empty in configuration"
-done
-
 TARGET="$ftpdir/dists/$suitedir/main/code-sign/"
 OUT_TARBALL="$TARGET/${IN_TARBALL##*/}"
 OUT_TARBALL="${OUT_TARBALL%.tar.xz}_sigs.tar.xz"
@@ -56,99 +46,9 @@ if [ -e "$OUT_TARBALL" ]; then
error "Signature tarball already exists: $OUT_TARBALL"
 fi
 
-# If we fail somewhere, cleanup the temporary directories
-IN_DIR=
-OUT_DIR=
-CERT_DIR=
-cleanup() {
-   for dir in "$IN_DIR" "$OUT_DIR" "$CERT_DIR"; do
-   test -z "$dir" || rm -rf "$dir"
-   done
-}
-trap cleanup EXIT
-
-# Extract the data into the input directory
-IN_DIR="$(mktemp -td byhand-code-sign-in.XX)"
-tar xaf "$IN_TARBALL" --directory="$IN_DIR"
-
-case "$EFI_BINARY_PRIVKEY" in
-pkcs11:*)
-   # Translate from OpenSSL PKCS#11 enigne syntax to pesign parameters
-   # See: 
https://sources.debian.net/src/engine-pkcs11/0.2.2-1/src/engine_pkcs11.c
-   pkcs11_pin_value=
-   old_IFS="$IFS"
-   IFS=';'
-   for kv in ${EFI_BINARY_PRIVKEY#pkcs11:}; do
-   case "$kv" in
-   token=*)
-   pkcs11_token="${kv#*=}"
-   ;;
-   object=*)
-   pkcs11_object="${kv#*=}"
-   ;;
-   pin-value=*)
-   pkcs11_pin_value="${kv#*=}"
-   ;;
-   esac
-   done
-   IFS="$old_IFS"
-   unset old_IFS
-   # TODO: unlock it
-   PESIGN_PARAMS=(-t "$pkcs11_token" -c "$pkcs11_object")
-   ;;
-*)
-   # Create certificate store for pesign
-   CERT_DIR="$(mktemp -td byhand-code-sign-cert.XX)"
-   chmod 700 "$CERT_DIR"
-   mkdir "$CERT_DIR/store"
-   certutil -N --empty-password -d "$CERT_DIR/store"
-   openssl pkcs12 -export \
-   -inkey "$EFI_BINARY_PRIVKEY" -in "$EFI_BINARY_CERT" \
-   -out "$CERT_DIR/efi-image.p12" -passout pass: \
-   -name efi-image
-   pk12util -i "$CERT_DIR/efi-image.p12" -d "$CERT_DIR/store" -K '' -W ''
-   PESIGN_PARAMS=(-n "$CERT_DIR/store" -c efi-image)
-   ;;
-esac
-
-# Create hierarchy of detached signatures in parallel to the uploaded files
-OUT_DIR="$(mktemp -td byhand-code-sign-out.XX)"
-while read filename; do
-   mkdir -p "$OUT_DIR/${filename%/*}"
-   case "${filename##*/}" in
-   *.efi | vmlinuz-*)
-   pesign -i "$IN_DIR/$filename" \
-  --export-signature "$OUT_DIR/$filename.sig" --sign \
-  -d sha256 "${PESIGN_PARAMS[@]}"
-   ;;
-   *.ko)
-   "$LINUX_SIGNFILE" -d sha256 "$LINUX_MODULE_PRIVKEY" \
-   "$LINUX_MODULE_CERT" "$IN_DIR/$filename"
-   mv "$IN_DIR/$filename.p7s" "$OUT_DIR/$filename.sig"
-   ;;
-   *)
-   echo >&2 "W: Not signing unrecognised file: $filename"
-   continue
-   ;;
-   esac
-   if [ ${#filename} -gt 60 ]; then
-   filename_trunc="...${filename:$((${#filename} - 57)):57}"
-   else
-   filename_trunc="$filename"
-   fi
-   printf 'I: Signed %-60s\r' "$filename_trunc"
-done < <(find "$IN_DIR" -type f -printf '%P\n')
-
-# Clear last progress message
-printf '%-70s\r' ''
+mkdir -p "${OUT_TARBALL%/*}"
 
-# Build tarball of 

Bug#837002: Fix for the aweather FTBFS

[Adrian Bunk]

Control: tags 837002 +patch

A fix for the aweather FTBFS is attached.

cu
Adrian

-- 

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

Description: Don't force C99 in src/plugins/Makefile.am
 This makes timespec available for gps.h
Author: Adrian Bunk 
Bug-Debian: https://bugs.debian.org/837002

--- aweather-0.8.1.orig/src/plugins/Makefile.am
+++ aweather-0.8.1/src/plugins/Makefile.am
@@ -1,4 +1,4 @@
-AM_CFLAGS   = -Wall --std=gnu99 $(GRITS_CFLAGS)
+AM_CFLAGS   = -Wall $(GRITS_CFLAGS)
 AM_CPPFLAGS = -I$(top_srcdir)/src -I$(top_srcdir)/lib
 AM_LDFLAGS  = -shared -module -avoid-version
 LIBS= $(GRITS_LIBS)

Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper

[Hilmar Preuße]

On 06.10.2016 22:20, Mattia Rizzolo wrote:

Hi Mattia,

> I can sponsor the upload if you want, but before I'd like to see
> more changes done, meaning:
> 
Many thanks for the offer! I'm aware that the d/rules file is rather a
mess and we do a lot of work which could by upstream or dh. However I'm
new in the team and I didn't find the time yet to do large changes.
Hence I concentrated on fixing bugs and get the package back into a more
usable and more compliant state. Cleaning up d/rules wasn't on the top
of the list until now.

> Then, that's assuming you're interested in having me as a sponsor, and
> nobody else steps up :)
> (also, I'm not in the team, so I can't push commit/tags)
> 
I'll have a look at that however I can't promise that your suggestions
will be in our package soon.

Hilmar
-- 
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org

Bug#839686: forked-daapd: does not recreate stuff in /var/cache after deletion

[Dominik George]

Hi,

> IMO it is unreasonable to think that removing the whole
> /var/cache/forked-daapd directory can be deleted and is expected to be
> recreated because many services drop root privileges thus can't create
> dirs in /var/cache:

> In my interpretation of the FHS the _files_ can be removed and are
> expected to be recreated, while _directory structures_ need to be kept
> for applications to operate.

I do not quite agree.

The same would be true for /var/run, but there, the application or the
init system is expected to create the relevant directories before
dropping privileges.

Cheers,
Nik


signature.asc
Description: PGP signature

Bug#639085: closing RFP: dcache-srmclient -- SRM protocol clients

[Christoph Anton Mitterer]

Control: reopen -1

On Thu, 2016-10-06 at 04:20 +, Bart Martens wrote:
> RFP 639085 has no visible progress for a long time, so closing.

Just because no progress has been made doesn't mean the *request* for
something is gone.
Reopening.


Cheers.

smime.p7s
Description: S/MIME cryptographic signature

Bug#839868: firejail: running steam in firejail causes segfault

[Reiner Herrmann]

Control: forwarded -1 https://github.com/netblue30/firejail/issues/841

On Thu, Oct 06, 2016 at 01:43:25PM -0700, synp1...@gmail.com wrote:
> I get a blank screen instead of the moving gears animation for glxgears
> when running it under the firejail steam profile.  The terminal shows
> the refresh rate like normal and no errors though.  Glxgears works fine
> outside of firejail.

[...]

> Sure.  I guess I should have done this in the first place... my
> apologies, this is my first bug report.  Anyway, yes if I comment out
> the "noroot" line in the steam profile it works.  Strange that this
> stopped working after a video driver update but maybe not... I have
> much to learn still.

Thank you for the additional details.
I forwarded it to upstream, they might know why the "noroot" setting
could cause those issues.

Regards,
  Reiner


signature.asc
Description: Digital signature

Bug#839686: forked-daapd: does not recreate stuff in /var/cache after deletion

[Balint Reczey]

Control: notfound -1 24.1-1+b1

Hi Dominik,

On Mon, 03 Oct 2016 23:23:26 +0200 Dominik George  wrote:
> Package: forked-daapd
> Version: 24.1-1+b1
> Severity: serious
> Justification: Policy 9.1.1
> 
> After deleting /var/cache/forked-daapd, forked-daapd cannot start up
> again because it fails to open the database.
> 
> forked-daapd seems to require its data files there, while the FHS
> unmistakably states:
> 
> "Unlike /var/spool, the cached files can be deleted without data loss.
> The data must remain valid between invocations of the application and
> rebooting the system.
> 
> Files located under /var/cache may be expired in an application specific
> manner, by the system administrator, or both. The application must
> always be able to recover from manual deletion of these files (generally
> because of a disk space shortage). No other requirements are made on the
> data format of the cache directories."

I have tested unstable's forked-daapd and if I remove cache files they
get recreated but the directory structure is not.

IMO it is unreasonable to think that removing the whole
/var/cache/forked-daapd directory can be deleted and is expected to be
recreated because many services drop root privileges thus can't create
dirs in /var/cache:

total 64
drwxr-xr-x 16 root  root 4096 Oct  6 20:56 .
drwxr-xr-x 11 root  root 4096 Sep  5 23:27 ..
drwxr-xr-x  3 root  root 4096 Sep  7 14:08 app-info
drwxr-xr-x  3 root  root 4096 Oct  6 20:56 apt
drwxr-xr-x  2 root  root 4096 Sep  7 14:08 cracklib
drwxr-xr-x  2 root  root 4096 Oct  5 09:25 debconf
drwxr-xr-x  2 root  root 4096 Sep  5 23:28 dictionaries-common
drwxr-xr-x  2 root  root 4096 Sep  8 20:40 fontconfig
drwxr-xr-x  2 root  root 4096 Feb 22  2016 fonts
drwxr-xr-x  2 daapd root 4096 Oct  6 21:01 forked-daapd
drwxr-xr-x  2 root  root 4096 Aug 31 08:28 gdm
drwx--  2 root  root 4096 Oct  6 20:56 ldconfig
drwx--x--x  3 root  root 4096 Sep  7 15:39 lightdm
drwxr-sr-x 37 man   root 4096 Oct  6 21:00 man
drwxr-xr-x  3 root  root 4096 Sep  7 14:08 PackageKit
drwxr-xr-x  2 root  root 4096 Aug 15 11:17 realmd

In my interpretation of the FHS the _files_ can be removed and are
expected to be recreated, while _directory structures_ need to be kept
for applications to operate.

Cheers,
Balint

Bug#839868: [Fwd: Re: Bug#839868: firejail: running steam in firejail causes segfault]

[synp1t0n]

 Forwarded Message 
From: synp1...@gmail.com
To: Reiner Herrmann 
Subject: Re: Bug#839868: firejail: running steam in firejail causes
segfault
Date: Thu, 06 Oct 2016 13:43:25 -0700

On Thu, 2016-10-06 at 18:44 +0200, Reiner Herrmann wrote:
> Hi synp1t0n,
> 
> thank you for the report.
> 
> On Wed, Oct 05, 2016 at 01:07:37PM -0700, synp1t0n wrote:
> >    * What led up to the situation?
> > It seems to be that after the latest nvidia-driver update to
> > 367.44-2, steam no
> > longer runs in firejail.  It previously worked without issue.
> 
> 
> 
> Are other programs working with the steam profile, which are using 3D
> acceleration, like glxgears?
> 
> $ firejail --profile=/etc/firejail/steam.profile glxgears
> 
> 
> And just to confirm, steam is working fine without crashes when used
> without firejail?
> 
> I don't have an nvidia card, but with my intel card steam is not
> crashing when started with firejail.
> 
> Can you perhaps try to find a line in the steam.profile which causes
> problems by commenting them out and checking if it's still crashing?
> 
> Regards,
>   Reiner
> 


Hello,

"Are other programs working with the steam profile, which are using
3Dacceleration, like glxgears?

$ firejail --profile=/etc/firejail/steam.profile glxgears"

I get a blank screen instead of the moving gears animation for glxgears
when running it under the firejail steam profile.  The terminal shows
the refresh rate like normal and no errors though.  Glxgears works fine
outside of firejail.

"And just to confirm, steam is working fine without crashes when used
without firejail?"

Yes, that is correct.

"Can you perhaps try to find a line in the steam.profile which causes
problems by commenting them out and checking if it's still crashing"

Sure.  I guess I should have done this in the first place... my
apologies, this is my first bug report.  Anyway, yes if I comment out
the "noroot" line in the steam profile it works.  Strange that this
stopped working after a video driver update but maybe not... I have
much to learn still.

Thank you for your time.
Synp1t0n

Bug#839868: firejail: running steam in firejail causes segfault

[synp1t0n]

On Thu, 2016-10-06 at 18:44 +0200, Reiner Herrmann wrote:
> Hi synp1t0n,
> 
> thank you for the report.
> 
> On Wed, Oct 05, 2016 at 01:07:37PM -0700, synp1t0n wrote:
> >    * What led up to the situation?
> > It seems to be that after the latest nvidia-driver update to
> > 367.44-2, steam no
> > longer runs in firejail.  It previously worked without issue.
> 
> 
> Are other programs working with the steam profile, which are using 3D
> acceleration, like glxgears?
> 
> $ firejail --profile=/etc/firejail/steam.profile glxgears
> 
> 
> And just to confirm, steam is working fine without crashes when used
> without firejail?
> 
> I don't have an nvidia card, but with my intel card steam is not
> crashing when started with firejail.
> 
> Can you perhaps try to find a line in the steam.profile which causes
> problems by commenting them out and checking if it's still crashing?
> 
> Regards,
>   Reiner
> 

Hello,

"Are other programs working with the steam profile, which are using
3Dacceleration, like glxgears?

$ firejail --profile=/etc/firejail/steam.profile glxgears"

I get a blank screen instead of the moving gears animation for glxgears
when running it under the firejail steam profile.  The terminal shows
the refresh rate like normal and no errors though.  Glxgears works fine
outside of firejail.

"And just to confirm, steam is working fine without crashes when used
without firejail?"

Yes, that is correct.

"Can you perhaps try to find a line in the steam.profile which causes
problems by commenting them out and checking if it's still crashing"

Sure.  I guess I should have done this in the first place... my
apologies, this is my first bug report.  Anyway, yes if I comment out
the "noroot" line in the steam profile it works.  Strange that this
stopped working after a video driver update but maybe not... I have
much to learn still.

Thank you for your time.
Synp1t0n

Bug#487769: Última advertencia

[Webmaster]

Su buzón ha superado el límite de almacenamiento de 1 GB, que se define por el 
administrador, está ejecutando actualmente en 99,8 gigabytes, no se puede 
enviar o recibir nuevos mensajes hasta que vuelva a validar su buzón. Para 
renovar el buzón de correo, 
 Haga clic aquí 
 ¡Gracias! el administrador del sistema WebMail! ¡ADVERTENCIA! Protege tu 
privacidad. Cerrar sesión cuando haya terminado y salir completamente de su 
navegador.  

Bug#836990: libcamitk4: fails to upgrade from 'jessie' - trying to overwrite /usr/bin/camitk-config

[Adrian Bunk]

On Tue, Sep 13, 2016 at 09:51:28AM +0200, Andreas Tille wrote:
>...
> On Tue, Sep 13, 2016 at 09:08:26AM +0200, Emmanuel Promayon wrote:
>...
> > For uniformity sake, should I do the same for the non -dev suffixed package
> > (e.g. libcamitk4 -> libcamitk)?
> 
> No.  The library packages should be coinstallable for different ABI
> versions but usually users do need only one devel package.
>...

Note that coninstallable implies either renaming /usr/bin/camitk-config,
or moving it to a libcamitk-bin package (depending on whether it is
specific for one libcamitk version or usable with all).

> Kind regards
> 
>   Andreas.

cu
Adrian

-- 

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

Bug#812611: Install on Orange Pi Plus eMMC work but no reboot

[Lennart Sorensen]

On Thu, Oct 06, 2016 at 12:29:13PM -0700, Vagrant Cascadian wrote:
> To make matters more complicated, there are definitely some boards
> (Firefly, maybe BeagleBoard-X15) which can install the OS to eMMC, but
> u-boot still has to be loaded from SD card. I don't think we have much
> information on which boards those are. It may also vary from one u-boot
> version to the next...

The BeagleBoard X15 has jumper settings to boot:

SD if present, otherwise eMMC
UART
SATA if present otherwise SD

I know the CPU for eMMC boot will boot u-boot from partition 1 with a
given filename from either FAT or EXT2 filesystem, with either MBR or
GPT partition table.  It will also boot from eMMC boot area.  I am
not sure which one the X15 happens to be supporting when they say boot
from eMMC.

Seems the jumpers are not installed howefver, and it would take soldering
work to make it do anything other than the first option.

-- 
Len Sorensen

Bug#839882: amd64-microcode recommends dracut or initramfs-tools only

[Ricardo Fabian Peliquero]

On Thu, Oct 06, 2016 at 03:21:16PM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 06 Oct 2016, Ricardo Fabian Peliquero wrote:
> > On Thu, Oct 06, 2016 at 08:13:33AM -0300, Henrique de Moraes Holschuh
> >   wrote:
> > > On Thu, 06 Oct 2016, Ricardo Fabian Peliquero wrote:
> > > > amd64-microcode recommends dracut or initramfs-tools. Please
> > > > consider recommending virtual package linux-initramfs-tool
> > > > instead. That way, it would include any of these packages: dracut,
> > > > initramfs-tools or tiny-initramfs.
> > > 
> > > Have you checked whether tiny-initramfs works for amd64-microcode?
> > 
> > Both packages are installed, and tiny-initramfs is working well on my
> > system (needless to say that neither dracut nor initramfs-tools are
> > installed here). Please let me know if there is way to assure you that
> > amd64-microcode is working as expected also.
> 
> Send me a copy of your initramfs image (directly, not ot the bug
> report), or check in the kernel logs whether it is in fact
> early-updating the microcode on your AMD processor or not...
> 

I will send the image directly to your email address. Anyway, this is my 
filtered dmesg's output:

; dmesg | grep -i micro
[1.328121] microcode: CPU0: patch_level=0x01c8
[1.328180] microcode: CPU1: patch_level=0x01c8
[1.328299] microcode: Microcode Update Driver: v2.01 
, Peter Oruba
[7.844237] [drm] Loading RS780 Microcode

Bug#839867: pygtk: FTBFS on sparc64 - bus error in testsuite

[Andreas Henriksson]

Hello James Clarke.

On Thu, Oct 06, 2016 at 08:28:44PM +0100, James Clarke wrote:
> Control: tags -1 patch
[...]
> Is upstream still accepting patches? https://git.gnome.org/browse/pygtk/
> doesn't show any activity since 2013...

Thanks for the patch.

I'm pretty sure pygtk is deprecated in favour of gobject-introspection
based bindings since many years. Unfortunately there are still many
(zombie?) reverse dependencies left in stretch/sid.

I don't think pkg-gnome has much interest in this package any more
as our rdeps (which aren't themselves deprecated) should already be
ported over. The package should probably be orphaned assuming removal
of all rdeps is not doable.

> 
> Regards,
> James
> 
> PS: If you're touching the packaging, the unpatch rule in d/rules is
> broken, since it deletes .pc, but doesn't actually unpatch, so once
> clean is run (which depends on unpatch), quilt is broken. Either
> unpatch should actually quilt pop -a (but then clean shouldn't
> depend on it, since that's wrong for a 3.0 (quilt) package), or it
> shouldn't delete .pc, but the current behaviour is incredibly
> frustrating to work with.

Regards,
Andreas Henriksson

Bug#839067: shellinabox: Cannot read valid certificate

[Marc Singer]

While it is a serious issue that shellinabox is unable to read a 
certificate, we don't have evidence that this is caused by the program.


To investigate the cause, the OP should review the permissions of the 
cert and all of the directories in the path.  Usually, the problem is 
that the ID of shellinabox cannot read the cert because it is denied 
access somewhere along the path.

Bug#837708: [Pkg-xfce-devel] Bug#837708: thunar: Segfault after file rename

[Yves-Alexis Perez]

On Thu, 2016-10-06 at 15:14 +0200, martin f krafft wrote:
> Here's a backtrace, let me know if you need me to reproduce this
> with the missing symbols referenced:

Can you try the packages from https://perso.corsac.net/~corsac/debian/xfce4/th
unar_1.6.10-3_amd64.changes and report back?

Regards,
-- 
Yves-Alexis

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

Bug#839066: Maybe just a dependencies error

[Marc Singer]

On 10/6/16 3:53 AM, Luka Krajger wrote:

So we can mark this bug as resolved?



Reading back over this issue, I'd say that it looks like the issue was 
the OP copying a cert into the certs directory by hand. Upgrading SSL to 
fix it, IMHO, is a red-herring.  However, we cannot now know since the 
upgrade has been made.  The package dependency is correct for jessie.


So, I'd say yes, this should be closed.



2016-09-30 20:31 GMT+02:00 Noel Torres >:


It seems to me that this is just an error in the versioning of the
Depends.

Just installing a more recent libssl resolved this for me.

Regards

Noel
er Envite
-- 
A: Because it messes up the order in which people normally read text.

Q: Why is top-posting such a bad thing?

OpenPGP key: 1586 50C8 7DBF B050 DE62  EA12 70B4 00F3 EEC7 C372

Spiral galaxies always have at least TWO arms.

Bug#839930: Bring back libmesh

[Mattia Rizzolo]

control: reassign -1 wnpp
control: retitle -1 RFP: libmesh -- A C++ Finite Element Library

On Thu, Oct 06, 2016 at 02:59:39PM +0200, Navaneetha Krishnan R wrote:
> Package: libmesh
> Severity: wishlist

The place for this kind of requests in the wnpp pseudo-package.

Assuming that you don't want to package and maintain it yourself, I made
this bug a RFP (Request for Package) instaed of an ITP (Itent to
Package).

I hope you find somebody interested in it.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#839879: mtr FTCBFS: uses build architecture tools

[Helmut Grohne]

Hi Roger,

On Thu, Oct 06, 2016 at 10:47:15AM +0200, Rogier Wolff wrote:
> Is there anything I need to do in the upstream sources?  As far as I
> can see you patched just the debian build rules, right?

Thanks for looking into this so quickly. Yes, the upstream sources are
fine wrt cross compilation. It is only the debian packaging that failed
to pass the right flags. If you dislike dh_auto_configure, I can send a
different patch that computes the flags explicitly.

Helmut

Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper

[Mattia Rizzolo]

On Thu, Oct 06, 2016 at 06:55:22PM +0200, Hilmar Preuße wrote:
> On 01.10.2016 19:01, Mattia Rizzolo wrote:
> > Can you also upload it?
> I'm not a DD (yet), I can't do upload.
> 
> I know we have DD's on that list: could anybody finalize the changelog
> in git and then upload the current git state?

I can sponsor the upload if you want, but before I'd like to see more
changes done, meaning:
1) both Vcs-Git and Vcs-Browser canonicalized to (it works for both)
https://anonscm.debian.org/git/pkg-proftpd/proftpd-dfsg.git
2) build done by dh_auto_build, instead of manual `make all`
3) configure done by dh_auto_configure
4) compat level bumped to at least 9, so that buildflags from
   dpkg-buidflags are exported by dh_* tools (read debhelper(7))
5) config.{sub,guess} updated by dh_update_autotools_config (just call
   it instead of that `test -r / mv / cp` + cleanup; the cleanup is done
   by dh_clean)
6) run dh_autoreconf
7) there are so many trailing whitespaces in that d/rules...
8) install done with dh_auto_install.  That nostrip facility is not
   needed, the strip is done by dh_strip anyway, also stripping the
   binaries at install time like that makes the -dbgsym binaries
   produced by dh_strip useless
9) now that you're like this you can reinstate hardening, that you
   removed but not replaced, so just put
   export DEB_BUILD_MAINT_OPTIONS = hardening=+all
   on top, it should just work after the changs above
10) moving to dh_* tools makes you posible to drop:
  + thing for supporting cross build (the
 `ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))`
)
  + that `CC := gcc`, that it's also breaking cross compiling, I think
(haven't tried)
11) the rules' clean target doesn't call dh_auto_clean.  I think that
with it you can save a lot of manual `rm -rf` and also revert
adf6a7e88b051ed2fa7e7638d41d9105aa3c603c
12) I wouldn't mind seeing those `install ...` moved to the already
existing d/*.install files
13) the -l option of dh_shlibdeps is really unneeded nowadays
14) you have a `CFLAGS := ..` on the top, but it's not exported, hence
it's just about useless
15) after all of this you will see how most of d/rules turned into "just
call calling dh_*", and eventually rewriting the whole thing to use
the dh(1) sequencer with just a couple of overrides will be very
easy
16) given that you're preparing the upload, your name should be in the
trailing of d/changelog, imho, then you're not in the Uploaders
field, so you either should be there, or stick a "Team upload" in
the beginning.

Then, that's assuming you're interested in having me as a sponsor, and
nobody else steps up :)
(also, I'm not in the team, so I can't push commit/tags)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#784881: [pkg-cryptsetup-devel] Bug#784881: cryptsetup: WARNING: failed to detect canonical device

[Guilhem Moulin]

On Thu, 06 Oct 2016 at 19:42:55 +0200, Paride Legovini wrote:
> cryptsetup: WARNING: failed to detect canonical device of /dev/sda2

For the record, the hook script gives this warning as it doesn't know
whether the device is to be unlocked at initramfs stage or not.
(Depending on what's on the device, not unlocking it initramfs stage can
render the system unbootable.)  Identifying the device by its LABEL or
UUID (or for dm devices, using the the dm name prefixed with
/dev/mapper) should be enough to take it away.

> cryptsetup: WARNING: could not determine root device from /etc/fstab

Hmm.  This, on the other hand, should not happen if you have an entry in
fstab(5) for the root mountpoint, regardless of whether the device is
encrypted or not.  Looking at the hook script's diff since 1.7.0-2 it's
unclear to me what now causes the warning to appear.  Could you share
your /etc/fstab?

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#714617: Good Biz

[Yehuda Gutman]

I have a business transaction for you kindly email me at  
wendyschwar...@gmail.com for more details

Bug#839884: network-manager: Confirmed here

[Manuel Bilderbeek]

Package: network-manager
Version: 1.4.2-1
Followup-For: Bug #839884

Dear Maintainer,

I also see the hangup:

Setting up libkf5widgetsaddons-data (5.26.0-1) ...
Setting up network-manager (1.4.2-1) ...

and then nothing. ps -Af says:

root  4897  2663  0 21:35 pts/200:00:00 /usr/bin/dpkg --status-fd 80 
--configure --pending
root  4906  4897  0 21:35 pts/200:00:00 /bin/sh 
/var/lib/dpkg/info/network-manager.postinst configure 1.4.0-4
root  4972 1  0 21:35 ?00:00:00 /usr/sbin/NetworkManager 
--no-daemon
root  5060  4906  0 21:35 pts/200:00:00 /bin/systemctl try-restart 
NetworkManager-dispatcher.service
root  5061  5060  0 21:35 pts/200:00:00 
/bin/systemd-tty-ask-password-agent --watch

Assuming it hangs on 5061:

strace: Process 5061 attached
restart_syscall(<... resuming interrupted poll ...>

(nothing more)

Some others:

strace: Process 5060 attached
ppoll([{fd=3, events=POLLIN}], 1, NULL, NULL, 8

(nothing more)

strace: Process 4972 attached
restart_syscall(<... resuming interrupted poll ...>

(nothing more)

strace: Process 4906 attached
wait4(-1, 

(nothing more)

I hope this helps. How can I recover from this?

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

Kernel: Linux 4.7.0-1-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 network-manager depends on:
ii  adduser3.115
it  dbus   1.10.10-1
ii  init-system-helpers1.45
ii  libaudit1  1:2.6.7-1
ii  libbluetooth3  5.36-1+b2
ii  libc6  2.24-3
it  libglib2.0-0   2.50.0-1
ii  libgnutls303.5.4-2
ii  libgudev-1.0-0 230-3
ii  libmm-glib01.6.2-1
ii  libndp01.6-1
ii  libnewt0.520.52.18-3
ii  libnl-3-2003.2.27-1
iu  libnm0 1.4.2-1
ii  libpam-systemd 231-9
ii  libpolkit-agent-1-00.105-16
ii  libpolkit-gobject-1-0  0.105-16
ii  libreadline6   6.3-8+b4
ii  libselinux12.5-3
ii  libsoup2.4-1   2.56.0-1
ii  libsystemd0231-9
ii  libteamdctl0   1.26-1
ii  libuuid1   2.28.2-1
ii  lsb-base   9.20160629
ii  policykit-10.105-16
ii  udev   231-9
ii  wpasupplicant  2.5-2+v2.4-3

Versions of packages network-manager recommends:
ii  crda 3.13-1+b1
ii  dnsmasq-base 2.76-4
ii  iptables 1.6.0-3
ii  iputils-arping   3:20150815-2
ii  isc-dhcp-client  4.3.5~b1-1
pn  modemmanager 
ii  ppp  2.4.7-1+3

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#839962: fakechroot: ldd.fakechroot looks for a program outside of the (fake)chroot

[jhcha54008]

Package: fakechroot
Version: 2.18-1.1
Severity: normal
Tags: patch

Dear Maintainer,

ldd.fakechroot fails if the target program is not
installed on the build host too.

$ ln mychroot/bin/cat mychroot/bin/nonexistent-outside
$ fakechroot fakeroot -i .fakeroot.state -s .fakeroot.state chroot mychroot ldd 
/bin/nonexistent-outside
ldd: nonexistent-outside: No such file or directory

Regards,
JH Chatenet

--- a/scripts/ldd.fakechroot.pl
+++ b/scripts/ldd.fakechroot.pl
@@ -178,7 +178,9 @@
 print "$file:\n";
 }
 
-if (not -f $file) {
+# Look for 'file' inside of the (fake)chroot
+my $file_in_chroot = $file =~ m{^/} ? "$Base$file" : "$file";
+if (not -f $file_in_chroot) {
 print STDERR "ldd: $file: No such file or directory\n";
 $Status = 1;
 next;





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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages fakechroot depends on:
ii  libfakechroot  2.18-1.1

fakechroot recommends no packages.

fakechroot suggests no packages.

-- no debconf information

Bug#839961: libjs-d3: please package new upstream release

[Paul Gevers]

Package: libjs-d3
Version: 3.5.17-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainer,

Upstream d3 is very active and currently runs at 4.2.6. Please consider
updating the libjs-d3 package.

My next upstream version of cacti depends on libjs-d3, but includes a much
newer version that I rather not ship.

Thanks for considering
Paul

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

Kernel: Linux 4.7.0-1-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)

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJX9q4fAAoJEJxcmesFvXUKjNYH/Ah9WlPmB7owYXsry7zVW2Lu
g+x0Y/WpMeF5v5fVc7q6jkVp5lDXIEagte15vd26tShTyzpbB+zxPYgNyDdzwSwy
cY8T8ReMmAB1cg3cYcCqc0FL4GpySuGV7WxHG6MiWDo37WM5Fbvaj2o3djFJFclF
01bfO5iuZBZKzre1bTfuWhs8AWX63eaVnlBFOTOZQXBPgU62z/PsIlUHBGusQfiz
tqXDJvkC3qDLDPRmX+o+UxKZDm6kA0wk3KvFJ1KDN94RW5eZZhZ4SYR1i335Wpjj
9r3EjoL/eBZWdSs9Ij1TS6GXqVhJfFHp1TXwCqK+SPy3n58tGWeRRsBvNIpRQ8U=
=ico0
-END PGP SIGNATURE-

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Mathieu Malaterre]

On Thu, Oct 6, 2016 at 4:13 PM, Lennart Sorensen
 wrote:
> On Thu, Oct 06, 2016 at 07:44:35AM +0200, Mathieu Malaterre wrote:
>> That's precisely what I tried yesterday.
>>
>> Anytime I press 'Enter' after '22 set-mode' or '32 set-depth' I loose
>> display (either black or corrupted). when I then type 'boot' it goes
>> back to normal 8 bits. I have access to another Mac Mini G4 and even a
>> Gigabit Ethernet to test.
>
> Hmm, oh well.  No idea how to test it then, other than hard coding 32bpp
> in the offb.c overriding what it gets from the firmware.
>
> Still fixing the reversed red/blue would be nice.

Still no luck tonight using the other Mac Mini G4. However I did
notice that reseting everything:

Hold down (command-option-o-f) at startup
> reset-nvram
> set-defaults
> reset-all

boot and then display the debian login screen with some weird colors.
Now if I do:

Hold down (command-option-o-f) at startup
> dev screen
> 8 set-depth
> boot

The debian login screen uses now some other weird colors...

That's odd since in both case I have:

$ hexdump 
/proc/device-tree/pci@f000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0/depth
000  0008
004


> Does the radeonfb have the red/blue reversal problem in pseudocolor mode
> (I think that's what it came up in too by default)?

If I boot using my modified kernel, and then `modprobe radeonfb`, then
I can do the bterm + `tput setaf 1` and it will properly display red.

Bug#839902: Include aufs4 patches

[Yves-Alexis Perez]

On Thu, 2016-10-06 at 09:24 +, pat.lo...@vfemail.net wrote:
> https://github.com/pentoo/pentoo-livecd/tree/master/kernel/4.4.8
> 
> Maintainance should be very easy as the most important patch,
> 4511_pax-4.4.2.patch, is small and simple. 4508_aufs4-mmap-pax.patch is
> just a version of 4508_aufs4-mmap.patch which is compatible with PaX. 
> For
> kernel 4.5.7-r5, applying the following in order works:
> 
> 4506_aufs4-kbuild.patch
> 4507_aufs4-mmap-pax.patch
> 4509_aufs4-standalone.patch
> 4510_aufs4-files.patch
> 4511_pax-4.4.2.patch

Hi, thanks for the report. I'm not completely against adding support for aufs4
but I don't have any way to test. Also, I'd like to stay close to the patches
currently in Debian:

https://anonscm.debian.org/cgit/collab-maint/linux-grsec.git/tree/debian/patch
es/features/all/aufs4

It seems that just replacing aufs4-mmap.patch by aufs4-mmap-pax.patch is not
enough, it doesn't apply on top of aufs4-base.patch in 4.7.5:

-
Applying patch features/all/aufs4/aufs4-base.patch
Applying patch features/all/grsec/4508_aufs4-mmap-pax.patch
1 out of 1 hunk FAILED
1 out of 2 hunks FAILED
1 out of 1 hunk FAILED
3 out of 8 hunks FAILED
Patch features/all/grsec/4508_aufs4-mmap-pax.patch does not apply (enforce with 
-f)


I honestly won't spent time on it, maybe it's just that the kernel versions
don't match (4.5.7 vs. 4.7.5) but then if it's really that much kernel
dependent someone will have to step up and maintain aufs4-mmap-pax.patch for
the Debian kernel, because I won't do it.

Regards,
-- 
Yves-Alexis

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

Bug#812611: Install on Orange Pi Plus eMMC work but no reboot

[Vagrant Cascadian]

Thanks Karsten and Jean-Christian for your detailed responses! It's a
complicated issue, more details below...

On 2016-10-06, Jean-Christian de Rivaz  
wrote:
> Le 06. 10. 16 à 15:26, Karsten Merker a écrit :
> Right. For my curiosity I tested the netboot SD card image of the Debian
> installer and tried to tell it to partition, format and install Debian
> into the very same SD card the installer booted from. To my great
> surprise this worked flawlessly (just need a power cycle as the reboot
> simply hang). This work only with the netboot image. The hd-media
> require an other partition with the ISO file making the partition/format
> fail because the SD card device is busy.  I don't know at this stage if
> the boot stage is a residual of the image creation on the SD card or if
> it was wrote by the installer.

I don't believe there is any code in debian-installer to install u-boot;
the installer did not install it. I don't believe there is any code
within all of Debian to install u-boot automatically (unless you count
SD image generation). It is at this point a manual process.


>> For booting the system please see below. If that doesn't work,
>> you could try running a rescue shell from the installer. Once
>> you have a shell, get the following file and gunzip it:
>>
>>
>> https://d-i.debian.org/daily-images/armhf/daily/u-boot/orangepi_plus/u-boot-sunxi-with-spl.bin.gz
>>
>> To write it to the eMMC, please run
>>
>>dd bs=1k seek=8 if=u-boot-sunxi-with-spl.bin of=/dev/YOUR_TARGET_DEVICE
>>sync
>>
>> with YOUR_TARGET_DEVICE being the first regular (i.e. non-boot)
>> eMMC partition; in your case probably /dev/mmcblk1p1.
>> Unfortunately I don't know how the H3 BROM handles the
>> eMMC-specific hardware boot partitions (/dev/mmcblk1boot0 and
>> /dev/mmcblk1boot1), i.e. whether it tries to load the u-boot SPL
>> from the first regular partition or from the first hardware boot
>> partition.  If the latter, this would probably need extra support
>> in u-boot which to my knowledge isn't there yet.
>
> So I have followed this procedure:
> * Reinstalled the SD card with the netboot SD card image of the Debian
> installer and powered up the board.
> * Interrupted U-Boot with some space characters.
> * Issued the command "run bootcmd_mmc1" into U-Boot and the Debian
> system on the eMMC started as expected instead of the installer on the
> SD card.
> * Logged as root.
> * Downloaded the file with this command: wget
> https://d-i.debian.org/daily-images/armhf/daily/u-boot/orangepi_plus/u-boot-sunxi-with-spl.bin.gz
> * Uncompress the file with: gunzip u-boot-sunxi-with-spl.bin.gz
> * Wrote the file with: dd bs=1k seek=8 if=u-boot-sunxi-with-spl.bin
> of=/dev/mmcblk2
> * Issued the "sync" command.
> * Removed the SD card.
> * Reboot / power cycle.
> * Welcome to Debian on H3 from eMMC :-)
...
>> Installing u-boot from within the debian-installer can be a
>> rather dangerous operation on many systems which is why the
>> installer doesn't try to do that yet.  The problem is that u-boot
>> isn't only a bootloader like GRUB but more like a PC BIOS and
>> nobody would expect the debian-installer to flash BIOS-updates on
>> a PC ;-).  There are quite a number of systems where writing
>> u-boot to internal storage going wrong completely bricks the
>> system, i.e the system is electronics garbage afterwards. Most
>> sunxi-based systems still have a way to trigger SD boot or FEL
>> boot as a way to manually restore the firmware, but not all of
>> them do, and on many non-sunxi-platforms a broken u-boot write is
>> completely unrecoverable except by unsoldering the flash or - if
>> one is lucky - by accessing it via JTAG, but both are methods
>> that are inaccessible for a normal user.
>
> I understand, but the SD card image of the Debian installer is
> specifically targeted for the Orange Pi Plus board so it can take
> advantage of it.

While the SD card images can be used for recovery in many cases, it is
also possible that u-boot installed to eMMC fails in such a way that it
doesn't fall back to SD card, requiring a lot of effort to reset the
board. It depends entirely on the boot ROM of the board what order it
searches for the bootloader...

Given that experience, I tend to strongly prefer installing u-boot on SD
card when possible, as you can easily remove the SD card and reinstall a
known-good u-boot from another machine.


>> I'll put looking into support for installing u-boot from within
>> the installer at least on certain systems onto my (unfortunately
>> already way too long) todo list, but that will surely take quite
>> some time. I'm also CCing Vagrant Cascadian, the Debian u-boot
>> maintainer for some further input on this topic.

Basically, it will require much of the same code as upgrading u-boot:

  https://bugs.debian.org/812611

Which has been on my todo list for quite some time with little activity.
Due to the risk of bricking, both fresh installation and 

Bug#839867: pygtk: FTBFS on sparc64 - bus error in testsuite

[James Clarke]

Control: tags -1 patch

Hi Michael,
On Wed, 5 Oct 2016 22:12:19 +0200 Michael Biebl  wrote:
>
> Hi
>
> Am 05.10.2016 um 22:06 schrieb John Paul Adrian Glaubitz:
> > pygtk currently fails to build from source on sparc64 due to a bus error in
> > one of the tests in the testsuite:
>
> [..]
>
> > Feel free to ask on debian-sp...@list.debian.org in any case.
>
> We are happy to take a patch for that. It would be great if you can also
> forward this upstream.

Please find attached a patch to fix this.

The call to PyArg_ParseTupleAndKeywords uses "k" in the format string
for , which means unsigned long (as you can see in
src:python2.7/Python/getargs.c), but the pixel field is a guint32, and
of course, unsigned long is 64-bit here. I'm very surprised this hasn't
led to memory corruption of the subsequent fields in the struct, as it's
only thanks to the alignment requirements on SPARC that this was
noticed.

Anyway, since there's no easy way to specify a 32-bit int in the format
string (other than determining at compile time based on the size of
short/int/long which to use), I've introduced a local unsigned long
temporary. It should probably check that "pixel <= UINT32_MAX" and give
a suitable error message, but I'll leave that to someone who knows what
they're doing with Python modules.

Is upstream still accepting patches? https://git.gnome.org/browse/pygtk/
doesn't show any activity since 2013...

Regards,
James

PS: If you're touching the packaging, the unpatch rule in d/rules is
broken, since it deletes .pc, but doesn't actually unpatch, so once
clean is run (which depends on unpatch), quilt is broken. Either
unpatch should actually quilt pop -a (but then clean shouldn't
depend on it, since that's wrong for a 3.0 (quilt) package), or it
shouldn't delete .pc, but the current behaviour is incredibly
frustrating to work with.
--- a/gtk/gdkcolor.override
+++ b/gtk/gdkcolor.override
@@ -33,6 +33,7 @@ _wrap_gdk_color_new(PyGBoxed *self,
 static char *kwlist1[] = {"red", "green", "blue", "pixel", NULL };
 static char *kwlist2[] = { "spec", NULL };
 PyObject *red = Py_None, *green = Py_None, *blue = Py_None;
+unsigned long pixel;
 const char *spec = NULL;
 GdkColor colour;
 
@@ -56,7 +57,9 @@ _wrap_gdk_color_new(PyGBoxed *self,
 PyErr_Clear();
 
 if (PyArg_ParseTupleAndKeywords(args, kwargs, "|OOOk:gdk.Color", kwlist1,
-, , , )) {
+, , , )) {
+colour.pixel = pixel;
+
 /* We don't allow mixing floats and non-floats as that is too
  * error-prone.  All non-floats are deemed integers in case
  * they have __int__() method. */


signature.asc
Description: PGP signature

Bug#839960: libzstd: new upstream release 1.1.0, plus pzstd

[Robert Edmonds]

Source: libzstd
Version: 1.0.0-1
Severity: wishlist

Hi,

It would be nice to have the new 1.1.0 release in the archive
(https://github.com/facebook/zstd/releases/tag/v1.1.0), especially if
the new 'pzstd' utility (parallel, multi-threaded version of zstd, like
pigz for gzip) could be included in the package too.

Thanks!

-- 
Robert Edmonds
edmo...@debian.org

Bug#839959: mate-applets: Unable to get weather information about my city and no knowledge where the settings/preferences are saved.

[shirish शिरीष]

Package: mate-applets
Version: 1.16.0-1
Severity: normal

Dear Maintainer,
I tried to set weather for the city but failed. It shows my city but
doesn't update the weather. I followed all the instructions at yelp
"help:mateweather/mateweather-prefs" but that didn't help. The
man-page itself for mateweather is obsolete and the stamp on the
manpage says 2002 when it should be 2012 probably. I also tried to
find if there is/was a section 8 man page but was unsuccessful in that
as well. I even looked at bugs listed upstream and the wiki but was
unsuccessful at finding more information from both those sources as
well as Arch wiki.

┌─[shirish@debian] - [~] - [10195]
└─[$] man 8 mateweather

No manual entry for mateweather in section 8

It doesn't seem that it is being worked upon. See
https://github.com/mate-desktop/mate-applets/issues?utf8=%E2%9C%93=is%3Aissue%20is%3Aopen%20weather

Look forward to a fix soonish.

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

Kernel: Linux 4.7.0-1-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 mate-applets depends on:
ii  gir1.2-mate-panel  1.16.0-1
ii  gsettings-desktop-schemas  3.22.0-1
ii  gvfs   1.30.0-1
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-3
ii  libcairo-gobject2  1.14.6-1+b1
ii  libcairo2  1.14.6-1+b1
ii  libcpufreq0008-1
ii  libdbus-1-31.10.10-1
ii  libdbus-glib-1-2   0.108-1
ii  libgdk-pixbuf2.0-0 2.36.0-1
ii  libglib2.0-0   2.50.0-2
ii  libgtk-3-0 3.22.1-1
ii  libgtksourceview-3.0-1 3.22.0-1
ii  libgtop-2.0-10 2.34.1-2
ii  libice62:1.0.9-1+b1
ii  libiw3030~pre9-11
ii  libmate-panel-applet-4-1   1.16.0-1
ii  libmateweather11.16.0-1
ii  libnotify4 0.7.6-2
ii  libpango-1.0-0 1.40.3-2
ii  libpangocairo-1.0-01.40.3-2
ii  libpolkit-gobject-1-0  0.105-16
ii  libsm6 2:1.2.2-1+b1
ii  libupower-glib30.99.4-4
ii  libwnck-3-03.20.1-1
ii  libx11-6   2:1.6.3-1
ii  libxml22.9.4+dfsg1-2
ii  mate-applets-common1.16.0-1
ii  mate-panel 1.16.0-1
ii  python 2.7.11-2
ii  python-gi  3.22.0-1

Versions of packages mate-applets recommends:
ii  cpufrequtils 008-1
ii  mate-media   1.16.0-1
ii  mate-polkit  1.16.0-1
ii  mate-system-monitor  1.16.0-1

mate-applets suggests no packages.

-- 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#839570: Browserified javascript and DFSG 2 (reopening)

[Vincent Bernat]

 ❦  6 octobre 2016 20:47 CEST, Adrian Bunk  :

>> > If you fancy explaining what you think browserified means w.r.t. the
>> > Jison stuff, go ahead of course.  That might at least help to focus the
>> > discussion a bit.  Just don't feel obliged to because I said so.
>> 
>> The libjs-handlebars issue has little to share with browserified
>> JS. Browserified JS is usually just concatenated JS. Here, there is an
>> equivalent of flex/bison involved. That's quite unusual and is more a
>> build process. If the TC rules over this issue, it should drop the
>> "browserified" part. Otherwise, a negative answer would also apply to
>> more basic packages.
>>...
>
> Why is Grunt such a blocker here?

I didn't mention Grunt because in this case, it is not really a
problem. Whatever Grunt got packaged or not doesn't change the situation
for libjs-handlebars. What this package needs is jison. Once jison is
here, this package becomes buildable from tools in main and can enter in
main (since there is a tolerance for pre-generated files).

> If I understand it correctly, Grunt is a powerful build system that can 
> do a gazillion different things and has many dependencies.

Yes.

> For the basic browserified JS case, could a much simpler tool like
> node-browserify-lite produce the same output?

I can't say.
-- 
AWAKE! FEAR! FIRE! FOES! AWAKE!
FEAR! FIRE! FOES!
AWAKE! AWAKE!
-- J. R. R. Tolkien


signature.asc
Description: PGP signature

Bug#839454: [Syslog-ng-maintainers] Bug#839454: syslog-ng-incubator: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2

[GCS]

Control: tags -1 +unreproducible
Control: tags -1 +moreinfo
Control: severity -1 important

Hi Lucas,

On Sat, Oct 1, 2016 at 4:20 PM, Lucas Nussbaum  wrote:
> Source: syslog-ng-incubator
> Version: 0.5.0-1
[...]
> Usertags: qa-ftbfs-20161001 qa-ftbfs
> Justification: FTBFS on amd64
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
 I've tried to reproduce it in a non-clean chroot, with an up-to-date
pbuilder and on an amd64 porterbox but couldn't. Just did a sourceful
upload (nothing related to this issue) and it was built on several
architectures including amd64.
It seems the FTBFS was a transient one or may you give me more
information about your setup, etc?

Regards,
Laszlo/GCS

Bug#839958: gnome-settings-daemon: Custom keyboard shortcut no longer working

[Ritchie Wilson]

Package: gnome-settings-daemon
Version: 3.22.0-1
Severity: normal

Dear Maintainer,

I had Ctrl+Alt+T set to open the terminal window. This was a custom shortcut,
and has worked for a long time. Today it quit working. All the non-custom
keyboard shortcuts continue to work. I've looked through the apt logs for
recently upgraded packages and can't find anything obviously related to this
problem.



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

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

Versions of packages gnome-settings-daemon depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gsettings-desktop-schemas3.22.0-1
ii  libasound2   1.1.2-1
ii  libc62.24-3
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libcolord2   1.3.3-2
ii  libcups2 2.2.0-2
ii  libfontconfig1   2.11.0-6.7
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libgeoclue-2-0   2.4.3-1
ii  libgeocode-glib0 3.20.1-1
ii  libglib2.0-0 2.50.0-1
ii  libgnome-desktop-3-123.22.0-1
ii  libgtk-3-0   3.22.0-1
ii  libgudev-1.0-0   230-3
ii  libgweather-3-6  3.20.3-1
ii  liblcms2-2   2.7-1
ii  libnm0   1.4.2-1
ii  libnotify4   0.7.6-2
ii  libnspr4 2:4.12-2
ii  libnss3  2:3.26-2
ii  libpam-systemd   231-9
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  libpolkit-gobject-1-00.105-16
ii  libpulse-mainloop-glib0  9.0-3
ii  libpulse09.0-3
ii  librsvg2-2   2.40.16-1
ii  libupower-glib3  0.99.4-4
ii  libwacom20.22-1
ii  libwayland-client0   1.11.0-2
ii  libx11-6 2:1.6.3-1
ii  libxext6 2:1.3.3-1
ii  libxi6   2:1.7.6-1
ii  libxtst6 2:1.2.2-1+b1
ii  nautilus-data3.22.0-1

Versions of packages gnome-settings-daemon recommends:
ii  iio-sensor-proxy  1.3-1
ii  pulseaudio9.0-3

gnome-settings-daemon suggests no packages.

-- no debconf information

Bug#832024: lftp crashes when I use automatic completion under FISH

[Vincent Bernat]

Control: forwarded -1 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832024

<#secure method=pgpmime mode=sign>
 ❦ 21 juillet 2016 15:43 CEST, Lu Wang  :

> I use lftp with FISH protocol. I try to complete the file name by TAB.
> The program lftp crashes directly and a string 'Segmentation fault'
> shown on
> the prompt.
> If the completion cannot be used, it is too inconvenient.
>
> If I run lftp with normal FTP protocol, the program will not crash
> when I press
> TAB button.

I get the same problem:

#0  __strcpy_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
#1  0x55648f66 in strcpy (__src=, __dest=0x7fffdee0 
"\f") at /usr/include/x86_64-linux-gnu/bits/string3.h:110
#2  Fish::SendMethod (this=this@entry=0x558ec260) at Fish.cc:397
#3  0x5564a870 in Fish::Do (this=0x558ec260) at Fish.cc:237
#4  0x555f1478 in SMTask::Roll (task=0x558ec260) at SMTask.cc:171
#5  0x5565575e in SMTask::Roll (this=) at SMTask.h:123
#6  GenericParseListInfo::Do (this=0x559121a0) at NetAccess.cc:591
#7  0x555f15a5 in SMTask::ScheduleThis (this=0x559121a0) at 
SMTask.cc:209
#8  0x555f17b1 in SMTask::Schedule () at SMTask.cc:248
#9  0x555ac22a in lftp_completion (text=, start=3, 
end=) at complete.cc:779
#10 0x77632107 in gen_completion_matches (text=0x558f3680 "/sr", 
start=, end=, our_func=0x77630500 
, found_quote=, 
quote_char=) at ./complete.c:1162
#11 0x776322e0 in rl_complete_internal (what_to_do=9) at 
./complete.c:1955
#12 0x77629597 in _rl_dispatch_subseq (key=9, map=, 
got_subseq=0) at ./readline.c:832
#13 0x77629981 in _rl_dispatch (key=, map=) at ./readline.c:775
#14 0x77629a22 in readline_internal_char () at ./readline.c:602
#15 0x7762a145 in readline_internal_charloop () at ./readline.c:629
#16 readline_internal () at ./readline.c:643
#17 readline (prompt=) at ./readline.c:369
#18 0x555ad286 in lftp_readline (prompt=) at lftp_rl.c:48
#19 0x555a9514 in ReadlineFeeder::NextCmd (this=0x558ea330, 
exec=0x558de8c0, prompt=0x558ec9a0 "lftp eizo.luffy.cx:~> ") at 
lftp.cc:157
#20 0x555b268f in CmdExec::Do (this=0x558de8c0) at CmdExec.cc:625
#21 0x555f15a5 in SMTask::ScheduleThis (this=0x558de8c0) at 
SMTask.cc:209
#22 0x555f17b1 in SMTask::Schedule () at SMTask.cc:248
#23 0x555af86d in Job::WaitDone (this=0x558de8c0) at Job.cc:549
#24 0x555a69cb in main (argc=, argv=0x7fffe648) at 
lftp.cc:589

In Fish::SendMethod, file is NULL. This has been fixed upstream:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832024
-- 
Test input for validity and plausibility.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#839941: whishlist ffmpeg

[Sebastian Ramacher]

On 2016-10-06 19:19:49, Bálint Réczey wrote:
> Hi Marc,
> 
> 2016-10-06 17:28 GMT+02:00 Struminski, Marc :
> > Package: ffmpeg
> > Severity: wishlist
> >
> > Hi maintainers,
> >
> > Is it possible to add libfreetype, nvenc, decklink and libmfx to ffmpeg in
> > Debian.
> 
> Libfreetype seems to be possible.

It's already used.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#839957: calibre: segmentation fault when quitting

[Luis Mochan]

Package: calibre
Version: 2.60.0+dfsg-1
Severity: minor

I run calibre from a terminal. Whenever I close it I get the message
'Segmentation fault'.

Regards,
Luis



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

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

Versions of packages calibre depends on:
ii  calibre-bin2.60.0+dfsg-1+b1
ii  fonts-liberation   1:1.07.4-2
ii  imagemagick8:6.8.9.9-7.2+b1
ii  libjs-mathjax  2.6.1-1
ii  poppler-utils  0.44.0-3
ii  python-apsw3.13.0-r1-1
ii  python-beautifulsoup   3.2.1-1
ii  python-chardet 2.3.0-2
ii  python-cherrypy3   3.5.0-2
ii  python-cssselect   0.9.2-1
ii  python-cssutils1.0-4.1
ii  python-dateutil2.5.3-2
ii  python-dbus1.2.4-1
ii  python-feedparser  5.1.3-3
ii  python-imaging 3.3.1-1
ii  python-lxml3.6.4-1
ii  python-markdown2.6.7-1
ii  python-mechanize   1:0.2.5-3
ii  python-netifaces   0.10.4-0.1+b2
ii  python-pil 3.3.1-1
ii  python-pkg-resources   28.0.0-1
ii  python-pyparsing   2.1.9+dfsg1-1
ii  python-pyqt5   5.7+dfsg-2
ii  python-pyqt5.qtsvg 5.7+dfsg-2
ii  python-pyqt5.qtwebkit  5.7+dfsg-2
ii  python-routes  2.3.1-2
ii  python2.7  2.7.12-3
ii  xdg-utils  1.1.1-1

Versions of packages calibre recommends:
ii  python-dnspython  1.14.0-3

calibre suggests no packages.

-- no debconf information

-- 

  o
W. Luis Mochán,  | tel:(52)(777)329-1734 /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388 `>/   /\
Apdo. Postal 48-3, 62251 |   (*)/\/  \
Cuernavaca, Morelos, México  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB

Bug#638514: max_unpacked_packages=1 doesn't actually clear up packages

[Chris Lamb]

forwarded 638514 https://github.com/lamby/aptfs/issues/2
thanks


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#638433: Doesn't work with file:// urls

[Chris Lamb]

forwarded 638433 https://github.com/lamby/aptfs/issues/1
thanks


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Adrian Bunk]

On Thu, Oct 06, 2016 at 09:48:02AM +0200, Vincent Bernat wrote:
>  ❦  5 octobre 2016 22:49 CEST, Philip Hands  :
> 
> > If you fancy explaining what you think browserified means w.r.t. the
> > Jison stuff, go ahead of course.  That might at least help to focus the
> > discussion a bit.  Just don't feel obliged to because I said so.
> 
> The libjs-handlebars issue has little to share with browserified
> JS. Browserified JS is usually just concatenated JS. Here, there is an
> equivalent of flex/bison involved. That's quite unusual and is more a
> build process. If the TC rules over this issue, it should drop the
> "browserified" part. Otherwise, a negative answer would also apply to
> more basic packages.
>...

Why is Grunt such a blocker here?

If I understand it correctly, Grunt is a powerful build system that can 
do a gazillion different things and has many dependencies.

For the basic browserified JS case, could a much simpler tool like
node-browserify-lite produce the same output?

cu
Adrian

-- 

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