Bug#829379: fix initialization of DEB_VENDOR for derivatives

[Rene Engelhard]

reassign 829379 src:libreoffice
severity 829379 wishlist
notfound 829379 5.2.0~rc1-1
thanks

Hi,

On Sat, Jul 02, 2016 at 10:47:45PM +0200, Jon Boden wrote:
> Package: libreoffice

It's not a bug in the package but in the source...

> Version: 5.2.0~rc1-1

That version doesn't exist and that confuses the BTS. The version is
1:5.2.0~rc1-1

> Tags: patch


How is this a "normal" bug? Sounds more like a minor bug or wishlist to me?

> debian/rules only supports two values for DEB_VENDOR: Debian and Ubuntu. As 
> derivative distributions put other values in this variable, libreoffice 
> cannot be built there.

Frankly speaking I consider the handling of Ubuntu there a nuisance, too.

And of course it can be built: patch it. This is a Debian package, not a
"general base for anything".

Regards,

Rene

Bug#829536: RM: erlang-hyperloglog -- ROM; not needed

[Philipp Huebner]

Package: ftp.debian.org
Severity: normal

Hi,
please remove erlang-hyplerloglog. I packaged it when I thought it would
be needed by ejabberd, but it wasn't and most likely never will be.
It's popcon value is near zero, so there's no point in keeping it
around.

Regards,
Philipp Huebner

Bug#829209: closed by (Bug#829209: fixed in libcypher-parser 0.3.4-1)

[Paul Wise]

On Sun, 2016-07-03 at 17:43 -0700, Chris Leishman wrote:

> Ok. I'll add that for next time.

Great, thanks.

> You'd think I'd know British spelling, but I've obviously been in the
> US for too long...

:)

-- 

bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#829379: fix initialization of DEB_VENDOR for derivatives

[Rene Engelhard]

Hi,

On Sun, Jul 03, 2016 at 10:01:57AM +0200, ericb wrote:
> Maybe a day, will be fixed the "apt-get install openoffice.org", installing
> LibreOffice.
> 
> Could be a great fix too. Waiting, this is just a shame, because LibreOffice
> is derivating the OpenOffice.org name.

You don't need to spam unrelated bugreports with that.

Besides, that it's lng fixed given there's no "openoffice.org" transitional
packages anymore since looong (it's not in any officially supported release[1]):

% rmadison openoffice.org
debian:
 openoffice.org | 1:3.2.1-11+squeeze8 | squeeze-security | source, amd64, 
armel, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, 
sparc
 openoffice.org | 1:3.2.1-11+squeeze8 | squeeze  | source, amd64, 
armel, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, 
sparc
 openoffice.org | 1:3.4.0~ooo340m1-7  | wheezy   | source, all

So since years:

% sudo apt-get install openoffice.org
[sudo] password for rene: 
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Package openoffice.org is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'openoffice.org' has no installation candidate

*If* you write mails like this please do your homework.

Regards,

Rene

[1] well, wheezy-lts has it, but...

Bug#829509: [Pkg-shadow-devel] Bug#829509: echo * ** *** when typing password, like all moblie apps

[積丹尼 Dan Jacobson]

All I know is I always wonder if my keyboard is attached.
I can't think of any program anywhere that does it different these days.

Bug#829535: kmail: Typo in recommends (kdepim-themeeditors)

[Zhang Jingqiang]

Package: kmail
Version: 4:16.04.2-1
Severity: minor
Tags: patch

Should be kdepim-themeeditors but not kdepim-themeditors.

Thanks

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

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

Versions of packages kmail depends on:
ii  akonadi-server  4:16.04.2-1
ii  kdepim-runtime  4:16.04.2-1
ii  kdepimlibs-data 4:16.04.2-1
ii  kf5-kdepimlibs-kio-plugins  4:16.04.2-1
ii  libc6   2.23-1
ii  libgcc1 1:6.1.1-8
ii  libkf5akonadiagentbase5 4:16.04.2-1
ii  libkf5akonadicalendar5  16.04.2-1
ii  libkf5akonadicontact5   4:16.04.2-1
ii  libkf5akonadicore-bin   4:16.04.2-1
ii  libkf5akonadicore5  4:16.04.2-1
ii  libkf5akonadimime5  4:16.04.2-1
ii  libkf5akonadisearchdebug5   16.04.2-1
ii  libkf5akonadiwidgets5   4:16.04.2-1
ii  libkf5alarmcalendar516.04.2-1
ii  libkf5archive5  5.23.0-1
ii  libkf5bookmarks55.23.0-1
ii  libkf5calendarcore5 4:16.04.2-1
ii  libkf5calendarsupport5  4:16.04.2-1
ii  libkf5calendarutils516.04.2-1
ii  libkf5codecs5   5.23.0-1
ii  libkf5completion5   5.23.0-1
ii  libkf5configcore5   5.23.0-1
ii  libkf5configgui55.23.0-1
ii  libkf5configwidgets55.23.0-1
ii  libkf5contacts5 16.04.2-1
ii  libkf5coreaddons5   5.23.0-1
ii  libkf5crash55.23.0-1
ii  libkf5dbusaddons5   5.23.0-1
ii  libkf5followupreminder5 4:16.04.2-1
ii  libkf5gpgmepp-pthread5  16.04.2-1
ii  libkf5gravatar5 4:16.04.2-1
ii  libkf5guiaddons55.23.0-1
ii  libkf5i18n5 5.23.0-1
ii  libkf5iconthemes5   5.23.0-1
ii  libkf5identitymanagement5   16.04.2-1
ii  libkf5incidenceeditor-bin   16.04.2-1
ii  libkf5incidenceeditor5  16.04.2-1
ii  libkf5itemmodels5   5.23.0-1
ii  libkf5itemviews55.23.0-1
ii  libkf5jobwidgets5   5.23.0-1
ii  libkf5kcmutils5 5.23.0-1
ii  libkf5kdelibs4support5  5.23.0-1
ii  libkf5kiocore5  5.23.0-1
ii  libkf5kiofilewidgets5   5.23.0-1
ii  libkf5kiowidgets5   5.23.0-1
ii  libkf5kmanagesieve5 4:16.04.2-1
ii  libkf5kontactinterface5 16.04.2-1
ii  libkf5ksieveui5 4:16.04.2-1
ii  libkf5libkdepim-plugins 4:16.04.2-1
ii  libkf5libkdepim54:16.04.2-1
ii  libkf5libkleo5  4:16.04.2-1
ii  libkf5mailcommon-plugins4:16.04.2-1
ii  libkf5mailcommon5   4:16.04.2-1
ii  libkf5mailimporter5 4:16.04.2-1
ii  libkf5mailtransport516.04.2-1
ii  libkf5messagecomposer5  4:16.04.2-1
ii  libkf5messagecore5  4:16.04.2-1
ii  libkf5messagelist5  4:16.04.2-1
ii  libkf5messageviewer54:16.04.2-1
ii  libkf5mime5 16.04.2-1
ii  libkf5notifications55.23.0-1
ii  libkf5notifyconfig5 5.23.0-1
ii  libkf5parts55.23.0-1
ii  libkf5pimcommon-plugins 4:16.04.2-1
ii  libkf5pimcommon54:16.04.2-1
ii  libkf5pimtextedit5  16.04.2-1
ii  libkf5sendlater54:16.04.2-1
ii  libkf5service-bin   5.23.0-1
ii  libkf5service5  5.23.0-1
ii  libkf5sonnetui5 5.23.0-1
ii  libkf5templateparser5   4:16.04.2-1
ii  libkf5textwidgets5  5.23.0-1
ii  libkf5wallet-bin5.23.0-1
ii  libkf5wallet5   5.23.0-1
ii  libkf5widgetsaddons55.23.0-1
ii  libkf5windowsystem5 5.23.0-1
ii  libkf5xmlgui5   5.23.0-1
ii  libqt5core5a5.6.1+dfsg-3
ii  libqt5dbus5 5.6.1+dfsg-3
ii  libqt5gui5  5.6.1+dfsg-3
ii  libqt5network5  5.6.1+dfsg-3
ii  libqt5widgets5  5.6.1+dfsg-3
ii  libqt5xml5  5.6.1+dfsg-3
ii  libstdc++6  6.1.1-8

Versions of packages kmail recommends:
ii  accountwizard   4:16.04.2-1
ii  gnupg-agent 2.1.11-7
ii  gnupg2  2.1.11-7
ii  kdepim-addons   16.04.2-1
pn  kdepim-doc  
pn  kdepim-themeditors  
ii  ktnef   4:16.04.2-1
ii  pinentry-qt [pinentry-x11]  0.9.7-5

Versions of packages kmail suggests:
ii  clamav 0.99.2+dfsg-2
ii  kaddressbook   4:16.04.1-1
pn  kleopatra  
pn  procmail   
pn  spamassassin | bogofilter | spambayes | bsfilter | crm114  

-- no debconf information

Bug#829533: kdenlive: Track effects are broken

[Kyanos]

Package: kdenlive
Version: 16.04.2-1
Severity: normal

Dear Maintainer,

Effects on tracks are not working. I tried this with multiple effects
and they are all broken when applied to tracks (as opposed to clips).

Audio effects are ignored, while video clips cause a crash upon trying
to preview the video in the Project Monitor. GDB session follows:


Thread 43 "RenderThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff89ffa700 (LWP 10882)]
convert_image (frame=0x7fff78b10ca0, image=0x7fff89ff9c58,
format=0x5854408c, output_format=mlt_image_yuv422)
at filter_avcolour_space.c:194
194 filter_avcolour_space.c: No such file or directory.
(gdb) bt
#0  convert_image (frame=0x7fff78b10ca0, image=0x7fff89ff9c58,
format=0x5854408c, output_format=mlt_image_yuv422)
at filter_avcolour_space.c:194
#1  0x766d3b58 in mlt_frame_get_image (self=0x7fff78b10ca0,
buffer=0x7fff89ff9c58, format=0x5854408c, width=0x7fff89ff9c44,
height=0x7fff89ff9c48, writable=0) at mlt_frame.c:591
#2  0x766d3b07 in mlt_frame_get_image
(self=self@entry=0x7fff78b10ca0,
buffer=buffer@entry=0x7fff89ff9c58, format=format@entry=0x5854408c,
width=width@entry=0x7fff89ff9c44, height=height@entry=0x7fff89ff9c48,
writable=writable@entry=0) at mlt_frame.c:585
#3  0x766e9a89 in producer_get_image
(self=self@entry=0x7fff78b0efb0,
buffer=buffer@entry=0x7fff89ff9c58, format=format@entry=0x5854408c,
width=width@entry=0x7fff89ff9c44, height=height@entry=0x7fff89ff9c48,
writable=writable@entry=0) at mlt_tractor.c:370
#4  0x766d3b07 in mlt_frame_get_image
(self=self@entry=0x7fff78b0efb0,
buffer=buffer@entry=0x7fff89ff9c58, format=format@entry=0x5854408c,
width=width@entry=0x7fff89ff9c44, height=height@entry=0x7fff89ff9c48,
writable=writable@entry=0) at mlt_frame.c:585
#5  0x766e7120 in consumer_read_ahead_thread (arg=0x58539eb0)
at mlt_consumer.c:897
#6  0x558514ed in RenderThread::run (this=0x7fff9b5facd0)
at /build/kdenlive-16.04.2/src/monitor/glwidget.cpp:1230
#7  0x70778808 in QThreadPrivate::start (arg=0x7fff9b5facd0)
at thread/qthread_unix.cpp:341
#8  0x7fffec742464 in start_thread (arg=0x7fff89ffa700)
at pthread_create.c:334
#9  0x7fffefb7be5d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109


Thank you for your consideration.

Kyanos

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

Kernel: Linux 4.6.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 kdenlive depends on:
ii  ffmpeg   7:3.0.2-4
ii  kded55.22.0-1
ii  kdenlive-data16.04.2-1
ii  kinit5.22.0-1
ii  kio  5.22.0-1
ii  libc62.22-11
ii  libgcc1  1:6.1.1-7
ii  libgl1-mesa-glx [libgl1] 11.2.2-1
ii  libglu1-mesa [libglu1]   9.0.0-2.1
ii  libkf5archive5   5.23.0-1
ii  libkf5attica55.23.0-1
ii  libkf5auth5  5.23.0-1
ii  libkf5bookmarks5 5.22.0-2
ii  libkf5codecs55.23.0-1
ii  libkf5completion55.23.0-1
ii  libkf5configcore55.23.0-1
ii  libkf5configgui5 5.23.0-1
ii  libkf5configwidgets5 5.22.0-1
ii  libkf5coreaddons55.23.0-1
ii  libkf5crash5 5.23.0-1
ii  libkf5dbusaddons55.23.0-1
ii  libkf5filemetadata3  5.22.0-1
ii  libkf5guiaddons5 5.23.0-1
ii  libkf5i18n5  5.22.1-1
ii  libkf5iconthemes55.22.0-1
ii  libkf5itemviews5 5.23.0-1
ii  libkf5jobwidgets55.23.0-1
ii  libkf5kiocore5   5.22.0-1
ii  libkf5kiofilewidgets55.22.0-1
ii  libkf5kiontlm5   5.22.0-1
ii  libkf5kiowidgets55.22.0-1
ii  libkf5newstuff5  5.22.0-1
ii  libkf5notifications5 5.23.0-1
ii  libkf5notifyconfig5  5.22.0-1
ii  libkf5plotting5  5.23.0-1
ii  libkf5service-bin5.22.0-1
ii  libkf5service5   5.22.0-1
ii  libkf5solid5 5.23.0-1
ii  libkf5sonnetui5  5.23.0-1
ii  libkf5textwidgets5   5.22.0-1
ii  libkf5widgetsaddons5 5.23.0-1
ii  libkf5xmlgui55.22.0-1
ii  libmlt++36.2.0-1
ii  libmlt6  6.2.0-1
ii  libqt5concurrent55.6.1+dfsg-3
ii  libqt5core5a 5.6.1+dfsg-3
ii  libqt5dbus5  5.6.1+dfsg-3
ii  libqt5gui5   5.6.1+dfsg-3
ii  libqt5network5   5.6.1+dfsg-3
ii  libqt5qml5   5.6.1-4
ii 

Bug#828819: intel-microcode: i7-6500U doesn't boot in 4/5 cases with 3.20160607.1

[Mike Palmer]

I had exactly the same issue with an ASUS UX305CA ultrabook.
Downgrading to the previous version of intel-microcode resolved it for
me as well. I was able to get intel-microcode 3.20160607.1 working by
upgrading from UX305CA.205 to UX305CA.300 BIOS revision from ASUS.

---

# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.
Table at 0x87656000.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: UX305CA.300
Release Date: 06/08/2016
Address: 0xF
Runtime Size: 64 kB
ROM Size: 6016 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
Smart battery is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 5.11

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: UX305CA
Version: 1.0   
Serial Number: FBN0CJ079030468 
UUID: 6AE3C30A-AE8A-804D-9527-6CE0851C1EF6
Wake-up Type: Power Switch
SKU Number: ASUS-NotebookSKU
Family: UX

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: UX305CA
Version: 1.0   
Serial Number: BSN12345678901234567
Asset Tag: ATN12345678901234567
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: MIDDLE  
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
Manufacturer: ASUSTeK COMPUTER INC.
Type: Notebook
Lock: Not Present
Version: 1.0   
Serial Number: FBN0CJ079030468 
Asset Tag: ATN12345678901234567
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0
SKU Number: Default string

Handle 0x0004, DMI type 10, 26 bytes
On Board Device 1 Information
Type: Video
Status: Enabled
Description:  VGA
On Board Device 2 Information
Type: Ethernet
Status: Enabled
Description:  GLAN
On Board Device 3 Information
Type: Ethernet
Status: Enabled
Description:  WLAN
On Board Device 4 Information
Type: Sound
Status: Enabled
Description:  Audio CODEC 
On Board Device 5 Information
Type: SATA Controller
Status: Enabled
Description:  SATA Controller
On Board Device 6 Information
Type: Other
Status: Enabled
Description:  USB 2.0 Controller
On Board Device 7 Information
Type: Other
Status: Enabled
Description:  USB 3.0 Controller
On Board Device 8 Information
Type: Other
Status: Enabled
Description:  SMBus Controller
On Board Device 9 Information
Type: Other
Status: Enabled
Description:  Card Reader
On Board Device 10 Information
Type: Other
Status: Enabled
Description:  Cmos Camera
On Board Device 11 Information
Type: Other
Status: Enabled
Description:  Bluetooth

Handle 0x0005, DMI type 11, 5 bytes
OEM Strings
String 1:  
String 2:  
String 3:  
String 4: 90NB0AA3-M00800
String 5:  
String 6:  
String 7:  
String 8:  
String 9:  
String 10:  

Handle 0x000C, DMI type 32, 20 bytes
System Boot Information
Status: No errors detected

Handle 0x000D, DMI type 7, 19 bytes
Cache Information
Socket Designation: L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 64 kB
Maximum Size: 64 kB
Supported SRAM Types:
Synchronous
Installed SRAM 

Bug#829096: [Pkg-emacsen-addons] Bug#829096: dh-make-elpa: fails to determine that it was not ran from git repository

[Lev Lamberov]

Hi Sean,

04.07.2016 06:59, Sean Whitton пишет:
> You know that smex is already packaged for Debian, right?

Yes, I've just tried smex to test dh-make-elpa.

> The two errors that you report are actually unrelated.  However, both of
> them are harmless

... and that's why I chose severity of #829096 as minor.


> dh-make-elpa is just failing to generate some files
> because it doesn't have enough information.  I've changed it to fail
> silently -- thanks.

And another option would be not fail silently (and not fail with
ordinary error message), but rather report a kind of warning or some
message that some particular information cannot be extracted. In this
case it will not scare users of dh-make-elpa and will inform them about
problems.

Cheers!
Lev Lamberov



signature.asc
Description: OpenPGP digital signature

Bug#816170: False positive deleted files after upgrade from wheezy to jessie

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Am Mo den  4. Jul 2016 um  1:29 schrieb Francois Marier:
> On 2016-04-26 at 13:50:21, Klaus Ethgen wrote:
> > Find attached a patch, cherry-picked from upstream, that fixes the
> > issue. Particular, it is c4d6d8b, 1e5e79a and b4a21a8.
> 
> Which upstream repo did you pull that from?
> 
> The only repo I know about is a CVS one on Sourceforge:
> 
>   http://rkhunter.cvs.sourceforge.net/viewvc/rkhunter/rkhunter/

Sorry, yes.

I just imported that into GIT to have a usable frontend and forgot that
CVS does not handle the same versions.

c4d6d8b is 4 commits after v1.4.3, 1e5e79a is 25 commits after and
b4a21a8 is 26 commits after that tag.

Regards
   Klaus
- -- 
Klaus Ethgen  http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Charset: ISO-8859-1

iQGcBAEBCgAGBQJXee3TAAoJEKZ8CrGAGfasxGQL+QFZ93h1uWVR0/t7NekNayYb
KqI/55sfSZMB0AINu+CVnsQH/RaKRUst55hY7ACdyRaHdan4/azxpvOfPfL7UGPR
GXY4N997uu9YJyyUB1ppVcJHvZ76hP4TQUvWNbib9ngvRkjh1948RyVYhnS3fvTJ
GhFvlHgHyqeRhqvD52mg6X7gl2Xpw7BFHyCtePCRALGi/csyg/hQDCihlK1IQugJ
JK4RvLvkEN08WkfCJWCMY1YKR/tDmi4yezWp4taWaNHbviK90lvaWmX6K4Mf6Zeq
qhyHTkjyzD5IfLPdOoLITZ1msr6enRt92sCmoaj0j2zfuVacw2rbIhYY3jCqXc0w
KFXUFMwHzunOA5189TZTev7hCIelBpFecbk24Rqt0T0BBwuUpYqtCE4bttSJRDY+
hJ+i8uYWhjOOllCmrraSjoZZmgYxhhHJurlnnvs/hleG8a6tHnAz4RbvjhoPhtNK
5rB0Wo3NOP+lGp24DWbAcwdImXZeVFy09gVRe2gaDg==
=R/sz
-END PGP SIGNATURE-

Bug#829532: linux-image-4.6.0-0.bpo.1-amd64: breaks qemu-nbd

[westlake]

Package: linux-image-4.6.0-0.bpo.1-amd64
Version: 4.6.1-1~bpo8+1
Severity: normal

kernels 4.5 and 4.6 breaks qemu-nbd from mapping partitions

qemu-nbd can map partitions from VM images and raw disk images to
/dev/nbdNpM nodes, but proper module options have to be loaded prior so
that qemu-nbd performs these additional mappings (the general consensus
around mapping image files has users issuing "kpartx -a /dev/",
but kpartx is not needed at all after issuing qemu-nbd)

nothing is specially set up other than a module option file and that's
pretty much it -- there's just 2 or 3 commands for the testing --- all
which indicates the issue is more towards kernel than it is with qemu-nbd.

after a modprobe nbd is issued, there is no "/dev/nbd0p1"-like devices,
so the main problem with kernels 4.5/4.6 is that qemu-nbd is not being
allowed to generate any device nodes. ("partition" device nodes that is
-- "/dev/nbd0" and "/dev/nbd1" nodes are generated by modprobe nbd)

here in nbd(module) options, there is a hint for max_part that needs to
be specified in order for qemu-nbd to later work in generating the
partition devices /dev/nbdNpM.
(nbds_max=2 just means for modprobe to create "/dev/nbd0" and "/dev/nbd1")

/etc/modprobe.d/mynbd.conf
"
options nbd nbds_max=2 max_part=10
"

basically just a raw disk image containing one partition

dd if=/dev/zero of=1.bin bs=10M count=10
 ,creates a raw diskimage called 1.bin

any tool to create a dosmbr table containing at least 1 partition
(qemu-nbd can also work with GPT tables but it is not used)
 cfdisk 1.bin , and exit the partition tool

no mkfs is needed, so one can immediately try to map the partitions from
the disk image 1.bin just by using qemu-nbd (here again "kpartx" is not
used at all. If one uses "kpartx", then it would rather create partition
device nodes in /dev/mapper.  Using qemu-nbd -d [/dev/nbdN] also unmaps
partition nodes.. so forgetting to issue kpartx -d /dev/nbd0 prior
qemu-nbd -d, would leave a mess of broken device links in /dev/mapper)

qemu-nbd should map 1.bin to /dev/nbd0 and its first partition to
"/dev/nbd0p1". this partition device node does not exist yet but is
something that qemu-nbd would generate

"qemu-nbd -c /dev/nbd0 1.bin"

there is an option "-P "(qemu-nbd command) for specifying an exposure to
a single partition, but this has null effect
" -P, --partition=num
  only expose partition I"

it is always "qemu-nbd -c /dev/nbd0 [IMAGE FILE]" that works (and after
max_part is used with "modprobe nbd") -- the /dev/nbd0p1 node then gets
generated... so something is up with the later kernels in breaking this
particular behaviour feature on behalf of qemu-nbd

Here the qemu-utils was updated and still no success...dmesg shows no
errors... there's also no errors from qemu-nbd's output but there is a
new notice about using "-f raw" for more safety for the end-user.

... the outcome is still the same (with or without "-f raw") -- the end
result is the image file is still treated as a "raw disk" which is
correct but there is no generation of partition devices

some output for the report,

modprobe -vvv nbd
insmod /lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko
nbds_max=20 max_part=10
modprobe: DEBUG: ../libkmod/libkmod-module.c:728 kmod_module_get_path()
name='nbd'
path='/lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko'

dpkg -l 'linux-image*'
ii linux-image-4.5.0-0.bpo.2-amd64 4.5.4-1~bpo8+1 amd64 Linux 4.5 for
64-bit PCs
ii linux-image-4.5.0-2-grsec-amd64 4.5.7-1+grsec201606222150+1~bpo8+1
amd64 Linux 4.5 for 64-bit PCs, Grsecurity protection
ii linux-image-4.6.0-0.bpo.1-amd64 4.6.1-1~bpo8+1 amd64 Linux 4.6 for
64-bit PCs

apt-cache policy qemu-utils
qemu-utils:
  Installed: 1:2.1+dfsg-12+deb8u6
  Candidate: 1:2.1+dfsg-12+deb8u6
  Version table:
 1:2.5+dfsg-4~bpo8+1 0
100 http://debian.bhs.mirrors.ovh.net/debian/
jessie-backports/main amd64 Packages
 *** 1:2.1+dfsg-12+deb8u6 0
500 http://debian.bhs.mirrors.ovh.net/debian/ jessie/main amd64
Packages
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status

linux-image-4.3.0-0.bpo.1-amd64   4.3.5-1~bpo8+1

latest kernel that works is 4.3, though i don't have access to a 4.4
kernel, i can't tell when between 4.3 and 4.5 qemu-nbd started to fail

Bug#829286: RFS: newlisp/10.7.0-2

[Sergio Durigan Junior]

On Sunday, July 03 2016, James Cowgill wrote:

>> Hm, here's what I see when I try it:
>> 
>>   D: dcut 0.2.1
>>   D: trying to get maintainer email from environment
>>   D: Uploader from env: Sergio Durigan Junior 
>>   D: first argument "ftp-master" treated as host
>>   D: loading dput
>>   D: calling dput.read_configs
>>   D: Parsing Configuration File /etc/dput.cf
>>   D: Parsing Configuration File /home/sergio/.dput.cf
>>   D: Successfully parsed command "reschedule -d 0 -f 
>> newlisp_10.7.0-2_source.changes"
>>   D: calling debsign: ['debsign', '-mSergio Durigan Junior ',
>>   
>> '/tmp/dcut.RMMfsD/dcut.Sergio_Durigan_Junior__sergiodj_sergiodj_net_.1467570258.1694.commands']
>>   .commands file has invalid Commands line: reschedule -d 0 -f 
>> newlisp_10.7.0-2_source.changes
>>   debsign: .commands file appears to be invalid. see:
>>   ftp://ftp.upload.debian.org/pub/UploadQueue/README
>>   for valid format
>>   Error: debsign failed.
>> 
>> Is this my fault?
>
> I think the syntax is:
>  dcut reschedule newlisp_10.7.0-2_source.changes 0-day
>
> The above link that dcut outputted contains the format of all the
> available commands.

Still nothing.  I had read the page, but it mentions the format of the
.commands file, and not dcut's CLI options.  I also tried specifying the
options in a different order, but I get the same error.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829531: icedove: Icedove closes abruptly

[Chad Fernandez]

Package: icedove
Version: 1:45.1.0-1~deb8u1
Severity: important

Dear Maintainer,


   * What led up to the situation?

I beleive the 6/14/2016 update started this.

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

While deleting or selecting to read an unread email the program simply closes.  
Relaunching Icedove allows for further progress, but sometimes it closes again, 
right away. 


-- System Information:
Debian Release: 8.5
  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.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 icedove depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u4
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libdbus-1-3   1.8.20-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libpixman-1-0 0.32.6-3
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
pn  iceowl-extension  

Versions of packages icedove suggests:
ii  fonts-lyx 2.1.2-2
ii  libgssapi-krb5-2  1.12.1+dfsg-19+deb8u2

-- no debconf information

Bug#829530: linux-image-4.5.0-0.bpo.2: breaks qemu-nbd

[westlake]

Package: linux-image-4.5.0-0.bpo.2-amd64
Version: 4.5.4-1~bpo8+1
Severity: normal

kernels 4.5 and 4.6 breaks qemu-nbd from mapping partitions

qemu-nbd can map partitions from VM images and raw disk images to
/dev/nbdNpM nodes, but proper module options have to be loaded prior so
that qemu-nbd performs these additional mappings (the general consensus
around mapping image files has users issuing "kpartx -a /dev/",
but kpartx is not needed at all after issuing qemu-nbd)

nothing is specially set up other than a module option file and that's
pretty much it -- there's just 2 or 3 commands for the testing --- all
which indicates the issue is more towards kernel than it is with qemu-nbd.

after a modprobe nbd is issued, there is no "/dev/nbd0p1"-like devices,
so the main problem with kernels 4.5/4.6 is that qemu-nbd is not being
allowed to generate any device nodes. ("partition" device nodes that is
-- "/dev/nbd0" and "/dev/nbd1" nodes are generated by modprobe nbd)

here in nbd(module) options, there is a hint for max_part that needs to
be specified in order for qemu-nbd to later work in generating the
partition devices /dev/nbdNpM.
(nbds_max=2 just means for modprobe to create "/dev/nbd0" and "/dev/nbd1")

/etc/modprobe.d/mynbd.conf
"
options nbd nbds_max=2 max_part=10
"

basically just a raw disk image containing one partition

dd if=/dev/zero of=1.bin bs=10M count=10
 ,creates a raw diskimage called 1.bin

any tool to create a dosmbr table containing at least 1 partition
(qemu-nbd can also work with GPT tables but it is not used)
 cfdisk 1.bin , and exit the partition tool

no mkfs is needed, so one can immediately try to map the partitions from
the disk image 1.bin just by using qemu-nbd (here again "kpartx" is not
used at all. If one uses "kpartx", then it would rather create partition
device nodes in /dev/mapper.  Using qemu-nbd -d [/dev/nbdN] also unmaps
partition nodes.. so forgetting to issue kpartx -d /dev/nbd0 prior
qemu-nbd -d, would leave a mess of broken device links in /dev/mapper)

qemu-nbd should map 1.bin to /dev/nbd0 and its first partition to
"/dev/nbd0p1". this partition device node does not exist yet but is
something that qemu-nbd would generate

"qemu-nbd -c /dev/nbd0 1.bin"

there is an option "-P "(qemu-nbd command) for specifying an exposure to
a single partition, but this has null effect
" -P, --partition=num
  only expose partition I"

it is always "qemu-nbd -c /dev/nbd0 [IMAGE FILE]" that works (and after
max_part is used with "modprobe nbd") -- the /dev/nbd0p1 node then gets
generated... so something is up with the later kernels in breaking this
particular behaviour feature on behalf of qemu-nbd

Here the qemu-utils was updated and still no success...dmesg shows no
errors... there's also no errors from qemu-nbd's output but there is a
new notice about using "-f raw" for more safety for the end-user.

... the outcome is still the same (with or without "-f raw") -- the end
result is the image file is still treated as a "raw disk" which is
correct but there is no generation of partition devices

some output for the report,

modprobe -vvv nbd
insmod /lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko
nbds_max=20 max_part=10
modprobe: DEBUG: ../libkmod/libkmod-module.c:728 kmod_module_get_path()
name='nbd'
path='/lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko'

dpkg -l 'linux-image*'
ii linux-image-4.5.0-0.bpo.2-amd64 4.5.4-1~bpo8+1 amd64 Linux 4.5 for
64-bit PCs
ii linux-image-4.5.0-2-grsec-amd64 4.5.7-1+grsec201606222150+1~bpo8+1
amd64 Linux 4.5 for 64-bit PCs, Grsecurity protection
ii linux-image-4.6.0-0.bpo.1-amd64 4.6.1-1~bpo8+1 amd64 Linux 4.6 for
64-bit PCs

apt-cache policy qemu-utils
qemu-utils:
  Installed: 1:2.1+dfsg-12+deb8u6
  Candidate: 1:2.1+dfsg-12+deb8u6
  Version table:
 1:2.5+dfsg-4~bpo8+1 0
100 http://debian.bhs.mirrors.ovh.net/debian/
jessie-backports/main amd64 Packages
 *** 1:2.1+dfsg-12+deb8u6 0
500 http://debian.bhs.mirrors.ovh.net/debian/ jessie/main amd64
Packages
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status

linux-image-4.3.0-0.bpo.1-amd64   4.3.5-1~bpo8+1

latest kernel that works is 4.3, though i don't have access to a 4.4
kernel, i can't tell when between 4.3 and 4.5 qemu-nbd started to fail

Bug#829529: linux-image-4.6.0-1-amd64: Please enable intel hid module

[Shengjing Zhu]

Package: src:linux
Version: 4.6.2-2
Severity: wishlist

Dear Maintainer,

intel-hid module supports various hid events including hotkeys.
Dell XPS 13 9350 requires it for wireless hotkey.

http://permalink.gmane.org/gmane.linux.drivers.platform.x86.devel/8161

I wish you could enable this module. This module is available in kernel 4.6

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

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

Versions of packages linux-image-4.6.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.125
ii  kmod22-1.1
ii  linux-base  4.3

Versions of packages linux-image-4.6.0-1-amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2

Versions of packages linux-image-4.6.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi2.02~beta2-36
pn  linux-doc-4.6   

Versions of packages linux-image-4.6.0-1-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
ii  firmware-brcm8021120160110-1
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
ii  firmware-misc-nonfree 20160110-1
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#829456: RFS: jquery-throttle-debounce/1.1+dfsg.1-1

[Ben Finney]

Gianfranco Costamagna  writes:

> I'm not completely satisfied with the packaing, sorry!

Thank you for taking this sponsorship request.

> look e.g. to the various node-* packages, they seem to be "clean" in
> the debian directory, your packaging seems more complicate

Can you point me to specific parts that you want to be cleaner, and how
they should be cleaned?

> but the problem I see is missing copyrights, e.g.
> ./examples/index.css:Copyright (c) 2008, Yahoo! Inc. All rights reserved.
> ./examples/index.css:Copyright (c) 2008, Yahoo! Inc. All rights reserved.
> ./examples/index.css:Copyright (c) 2008, Yahoo! Inc. All rights reserved.

Thank you for finding those, I will remove the file. More bundled
third-party files that can't be in the source package :-/

-- 
 \ “Everything is futile.” —Marvin of Borg |
  `\   |
_o__)  |
Ben Finney

Bug#826994: [Pkg-zfsonlinux-devel] Bug#826994: Bug#826994: Missing init-script(s)?

[Richard Laager]

On 07/03/2016 09:37 PM, Tim Connors wrote:

(we've also lost:
-rw-r--r-- root/root 11305 2016-05-20 08:52 ./etc/bash_completion.d/zfs


This is present:
/usr/share/bash-completion/completions/zfs

--
Richard

Bug#726530: bug still present in Fvwm 2.6.5

[Jim Cline]

further to my previous message, I should have mentioned that I experienced 
the crashes using version fvwm/1:2.6.5.ds-4.1.  Downgrading to 
version 1.2.5.30.ds-1 seems to solve the problem.  It might also be 
worth mentioning that both times the crash was triggered by closing the 
.fvwm2rc file in nedit.

Bug#829528: Please migrate bash-completion file from "bash-completion" package to desktop-file-utils

[Josh Triplett]

Package: desktop-file-utils
Version: 0.23-1
Severity: wishlist

The changelog for 0.23-1 mentions:
>   * Do not install bash-completion (already provided by "bash-completion").

This seems the wrong way around.  bash-completion provides completions
for packages that don't provide completions for themselves.[1]  If a
package has its own completion file, ideally bash-completion should stop
providing that completion, and the package should start providing it
(and conflict with bash-completion versions that provided it).

- Josh Triplett

[1] Insert paradox joke here.

Bug#826994: [Pkg-zfsonlinux-devel] Bug#826994: Missing init-script(s)?

[Tim Connors]

DDs - any news on this?

zfsutils_0.6.5.7-8-jessie_amd64.deb from ZoL contained amongst others:

-rwxr-xr-x root/root  2871 2016-05-20 08:59 ./etc/init.d/zfs-zed
-rwxr-xr-x root/root  5623 2016-05-20 08:59 ./etc/init.d/zfs-mount
-rwxr-xr-x root/root  2262 2016-05-20 08:59 ./etc/init.d/zfs-share
-rwxr-xr-x root/root  5100 2016-05-20 08:59 ./etc/init.d/zfs-import

This was sufficient to ensure my pools were all imported and mounted on
the systems I've banished systemd from for reliability reasons.  Alas, all
that zfsutils-linux in debian contains in the whole of /etc/ are:

168691,5> dpkg -L zfsutils-linux  | grep /etc/
/etc/cron.d
/etc/cron.d/zfsutils-linux
/etc/default
/etc/default/zfs
/etc/zfs
/etc/zfs/zfs-functions


(we've also lost:
-rw-r--r-- root/root 11305 2016-05-20 08:52 ./etc/bash_completion.d/zfs
)


-- 
Tim Connors

Bug#829208: RFS: evil-paredit-el/0.0.2-1 ITP

[Sean Whitton]

control: noowner -1
control: tag -1 +confirmed -moreinfo

Dear Dmitry,

In my view evil-paredit-el is ready to be uploaded, bar `dch -r`.
Thanks.

-- 
Sean Whitton

Bug#829516: ITP: cubicsdr -- software defined radio receiver

[A . Maitland Bottoms]

Hi!

Welcome to the wonderful world of SDR software in Debian!

I have been considering packaging the liquidsdr library too.
For CubicSDR, I think the existing fonts-dejavu package could be used
instead of the CubicSDR/font directory.

Good luck,
-Maitland

Bug#829522: glances: crashes when checking processes that already finished

[Daniel Echeverry]

Hi Tiago!

Thanks for the report!

2016-07-03 20:16 GMT-05:00 Tiago Ilieve :
> Package: glances
> Version: 2.1.1-1
> Severity: important
>
> Hi Daniel and Sebastien,
>
> Sometimes, when I left glances running for a while (can't say exactly,
> but at least a few minutes) it crashes showing the following exceptions:
>
> -8<-
>
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/psutil/_pslinux.py", line 694, in 
> wrapper
> return fun(self, *args, **kwargs)
>   File "/usr/lib/python3/dist-packages/psutil/_pslinux.py", line 724, in name
> f = open(fname, "rt", encoding=DEFAULT_ENCODING)
>   FileNotFoundError: [Errno 2] No such file or directory: '/proc/672/stat'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>  File "/usr/bin/glances", line 9, in 
>load_entry_point('Glances==2.1.1', 'console_scripts', 'glances')()
>  File "/usr/lib/python3/dist-packages/glances/__init__.py", line 121, in main
>standalone.serve_forever()
>  File "/usr/lib/python3/dist-packages/glances/core/glances_standalone.py", 
> line 71, in serve_forever
>self.stats.update()
>  File "/usr/lib/python3/dist-packages/glances/core/glances_stats.py", line 
> 130, in update
>self.__update__(input_stats)
>  File "/usr/lib/python3/dist-packages/glances/core/glances_stats.py", line 
> 121, in __update__
>self._plugins[p].update()
>  File 
> "/usr/lib/python3/dist-packages/glances/plugins/glances_processcount.py", 
> line 55, in update
>glances_processes.update()
>  File "/usr/lib/python3/dist-packages/glances/core/glances_processes.py", 
> line 324, in update
>standard_stats=self.get_max_processes() is None)
>  File "/usr/lib/python3/dist-packages/glances/core/glances_processes.py", 
> line 149, in __get_process_stats
>procstat.update(proc.as_dict(attrs=['cpu_percent', 'memory_percent', 
> 'name'], ad_value=''))
>  File "/usr/lib/python3/dist-packages/psutil/__init__.py", line 414, in 
> as_dict
>ret = attr()
>  File "/usr/lib/python3/dist-packages/psutil/__init__.py", line 490, in name
>name = self._proc.name()
>  File "/usr/lib/python3/dist-packages/psutil/_pslinux.py", line 704, in 
> wrapper
>raise NoSuchProcess(self.pid, self._name)
>  psutil.NoSuchProcess: process no longer exists (pid=672)
>
> -8<-
>
> Looks like it crashes when looking for information about a process that
> already finished. It also messes the terminal (/bin/bash), needing a
> "reset" command or closing it and opening a new one (but I guess this is
> expected when a curses-based tool isn't properly finished).
>
> Regards,
> Tiago.
>

Could you test if the crash persists with last version in unstable [1]?

> P.s.: Thanks for you work adopting this package a few months ago. It is a
> really useful monitoring tool.
>
>

It is a pleasure for us ;)

Regards

[1]: https://packages.debian.org/source/unstable/glances

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
http://rinconinformatico.net
Linux user: #477840
Debian user

Bug#824955: u-boot: please enable support for dragonboard410c

[Ricardo Salveti]

On Sat, May 28, 2016 at 11:07 PM, Vagrant Cascadian  wrote:
>> The patch also includes a packaging patch that fixes the distro
>> bootcmd support, and also some minor fixes for extlinux and pxeboot
>> support (which I'm also forwarding upstream).
>
> Please get those patches upstream. Though at a quick glance, the changes
> seem mostly reasonable. A few comments below...

Env size change is now a backport, and finally had time to send the
other fixes I had (just missing the fixed bootcmd_mmc0 change, trying
to play with mbr/gpt first).

Attached you can find the new version of the patch, tested by booting
the system from the sdcard.

> As Martin mentioned, we should probably split this into a separate
> package, such as u-boot-qcom.

Done.

Thanks,
-- 
Ricardo Salveti de Araujo
From 62d3c60d91c651e8414205e6986e0f6bee5cebc3 Mon Sep 17 00:00:00 2001
From: Ricardo Salveti 
Date: Sun, 3 Jul 2016 13:44:48 -0300
Subject: [PATCH] Enable support for dragonboard410c

Signed-off-by: Ricardo Salveti 
---
 debian/control | 14 +
 ...ard410c-Increase-default-environment-size.patch | 31 
 ...410c-adding-missing-default-addr-for-scri.patch | 29 ++
 ...gonboard410c-prefer-sdcard-boot-over-emmc.patch | 34 ++
 debian/patches/series  |  4 +++
 debian/targets |  3 ++
 debian/u-boot-qcom.install |  2 ++
 debian/u-boot-qcom.lintian-overrides   | 14 +
 8 files changed, 131 insertions(+)
 create mode 100644 debian/patches/qcom/dragonboard410c-Increase-default-environment-size.patch
 create mode 100644 debian/patches/qcom/dragonboard410c-adding-missing-default-addr-for-scri.patch
 create mode 100644 debian/patches/qcom/dragonboard410c-prefer-sdcard-boot-over-emmc.patch
 create mode 100755 debian/u-boot-qcom.install
 create mode 100644 debian/u-boot-qcom.lintian-overrides

diff --git a/debian/control b/debian/control
index 6e2d3ee..19629b9 100644
--- a/debian/control
+++ b/debian/control
@@ -38,6 +38,20 @@ Description: A boot loader for imx systems
  This package includes boot loaders for various imx platforms.
  ${uboot:platforms}
 
+Package: u-boot-qcom
+Architecture: arm64
+Multi-Arch: same
+Depends: ${misc:Depends}
+Description: A boot loader for qcom systems
+ Das U-Boot is a cross-platform bootloader for embedded systems,
+ used as the default boot loader by several board vendors.  It is
+ intended to be easy to port and to debug, and runs on many
+ supported architectures, including PPC, ARM, MIPS, x86, m68k,
+ NIOS, and Microblaze.
+ .
+ This package includes boot loaders for various qcom platforms.
+ ${uboot:platforms}
+
 Package: u-boot-tegra
 Architecture: armhf arm64
 Multi-Arch: same
diff --git a/debian/patches/qcom/dragonboard410c-Increase-default-environment-size.patch b/debian/patches/qcom/dragonboard410c-Increase-default-environment-size.patch
new file mode 100644
index 000..ae016cd
--- /dev/null
+++ b/debian/patches/qcom/dragonboard410c-Increase-default-environment-size.patch
@@ -0,0 +1,31 @@
+From 333463d6698b9e7b8a36c7fd3bd5887c34e5cd71 Mon Sep 17 00:00:00 2001
+From: Mateusz Kulikowski 
+Date: Sun, 19 Jun 2016 23:05:32 +0200
+Subject: [PATCH] dragonboard410c: Increase default environment size.
+
+Due to changes in distro environment, ENV_SIZE limit was reached on Dragonboard.
+This patch increases environment size to 8KiB.
+
+Patch from upstream.
+
+Signed-off-by: Mateusz Kulikowski 
+---
+ include/configs/dragonboard410c.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/include/configs/dragonboard410c.h b/include/configs/dragonboard410c.h
+index d32889d..4b00922 100644
+--- a/include/configs/dragonboard410c.h
 b/include/configs/dragonboard410c.h
+@@ -129,7 +129,7 @@ REFLASH(dragonboard/u-boot.img, 8)\
+ 	BOOTENV
+ 
+ #define CONFIG_ENV_IS_NOWHERE
+-#define CONFIG_ENV_SIZE			0x1000
++#define CONFIG_ENV_SIZE			0x2000
+ #define CONFIG_ENV_VARS_UBOOT_CONFIG
+ #define CONFIG_SYS_NO_FLASH
+ 
+-- 
+2.7.4
+
diff --git a/debian/patches/qcom/dragonboard410c-adding-missing-default-addr-for-scri.patch b/debian/patches/qcom/dragonboard410c-adding-missing-default-addr-for-scri.patch
new file mode 100644
index 000..5dc2066
--- /dev/null
+++ b/debian/patches/qcom/dragonboard410c-adding-missing-default-addr-for-scri.patch
@@ -0,0 +1,29 @@
+From: Ricardo Salveti 
+Date: Sun, 3 Jul 2016 14:15:16 -0300
+Subject: [PATCH] dragonboard410c: adding missing default addr for script and
+ pxe boot
+
+Cc: Mateusz Kulikowski 
+Signed-off-by: Ricardo Salveti 
+
+Forwarded: yes
+---
+ include/configs/dragonboard410c.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git 

Bug#829525: [PATCH] 1.15 requires libdrm-dev >= 2.4.64

[Vincent Cheng]

Control: tag -1 + pending

On Sun, Jul 3, 2016 at 6:48 PM, Nicholas D Steeves  wrote:
> Package: intel-gpu-tools
> Version: 1.15-1
>
> I'm working on backporting intel-vaapi-driver to Jessie; it depends on
> intel-gpu-tools (>= 1.9) so I'm also working on backporting
> intel-gpu-tools.  I discovered that intel-gpu-tools-1.15 requires
> libdrm-dev >= 2.4.64.  Patch attached!
>
> Thank you,
> Nicholas

Applied, thanks for the patch.

Regards,
Vincent

Bug#829527: youtube-dl: don't "call home" by default

[Christoph Anton Mitterer]

Package: youtube-dl
Version: 2016.06.25-1
Severity: normal


Hi.

I think the package should ship the system wide config
file, with "--no-call-home" set for privacy reasons.

Cheers,
Chris.

Bug#829509: [Pkg-shadow-devel] Bug#829509: echo * ** *** when typing password, like all moblie apps

[Serge E. Hallyn]

That sounds like an anti-feature, as anyone looking over
your shoulder knows the number of characters.

Bug#813749: mozjs24: Unsatisfiable Build-Depends and Build-Conflicts

[dai]

Control: tags -1 + patch

I have rebuilt mozjs24 24.2.0-3 on Jessie and
built mozjs24 24.2.0-3 removed python3*-minimal from Build-Depends on Jessie,
both packages have same binaries.
So I think Build-Depends: python3*-minimal is not needed to build at present.

Patch attached.
It also contains "Fix build with perl 5.22" patch, taken from Ubuntu.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E
diff -Nru mozjs24-24.2.0/debian/changelog mozjs24-24.2.0/debian/changelog
--- mozjs24-24.2.0/debian/changelog	2015-05-02 23:13:04.0 +0900
+++ mozjs24-24.2.0/debian/changelog	2016-07-04 00:56:46.0 +0900
@@ -1,3 +1,12 @@
+mozjs24 (24.2.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * remove Build-Conflicts: python3{,.3,.4}-minimal (Closes: #813749)
+  * debian/patches/fix-perl.patch: Fix build with perl 5.22,
+taken from Ubuntu package 24.2.0-3ubuntu2.
+
+ -- HIGUCHI Daisuke (VDR dai)   Mon, 04 Jul 2016 00:56:44 +0900
+
 mozjs24 (24.2.0-3) unstable; urgency=low
 
   * Update Standards-Version to 3.9.6 .
diff -Nru mozjs24-24.2.0/debian/control mozjs24-24.2.0/debian/control
--- mozjs24-24.2.0/debian/control	2015-05-02 22:40:23.0 +0900
+++ mozjs24-24.2.0/debian/control	2016-07-04 00:54:13.0 +0900
@@ -10,7 +10,6 @@
pkg-kde-tools,
python,
zip
-Build-Conflicts: python3-minimal, python3.3-minimal, python3.4-minimal
 Standards-Version: 3.9.6
 Homepage: http://www.mozilla.org/js/spidermonkey/
 
diff -Nru mozjs24-24.2.0/debian/patches/fix-perl.patch mozjs24-24.2.0/debian/patches/fix-perl.patch
--- mozjs24-24.2.0/debian/patches/fix-perl.patch	1970-01-01 09:00:00.0 +0900
+++ mozjs24-24.2.0/debian/patches/fix-perl.patch	2016-07-04 00:54:13.0 +0900
@@ -0,0 +1,12 @@
+--- mozjs24-24.2.0/js/src/config/milestone.pl	2013-11-19 20:42:43.0 +0100
 mozjs-31.5.0/config/milestone.pl	2015-03-06 22:41:57.0 +0100
+@@ -56,7 +56,7 @@
+ #
+ my $milestone = Moz::Milestone::getOfficialMilestone($MILESTONE_FILE);
+ 
+-if (defined(@TEMPLATE_FILE)) {
++if (@TEMPLATE_FILE) {
+   my $TFILE;
+ 
+   foreach $TFILE (@TEMPLATE_FILE) {
+
diff -Nru mozjs24-24.2.0/debian/patches/series mozjs24-24.2.0/debian/patches/series
--- mozjs24-24.2.0/debian/patches/series	2015-05-02 23:17:34.0 +0900
+++ mozjs24-24.2.0/debian/patches/series	2016-07-04 00:54:13.0 +0900
@@ -2,3 +2,4 @@
 aarch64-support.patch
 hurd-support.patch
 hppa-support.patch
+fix-perl.patch


signature.asc
Description: PGP signature

Bug#829526: dgit rpush should allow the user to accept an unknown SSH host key

[Sean Whitton]

Package: dgit
Version: 1.4
Severity: normal

Dear maintainer,

dgit rpush can fail if the SSH host key of the dgit-repos server is
unknown on the remote machine.  E.g.:

$ dgit rpush pan src/ocrmypdf
canonical suite name for unstable is sid
Host key verification failed.
dgit (build host): failed command: ssh 'd...@push.dgit.debian.org' ':
dgit debian git-check ocrmypdf ; set -e; cd /dgit/debian/repos; if
test -d ocrmypdf.git; then echo 1; else echo 0; fi'
dgit (build host): subprocess failed with error exit status 255
dgit: build host child failed with error exit status 255
! Push failed, while checking state of the archive.
! You can retry the push, after fixing the problem, if you like.

-- 
Sean Whitton

Bug#829096: [Pkg-emacsen-addons] Bug#829096: dh-make-elpa: fails to determine that it was not ran from git repository

[Sean Whitton]

control: tag -1 +pending

Dear Lev,

You know that smex is already packaged for Debian, right? :) Indeed, I
think I used dh-make-elpa to prepare it.

The two errors that you report are actually unrelated.  However, both of
them are harmless: dh-make-elpa is just failing to generate some files
because it doesn't have enough information.  I've changed it to fail
silently -- thanks.

-- 
Sean Whitton

Bug#829525: [PATCH] 1.15 requires libdrm-dev >= 2.4.64

[Nicholas D Steeves]

Package: intel-gpu-tools
Version: 1.15-1

I'm working on backporting intel-vaapi-driver to Jessie; it depends on
intel-gpu-tools (>= 1.9) so I'm also working on backporting
intel-gpu-tools.  I discovered that intel-gpu-tools-1.15 requires
libdrm-dev >= 2.4.64.  Patch attached!

Thank you,
Nicholas
From 7a5ad28ea9dc37d27f3beeba961cdd1fe4f5ef71 Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves 
Date: Sun, 3 Jul 2016 21:43:07 -0400
Subject: [PATCH] bump required libdrm-dev. Fixes the following when
 backporting: configure: error: Package requirements (libdrm_intel >= 2.4.64
 libdrm) were not met:

Requested 'libdrm_intel >= 2.4.64' but version of libdrm_intel is 2.4.58

Signed-off-by: Nicholas D Steeves 
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 0f72c98..4c2f604 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends:
  dh-autoreconf,
  gtk-doc-tools,
  libcairo2-dev,
- libdrm-dev (>= 2.4.38),
+ libdrm-dev (>= 2.4.64),
  libpciaccess-dev (>= 0.10),
  libudev-dev,
  libunwind-dev,
-- 
2.1.4

Bug#815268: f3: FTBFS on non-linux architectures: libudev-dev is only available on linux-any

[Eriberto]

Hi Andreas,

Sorry for my delay. I didn't see your previous message. Changing now
to linux-any.

Thanks!

Regards,

Eriberto


2016-07-03 20:52 GMT-03:00 Andreas Beckmann :
> Control: reassign -1 ftp.debian.org
> Control: severity -1 normal
> Control: retitle -1 RM: f3 [kfreebsd-amd64 kfreebsd-i386 hurd-i386] -- RoQA; 
> new linux-specific B-D libudev-dev
>
> On Sat, 20 Feb 2016 14:53:38 +0100 Andreas Beckmann  wrote:
>> The libudev-dev build-dependency is not satisfiable on hurd-i386,
>> kfreebsd-i386, kfreebsd-amd64.
>
> No reaction, so I assume this dependency is essential and request decrufting.
>
>
> Andreas

Bug#829524: ITP: golang-github-svent-go-flags -- go library for parsing command line arguments

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: "ChangZhuo Chen (陳昌倬)" 

* Package name: golang-github-svent-go-flags
  Version : v1
  Upstream Author : https://github.com/svent/go-flags
* URL : http://www.example.org/
* License : BSD-3-clause
  Programming Lang: Go
  Description : go library for parsing command line arguments

 This library provides similar functionality to the builtin flag library
 of go, but provides much more functionality and nicer formatting.
 Supported features are:
 .
  * Options with short names (-v)
  * Options with long names (--verbose)
  * Options with and without arguments (bool v.s. other type)
  * Options with optional arguments and default values
  * Multiple option groups each containing a set of options
  * Generate and print well-formatted help message
  * Passing remaining command line arguments after -- (optional)
  * Ignoring unknown command line options (optional)
  * Supports -I/usr/include -I=/usr/include -I /usr/include option
argument specification
  * Supports multiple short options -aux
  * Supports all primitive go types (string, int{8..64}, uint{8..64},
float)
  * Supports same option multiple times (can store in slice or last option
counts)
  * Supports maps
  * Supports function callbacks
  * Supports namespaces for (nested) option groups


This package is dependency of sift-tool

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D
  BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#829395: [Debian-med-packaging] Bug#829395: python-cobra: FTBFS on hurd-i386: This platform lacks a functioning sem_open implementation

[Afif Elghraoui]

Control: reassign -1 ftp.debian.org
Control: severity -1 normal
Control: retitle -1 RM: python-cobra [hurd-i386] -- RoM; FTBFS; platform
lacks a functioning sem_open implementation

This doesn't look trivially fixable, so requesting decrufting as advised.

regards
Afif


على السبت  2 تـمـوز 2016 ‫16:07، كتب Andreas Beckmann:
> Source: python-cobra
> Version: 0.4.1-2
> Severity: important
>
> Hi,
>
> python-cobra FTBFS on hurd-i386, but the previous version built there:
>
>
https://buildd.debian.org/status/fetch.php?pkg=python-cobra=hurd-i386=0.4.1-2=1464980277
>
> test_double_gene_deletion
(cobra.test.flux_analysis.TestCobraFluxAnalysis) ... ERROR
> Exception AttributeError: "'CobraDeletionPool' object has no attribute
'processes'" in > ignored
>
> ==
> ERROR: test_double_gene_deletion
(cobra.test.flux_analysis.TestCobraFluxAnalysis)
> --
> Traceback (most recent call last):
>   File "/«PKGBUILDDIR»/cobra/test/flux_analysis.py", line 170, in
test_double_gene_deletion
> solution = double_gene_deletion(cobra_model, gene_list1=genes)
>   File "/«PKGBUILDDIR»/cobra/flux_analysis/double_deletion.py", line
283, in double_gene_deletion
> gene_id_to_result, **kwargs)
>   File "/«PKGBUILDDIR»/cobra/flux_analysis/double_deletion.py", line
403, in _double_gene_deletion_fba
> solver=solver, **kwargs) as pool:
>   File "/«PKGBUILDDIR»/cobra/flux_analysis/deletion_worker.py", line
66, in __init__
> self.job_queue = Queue()  # format is (indexes, job_label)
>   File "/usr/lib/python2.7/multiprocessing/__init__.py", line 217, in
Queue
> from multiprocessing.queues import Queue
>   File "/usr/lib/python2.7/multiprocessing/queues.py", line 48, in

> from .synchronize import Lock, BoundedSemaphore, Semaphore, Condition
>   File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 59,
in 
> " function, see issue 3770.")
> ImportError: This platform lacks a functioning sem_open
implementation, therefore, the required synchronization primitives
needed will not function, see issue 3770.
>
> --
> Ran 129 tests in 6.040s
>
> FAILED (errors=1, skipped=11)
>
>
> If this is not trivially fixable, please request decrufting of the
> outdated binary packages:
>
> Control: reassign -1 ftp.debian.org
> Control: severity -1 normal
> Control: retitle -1 RM: python-cobra [hurd-i386] -- RoM; FTBFS;
platform lacks a functioning sem_open implementation
>


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#829521: #829521: vpim: horribly broken

[Christian Hofstaedtler]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: vpim -- RoQA; unmaintained, broken, dead upstream

Dear ftpmasters,

please remove vpim.

The last maintainer upload was 6 years ago; the last upstream commit
was 2 years ago, but when I tried building from upstream sources, I
found that the code is in the same state as our package: almost
nothing works, most scripts just crash on startup, libraries this
code depends on have long been renamed/removed/vanished ...
popcon is very low.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#829522: glances: crashes when checking processes that already finished

[Tiago Ilieve]

Package: glances
Version: 2.1.1-1
Severity: important

Hi Daniel and Sebastien,

Sometimes, when I left glances running for a while (can't say exactly,
but at least a few minutes) it crashes showing the following exceptions:

-8<-

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/psutil/_pslinux.py", line 694, in wrapper
return fun(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/psutil/_pslinux.py", line 724, in name
f = open(fname, "rt", encoding=DEFAULT_ENCODING)
  FileNotFoundError: [Errno 2] No such file or directory: '/proc/672/stat'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
 File "/usr/bin/glances", line 9, in 
   load_entry_point('Glances==2.1.1', 'console_scripts', 'glances')()
 File "/usr/lib/python3/dist-packages/glances/__init__.py", line 121, in main
   standalone.serve_forever()
 File "/usr/lib/python3/dist-packages/glances/core/glances_standalone.py", line 
71, in serve_forever
   self.stats.update()
 File "/usr/lib/python3/dist-packages/glances/core/glances_stats.py", line 130, 
in update
   self.__update__(input_stats)
 File "/usr/lib/python3/dist-packages/glances/core/glances_stats.py", line 121, 
in __update__
   self._plugins[p].update()
 File "/usr/lib/python3/dist-packages/glances/plugins/glances_processcount.py", 
line 55, in update
   glances_processes.update()
 File "/usr/lib/python3/dist-packages/glances/core/glances_processes.py", line 
324, in update
   standard_stats=self.get_max_processes() is None)
 File "/usr/lib/python3/dist-packages/glances/core/glances_processes.py", line 
149, in __get_process_stats
   procstat.update(proc.as_dict(attrs=['cpu_percent', 'memory_percent', 
'name'], ad_value=''))
 File "/usr/lib/python3/dist-packages/psutil/__init__.py", line 414, in as_dict
   ret = attr()
 File "/usr/lib/python3/dist-packages/psutil/__init__.py", line 490, in name
   name = self._proc.name()
 File "/usr/lib/python3/dist-packages/psutil/_pslinux.py", line 704, in wrapper
   raise NoSuchProcess(self.pid, self._name)
 psutil.NoSuchProcess: process no longer exists (pid=672)

-8<-

Looks like it crashes when looking for information about a process that
already finished. It also messes the terminal (/bin/bash), needing a
"reset" command or closing it and opening a new one (but I guess this is
expected when a curses-based tool isn't properly finished).

Regards,
Tiago.

P.s.: Thanks for you work adopting this package a few months ago. It is a
really useful monitoring tool.


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

Kernel: Linux 3.16.0-4-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 glances depends on:
ii  adduser3.113+nmu3
ii  lsb-base   4.1+Debian13+nmu1
ii  python33.4.2-2
ii  python3-pkg-resources  5.5.1-1
ii  python3-psutil 2.1.1-1+b1
pn  python3:any

Versions of packages glances recommends:
ii  hddtemp  0.3-beta15-52
ii  lm-sensors   1:3.3.5-2
ii  python3-bottle   0.12.7-1
ii  python3-jinja2   2.7.3-1
ii  python3-pysnmp4  4.2.5-1

glances suggests no packages.

-- no debconf information

Bug#829515: [Debian-med-packaging] Bug#829515: htseq: B-D python-pysam not available on all architectures where htseq previously built

[Afif Elghraoui]

Hello,

على الأحد  3 تـمـوز 2016 ‫15:39، كتب Andreas Beckmann:
> Package: htseq
> Version: 0.6.1p1-4
> Severity: serious
> Justification: fails to build from source
> 

I'm not sure about this severity, because there's only one case of
FTBFS. the rest are BD-uninstallable.

The build failure on armel [1] is because of one test failure:

testing on architecture arm
python2.7 test/test.py
Doctest of tss.rst:
**
File "../doc/tss.rst", line 114, in tss.rst
Failed example:
wincvg
Expected:
array([0, 0, 0, ..., 0, 0, 0], dtype=int32)
Got:
array([0, 0, 0, ..., 0, 0, 0])
**

> htseq 0.6 added a Build-Depends: python-pysam (for testing),
> but that is only available on a few architectures.
> 
> Either restrict this to the architectures where it is available or
> request decrufting of the outdated binary packages on the architectures
> where it is missing/failing.
> 

Maybe removal on just armhf, mips, powerpc, and s390x if the armel build
can be fixed. Those are what are holding up testing migration [2].

regards
Afif

1.
https://buildd.debian.org/status/fetch.php?pkg=htseq=armel=0.6.1p1-4=1449681506
2. https://release.debian.org/migration/testing.pl?package=htseq

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#829521: vpim: horribly broken

[Christian Hofstaedtler]

Package: vpim
Version: 0.695-1.5
Severity: serious

Half of the shipped binaries just crash:

% mutt-aliases-to-vcf
/usr/lib/ruby/vendor_ruby/vpim/vcard.rb:760: warning: assigned but unused 
variable - v
/usr/lib/ruby/vendor_ruby/vpim/vcard.rb:1135: warning: assigned but unused 
variable - fn
/usr/bin/mutt-aliases-to-vcf: /usr/lib/ruby/vendor_ruby/vpim/vcard.rb:678: 
invalid multibyte escape: /^\xFE\xFF/ (SyntaxError)
invalid multibyte escape: /^\xFF\xFE/
% vcf-dump
/usr/lib/ruby/vendor_ruby/vpim/vcard.rb:760: warning: assigned but unused 
variable - v
/usr/lib/ruby/vendor_ruby/vpim/vcard.rb:1135: warning: assigned but unused 
variable - fn
/usr/bin/vcf-dump: /usr/lib/ruby/vendor_ruby/vpim/vcard.rb:678: invalid 
multibyte escape: /^\xFE\xFF/ (SyntaxError)
invalid multibyte escape: /^\xFF\xFE/
% vcf-to-ics
/usr/bin/vcf-to-ics: /usr/lib/ruby/vendor_ruby/vpim/vcard.rb:678: invalid 
multibyte escape: /^\xFE\xFF/ (SyntaxError)
invalid multibyte escape: /^\xFF\xFE/
% vcf-to-mutt
/usr/lib/ruby/vendor_ruby/vpim/vcard.rb:760: warning: assigned but unused 
variable - v
/usr/lib/ruby/vendor_ruby/vpim/vcard.rb:1135: warning: assigned but unused 
variable - fn
/usr/bin/vcf-to-mutt: /usr/lib/ruby/vendor_ruby/vpim/vcard.rb:678: invalid 
multibyte escape: /^\xFE\xFF/ (SyntaxError)
invalid multibyte escape: /^\xFF\xFE/

The ICS Repo support relies on a plist library, but the package does
not depend on one, as such that code just crashes.

It's clear this package has not been used by anybody except for very
limited use cases, and the NMUs were mostly a waste of time...

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#824955: u-boot: please enable support for dragonboard410c

[Ricardo Salveti]

On Thu, May 26, 2016 at 8:44 PM, Martin Michlmayr  wrote:
> I'm not Debian's u-boot maintainer but I have some interest in Debian
> on this board.

First sorry for the delay, I had an issue with my mail filters and I
only saw the bug updates this week, after Mateusz pinged me directly
on IRC.

> I have some questions/comments:
>
> First of all, please split the upstream fixed in 3 patches and submit
> them upstream.  I haven't seen them there yet.  I definitely agree
> with changing the boot order.  I cannot comment about the other
> changes.

Mateusz fixed the env size already, and I finally got time to send the
other two minor fixes upstream.

http://lists.denx.de/pipermail/u-boot/2016-June/258552.html
http://lists.denx.de/pipermail/u-boot/2016-July/259567.html
http://lists.denx.de/pipermail/u-boot/2016-July/259568.html

Didn't yet send the change that fixes the partition id used to boot
when using eMMC, trying to play with the bootable mbr/gpt flag first.

> The other comments are related to the packaging: I believe on armhf
> and arm64, the u-boot source builds different binary packages for the
> different packages.  You could probably create something like a
> u-boot-qcom package with the DragonBoard support. (Vagrant can
> confirm)

I decided not to create a new package simply because there were not a
lot of targets for arm64, but fine to add a package just for qcom
devices. Will send another patch.

> My bigger question is around Debian support: the boot loader on this
> device requires boot images to be in a specific format made with
> Qcom's "skeles" tools.  They are currently not packages in Debian.
> Is the ELF file useful, i.e. have you found a way to boot that
> directly?  Or do we need to package the skeles tools and create the
> dt.img and a bootable .img file?

We still need the qcom tool to create a working boot image, and we
should definitely package that as well (will have a look into that). I
know Mateusz was first working on chainloading from lk, so once we get
u-boot to replace it completely, the special tool shouldn't be needed
anymore (but that might take a while).

Thanks,
-- 
Ricardo Salveti de Araujo

Bug#829520: RFS: mbpfan/1.9.1-1 ITP

[Herminio Hernandez Jr]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "mbpfan"

 Package name: mbpfan
 Version : 1.9.1-1
 Upstream Author : Daniel Graziotin 
 URL : https://github.com/dgraziotin/mbpfan
 License : GPL-3

It builds those binary packages:

  mbpfan - Fan-Control-Daemon for MacBook Pro

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/mbpfan


Alternatively, one can download the package with dget using this command:

 dget -x https://mentors.debian.net/debian/pool/main/m/mbpfan/mbpfan_1.9.1-1.dsc

More information about mbpfan can be obtained from 
https://github.com/dgraziotin/mbpfan.

Regards,
Herminio


signature.asc
Description: PGP signature

Bug#829519: RM: kineticstools [i386 kfreebsd-i386 hurd-i386] -- ROM; not installable

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


This package indirectly depends on python-pysam, which is no longer available
for any-i386. Testing migration of the new kineticstools upload is currently
blocked by the lack of an i386 build.

Many thanks and regards
Afif

Bug#829209: closed by (Bug#829209: fixed in libcypher-parser 0.3.4-1)

[Chris Leishman]

Ok. I'll add that for next time. You'd think I'd know British spelling, but
I've obviously been in the US for too long...

On 2 July 2016 at 23:14, Paul Wise  wrote:

> On Sat, 2016-07-02 at 19:03 +, Debian Bug Tracking System wrote:
>
> > #829209: cypher-lint: colourise improvements
> >
> > It has been closed by Chris Leishman .
>
> BTW, the variants that have been added are missing the 'u' character:
>
>   { "colorize", no_argument, NULL, COLORIZE_OPT },
>   { "colorise", no_argument, NULL, COLORIZE_OPT },
>   { "no-colorize", no_argument, NULL, NO_COLORIZE_OPT },
>   { "no-colorise", no_argument, NULL, NO_COLORIZE_OPT },
>
> I would suggest this instead:
>
>   { "colorize", no_argument, NULL, COLORIZE_OPT },
>   {
> "colourise", no_argument, NULL, COLORIZE_OPT },
>   { "no-colorize",
> no_argument, NULL, NO_COLORIZE_OPT },
>   { "no-colourise",
> no_argument, NULL, NO_COLORIZE_OPT },
>
> --
>
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>

Bug#816170: False positive deleted files after upgrade from wheezy to jessie

[Francois Marier]

On 2016-04-26 at 13:50:21, Klaus Ethgen wrote:
> Find attached a patch, cherry-picked from upstream, that fixes the
> issue. Particular, it is c4d6d8b, 1e5e79a and b4a21a8.

Which upstream repo did you pull that from?

The only repo I know about is a CVS one on Sourceforge:

  http://rkhunter.cvs.sourceforge.net/viewvc/rkhunter/rkhunter/

Francois

-- 
https://fmarier.org/

Bug#815268: f3: FTBFS on non-linux architectures: libudev-dev is only available on linux-any

[Andreas Beckmann]

Control: reassign -1 ftp.debian.org
Control: severity -1 normal
Control: retitle -1 RM: f3 [kfreebsd-amd64 kfreebsd-i386 hurd-i386] -- RoQA; 
new linux-specific B-D libudev-dev

On Sat, 20 Feb 2016 14:53:38 +0100 Andreas Beckmann  wrote:
> The libudev-dev build-dependency is not satisfiable on hurd-i386,
> kfreebsd-i386, kfreebsd-amd64.

No reaction, so I assume this dependency is essential and request decrufting.


Andreas

Bug#829518: qemu-utils: qemu-nbd max_part issue

[westlake]

Package: qemu-utils
Version: 1:2.1+dfsg-12+deb8u6
Severity: normal

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

The report I sent this against package linux-image-4.5.0-2-grsec-amd64 
breaks qemu-nbd's ability to work with max_part.  Since the kernel team 
is unwillingly to bother about it because they have to try commands with 
"qemu-nbd", they are unwilling to look into  it.


Here I've tried 4 kernels, the ones that are output with dpkg -l has 
been tried. The excuse the kernel team gives about "grsec/non-grsec" is 
a mere distration.  The bug occurs whether the kernel has grsec built 
into it or not, but it occurs against the kernel package it is report 
against. They're just unwillingly to bother about it.


My observation is "qemu-nbd" (latest 1:2.5) or "1:2.1" both work fine 
and exhibit the same "bug" for kernels above 4.3



"
kernels 4.5 and 4.6 breaks qemu-nbd from mapping partitions.

"qemu-nbd can map partitions from VM images and raw disk images to 
/dev/nbdNpM nodes, but proper module options have to be loaded prior so 
that qemu-nbd performs these additional mappings (the general consensus 
around mapping image files has users issuing "kpartx -a /dev/", 
but kpartx is not needed at all after issuing qemu-nbd)


nothing is specially set up other than a module option file and that's 
pretty much it -- there's just 2 or 3 commands for the testing --- all 
which indicates the issue is more towards kernel than it is with qemu-nbd.


after a modprobe nbd is issued, there is no "/dev/nbd0p1"-like devices, 
so the main problem with kernels 4.5/4.6 is that qemu-nbd is not being 
allowed to generate any device nodes. ("partition" device nodes that is 
-- "/dev/nbd0" and "/dev/nbd1" nodes are generated by modprobe nbd)


here in nbd(module) options, there is a hint for max_part that needs to 
be specified in order for qemu-nbd to later work in generating the 
partition devices /dev/nbdNpM.

(nbds_max=2 just means for modprobe to create "/dev/nbd0" and "/dev/nbd1")

/etc/modprobe.d/mynbd.conf
"
options nbd nbds_max=2 max_part=10
"

basically just a raw disk image containing one partition

dd if=/dev/zero of=1.bin bs=10M count=10
,creates a raw diskimage called 1.bin

any tool to create a dosmbr table containing at least 1 partition 
(qemu-nbd can also work with GPT tables but it is not used)

cfdisk 1.bin , and exit the partition tool

no mkfs is needed, so one can immediately try to map the partitions from 
the disk image 1.bin just by using qemu-nbd (here again "kpartx" is not 
used at all. If one uses "kpartx", then it would rather create partition 
device nodes in /dev/mapper. Using qemu-nbd -d [/dev/nbdN] also unmaps 
partition nodes.. so forgetting to issue kpartx -d /dev/nbd0 prior 
qemu-nbd -d, would leave a mess of broken device links in /dev/mapper)


qemu-nbd should map 1.bin to /dev/nbd0 and its first partition to 
"/dev/nbd0p1". this partition device node does not exist yet but is 
something that qemu-nbd would generate


"qemu-nbd -c /dev/nbd0 1.bin"

there is an option "-P "(qemu-nbd command) for specifying an exposure to 
a single partition, but this has null effect

" -P, --partition=num
only expose partition I"

it is always "qemu-nbd -c /dev/nbd0 [IMAGE FILE]" that works (and after 
max_part is used with "modprobe nbd") -- the /dev/nbd0p1 node then gets 
generated... so something is up with the later kernels in breaking this 
particular behaviour feature on behalf of qemu-nbd


Here the qemu-utils was updated and still no success...dmesg shows no 
errors... there's also no errors from qemu-nbd's output but there is a 
new notice about using "-f raw" for more safety for the end-user.


... the outcome is still the same (with or without "-f raw") -- the end 
result is the image file is still treated as a "raw disk" which is 
correct but there is no generation of partition devices


some output for the report,

modprobe -vvv nbd
insmod /lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko 
nbds_max=20 max_part=10
modprobe: DEBUG: ../libkmod/libkmod-module.c:728 kmod_module_get_path() 
name='nbd' 
path='/lib/modules/4.5.0-2-grsec-amd64/kernel/drivers/block/nbd.ko'


dpkg -l 'linux-image*'
ii linux-image-4.5.0-0.bpo.2-amd64 4.5.4-1~bpo8+1 amd64 Linux 4.5 for 
64-bit PCs
ii linux-image-4.5.0-2-grsec-amd64 4.5.7-1+grsec201606222150+1~bpo8+1 
amd64 Linux 4.5 for 64-bit PCs, Grsecurity protection
ii linux-image-4.6.0-0.bpo.1-amd64 4.6.1-1~bpo8+1 amd64 Linux 4.6 for 
64-bit PCs


apt-cache policy qemu-utils
qemu-utils:
Installed: 1:2.1+dfsg-12+deb8u6
Candidate: 1:2.1+dfsg-12+deb8u6
Version table:
1:2.5+dfsg-4~bpo8+1 0
100 http://debian.bhs.mirrors.ovh.net/debian/ jessie-backports/main 
amd64 Packages

*** 1:2.1+dfsg-12+deb8u6 0
500 http://debian.bhs.mirrors.ovh.net/debian/ jessie/main amd64 Packages
500 http://security.debian.org/ jessie/updates/main amd64 Packages
100 /var/lib/dpkg/status

linux-image-4.3.0-0.bpo.1-amd64 4.3.5-1~bpo8+1

latest kernel that works is 4.3, 

Bug#829517: librtlsdr0: should remove rtl-sdr-blacklist.conf on upgrade

[Bob Bib]

Package: librtlsdr0
Version: 0.5.3-9

Dear Maintainer,

/etc/modprobe.d/rtl-sdr-blacklist.conf
was removed from librtlsdr0 in 0.5.3-6 (see bug #823022);
IMHO, that file should get removed on upgrade, but unfortunately it doesn't.

Hope this helps:
https://raphaelhertzog.com/2010/10/07/the-right-way-to-remove-an-obsolete-conffile-in-a-debian-package/

--
Best wishes,
Bob

Bug#809194: ITP: golang-github-docopt-docopt-go -- An implementation of docopt in the Go programming language.

[Alessandro Ghedini]

Hello,

On Mon, Dec 28, 2015 at 02:04:06pm +0800, gustavo panizzo wrote:
> Package: wnpp
> Severity: wishlist
> Owner: gustavo panizzo 
> 
> * Package name: golang-github-docopt-docopt-go
>   Version : 0.6.1
>   Upstream Author : Keith Batten
> * URL : http://docopt.org
> * License : MIT/X
>   Programming Lang: Go
>   Description : An implementation of docopt in the Go programming 
> language.
> 
> docopt helps you define an interface for your command-line app and
> automatically generate a parser for it. Its interface descriptions are
> based on a formalization of the standard conventions used in help
> messages and man pages.
> 
> This package provides an implementation of docopt in the Go programming
> language.

Any news about this? I'd be interested in using such package :)

Cheers


signature.asc
Description: PGP signature

Bug#827160: jessie-pu: package dosfstools/3.0.27-1+deb8u1

[Andreas Bombe]

On Sun, Jun 26, 2016 at 09:27:57AM +0200, Petter Reinholdtsen wrote:
> 
> Andreas, while I wait for a reply from the release managers, it would be
> great to know the answer to this question:
> 
> [Petter Reinholdtsen]
> > OK to push it to the collab-maint git repo before upload, or should I
> > wait until it is accepted?

If you strongly expect it to be accepted as it is, then push it.

Or wait with tagging until it is accepted. Moving tags and releases that
aren't releases after all is something I'd like to avoid.

Bug#828692: Repo

[Sebastien Badia]

On Mon, Jun 27, 2016 at 01:15:05PM (+0100), Iain R. Learmonth wrote:
> Hi Gordon,
> 
> On 27/06/16 08:39, Gordon Ball wrote:
> > Sebastien prepared a repository for this at [0] last year, but for
> > whatever reason an ITP was never done.
> > I would concur this would also be suitable for a tasktools team.
> 
> Let's make a team. I'll add this to my tasks for later today.
> 
> I spotted this repo already, and sent Sebastien a mail to ask what was
> the plan with it. Sorry, forgot to CC the bug.
> 
> Thanks,
> Iain.

Hello pkg-tasktools team,

In fact, tasksh was included in taskwarrior (task) package before release 2.4.0,
after, upstream decided to split this part of code in another repository.

When we took over maintenance of the package with Gordon, I created the GIT
repo, but indeed I never filled an ITP because of an hardening issue, and
more due to a lack of time :-/

https://anonscm.debian.org/cgit/collab-maint/tasksh.git/commit/?id=be9c6a5aa3b08a10a3eb91b43dbfad27f46df245

We can go ahead and possibly merge the two repos.

Thanks!

Seb


signature.asc
Description: PGP signature

Bug#829516: ITP: cubicsdr -- software defined radio receiver

[Andreas Bombe]

Package: wnpp
Severity: wishlist
Owner: Andreas Bombe 

* Package name: cubicsdr
  Version : 0.2.0-beta-rc2
  Upstream Author : Charles J. Cliffe 
* URL : http://cubicsdr.com
* License : GPL
  Programming Lang: C++
  Description : software defined radio receiver

CubicSDR is a cross-platform graphical Software-Defined Radio
application providing waterfall displays which allows you to navigate
the radio spectrum and demodulate any signals you might discover. It
currently includes several common analog demodulation schemes such as FM
and AM including single sideband modes.

Any hardware supported by a SoapySDR module can be used as a receiver by
CubicSDR.

Bug#829514: New upstream version available

[Christian Hofstaedtler]

Package: sqliteodbc
Version: 0.9992-0.1

A new upstream version, 0.9994, is available for some time already.
Please consider packaging it.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#829515: htseq: B-D python-pysam not available on all architectures where htseq previously built

[Andreas Beckmann]

Package: htseq
Version: 0.6.1p1-4
Severity: serious
Justification: fails to build from source

htseq 0.6 added a Build-Depends: python-pysam (for testing),
but that is only available on a few architectures.

Either restrict this to the architectures where it is available or
request decrufting of the outdated binary packages on the architectures
where it is missing/failing.


Andreas

Bug#829401: linux-image-4.5.0-2-grsec-amd64: breaks qemu-nbd

[westlake]

You're confused from a dpkg -l output?  I think it's pretty clear what 
the full package for "4.6" really is.  Try reading the dpkg -l output 
from above.


thanks

On 03/07/16 03:18 AM, Yves-Alexis Perez wrote:

On sam., 2016-07-02 at 20:36 -0400, westlake wrote:

kernels 4.5 and 4.6 breaks qemu-nbd from mapping partitions


There's no 4.6 grsec kernel, so I'm a bit confused about your report. Can you
check with the non grsec 4.5 and 4.6 kernel and report back? I have the
feeling it's completely unrelated and thus should be reported to the non grsec
linux images.

Regards,

Bug#829513: Timeout for reading PIDFile is too low for some services

[Christian Hofstaedtler]

Package: systemd
Version: 230-5
Severity: minor

Hi,

espeakup needs about 0.25sec on my machine from fork to writing its
pid file. When using PIDFile= in the corresponding unit file,
systemd will complain:

Jul 03 21:39:57.509264 sxl systemd[1]: Starting Software speech output for 
Speakup...
Jul 03 21:39:57.523409 sxl systemd[1]: espeakup.service: PID file 
/run/espeakup.pid not readable (yet?) after start: No such file or directory
Jul 03 21:39:57.773883 sxl systemd[1]: Started Software speech output for 
Speakup.

Please address:

1) error message is not clear if the PID file read is retried

2) giving a daemon only ~0.2sec to start is a bit harsh IMO

(See #796608 for more context.)

Thanks,
-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#829512: RM: tarantool [kfreebsd-amd64 kfreebsd-i386] -- ANAIS; restricted to amd64, i386

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

tarantool has been restricted to only build for amd64 and i386 (linux).


Andreas

Bug#829511: New upstream version

[Christian Hofstaedtler]

Package: lldpad

Dear Maintainer,

https://github.com/jrfastab/lldpad hosts newer commits touching
lldpad that apparently provide better systemd integration and a ton
of other fixes.

The currently packaged fcoe-utils seem to already rely on some of
those commits.

Best,
-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#829510: ITP: consensuscore2 -- generate consensus sequences for PacBio sequencing data

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 

* Package name: consensuscore2
  Version : 0.12.0
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/ConsensusCore2
* License : BSD
  Programming Lang: C++, Python
  Description : generate consensus sequences for PacBio sequencing data

ConsensusCore2 embodies core C++ routines underlying the Arrow HMM
algorithm for PacBio multi-sequence consensus.  Arrow is the successor
to the Quiver model---a CRF model that was embodied in the
ConsensusCore C++ library. Compared to Quiver, the Arrow model is more
statistically principled and easier and more robust to train.


This package will become a Depends or Recommends of the pbgenomicconsensus
package. It will be maintained by the Debian Med team.

Bug#809984: working on it...

[Bdale Garbee]

I've packaged and uploaded mdocml/mandoc, as soon as it's accepted into the
archive I'll be able to update the build process for sudo to fix this.

Bdale

Bug#643042: opendnssec-signer: Assertion zone->task failed in cmdhandler

[Andreas Beckmann]

Control: fixed -1 1:1.4.6-5

On Wed, 21 Oct 2015 10:55:50 +0200 =?UTF-8?Q?Ond=C5=99ej=20Sur=C3=BD?=
 wrote:
> Version: 1:1.4.6-6
> 
> Just doing the cleanup, this has been fixed long since it has been
> reported.

so probably in the predecessor version, too, which is the LCA of the
versions in unstable and stable


Andreas

Bug#698491: closed by Andreas Glaeser <bugs.andreas.glae...@freenet.de> (old report done)

[積丹尼 Dan Jacobson]

I hope the main focus of everything is memory sticks these days.

Bug#829509: echo * ** *** when typing password, like all moblie apps

[積丹尼 Dan Jacobson]

Package: login
Version: 1:4.2-3.1
Severity: wishlist

Perhaps echo
Password: *
Password: **
Password: ***...
as one types, by default, like all moble apps do these days.
Test to be sure DEL eats them back too.

Bug#829506: ITP: flask-multistatic -- A simple flask plugin for overriding static files

[Afif Elghraoui]

على الأحد  3 تـمـوز 2016 ‫15:15، كتب Sergio Durigan Junior:
[...]
> 
> This package is a dependency necessary for pagure.
> 

Many thanks for working towards a pagure package! It looks like a very
nice thing to have in Debian.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#825606: collectd: B-D: libsigrok-dev unavailable on kfreebsd

[Andreas Beckmann]

Control: reassign -1 ftp.debian.org
Control: severity -1 normal
Control: retitle -1 RM: collectd [kfreebsd-i386 kfreebsd-amd64] -- RoQA; new 
B-D libsigrok-dev is only available on linux

On Sat, 28 May 2016 08:24:52 +0200 Andreas Beckmann  wrote:
> the recently added B-D: libsigrok-dev is only available on Linux.
> If this can be optional, please restrict it to [linux], otherwise please
> request decrufting of the outdated binary packages on kfreebsd-*.

I haven't heard something within the last month, so I'm requesting the 
decrufting.


Andreas

Bug#829145: transition: glibc 2.23

[Aurelien Jarno]

On 2016-07-01 09:42, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 01/07/16 01:41, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear release team,
> > 
> > We would like to get a transition slot for glibc 2.23. It is currently
> > available in experimental and has been built successfully on all
> > official architectures except hurd-i386. We have fixed the hurd-i386
> > failure in out git, and we are working on build failures for alpha, hppa
> > and sparc64. There are due to testsuite issue, mostly in the math parts
> > and do not look very critical.
> > 
> > It should be noted that this upload will make a few packages to FTBFS,
> > mostly due to more precise checking in the floating-point classification
> > macros (isnan, isinf, ...). In most of the cases the changes just make
> > existing bugs visible. The list of affected packages is available [1]
> > (thanks to Martin Michlmayr), and the bugs have been opened for more
> > than 3 months.
> > 
> > As the glibc is using symbol versioning, there is no soname change. That
> > said a few packages are using libc internal symbols and have to be
> > rebuilt for this transition:
> >  - apitrace
> >  - bro
> >  - dante
> >  - libnih
> >  - libnss-db
> >  - unscd
> >  
> > Here is the corresponding ben file:
> >  
> > title = "glibc";
> > is_affected = .depends ~ /libc[0-9.]* \(< > is_good = .depends ~ /libc[0-9.]* \(<< 2.24\)/;
> > is_bad = .depends ~ /libc[0-9.]* \(<< 2.23\)/;
> > 
> > In addition to that, a few new symbols have been added that might
> > prevent a few other packages to transition to testing if they pick up
> > the new symbols, namely the fts64_* and the lgamma* ones. It should not
> > concerns many packages.
> 
> Go ahead.

It has just been accepted by dak.

Cheers,
Aurelien

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

Bug#800820: firmware-atheros: Missing firmware for QCA6174

[Antos Andras]

Some complementary info:

The firmware files can be found here
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA6174
and/or
http://github.com/kvalo/ath10k-firmware/blob/master/ath10k

See also reports via http://google.com/search?q=atheros+board-2.bin
and recent Ubuntu linux-firmware 1.158 package that has

$ dpkg -L linux-firmware |grep -i ath10k/QCA6.*bin$
/lib/firmware/ath10k/QCA6174/hw2.1/firmware-5.bin
/lib/firmware/ath10k/QCA6174/hw2.1/board-2.bin
/lib/firmware/ath10k/QCA6174/hw2.1/board.bin
/lib/firmware/ath10k/QCA6174/hw3.0/firmware-4.bin
/lib/firmware/ath10k/QCA6174/hw3.0/board-2.bin
/lib/firmware/ath10k/QCA6174/hw3.0/board.bin

Thanks,
Andras

Bug#829508: sordi misses sord_validate binary

[Robin Gareus]

Package: sordi
Version: 0.14.0~dfsg0-1
Severity: important

Dear Maintainer,

The sordi package only contains the manual page for sord_validate
but the actual binary is missing.


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

Kernel: Linux 4.6.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 sordi depends on:
ii  libc62.22-11
ii  libserd-0-0  0.22.0~dfsg0-2
ii  libsord-0-0  0.14.0~dfsg0-1

sordi recommends no packages.

sordi suggests no packages.

-- no debconf information

Bug#829507: should change file permission on import

[W. Martin Borgert]

Package: shotwell
Version: 0.22.1-1
Severity: wishlist

Shotwell currently just takes the permissions of original files
on import. In many cases, this is 755 or 777, because users may
import files from typically VFAT formatted SD cards.

For security, it would be nice to have no executable bits set.
For privacy, it would be nice to allow only user and group to
read imported files.

I suggest 640 as permission of imported files
and 750 or maybe 2750 for new directories.

Bug#829155: murrine-themes: Please split into separate packages

[Jeremy Bicha]

On Fri, Jul 1, 2016 at 1:57 AM, Yves-Alexis Perez  wrote:
> Honestly I don't really think it's worth the effort, but feel free to work on
> it if you're interested. The packaging is in collab-maint: https://anonscm.deb
> ian.org/cgit/collab-maint/murrine-themes.git/

Ok, I pushed my work here so you can review first:

https://anonscm.debian.org/cgit/users/jbicha-guest/blackbird-gtk-theme.git/
https://anonscm.debian.org/cgit/users/jbicha-guest/greybird-gtk-theme.git/
https://anonscm.debian.org/cgit/users/jbicha-guest/murrine-themes.git/

Albatross and Bluebird haven't been updated for GTK 3.20 yet. Do you
want to drop them from murrine-themes now too?
I could package them too (since it looks like they may be useful to
Xfce still), but I think it's an RC bug that they don't work with all
the GTK3 desktops.

Jeremy

Bug#829506: ITP: flask-multistatic -- A simple flask plugin for overriding static files

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: flask-multistatic
  Version : 1.0
  Upstream Author : Pierre-Yves Chibon 
* URL : https://pagure.io/flask-multistatic
* License : GPL-3+
  Programming Lang: Python
  Description : A simple flask plugin for overriding static files

 Simple flask plugin allowing to override static files, making theming
 flask applications really easy.

This package is a dependency necessary for pagure.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829505: ITP: mbpfan -- A simple daemon to control fan speed on all Macbook/Macbook Pros for Linux

[Herminio Hernandez Jr.]

Package: wnpp
Severity: wishlist
Owner: "Herminio Hernandez Jr." 

* Package name: mbpfan
  Version : 1.9.1
  Upstream Author : Daniel Graziotin  
* URL : https://github.com/dgraziotin/mbpfan
* License : GPL-3
  Programming Lang: C
  Description : A simple daemon to control fan speed on all Macbook/Macbook
Pros for Linux

>From the site: 'Fan-Control-Daemon is a daemon that uses input from coretemp
module and sets the fan speed using the applesmc module. This enhanced version
assumes any number of processors and fans (max. 10).'

People running Debain on their MacBook Pros will benefit running this daemon.
It will offer an alternative to the macfanctl daemon that is the repository.

My desire is to work with the upstream developers with any issues that may
arise and help contribute. I have already written the man page and submitted it
as a pull request.

Bug#829324: iproute2: malformed git repository (missingSpaceBeforeDate: invalid author/committer line - missing space before date)

[intrigeri]

Control: tag -1 + upstream

Hi,

Daniel Kahn Gillmor wrote (02 Jul 2016 14:51:26 GMT) :
> It looks like there is an error in the git repository for debian
> packaging for iproute2:

FWIW, I've just stumbled upon the same problem (trying to help with
#783276) when cloning the upstream repo:
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git

Cheers,
--
intrigeri

Bug#827259: samba-libs: winbind segfault in libsamba-security.so.0 after update to 4.2.10+dfsg-0+deb8u3

[Jorge]

Hello

I have two machines with the exact same problem.  Both of them have 
squid and they're joint to the same windows active directory. The 
problem started to appear when I updated them to 4.2.10+dfsg-0+deb8u3.


I've manually downgraded one of them to samba and winbind version 
4.1.17+dfsg-2+deb8u2 and everything works fine again. The other one 
still has 4.2.10+dfsg-0+deb8u3 and it has the problem when ntlm_auth 
check the credentials of user which are given from squid.


Thanks

--
Jorge

Bug#829489: [debian-mysql] Bug#829489: mariadb-server-10.0: Fails to stop, package can't be uninstalled/purged

[Otto Kekäläinen]

2016-07-03 23:07 GMT+03:00 Axel Beckert :
> My only ideas so far:
>
> * Maybe a longer timeout to wait for the shutdown could help? (If
>   there's some kind of timeout at all.)
> * Maybe trying to stop it a second time after some short "sleep"?

Stopping is done by invoking the general init script from the postrm script:
http://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/tree/debian/mariadb-server-10.0.postrm

The stop already has a 600 second loop:
http://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/tree/debian/mariadb-server-10.0.mysql.init#n135

...but in this case the loop does not run, but the first stopping
throws an error code immediately.

I tried to grep parts of "[FAIL] Stopping MariaDB database server:
mysqld failed!" to find what emits it, but without success.

Bug#815659: postfix: Build Postfix 3.x with LMDB Support

[Guilhem Moulin]

On Mon, 04 Apr 2016 at 14:47:43 +0200, Thomas Leuxner wrote:
> Complete debdiff against 3.1.0-1 attached. Please consider importing.

I'd like to second this; I'm also able to create and query LMDB maps
after applying the patch.  Just one remark though: although harmless,
the conditional ‘delmap’ in the postinst script doesn't seem useful
since Postfix < 2.3.3-3 isn't compiled with LMDB support.

Furthermore, the debian/postfix-lmdb.* are identical to their -cdb
counterparts, thus postfix-lmdb and postfix-cdb have the same lintian
warnings.  In particular, the prerm scripts other than the one for -doc
trigger ‘maintainer-script-empty’ (they only seem to contain comments
and boilerplate code), hence should probably be removed.  IMHO this
doesn't belong to this patch though.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#800820: firmware-atheros: Missing firmware for QCA6174

[Andras Antos]

Package: firmware-atheros
Version: 20160110-1
Followup-For: Bug #800820

Dear Maintainers,

There were multiple upgrades and increased support in the kernel firmware
since Oct 4, see, e.g.,
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/log/ath10k/QCA6174?showmsg=1 
Please, re-package firmware-atheros with these improvements letting 
support for several newer boards in the 168c:003e and 168c:0041 domains.


My Qualcomm Atheros QCA6174 [168c:003e] (rev 32) Lite-On Communications Inc
[11ad:0807] board does not work with Debian sid firmwares, but works 
(though sometimes connection breaks having to reconnect) after downloading 
hw3.0/board-2.bin from git.kernel.org (and putting it into 
/lib/firmware/ath10k/QCA6174/hw3.0/).


Also, I think 6164 is a typo in the title, instead of 6174 (and probably 
was also in bug 800703).


Thank you for your work,
Andras

-- System Information:
07:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac Wireless 
Network Adapter [168c:003e] (rev 32)
Subsystem: Lite-On Communications Inc QCA6174 802.11ac Wireless Network 
Adapter [11ad:0807]
Kernel driver in use: ath10k_pci
Kernel modules: ath10k_pci

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 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 firmware-atheros suggests:
ii  initramfs-tools  0.125
-- no debconf information

Bug#829504: ITP: panoramisk -- asyncio based library to play with asterisk

[Orestis Ioannou]

Package: wnpp
Severity: wishlist
Owner: Orestis Ioannou 

* Package name: panoramisk
  Version : 1.0
  Upstream Author : Gael Pasgrimaud
* URL : https://panoramisk.readthedocs.org/
* License : MIT
  Programming Lang: Python
  Description : asyncio based library to play with asterisk

Panoramisk is a library based on python's AsyncIO to play with Asterisk's
manager.
It uses the TCP manager server to listen to events and send actions.

Asterisk is an open source telephony switching and private branch exchange
service for Linux.

I intend to package this in the DPMT!

Bug#734101: Planned upload of a newer jquery-mobile?

[Michael Prokop]

Hi,

[explicitely Cc-ing Marcelo as uploader of jquery-mobile package]

* Mathieu Parent [Wed Aug 27, 2014 at 08:47:44PM +0200]:

> Do you plan to release a newer jquery-mobile soon? Horde is currently
> broken because of the currently outdated version (#749799).

> If not, can anybody else do the job (I tried without success yet).

In the meanwhile there's upstream version 1.4.5.
I just took a brief look at it and packaged it based on the upstream
source handling I found in debian/rules (the [u]watch stuff doesn't
really work anymore).

I've exported my patches and built a Debian package which is
available at https://people.debian.org/~mika/jquery-mobile/
- I'd appreciate some testing and a review though (not being deep
into the jquery stuff on my own personally), and mabye Mathieu could
take care of a new upload (feel free to base it on what I did)?

regards,
-mika-


signature.asc
Description: Digital signature

Bug#829503: netbeans: Fails to create a new project as Java Application

[Ismael]

Package: netbeans
Version: 8.1+dfsg3-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Creating a new project

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

1. File/New Project
2. Java/Java Application, press next
3. Complete name and location, ensure "Create Main Class" is selected, press 
finish

   * What was the outcome of this action?

The wizard didn't close, and a silent notification appeared on status bar.

The notification in the details show this stack trace:

java.lang.ClassNotFoundException: freemarker.template.Template
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
Caused: java.lang.ClassNotFoundException: freemarker.template.Template starting 
from ModuleCL@4bc9a64f[org.netbeans.libs.freemarker] with possible defining 
loaders null and declared parents 
[org.netbeans.MainImpl$BootClassLoader@4eec, 
ModuleCL@4fe71683[org.netbeans.modules.queries]]
at org.netbeans.ProxyClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
Caused: java.lang.NoClassDefFoundError: freemarker/template/Template
at 
org.netbeans.libs.freemarker.FreemarkerFactory.getScriptEngine(Unknown Source)
at 
javax.script.ScriptEngineManager.getEngineByName(ScriptEngineManager.java:238)
at 
org.netbeans.modules.templates.ScriptingCreateFromTemplateHandler.getEngine(Unknown
 Source)
at 
org.netbeans.modules.templates.ScriptingCreateFromTemplateHandler.engine(Unknown
 Source)
at 
org.netbeans.modules.templates.ScriptingCreateFromTemplateHandler.accept(Unknown
 Source)
at org.netbeans.api.templates.CreateFromTemplateImpl.build(Unknown 
Source)
at org.netbeans.api.templates.CreateFromTemplateImpl.build(Unknown 
Source)
at org.netbeans.api.templates.FileBuilder.build(Unknown Source)
at org.netbeans.api.templates.FileBuilder.createFromTemplate(Unknown 
Source)
at org.openide.loaders.MultiDataObject.handleCreateFromTemplate(Unknown 
Source)
at org.openide.loaders.DataObject$CreateAction.run(Unknown Source)
at org.openide.loaders.DataObjectPool$1WrapAtomicAction.run(Unknown 
Source)
at org.openide.filesystems.EventControl.runAtomicAction(Unknown Source)
at org.openide.filesystems.FileSystem.runAtomicAction(Unknown Source)
at org.openide.loaders.DataObjectPool.runAtomicAction(Unknown Source)
at org.openide.loaders.DataObject.invokeAtomicAction(Unknown Source)
at org.openide.loaders.DataObject.createFromTemplate(Unknown Source)
at org.openide.loaders.DataObject.createFromTemplate(Unknown Source)
at 
org.netbeans.modules.java.j2seproject.api.J2SEProjectBuilder.createMainClass(Unknown
 Source)
at 
org.netbeans.modules.java.j2seproject.api.J2SEProjectBuilder.access$2100(Unknown
 Source)
at 
org.netbeans.modules.java.j2seproject.api.J2SEProjectBuilder$1.run(Unknown 
Source)
at org.openide.filesystems.EventControl.runAtomicAction(Unknown Source)
at org.openide.filesystems.FileSystem.runAtomicAction(Unknown Source)
at 
org.netbeans.modules.java.j2seproject.api.J2SEProjectBuilder.build(Unknown 
Source)
at 
org.netbeans.modules.java.j2seproject.J2SEProjectGenerator.createProject(Unknown
 Source)
at 
org.netbeans.modules.java.j2seproject.ui.wizards.NewJ2SEProjectWizardIterator.instantiate(Unknown
 Source)
at 
org.openide.loaders.TemplateWizard$InstantiatingIteratorBridge.instantiate(Unknown
 Source)
at org.openide.loaders.TemplateWizard.handleInstantiate(Unknown Source)
at org.openide.loaders.TemplateWizard.instantiateNewObjects(Unknown 
Source)
at org.openide.loaders.TemplateWizardIterImpl.instantiate(Unknown 
Source)
at 
org.openide.loaders.TemplateWizardIteratorWrapper$ProgressInstantiatingIterator.instantiate(Unknown
 Source)
at org.openide.WizardDescriptor.callInstantiateOpen(Unknown Source)
at org.openide.WizardDescriptor.callInstantiate(Unknown Source)
at org.openide.WizardDescriptor.access$2300(Unknown Source)
at org.openide.WizardDescriptor$Listener$2$1.run(Unknown Source)
at org.openide.util.RequestProcessor$Task.run(Unknown Source)
at org.netbeans.modules.openide.util.GlobalLookup.execute(Unknown 
Source)
[catch] at org.openide.util.lookup.Lookups.executeWith(Unknown Source)
at org.openide.util.RequestProcessor$Processor.run(Unknown Source)


   * What outcome did you expect instead?

The wizard should complete, and the project appear in the IDE.
The project folder is created, but appears empty.

Previously I had an error reported here 

Bug#829502: ITP: r-cran-rngtools -- GNU package for utility functions for working with Random Number Generators

[Alba Crespi]

Package: wnpp
Severity: wishlist
Owner: Alba Crespi 

* Package name: r-cran-rngtools
  Version : 1.2.4
  Upstream Author : Renaud Gaujoux 
* URL : https://cran.r-project.org/web/packages/rngtools/
* License : GPL-3
  Programming Lang: R
  Description : GNU package for utility functions for working with Random 
Number Generators

This package contains a set of functions for working with
Random Number Generators (RNGs). In particular, it defines a generic
S4 framework for getting/setting the current RNG, or RNG data
that are embedded into objects for reproducibility.
Notably, convenient default methods greatly facilitate the way current
RNG settings can be changed.

Bug#829501: ITP: r-cran-registry -- GNU R package for registries.

[Alba Crespi]

Package: wnpp
Severity: wishlist
Owner: Alba Crespi 

* Package name: r-cran-registry
  Version : 0.3
  Upstream Author : David Meyer 
* URL : https://cran.r-project.org/web/packages/registry/
* License : GPL-2
  Programming Lang: R
  Description : GNU R package for registries.

This package provides a generic infrastructure for creating and using
 registries.

Bug#829488: openrc: upgrade jessie -> stretch fails: util-linux.postinst: update-rc.d: not found

[Adam Borowski]

On Sun, Jul 03, 2016 at 08:28:45PM +0200, Andreas Beckmann wrote:
> Package: openrc
> Version: 0.21-1
> Severity: serious
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'jessie'.
> It installed fine in 'jessie', then the upgrade to 'stretch' fails.

> This seems to be related to openrc, since I haven't seen a similar failure
> without openrc installed.

The problem here is that init-system-helpers can't be relied upon to provide
update-rc.d without a versioned dependency as it's not yet present in
jessie's version.


Here's your log trimmed to interesting parts:

  The following packages will be REMOVED:
openrc systemd-sysv
  The following NEW packages will be installed:
file-rc gcc-6-base init-system-helpers sysvinit-core [...]
[...]
  dpkg: openrc: dependency problems, but removing anyway as you requested:
   initscripts depends on sysv-rc | file-rc; however:
Package sysv-rc is not installed.
Package openrc which provides sysv-rc is to be removed.
Package file-rc is not installed.
   systemd depends on sysv-rc; however:
Package sysv-rc is not installed.
Package openrc which provides sysv-rc is to be removed.
  
(Reading database ... 7525 files and directories currently installed.)
  Removing openrc (0.13.1-4) ...
[...]
  Setting up util-linux (2.28-5) ...
  Installing new version of config file /etc/init.d/hwclock.sh ...
  /var/lib/dpkg/info/util-linux.postinst: 35: 
/var/lib/dpkg/info/util-linux.postinst: update-rc.d: not fo
und


At that moment, openrc is already removed and init-system-helpers not yet
upgraded, thus update-rc.d is not present.  Handing over essential
functionality to another package requires a versioned dependency and is
notoriously hard to do right.  Not sure what's the proper package that
should express this dependency -- it's certainly not openrc though as at
this point apt cares only about jessie's version of it.


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#829500: undefined reference to `capng_have_capability'

[Hannes von Haugwitz]

Package: libaudit-dev
Version: 1:2.6.1-1
Severity: important

Dear Maintainer,

AIDE fails to build from source with libaudit-dev 1:2.6.1-1, due to
"undefined reference to `capng_have_capability'":

[...]
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libaudit.a(libaudit.o):
 In function `audit_is_enabled':
(.text+0x740): undefined reference to `capng_have_capability'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libaudit.a(libaudit.o):
 In function `audit_can_control':
(.text+0x273b): undefined reference to `capng_have_capability'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libaudit.a(libaudit.o):
 In function `audit_can_write':
(.text+0x274b): undefined reference to `capng_have_capability'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libaudit.a(libaudit.o):
 In function `audit_can_read':
(.text+0x275b): undefined reference to `capng_have_capability'
collect2: error: ld returned 1 exit status
Makefile:586: recipe for target 'aide' failed
make[3]: *** [aide] Error 1
make[3]: Leaving directory '/build/aide-0.16~b1/aide'
Makefile:434: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/build/aide-0.16~b1/aide'
dh_auto_build: make -j1 returned exit code 2
debian/rules:33: recipe for target 'override_dh_auto_build-arch' failed
make[1]: *** [override_dh_auto_build-arch] Error 2
make[1]: Leaving directory '/build/aide-0.16~b1'
debian/rules:25: recipe for target 'build' failed
make: *** [build] Error 2

The full build log is attached.

Best regards

Hannes


aide_0.16~b1-1_amd64.build.gz
Description: application/gzip

Bug#829499: src:xen: jessie xen domU in jessie dom0 sends ARP query for host behind router

[Holger Levsen]

Package: src:xen
Version: 4.4.1-9+deb8u5
Severity: normal

Dear Maintainer,

> * What led up to the situation?

Operated a domU with host-bridged network and a single static IP. The
dom0 interface is also a bridge, with one VLAN subinterface, one physical
interface and several vif interfaces for various other domU:s.

dom0 with standard jessie kernel 3.16.7-ckt25-2 and jessie userland.
domU with standard wheezy kernel 3.2.0-4-amd64 and jessie userland.

The domU was migrated to this dom0 from another dom0 with wheezy kernel and
userland, using the xm xen toolstack. The new jessie dom0 where the problem
was seen uses the xl xen toolstack.

The domU kernel was copied along with the domU disk image and *not* booted
using pygrub but specified in the xen .cfg file used to create the domU on
the new dom0.


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

ping to a particular internet IP within the domU.


> * What was the outcome of this action?

An ARP request for the internet IP was seen by tcpdump running in dom0.


> * What outcome did you expect instead?

An ARP request for the default gateway IP seen by tcpdump running in dom0.



When trying to reproduce this problem by starting the domU on the problematic
dom0 host but connected to a new, different, bridge interface on the dom0,
unfortunately we have so far *not* been successful. Another difference
in the real life situation where that the dom0 was running 6 or 7 domUs.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#827834: deprecated: use ruby-state-machines instead

[Cédric Boutillier]

Package: ruby-state-machine
Followup-For: Bug #827834


This gem is indicated as obsolete, see:
https://github.com/pluginaweek/state_machine/issues/343

the only reverse dependency ruby-eye has been patched to use a
maintained fork, ruby-state-machines, already in the archive.

This bug is not worth fixing. Just remove the package when the new ruby-eye 
0.7-4
migrates to testing.

Cheers,

Cédric

Bug#829375: [PKG-Openstack-devel] Bug#829375: Bug#829375: Bug#829375: IOError: No such file or directory: '/etc/swift/account.ring.gz'

[Turbo Fredriksson]

On Jul 3, 2016, at 10:05 PM, Turbo Fredriksson wrote:

> Thanx! While you're at it, do the same for the other
> services as well.

Sorry, just took a look at the patch and I see you did.
Thanx.
-- 
Try not. Do. Or do not. There is no try!
- Yoda

Bug#829375: [PKG-Openstack-devel] Bug#829375: Bug#829375: Bug#829375: IOError: No such file or directory: '/etc/swift/account.ring.gz'

[Turbo Fredriksson]

On Jul 3, 2016, at 10:01 PM, Ondrej Novy wrote:

> you are right, sorry I misunderstood you. Fixed in git.


Thanx! While you're at it, do the same for the other
services as well.
-- 
I love deadlines. I love the whooshing noise they
make as they go by.
- Douglas Adams

Bug#829375: [PKG-Openstack-devel] Bug#829375: Bug#829375: IOError: No such file or directory: '/etc/swift/account.ring.gz'

[Ondrej Novy]

Hi,

2016-07-03 21:45 GMT+02:00 Turbo Fredriksson :

>  still consider it a bug. The service(s) should refuse to
> start if these files don't exist.
>

you are right, sorry I misunderstood you. Fixed in git.

-- 
Best regards
 Ondřej Nový

Bug#829293: libatk-wrapper-java: Can't create new web project in Netbeans 8.1 when AtkWrapper is activated

[Ismael Bejarano]

Hi!

2016-07-03 15:20 GMT-03:00 Samuel Thibault :
>
> Hello,
>
> Ismael, on Sat 02 Jul 2016 02:41:11 -0300, wrote:
> > 1. File/New Project/Java Web/Web Application, press next
>
> I don't have a "Java Web" choice there, do I need some additional
> netbeans package to get it?
>

I've installed the plugin "Restful Web Services" from Tools/Plugins (you
first have to enable
Netbeans distribution in the Settings tab).


> > java.lang.NullPointerException
> >   at
org.GNOME.Accessibility.AtkWrapper$4.propertyChange(AtkWrapper.java:584)
>
> I see how that could happen, I have built fixed packages on
> http://people.debian.org/~sthibault/tmp/
> could you give them a try?
>

After installing your packages that exception is gone. Although Netbeans
still fails with other exception java.lang.ClassNotFoundException:
freemarker.template.Template. I'll report a new bug it against Netbeans.

ii  libatk-wrapper-java 0.33.3-8 all
   ATK implementation for Java using JNI
ii  libatk-wrapper-java-jni:amd64   0.33.3-8 amd64
   ATK implementation for Java using JNI (JNI bindings)


> Thanks,
> Samuel

Thank you very much for the quick response!

Regards,

Ismael

Bug#829498: shadowsocks-libev: FTBFS on alpha and hppa: -fstack-protector not supported

[Aaron M. Ucko]

Source: shadowsocks-libev
Version: 2.4.7+20160630+ds-1
Severity: important
Justification: fails to build from source

Builds of shadowsocks-libev on alpha and hppa have been failing:

  utils.c:1:0: error: -fstack-protector not supported for this target [-Werror]

It looks like this instance of -fstack-protector comes from upstream's
build system, which doesn't account for these architectures' lack of
support for it.  Moreover, on the remaining architectures, dpkg-buildflags
already supplies -fstack-protector-strong, so -fstack-protector either is
redundant or results in less strong protection.

Ideally, upstream's build system would test that -fstack-protector
actually works, rather than hardcoding a list of architectures on which
it's expected to.  (It would be even better if the build system got out of
the way if it noticed -fstack-protector or -fstack-protector-strong
already in CFLAGS.)

As it is, I would suggest unconditionally configuring with --disable-ssp
and deferring to dpkg-buildflags.

Could you please take a look?

Thanks!

Bug#796608: espeakup: diff for NMU version 1:0.71-27.1

[Felipe Sateler]

On 3 July 2016 at 16:44, Samuel Thibault  wrote:
> Felipe Sateler, on Sun 03 Jul 2016 17:38:58 -0300, wrote:
>> On 3 July 2016 at 16:33, Samuel Thibault  wrote:
>> > Felipe Sateler, on Sun 03 Jul 2016 17:31:14 -0300, wrote:
>> >> I think the daemonization needs to move later as well:
>> >
>> > Why?
>>
>> Because the usual protocol is "fork when ready".
>
> ? I would rather expect it to be "parent exits when ready".

Indeed. But using daemon(3), "fork" and "parent exit" time are the same.

>
>> > Opening the sound card before forking doesn't look like a good idea to
>> > me.
>>
>> Why would it be bad?
>
> Because then you have two processes which hold a file descriptor on the
> sound card, one will close it, and you never know what the driver would
> be doing.

That seems a valid concern.

>
>> Eg, pulseaudio opens the sound card before forking as well.
>
> Is it really?  That doesn't sound really safe to me.

And indeed, I was wrong. I now rechecked and indeed it first forks and
then loads the device modules. But the parent waits for the child to
be done before exiting. Which appears to be impossible with daemon(3).

-- 

Saludos,
Felipe Sateler

Bug#829497: ruby-bdb: unmaintained

[Christian Hofstaedtler]

Package: ruby-bdb
Severity: serious

ruby-bdb has a dead upstream and we do not really want it to be in
stretch.

Filing this bug to cause a testing removal, and follow up with an RM
bug in a while.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#784602: please make monkeysign reproducible

[intrigeri]

Hi,

Daniel Kahn Gillmor wrote (07 May 2015 04:24:33 GMT) :
> The attached patch should fix the problem.

This patch should be updated to use $SOURCE_DATE_EPOCH, I suppose.

Cheers,
--
intrigeri

Bug#829496: kpartx -d ( detach ) option silently fails

[Emmanuel Kasper]

Package: kpartx
Version: 0.6.1-3
Severity: normal

Hi

Since the 0.6.1-* version of kpartx, the '-d' option does not work anymore.

Simple test case:

# add loopdevice and partition mappings, freedos.raw is here a disk image
kpartx -av freedos.raw
add map loop0p1 (253:0): 0 262017 linear 7:0 63

# ask kpartx to detach the loop device
kpartx -d freedos.raw

# but the loop device is still there
file --special-files --dereference /dev/loop0 
/dev/loop0: DOS/MBR boot sector; partition 1 : ID=0xe, active, start-CHS 
(0x0,1,1), end-CHS (0x13,15,63), startsector 63, 262017 sectors

losetup --list 
NAME   SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE  
DIO
/dev/loop0 0  0 0  0 
/home/manu/Projects/emul/i386/kvm/freedos.raw

fortunately it is possible to detach manually the loop device with losetup 
--detach /dev/loop0


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

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

Versions of packages kpartx depends on:
ii  dmsetup 2:1.02.124-1
ii  libc6   2.22-11
ii  libdevmapper1.02.1  2:1.02.124-1
ii  udev230-2

kpartx recommends no packages.

kpartx suggests no packages.

-- no debconf information

Bug#796608: espeakup: diff for NMU version 1:0.71-27.1

[Samuel Thibault]

Felipe Sateler, on Sun 03 Jul 2016 17:38:58 -0300, wrote:
> On 3 July 2016 at 16:33, Samuel Thibault  wrote:
> > Felipe Sateler, on Sun 03 Jul 2016 17:31:14 -0300, wrote:
> >> I think the daemonization needs to move later as well:
> >
> > Why?
> 
> Because the usual protocol is "fork when ready".

? I would rather expect it to be "parent exits when ready".

> > Opening the sound card before forking doesn't look like a good idea to
> > me.
> 
> Why would it be bad?

Because then you have two processes which hold a file descriptor on the
sound card, one will close it, and you never know what the driver would
be doing.

> Eg, pulseaudio opens the sound card before forking as well.

Is it really?  That doesn't sound really safe to me.

Samuel

Bug#796700: #796700: fixed in unstable

[Joost van Baal-Ilić]

On Sun, Jul 03, 2016 at 08:32:03PM +0200, Christian Hofstaedtler wrote:
> Control: fixed -1 20160218-1
> 
> The uruk package started installing an uruk.service in version
> 20160218-1.

Thanks for taking care of this.

Bye,

Joost

Bug#796608: espeakup: diff for NMU version 1:0.71-27.1

[Felipe Sateler]

On 3 July 2016 at 16:33, Samuel Thibault  wrote:
> Felipe Sateler, on Sun 03 Jul 2016 17:31:14 -0300, wrote:
>> I think the daemonization needs to move later as well:
>
> Why?

Because the usual protocol is "fork when ready". This way you can
simply do stuff like:

$ sudo espeakup && espeak hola || echo "failed to start!"

And it works as expected.


> Opening the sound card before forking doesn't look like a good idea to
> me.

Why would it be bad? Eg, pulseaudio opens the sound card before forking as well.

> I prefer to use the pidfile presence as the notification of
> espeakup being ready than risking forkish things :)

I think the usual protocol is that the forking is done when ready.

-- 

Saludos,
Felipe Sateler

Bug#829495: libosinfo: FTBFS: amd64 .la path hardcoded in debian/rules

[Aaron M. Ucko]

Source: libosinfo
Version: 0.3.1-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of libosinfo for architectures other than amd64 have been
failing with errors along the lines of

 debian/rules override_dh_install
  make[1]: Entering directory '/«PKGBUILDDIR»'
  rm -f debian/tmp/usr/lib/x86_64-linux-gnu/libosinfo-1.0.la
  dh_install --fail-missing
  dh_install: usr/lib/aarch64-linux-gnu/libosinfo-1.0.la exists in debian/tmp 
but is not installed to anywhere
  dh_install: missing files, aborting
  debian/rules:38: recipe for target 'override_dh_install' failed
  make[1]: *** [override_dh_install] Error 2
  make[1]: Leaving directory '/«PKGBUILDDIR»'
  debian/rules:22: recipe for target 'binary-arch' failed
  make: *** [binary-arch] Error 2

Please replace the hardcoded path component x86_64-linux-gnu with
either $(DEB_HOST_MULTIARCH) or a wildcard.

Thanks!

Bug#829494: chirpw phones home without informed consent

[Neil Van Dyke]

Package: chirp
Version: 0.4.0-1
Severity: serious

A pop-up dialog from the "chirpw" program says that it reports some kind 
of usage information to some external party, and describes how to 
opt-out of this.  There are at least two privacy problems:


1. It appears that some phoning home happens before the user has given 
informed consent.  For example, when I received the pop-up dialogue, I 
immediately disabled reporting, but I found that "chirpw" had already 
contacted some server and informed me that I was not using the latest 
version.  Therefore, the suggestion that one can opt-out of phoning-home 
is misleading, since some phoning-home has already occurred.


2. Also, the text suggests that this is anonymous, but that is 
misleading (due, e.g., to IP address traceability), so any consent would 
not be informed, even were it given prior to phoning-home occurring.


Note that I have not looked at what information is transmitted, so there 
might be a third problem, but I believe these two identified problems 
alone require action.


I recommend and request that this reporting and any other "phoning home" 
either be disabled completely in the Debian "chirp" package, or changed 
to be an express *opt-in* (like opt-in is long used elsewhere in Debian, 
such as for package "popularity contest"). Thank you.

Bug#796608: espeakup: diff for NMU version 1:0.71-27.1

[Samuel Thibault]

Felipe Sateler, on Sun 03 Jul 2016 17:31:14 -0300, wrote:
> I think the daemonization needs to move later as well:

Why?

Opening the sound card before forking doesn't look like a good idea to
me.  I prefer to use the pidfile presence as the notification of
espeakup being ready than risking forkish things :)

Samuel

Bug#796608: espeakup: diff for NMU version 1:0.71-27.1

[Christian Hofstaedtler]

Hello,

* Samuel Thibault  [160703 22:27]:
> Christian Hofstaedtler, on Sun 03 Jul 2016 22:02:59 +0200, wrote:
> > * Samuel Thibault  [160703 21:51]:
> > > Christian Hofstaedtler, on Sun 03 Jul 2016 21:43:01 +0200, wrote:
> > > > There's another minor thing I've noticed: espeakup takes a
> > > > relatively long time to write it's pidfile after forking.
> > > 
> > > What do you mean by "long time"? seconds? minutes?
> > 
> > No, in my testing it takes 0.2sec. So not really "long time", but
> > too long for systemd to notice the pidfile at the first try.
> 
> Ok. But does systemd retry several times? If so, then we are as safe as
> the init.d script version, unless there are other side effects?

It appears to. The main process tracking appears to work correctly.
I'll report a bug in systemd about this though.

> [..]
> 
> > I've tried reverting that patch, and then systemd finds the pidfile.
> 
> But we do need the change :)

Ok. I'll upload the previously submitted diff to DELAYED/5, and
propose we'll see what comes out of the systemd bug report at a
later time.

Thanks,
-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-