Bug#819611: libcupsfilters-dev: #include should be #include

[Jason Lewis]

Package: libcupsfilters-dev
Version: 1.0.61-5+deb8u3
Severity: normal

Dear Maintainer,


   * What led up to the situation?
trying to compile and install the Perl module Net::CUPS::Destination

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
raster.h has been moved from /usr/include/cups to /usr/include/cupsfilters but
the cups header files still try and #include it as cups/raster.h


see /usr/include/cupsfilters/*.h  image.h, driver.h, colormanger.h and raster.h
have the wrong path.




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

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

Versions of packages libcupsfilters-dev depends on:
ii  libcupsfilters1  1.0.61-5+deb8u3

libcupsfilters-dev recommends no packages.

libcupsfilters-dev suggests no packages.

-- no debconf information

Bug#790690: Powermac G5 7,2 Nvidia GeForce 6800 GT graphics issues

[Risto Suominen]

The corresponding source package number is 3.16.7-ckt20-1+deb8u4.

Risto

Bug#819610: mate-panel hangs with 100% CPU on restart with specific layout

[Jephte CLAIN]

Package: mate-panel
Version: 1.8.1+dfsg1-3
Severity: important

Dear Maintainer,

When I change the layout to put the bottom panel to the top (such that there is
2 panels at the top), everything works fine until I restart the session. Then
the screen is empty with a flickering blank panel at the top. Switching to the
console, I can see that mate-panel is eating 100% CPU and eventually dies
because of out of memory condition.

This is 100% reproducible. I have to reset the panel to be able to login again:
DISPLAY=:0.0
mate-panel --reset
sudo service lightdm restart

I have searched on internet, and several people have the same problem, but I
can't find any bug report, so there it is.

This is annoying. I just upgraded from squeeze that I have run for several
years, and I would like to put the two panels to the top like I'm used to.

I have not tested if the problem is still there with more recent versions of
mate-panel. Even if it was fixed in a later version, I cannot afford to run
anything but debian stable.

I'm willing to help by testing any fix. Thank you for your help. 
Best regards,
Jephte Clain


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

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

Versions of packages mate-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.22.0-1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u3
ii  libcairo21.14.0-2.1
ii  libcanberra-gtk0 0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libdbus-1-3  1.8.20-0+deb8u1
ii  libdbus-glib-1-2 0.102-1
ii  libdconf10.22.0-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-3+deb8u1
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u4
ii  libglib2.0-0 2.42.1-1
ii  libgtk2.0-0  2.24.25-3
ii  libice6  2:1.0.9-1+b1
ii  libmate-desktop-2-17 1.8.1+dfsg1-3+deb8u1
ii  libmate-menu21.8.0-5
ii  libmate-panel-applet-4-1 1.8.1+dfsg1-3
ii  libmateweather1  1.8.0-2
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  librsvg2-2   2.40.5-1
ii  libsm6   2:1.2.2-1+b1
ii  libstartup-notification0 0.12-4
ii  libwnck222.30.7-2
ii  libx11-6 2:1.6.2-3
ii  libxau6  1:1.0.8-1
ii  libxrandr2   2:1.4.2-1+b1
ii  mate-desktop 1.8.1+dfsg1-3+deb8u1
ii  mate-menus   1.8.0-5
ii  mate-panel-common1.8.1+dfsg1-3
ii  mate-polkit  1.8.0+dfsg1-4
ii  menu-xdg 0.5
ii  python   2.7.9-1

mate-panel recommends no packages.

mate-panel suggests no packages.

-- no debconf information

Bug#819546: vsftpd no longer starts with systemd because of listen_ipv6=NO from Bug: #803999

[Jörg Frings-Fürst]

severity 819546 normal
thanks

Hello Louis,

thank you for spending your time helping to make Debian better with
this bug report.

I think that no configuration of vsftpd should be activated without
verification.

FTP is also not a service that is absolutely necessary immediately
after a new installation for the system functionality.

And there are many examples configurations in the documentation.

I do not close this bug because when installing no notice will be
posted.

CU
Jörg



-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54538 Bausendorf

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#807698: CVE-2015-6360: Prevent potential DoS attack due to lack of bounds checking on RTP header CSRC count and extension header length

[Markus Koschany]

Control: severity -1 important

On Fri, 11 Dec 2015 18:22:55 +0100 Guido =?iso-8859-1?Q?G=FCnther?=
 wrote:
> Source: srtp
> Version: 1.4.5~20130609~dfsg-1.1
> Severity: grave
> Tags: security
> 
> Hi,
> from what I figured out it seems the 1.4 series is also affected by
> CVE-2015-6360. While there is no aead mode srtp_unprotect needs the
> patch nevertheless. See:
> 
> https://security-tracker.debian.org/tracker/CVE-2015-6360
> 
> for a list of patches.
> Cheers,
>  -- Guido


Hello Guido, hello Security Team,

I have investigated bug #807698, alias CVE-2015-6360, and I agree with
Guido that at least Wheezy is partially affected. I'm attaching my
proposed patch for this issue. AEAD mode is not available in those
versions, so there is only one hunk that can be applied to the
srtp_unprotect function in srtp/srtp.c.

However I don't think Jessie/Stretch/Sid are affected as well. Looking
at srtp/srtp.c again the AEAD mode is still not present and none of the
upstream commits from [1] can be applied for the srtp_protect and
srtp_unprotect functions. Thus I'm going to downgrade the severity to
important for now. I would appreciate another look and confirmation though.

Regards,

Markus


[1]
https://github.com/cisco/libsrtp/commit/704a31774db0dd941094fd2b47c21638b8dc3de2
From: Markus Koschany 
Date: Wed, 30 Mar 2016 18:51:04 +0200
Subject: CVE-2015-6360

---
 srtp/srtp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/srtp/srtp.c b/srtp/srtp.c
index 3301858..a0dd047 100644
--- a/srtp/srtp.c
+++ b/srtp/srtp.c
@@ -1076,6 +1076,8 @@ srtp_unprotect(srtp_ctx_t *ctx, void *srtp_hdr, int *pkt_octet_len) {
   srtp_hdr_xtnd_t *xtn_hdr = (srtp_hdr_xtnd_t *)enc_start;
   enc_start += (ntohs(xtn_hdr->length) + 1);
 }  
+if (!((uint8_t*)enc_start < (uint8_t*)hdr + (*pkt_octet_len - tag_len)))
+return err_status_parse_err;
 enc_octet_len = (uint32_t)(*pkt_octet_len - tag_len 
 			   - ((enc_start - (uint32_t *)hdr) << 2));
   } else {


signature.asc
Description: OpenPGP digital signature

Bug#819475: [Pkg-rust-maintainers] Bug#819475: Bug#819475: rustc not run depend on gcc 4.9.2

[Lihe Wang]

I said I resolved this problem by update gcc tool chain. I send report not
ask for "rustc should support gcc 4.9 and binutils ", I mean you should
add binutils versions into dep list to make it run correctly just after
someone type "apt install rustc". The dep list you are using is making
"installation not complete".

Please do that to make other people install rustc easier. I can run rustc
perfect now and don't need any more help, so close the report if you want.

2016-03-30 11:19 GMT+08:00 Angus Lees :

> On Wed, 30 Mar 2016 at 13:27 Lihe Wang 
> wrote:
>
>> #~ rustc hello.rs
>> error: linking with `cc` failed: exit code: 1
>> note: "cc" "-Wl,--as-needed" "-m64" "-L"
>> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "hello.0.o" "-o" "hello"
>> "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L"
>> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic"
>> "-Wl,-Bdynamic"
>> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-6a154fe0.rlib"
>> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-6a154fe0.rlib"
>> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-6a154fe0.rlib"
>> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-6a154fe0.rlib"
>> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-6a154fe0.rlib"
>> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-6a154fe0.rlib"
>> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-6a154fe0.rlib"
>> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-6a154fe0.rlib" "-l"
>> "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt"
>> "-l" "compiler-rt"
>> note: /usr/bin/ld:
>> /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-6a154fe0.rlib(jemalloc.pic.o):
>> unrecognized relocation (0x2a) in section `.text.malloc_conf_init'
>> /usr/bin/ld: final link failed: Bad value
>> collect2: error: ld returned 1 exit status
>>
>
> It looks like this is a change in recent binutils (see discussion in
> Bug#808205) - which I _think_ means our static libraries (librust-std-dev)
> need to depend on binutils >= 2.25.90.20151209-1.  I note in the glibc-dev
> case, however, the decision was "I therefore don't think we need to fix
> that at the glibc level. Either we just ignore the problem saying we don't
> support partial upgrades or we try to find a global way to fix the
> dependencies for all libraries."
>
> Lihe: The short version for you is if you're trying to run a mixed
> stable/testing system(*), then you will also need to install binutils from
> testing.
> (*) rather than rebuild rustc.deb from source for stable.  If we had
> enough man-power, it would probably make sense for us to maintain a
> rustc.deb for stable-backports.
>
>  - Gus
>

Bug#819576: linux-image-4.4.0-0.bpo.1-amd64: Brightness slowdown - Changing brightness takes some seconds and causes system slowdown

[Leonardo Santana Vieira]

I uninstalled the 3 modules mentioned from kernel 4.4 and it didn't solve
the problem.

"uname -a" command result:
Linux debian 4.4.0-0.bpo.1-amd64 #1 SMP Debian 4.4.6-1~bpo8+1 (2016-03-20)
x86_64 GNU/Linux

"dkms status" command result:
bbswitch, 0.8, 3.16.0-4-amd64, x86_64: installed
bbswitch, 0.8, 4.3.0-0.bpo.1-amd64, x86_64: installed
nvidia-current, 352.79, 3.16.0-4-amd64, x86_64: installed
nvidia-current, 352.79, 4.3.0-0.bpo.1-amd64, x86_64: installed
virtualbox, 5.0.16, 3.16.0-4-amd64, x86_64: installed
virtualbox, 5.0.16, 4.3.0-0.bpo.1-amd64, x86_64: installed


2016-03-30 16:50 GMT-03:00 Ben Hutchings :

> Control: tag -1 moreinfo
>
> On Wed, 2016-03-30 at 14:14 -0300, Leonardo Santana Vieira wrote:
> > Package: src:linux
> > Version: 4.4.6-1~bpo8+1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > After kernel upgrade, changing brightness takes some seconds and causes
> system
> > slowdown if i try to change more than one level at a time. This problem
> does
> > not happen in the other kernel packages i have installed(3.16, 4.3). I'm
> using
> > Gnome desktop, the problem happens when i try the change through the
> menu at
> > the top bar and especially if i try using fn keys to do it. If a hold
> fn+f5 or
> > f6 all the way to minimum or maximum, the action causes severe slowdown
> in the
> > system making it unusable for some time. I have theses modules installed
> in all
> > the kernel packages as can be seen below the result of "dkms status"
> command.
> >
> > bbswitch, 0.8, 3.16.0-4-amd64, x86_64: installed
> > bbswitch, 0.8, 4.3.0-0.bpo.1-amd64, x86_64: installed
> > bbswitch, 0.8, 4.4.0-0.bpo.1-amd64, x86_64: installed
> > nvidia-current, 352.79, 3.16.0-4-amd64, x86_64: installed
> > nvidia-current, 352.79, 4.3.0-0.bpo.1-amd64, x86_64: installed
> > nvidia-current, 352.79, 4.4.0-0.bpo.1-amd64, x86_64: installed
> > virtualbox, 5.0.16, 3.16.0-4-amd64, x86_64: installed
> > virtualbox, 5.0.16, 4.3.0-0.bpo.1-amd64, x86_64: installed
> > virtualbox, 5.0.16, 4.4.0-0.bpo.1-amd64, x86_64: installed
> [...]
>
> Please test without these modules installed.
>
> Ben.
>
> --
> Ben Hutchings
> Tomorrow will be cancelled due to lack of interest.

Bug#818708: didiwiki regression: fix for CVE-2013-7448 renders many existing pages inaccessible

[Ignace Mouzannar]

Hi Sergio,

Thank you for reporting this issue. Here is the fix I intend to push
in src/wiki.c. I have tested the solution on my didiwiki installation,
and it seems to be working fine.


int page_name_is_good(char* page_name)
{
/* We should give access only to subdirs of didiwiki root.
   I guess that check for absense of '/' is enough.

   TODO: Use realpath()
*/
if (!page_name)
return FALSE;

if (strncmp(page_name, "/", 1) == 0)
return FALSE;

if (strncmp(page_name, "./", 2) == 0)
return FALSE;

if (strncmp(page_name, "..", 2) == 0)
return FALSE;

if (strstr(page_name, "../"))
return FALSE;

if (strstr(page_name, "/.."))
return FALSE;

return TRUE;
}


I will be pushing this solution, , unless you think there is a better
way to solve this.

Cheers,
 Ignace M

Bug#819604: arduino-mk: Broken with latest pyserial

[Ian Wienand]

Package: arduino-mk
Version: 1.5-2
Severity: normal

Hi,

/usr/bin/ard-reset-arduino isn't compatible with pyserial 3.0 as in
testing.  It was fixed with [1] which is in the 1.5.1 release.  Ergo,
updating to this should fix the bug

Thanks,

-i

[1] 
https://github.com/sudar/Arduino-Makefile/commit/745b520dd6de348c2016a9c699b8590290819195

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

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

Versions of packages arduino-mk depends on:
ii  arduino-core   2:1.0.5+dfsg2-4
ii  make   4.1-9
ii  python 2.7.11-1
ii  python-serial  3.0.1-1

Versions of packages arduino-mk recommends:
ii  screen  4.3.1-2

arduino-mk suggests no packages.

-- no debconf information

Bug#819603: aptitude: [INTL:ja] Japanese translation of po documentation update

[Takuma Yamada]

Package: aptitude
Version: 0.6.11-1+b1
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

Here's Japanese translationf of po documentation (ja.po) file that 
reviewed by several Japanese Debian developers and users.

Please copy the attachment into po/ja.po.

Kind regards.
--
Takuma Yamada


-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.6.11 compiled at Nov  8 2014 13:34:39
Compiler: g++ 4.9.1
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.4.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20140913
  cwidget version: 0.5.17
  Apt version: 4.12.0

aptitude linkage:
linux-vdso.so.1 (0x7ffed47a2000)
libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 
(0x7fc2ca20a000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7fc2c9fd4000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7fc2c9daa000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fc2c9ba4000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7fc2c988e000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fc2c95c5000)
libboost_iostreams.so.1.55.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7fc2c93ad000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x7fc2c8f9c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fc2c8d7f000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fc2c8a74000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fc2c8773000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fc2c855d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc2c81b2000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7fc2c7faf000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc2c7dab000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fc2c7b9)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fc2c798)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fc2c775d000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fc2c7555000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fc2c735)
/lib64/ld-linux-x86-64.so.2 (0x7fc2cabcc000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.6.11-1
ii  libapt-pkg4.121.0.9.8.2
ii  libboost-iostreams1.55.0  1.55.0+dfsg-3
ii  libc6 2.19-18+deb8u3
ii  libcwidget3   0.5.17-2
ii  libgcc1   1:4.9.2-10
ii  libncursesw5  5.9+20140913-1+b1
ii  libsigc++-2.0-0c2a2.4.0-1
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstdc++64.9.2-10
ii  libtinfo5 5.9+20140913-1+b1
ii  libxapian22   1.2.19-1

Versions of packages aptitude recommends:
ii  aptitude-doc-en [aptitude-doc]  0.6.11-1
ii  libparse-debianchangelog-perl   1.2.0-1.1
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
pn  apt-xapian-index  
pn  debtags   
ii  tasksel   3.31+deb8u1

-- no debconf information


ja.po.gz
Description: application/gzip

Bug#819602: nodm: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Package: nodm
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

Here's Japanese po-debconf templates translation (ja.po) file that 
reviewed by several Japanese Debian developers and users.

Please copy the attachment into debian/po/ja.po.

Kind regards.
--
Takuma Yamada


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

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


ja.po.gz
Description: application/gzip

Bug#819601: kexec-tools: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Package: kexec-tools
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

Here's Japanese po-debconf templates translation (ja.po) file that 
reviewed by several Japanese Debian developers and users.

Please copy the attachment into debian/po/ja.po.

Kind regards.
--
Takuma Yamada


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

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


ja.po.gz
Description: application/gzip

Bug#809344: ntp: Confirming issue and provided patch

[Michael Berg]

Package: ntp
Version: 1:4.2.8p4+dfsg-3+b1
Followup-For: Bug #809344
Tags: patch

Since the original bug report didn't have the "patch" tag, I'm following
up to add the patch tag.

--- ntp.orig	2016-03-30 19:04:47.859783599 -0600
+++ ntp.fixed	2016-03-30 19:31:39.542680609 -0600
@@ -40,9 +40,9 @@
 		echo "server $server iburst"
 	  done
 	  echo
-	  sed -r -e '/^ *(server|peer).*$/d' $NTP_CONF
+	  sed -r -e '/^ *(server|peer|pool).*$/d' $NTP_CONF
 	) >>$tmp
-	
+
 	mv $tmp $NTP_DHCP_CONF
 
 	ntp_server_restart

Bug#819600: kismet: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Source: kismet
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

Here's Japanese po-debconf templates translation (ja.po) file that 
reviewed by several Japanese Debian developers and users.

Please copy the attachment into debian/po/ja.po.

Kind regards.
--
Takuma Yamada


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

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


ja.po.gz
Description: application/gzip

Bug#819599: tzdata: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Package: tzdata
Version: 2015g-0+deb8u1
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

Here's Japanese po-debconf templates translation (ja.po) file that 
reviewed by several Japanese Debian developers and users.

Please copy the attachment into debian/po/ja.po.

Kind regards.
--
Takuma Yamada


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

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

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0]  1.5.56

tzdata recommends no packages.

tzdata suggests no packages.

-- debconf information excluded


ja.po.gz
Description: application/gzip

Bug#809344: ntp: Confirming issue and provided patch

[Michael Berg]

Package: ntp
Version: 1:4.2.8p4+dfsg-3+b1
Followup-For: Bug #809344

I recently noticed this same issue with the dhcp hook
not removing the new "pool" lines from copied ntp.conf.

This issue is still present in 1:4.2.8p4+dfsg-3+b1.

I can also confirm that the patch provided by Ron
in the initial bug report fixes this issue.
I independently arrived at the same patch and then
found Ron's bug report when I was checking the ntp
bug list before submitting my report and patch.

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

Kernel: Linux 4.4.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 ntp depends on:
ii  adduser  3.114
ii  dpkg 1.18.4
ii  libc62.22-5
ii  libcap2  1:2.24-12
ii  libedit2 3.1-20150325-1+b1
ii  libopts251:5.18.7-3
ii  libssl1.0.2  1.0.2g-1
ii  lsb-base 9.20160110
ii  netbase  5.3

Versions of packages ntp recommends:
ii  perl  5.22.1-9

Versions of packages ntp suggests:
pn  ntp-doc  

-- no debconf information

Bug#819598: (no subject)

[Matthew Gabeler-Lee]

Addenda:

I meant #816865, not 816815

Upgrading bluez locally gets rid of the prior errors, but produces other
errors, and the mouse still doesn't work (at first, but keep reading)

I cleared the previous pairing and tried to re-pair, just to be "safe"

Mar 30 21:20:56 hostname bluetoothd[1421]: GATT service objects disabled
Mar 30 21:20:56 hostname kernel: [   36.700194] Bluetooth: SMP security
requested but not available

The last line repeats every ~15 *milliseconds* until it times out and
gives up.  That sounds like
https://bugzilla.kernel.org/show_bug.cgi?id=104011

Following the suggestion there (bluetoothctl power off / power on) I was
able to pair and use the mouse!

The kernel.org ticket suggests it will be temporarily broken again when
I reboot, and that the root cause of that is a udev rule causing the
bluetooth host to be brought up in "legacy mode".

Bug#819548: gnome-maps fails to start

[gpe92]

Package: gnome-maps
Version: 3.20.0-1
Followup-For: Bug #819548

Same problem for me:

(org.gnome.Maps:25763): Gjs-WARNING **: JS ERROR: TypeError: 
GObject.ParamSpec.override is not a function
@resource:///org/gnome/Maps/js/mapMarker.js:44
@resource:///org/gnome/Maps/js/placeMarker.js:24
@resource:///org/gnome/Maps/js/geoJSONSource.js:30
@resource:///org/gnome/Maps/js/geoJSONShapeLayer.js:22
@resource:///org/gnome/Maps/js/mapView.js:34
@resource:///org/gnome/Maps/js/mainWindow.js:38
@resource:///org/gnome/Maps/js/application.js:36
@resource:///org/gnome/Maps/js/main.js:43
start@resource:///org/gnome/gjs/modules/package.js:176
@/usr/bin/gnome-maps:5

JS_EvaluateScript() failed

BR

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

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

Versions of packages gnome-maps depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  geoclue-2.0  2.4.1-1
ii  gir1.2-champlain-0.120.12.13-1
ii  gir1.2-clutter-1.0   1.24.2-1
ii  gir1.2-cogl-1.0  1.22.0-2
ii  gir1.2-gdkpixbuf-2.0 2.32.3-1.2
ii  gir1.2-geoclue-2.0   2.4.1-1
ii  gir1.2-geocodeglib-1.0   3.20.0-1
ii  gir1.2-gfbgraph-0.2  0.2.3-1
ii  gir1.2-glib-2.0  1.46.0-4
ii  gir1.2-goa-1.0   3.18.4-1
ii  gir1.2-gtk-3.0   3.18.9-1
ii  gir1.2-gtkchamplain-0.12 0.12.13-1
ii  gir1.2-gtkclutter-1.01.6.6-1
ii  gir1.2-gweather-3.0  3.20.0-1
ii  gir1.2-rest-0.7  0.7.93-1
ii  gir1.2-secret-1  0.18.3-1
ii  gir1.2-soup-2.4  2.52.2-1
ii  gir1.2-webkit2-4.0   2.10.8-1
ii  gjs  1.43.3-2
ii  libatk1.0-0  2.18.0-1
ii  libc62.22-4
ii  libcairo-gobject21.14.6-1
ii  libcairo21.14.6-1
ii  libchamplain-0.12-0  0.12.13-1
ii  libclutter-1.0-0 1.24.2-1
ii  libcogl-pango20  1.22.0-2
ii  libcogl-path20   1.22.0-2
ii  libcogl201.22.0-2
ii  libdrm2  2.4.67-1
ii  libegl1-mesa [libegl1-x11]   11.1.2-1
ii  libfolks25   0.11.1-2+b1
ii  libgbm1  11.1.2-1
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libgee-0.8-2 0.18.0-1
ii  libgeocode-glib0 3.20.0-1
ii  libglib2.0-0 2.48.0-1
ii  libgtk-3-0   3.18.9-1
ii  libjson-glib-1.0-0   1.2.0-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  librest-0.7-00.7.93-1
ii  libsoup2.4-1 2.52.2-1
ii  libwayland-client0   1.9.0-1
ii  libwayland-cursor0   1.9.0-1
ii  libwayland-egl1-mesa [libwayland-egl1]   11.1.2-1
ii  libwayland-server0   1.9.0-1
ii  libx11-6 2:1.6.3-1
ii  libxcomposite1   1:0.4.4-1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.1-2+b2
ii  libxi6   2:1.7.6-1
ii  libxkbcommon00.5.0-1
ii  libxml2  2.9.3+dfsg1-1
ii  libxrandr2   2:1.5.0-1

gnome-maps recommends no packages.

gnome-maps suggests no packages.

-- no debconf information

Bug#819598: bluetooth: Can't use bluetooth 4 / LE HID devices

[Matthew Gabeler-Lee]

Package: bluetooth
Version: 5.36-1
Severity: normal
Tags: upstream

I'm having the same problem as described in this Ubuntu ticket:

https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1546603

My log entries, for completeness:

Mar 30 20:43:56 hostname bluetoothd[1525]: Error reading PNP_ID value: 
Attribute requires authentication before read/write
Mar 30 20:43:56 hostname bluetoothd[1525]: Unable to register GATT service with 
handle 0x0009 for device C6:E5:C2:98:9B:58
Mar 30 20:43:56 hostname bluetoothd[1525]: Unable to register GATT service with 
handle 0x000e for device C6:E5:C2:98:9B:58
Mar 30 20:43:57 hostname bluetoothd[1525]: Report Map read failed: Attribute 
requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Protocol Mode characteristic read 
failed: Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: HID Information read failed: 
Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Read Report Reference descriptor 
failed: Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Read Report Reference descriptor 
failed: Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Read Report Reference descriptor 
failed: Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Read Report Reference descriptor 
failed: Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Read Report Reference descriptor 
failed: Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Read Report Reference descriptor 
failed: Attribute requires authentication before read/write

I'm using a Microsoft Bluetooth Mouse 3600 for reference.  It is a BT4/LE
device.  It pairs and connects just fine, but no HID events make it through
(at least not through to X) -- no pointer movement, clicks, or scrolls.

Some deep time with Google suggests that this issue affects quite a few
folks (not just Debian, includes keyboards as well as other mice) and _may_
be fixed by this upstream patch:

http://www.spinics.net/lists/linux-bluetooth/msg66469.html
AKA
http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=064f48ad6dd0eb4becb94f5492b6c78218065f19

Which I think is included in the latest upstream release (5.38).  I haven't
had the chance yet to test/verify this.

I see #816815 is also requesting an update to newer upstream to support
newer hardware, though not related to this specific issue.

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

Kernel: Linux 4.4.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 bluetooth depends on:
ii  bluez  5.36-1

bluetooth recommends no packages.

Versions of packages bluetooth suggests:
ii  bluez-cups   5.36-1
ii  bluez-obexd  5.36-1

-- no debconf information

Bug#819597: kernel-image-4.4.0-1-amd64 does not boot

[Jonathan Polak]

Package: linux-image-4.4.0-1-amd64 (4.4.6-1)

I previously made a report referring to issue #815173 -- however, Ben
Hutchings replied saying that I should file a new report.

X230 - does not boot on 4.4.6 -- latest kernel in debian testing. The boot
dies very early on, no logs in syslog / dmesg. However, it generated a
bunch of *efivars dump files* which I include here in the event there is
anything useful.

efivars produced dozens of dump files. I concatenated them all into one
file for each crash. Including attached two crashes.
Oops#1 Part10
<6>[5.944500] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit 
banging on pin 5
<6>[5.961325] iTCO_vendor_support: vendor-support=0
<6>[5.961747] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
<6>[5.961788] iTCO_wdt: Found a Panther Point TCO device (Version=2, 
TCOBASE=0x0460)
<6>[5.961860] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
<6>[5.970694] cfg80211: World regulatory domain updated:
<6>[5.970698] cfg80211:  DFS Master region: unset
<6>[5.970700] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
<6>[5.970702] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 
2000 mBm), (N/A)
<6>[5.970705] cfg80211:   (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 
2000 mBm), (N/A)
<6>[5.970707] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 
2000 mBm), (N/A)
<6>[5.970709] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 
KHz AUTO), (N/A, 2000 mBm), (N/A)
H‰•T[oÚH~ϯ8R_ˆTÌØø†Õ] ÝҒĭ©’BՀ‡2Û3Iþ}ØMwµ< 
ñè|—óÍÌIiÅ×oß¾î?Å|áõk#_ؚa$ùþÌ¿°)¬Þ‚B.^28`£D
éôܗÏ'˜;¯¤5  ÌxÙ=7ë-P
½ãiõfW·ÙßÙü2!ä°}Íêuz•’1¹¨—{‚ÃÐäë܇ãtÚ 
_̦Ëfa¹'#YÁ˜„‘5FTÿÃʤe%l+OV‹l–ŽZnb?:¹IÅ=Þäÿv“Þ|]µ,D-ڀ©Ž¨AÅGLTXŒ†sl°³:nJÅ4™&:ìð¤¯ÐÝN8 ðŖx÷±ü83v®Óo 
¢AT{ÞòêNÒü]Ke^¦øvk8åqÚkØÇZØz趰[cdÒëñUÙ­7½q*fzm ÷{ÑÑô:ƒ¿¼É|èÝÜ@ÇsBÎßÂd
¶º«Ä}ÕæòᚱJìÄ3å­×ÇÈq†á Âe8ž_ŸýŠª±Oops#1 Part11
<6>[5.868268] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1b.0/sound/card0/input15
<6>[5.868322] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1b.0/sound/card0/input16
<6>[5.879536] ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
<6>[5.879731] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input17
<6>[5.879957] [drm] Initialized i915 1.6.0 20151010 for :00:02.0 on 
minor 0
<6>[5.880069] i801_smbus :00:1f.3: SMBus using PCI interrupt
<6>[5.895001] pstore: Registered efi as persistent store backend
<6>[5.896616] AVX version of gcm_enc/dec engaged.
<6>[5.896619] AES CTR mode by8 optimization enabled
<7>[5.896658] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
<4>[5.908079] FAT-fs (sda2): utf8 is not a recommended IO charset for FAT 
filesystems, filesystem will be case sensitive!
<6>[5.915887] fuse init (API version 7.23)
Oops#1 Part1
<4>[6.680783]  [] ? poll_select_copy_remaining+0x150/0x150
<4>[6.680786]  [] ? generic_update_time+0x79/0xd0
<4>[6.680788]  [] ? current_fs_time+0x23/0x30
<4>[6.680790]  [] ? file_update_time+0x5f/0x110
<4>[6.680793]  [] ? pipe_write+0x2af/0x3f0
<4>[6.680795]  [] ? __sys_sendmsg+0x4e/0x90
<4>[6.680798]  [] ? system_call_fast_compare_end+0xc/0x67
<4>[6.680815] Code: e8 ae b8 7c e0 85 c0 78 28 74 2f 48 8b 5b 08 48 85 db 
75 d9 f6 85 90 00 00 00 04 74 39 4d 85 f6 74 34 4c 89 f0 44 84 68 18 74 18 <48> 
8b 5b 10 eb b7 49 89 de 48 8b 5b 10 eb ae 48 89 d8 44 84 68 
<1>[6.680817] RIP  [] nft_rbtree_lookup+0x88/0xf0 
[nft_rbtree]
<4>[6.680818]  RSP 
<4>[6.680818] CR2: 0010
<4>[6.680820] ---[ end trace 733a1aed47d5441a ]---
Oops#1 Part1
<4>[7.012667]  [] ? udp_send_skb+0x99/0x250
<4>[7.012669]  [] ? udp_sendmsg+0x2c1/0x9b0
<4>[7.012672]  [] ? do_set_pte+0xcf/0x100
<4>[7.012674]  [] ? filemap_map_pages+0x229/0x240
<4>[7.012676]  [] ? sock_sendmsg+0x30/0x40
<4>[7.012677]  [] ? SYSC_sendto+0xd3/0x150
<4>[7.012680]  [] ? __do_page_fault+0x1b7/0x430
<4>[7.012682]  [] ? system_call_fast_compare_end+0xc/0x67
<4>[7.012699] Code: e8 ae 88 77 e0 85 c0 78 28 74 2f 48 8b 5b 08 48 85 db 
75 d9 f6 85 90 00 00 00 04 74 39 4d 85 f6 74 34 4c 89 f0 44 84 68 18 74 18 <48> 
8b 5b 10 eb b7 49 89 de 48 8b 5b 10 eb ae 48 89 d8 44 84 68 
<1>[7.012701] RIP  [] nft_rbtree_lookup+0x88/0xf0 
[nft_rbtree]
<4>[7.012702]  RSP 
<4>[7.012702] CR2: 

Bug#819319: apcupsd: BD-Uninstallable on kfreebsd

[Steven Chamberlain]

notfound 819319 apcupsd/3.14.12-1.2
close 819319
thanks

Carsten Leonhardt wrote:
> My understanding is that apcupsd is BD-Uninstallable because of bug
> #810982 net-snmp: FTBFS on kfreebsd10

You were right, as it has built now on kfreebsd.  Thanks, and sorry!

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#819596: dh-golang: fails when golang-go:native is included in Build-Depends

[Stephen Gelman]

Package: dh-golang
Version: 1.12
Severity: important
Tags: patch

Building the git-lfs debian package I have found a bug in dh-golang
1.12.  The build depends line for the package
(https://github.com/github/git-lfs) is:

Build-Depends: debhelper (>= 9), dh-golang, golang-go:native (>= 1.3.0),
git (>= 1.8.2), ruby-ronn

This causes the following error when building the package:

dh_golang -O--buildsystem=golang
Can't call method "get_deps" on an undefined value at /usr/bin/dh_golang
line 114.
debian/rules:18: recipe for target 'binary' failed
make: *** [binary] Error 255
dpkg-buildpackage: error: debian/rules binary gave error exit status 2

When running dh-golang by hand the error is:

-e: warning: can't parse dependency golang-go:native (>= 1.3.0)

The error occurs because dh_golang calls deps_parse in Dpkg::Deps which
fails on the "native" architecture.  This happens because that arch is
only allowed on build-depends lines, not depends.  In the manpage for
Dpkg::Deps, one of the flags listed for deps_parse is:

build_dep (defaults to 0)
If set to 1, allow build-dep only arch qualifiers, that is
“:native”.  This should be set whenever working with build-deps.

Setting this flag on the deps_parse command fixes the issue.  Patch is
attached.


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/16 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 dh-golang depends on:
ii  debhelper 9.20150101
ii  dpkg  1.17.25
ii  libdpkg-perl  1.17.25
ii  perl  5.20.2-3+deb8u1

dh-golang recommends no packages.

dh-golang suggests no packages.

-- no debconf information
diff --git a/script/dh_golang b/script/dh_golang
index fad7998..1eb0922 100755
--- a/script/dh_golang
+++ b/script/dh_golang
@@ -106,7 +106,7 @@ if (defined($build_depends) && $build_depends ne '') {
 die 'Unexpected object (of type ' . blessed($dep) . '), has the Dpkg::Deps API changed?';
 }
 
-my $deps = deps_parse($build_depends, reduce_restrictions => 1);
+my $deps = deps_parse($build_depends, reduce_restrictions => 1, build_dep => 1);
 my $golang_deps = join(' ', grep { /^golang-/ }
 map { flatten($_) }
 $deps->get_deps());

Bug#818582: aptitude cannot deal with often changing IP

[Jaakov]

For an unknown reason, since switching from ftp to http, I have always 
been getting the same IP address. I check the IP before/after aptitude 
operations via


# ip addr show eth0 | grep "inet .* brd" ; aptitude - update ; ip 
addr show eth0 | grep "inet .* brd"


Am I'm doing the IP check in a correct way?

Bug#819595: xscreensaver: please make the build reproducible

[Jamie Zawinski]

But shell wildcards return sorted results. How does this change anything?

Bug#819595: xscreensaver: please make the build reproducible

[Sascha Steinbiss]

Source: xscreensaver
Version: 5.34-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering

Dear Maintainer,

While working on the "reproducible builds" effort [1], we have noticed
that xscreensaver could not be built reproducibly.

The file hacks/Makefile.in uses wildcards to obtain parameters for a script,
leading to unstable input file order and potentially different resulting
binaries.

I have attached a patch to use a fixed, sorted order for these files.
This makes the build reproducible for me in my local test environment.

Regards,
Sascha

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/81_deterministic_file_order.patch b/debian/patches/81_deterministic_file_order.patch
new file mode 100644
index 000..3383986
--- /dev/null
+++ b/debian/patches/81_deterministic_file_order.patch
@@ -0,0 +1,13 @@
+--- a/hacks/Makefile.in
 b/hacks/Makefile.in
+@@ -854,8 +854,8 @@
+ 
+ m6502.h:
+ 	@echo "building m6502.h from $(srcdir)/images/m6502/*.asm"; \
+-	UTILS_SRC="$(UTILS_SRC)" \
+-	$(srcdir)/m6502.sh m6502.h $(srcdir)/images/m6502/*.asm
++	find $(srcdir)/images/m6502/ -name '*.asm' | LC_ALL=C sort | \
++	  UTILS_SRC="$(UTILS_SRC)" xargs $(srcdir)/m6502.sh m6502.h
+ 
+ m6502.o:	m6502.h
+ m6502:		m6502.o		asm6502.o $(HACK_OBJS) $(ATV)
diff --git a/debian/patches/series b/debian/patches/series
index e446a27..7c98703 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -21,3 +21,4 @@
 
 57_grabDesktopImages_default_off.patch
 80_Makefile_in-clean-fix.patch
+81_deterministic_file_order.patch

Bug#433568: [PATCH 1/3] Add vlan support.

[Philipp Kern]

If only I had had a test environment to test my rewrite against, oh
well.

On Wed, Mar 30, 2016 at 05:18:11PM +0100, Dimitri John Ledkov wrote:
> +Template: netcfg/use_vlan
> +Type: boolean
> +Default: false
> +# :sl6:
> +_Description: Are you configuring on an IEEE 802.1Q VLAN trunk port?
> + Virtual LAN (VLAN) is a concept of partitioning a physical network to create
> + distinct broadcast domains. Packets can be marked for different IDs by
> + tagging, so that a single interconnect (trunk) may be used to transport
> + data for various VLANs.
> + .
> + If your network interface is directly attached to a VLAN trunk port,
> + specifying a VLAN ID may be necessary to get a working connection.

s/configuring on/connected to/? It'd be good to also get the template
changes reviewed.

> +Template: netcfg/vlan_id
> +Type: string
> +# :sl6:
> +_Description: VLAN ID (1-4094):
> + VLAN IDs are divided into a normal range and an extended range:
> + .
> + Normal range IDs are 1-1005. 1 is the default native VLAN,
> + and 1002-1005 are reserved for Token Ring and FDDI VLANs.
> + Extended range IDs are 1006-4094, which are designed for service
> + providers and have fewer options.

This description is probably not very useful.

> +Template: netcfg/vlan_cmderror
> +Type: error
> +# :sl6:
> +_Description: Error setting VLAN
> + The command used to set VLAN during installation got an error,
> + please go back and try again.

s/got/returned/ I guess.

> diff --git a/netcfg.c b/netcfg.c
> index 195681b..df0bc04 100644
> --- a/netcfg.c
> +++ b/netcfg.c
> @@ -222,6 +222,11 @@ int main(int argc, char *argv[])
>  else
>  state = GET_METHOD;
>  }
> +
> +if(netcfg_set_vlan(, client) == GO_BACK){
> +state = BACKUP;
> +}
> +
>  break;
>  case GET_HOSTNAME_ONLY:
>  if(netcfg_get_hostname(client, "netcfg/get_hostname", hostname, 
> 0))

Please adjust to the surrounding coding style (either no curly braces or
a space before it). I would also have preferred a GET_VLAN state in the
state machine.

> diff --git a/vlan.c b/vlan.c
> new file mode 100644
> index 000..ec2a19b
> --- /dev/null
> +++ b/vlan.c
> @@ -0,0 +1,67 @@
> +#include 
> +#include 
> +#include 
> +#include "netcfg.h"
> +
> +#define VLAN_SUCESSED 0

SUCESSED?

> +#define VLAN_FAILED 1
> +int netcfg_set_vlan(struct netcfg_interface *interface, struct debconfclient 
> *client){
> +char *vlaniface = NULL, *vlanid = NULL, *vlancmd = NULL;
> +int vlaniface_len, vlancmd_len;
> +
> +/*kfreebsd or hurd has different cmd to set vlan*/

I would've prefered a get_vlan_command(const char* parentif, const char*
vlanif, int vlanid) here. The attached vlan.c (untested) has it.

> +#if defined(__linux__)
> +char vlancmd_template[] = "ip link add link %s name %s type vlan id %s";
> +#elif defined(__FreeBSD_kernel__)
> +/*export 2 more to make it the same formt with Linux*/
> +char vlancmd_tmplate[] = "export NIC=%s; export VNIC=%s; export 
> VLANID=%s;" 
> + " ifconfig $VNIC create";
> +#endif
> +int vlancmd_template_len = sizeof(vlancmd_template);
> +
> +debconf_input(client, "medium", "netcfg/use_vlan");
> +
> +if (debconf_go(client) == CMD_GOBACK)
> +   return GO_BACK;
> +debconf_get(client, "netcfg/use_vlan");
> +
> +if (!strcmp(client->value, "false")){
> +   goto error;
> +}
> +
> +debconf_input(client, "critical", "netcfg/vlan_id");
> +debconf_get(client, "netcfg/vlan_id");
> +vlanid = client -> value;
> +
> +vlaniface_len = strlen(interface->name)+strlen(vlanid)+2;
> +vlaniface = malloc(vlaniface_len);
> +if(! vlaniface){
> +   goto error;
> +}
> +snprintf(vlaniface, vlaniface_len, "%s.%s", interface->name, vlanid);
> +vlancmd_len = vlancmd_template_len + vlaniface_len*2 +1;
> +vlancmd = malloc(vlancmd_len);
> +if(! vlancmd){
> +   goto error;
> +}
> +snprintf(vlancmd, vlancmd_len, vlancmd_template, interface->name, 
> vlaniface, vlanid);
> +if(di_exec_shell_log(vlancmd)){
> +   di_warning("^ Setting VLAN error: the command is \n%s", vlancmd);
> +   debconf_capb(client); 
> +   debconf_input(client, "critical", "netcfg/vlan_cmderror"); 
> +   debconf_go(client); 
> +   debconf_capb(client, "backup"); 
> +   goto error;
> +}
> +if(interface->name){
> + free(interface->name);
> + interface->name = vlaniface;
> +}
> +free(vlancmd);
> +return VLAN_SUCESSED;
> +
> +error:
> +if(vlaniface) free(vlaniface);
> +if(vlancmd) free(vlancmd);
> +return VLAN_FAILED;
> +}

Please convert this down into a consistent coding style. (Or maybe look
at the attached file. It has been a long time ago so maybe I didn't make
much sense of it either.)

> diff --git a/write_interface.c b/write_interface.c
> index 2ab1a34..be0d78b 100644
> --- a/write_interface.c
> +++ 

Bug#810982: [Pkg-net-snmp-devel] Bug#810982: net-snmp: FTBFS on kfreebsd10

[Steven Chamberlain]

found 810982 net-snmp/5.7.3+dfsg-1.2
thanks

Steinar H. Gunderson wrote:
> I made a new upload, and tested that it installs (including upgrades from the
> version in testing).

The debian/control file wasn't actually updated with my patch?

and so it still has this issue:
https://buildd.debian.org/status/fetch.php?pkg=net-snmp=kfreebsd-amd64=5.7.3%2Bdfsg-1.2=1459377666
> make[1]: pkg-config: Command not found
> make[1]: pkg-config: Command not found

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#810982: [Pkg-net-snmp-devel] Bug#810982: net-snmp: FTBFS on kfreebsd10

[Steinar H. Gunderson]

On Thu, Mar 31, 2016 at 12:11:17AM +0100, Steven Chamberlain wrote:
> Don't worry!  Seems we've all made a few mistakes each.  It's a complex
> package and had 100 bugs filed to begin with, now it has only 90.  So
> it's already benefit from all the attention recently, even if it's
> taken a few uploads.

Well, now it's at least on its way up, hopefully fixed this time. :-)

I wish net-snmp upstream would be more responsive; it would reduce this kind
of pain. They have tons of patches in their patch tracker which they simply
do not have the time or energy to look at. The patches in my NMU have all
been pushed upstream, but when you wait two years and then find an almost
identical patch in the patch tracker that's yet two years older, you sort of
lose hope...

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#810982: [Pkg-net-snmp-devel] Bug#810982: net-snmp: FTBFS on kfreebsd10

[Steven Chamberlain]

Steinar H. Gunderson wrote:
> On Wed, Mar 30, 2016 at 11:57:50PM +0100, Steven Chamberlain wrote:
> > The debian/control file wasn't actually updated with my patch?
> 
> Urrrg, double-messup. I hadn't saved the file, it seems. I'm on a bad streak.

Don't worry!  Seems we've all made a few mistakes each.  It's a complex
package and had 100 bugs filed to begin with, now it has only 90.  So
it's already benefit from all the attention recently, even if it's
taken a few uploads.

Thanks!
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#819594: totem: unable to play a file

[gpe92]

Package: totem
Version: 3.18.1-2+b1
Severity: normal

Dear Maintainer,

When I try to play a file with totem there is the following error:
"The file cannot be played over the network. Try downloading it locally
first."
But the file is in a local place ...

BR

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

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

Versions of packages totem depends on:
ii  gnome-icon-theme3.12.0-1
ii  gnome-icon-theme-symbolic   3.12.0-1
ii  grilo-plugins-0.2   0.2.17-1
ii  gsettings-desktop-schemas   3.18.1-1
ii  gstreamer1.0-clutter-3.03.0.18-1
ii  gstreamer1.0-plugins-bad1:1.6.3-dmo2
ii  gstreamer1.0-plugins-base   1.6.3-1
ii  gstreamer1.0-plugins-good   1.6.3-1
ii  gstreamer1.0-x  1.6.3-1
ii  libc6   2.22-4
ii  libcairo2   1.14.6-1
ii  libgdk-pixbuf2.0-0  2.32.3-1.2
ii  libglib2.0-02.48.0-1
ii  libgstreamer-plugins-base1.0-0  1.6.3-1
ii  libgstreamer1.0-0   1.8.0-1
ii  libgtk-3-0  3.18.9-1
ii  libnautilus-extension1a 3.18.5-1
ii  libpango-1.0-0  1.38.1-1
ii  libpangocairo-1.0-0 1.38.1-1
ii  libtotem-plparser18 3.10.6-4
ii  libtotem0   3.18.1-2+b1
ii  libx11-62:1.6.3-1
ii  totem-common3.18.1-2

Versions of packages totem recommends:
ii  gstreamer1.0-libav 1:1.8.0-dmo1
ii  gstreamer1.0-plugins-ugly  1.6.3-1
ii  gstreamer1.0-pulseaudio1.6.3-1
ii  totem-plugins  3.18.1-2+b1

Versions of packages totem suggests:
pn  gnome-codec-install  

-- no debconf information

Bug#810982: [Pkg-net-snmp-devel] Bug#810982: net-snmp: FTBFS on kfreebsd10

[Steinar H. Gunderson]

On Wed, Mar 30, 2016 at 11:57:50PM +0100, Steven Chamberlain wrote:
> The debian/control file wasn't actually updated with my patch?

Urrrg, double-messup. I hadn't saved the file, it seems. I'm on a bad streak.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#819588: openjade: Tries to open /etc/sgml/openjade1.3.cat

[Neil Roeth]

Thanks for the report. Can you provide answers to these questions?

  * Was the openjade1.3 package installed when this error occurred?
  * If removed, did you do a purge as well?
  * Did /etc/sgml/catalog contain both openjade1.3.cat and openjade.cat,
or just openjade1.3.cat?

Thanks.

-- 
Neil Roeth

Bug#819592: Can't complete horde webmail-install script

[Евгений Бахтин]

Package: php-horde-webmail
Version: 5.2.12-2
Severity: grave
Tags: sid

I use only 'sid' repository. I install on 'clean' system.
When I try to complete horde webmail installation with script
'webmail-install' I see this message:

~# webmail-install

Configuring database settings

PHP Fatal error:  Uncaught TypeError: Argument 1 passed to
IMP_Application::exceptionHandler() must be an instance of Exception,
instance of ParseError given in /usr/share/horde/imp/lib/Application.php:610
Stack trace:
#0 [internal function]:
IMP_Application->exceptionHandler(Object(ParseError))
#1 {main}
  thrown in /usr/share/horde/imp/lib/Application.php on line 610

Fatal error: Uncaught TypeError: Argument 1 passed to
IMP_Application::exceptionHandler() must be an instance of Exception,
instance of ParseError given in /usr/share/horde/imp/lib/Application.php:610
Stack trace:
#0 [internal function]:
IMP_Application->exceptionHandler(Object(ParseError))
#1 {main}
  thrown in /usr/share/horde/imp/lib/Application.php on line 610

Broadcast message from systemd-journald@somecpu (Wed 2016-03-30 18:02:45
EDT):

HORDE[11734]: [horde] Uncaught TypeError: Argument 1 passed to
IMP_Application::exceptionHandler() must be an instance of Exception,
instance of ParseError given in /usr/share/horde/imp/lib/Application.php:610
Stack trace:
#0 [internal function]:
IMP_Application->exceptionHandler(Object(ParseError))
#1 {main}
  thrown [pid 11734 on line 610 of
"/usr/share/horde/imp/lib/Application.php"]


Message from syslogd@somecpu at Mar 30 18:02:45 ...
 HORDE: [horde] Uncaught TypeError: Argument 1 passed to
IMP_Application::exceptionHandler() must be an instance of Exception,
instance of ParseError given in
/usr/share/horde/imp/lib/Application.php:610#012Stack trace:#012#0
[internal function]:
IMP_Application->exceptionHandler(Object(ParseError))#012#1 {main}#012
 thrown [pid 11734 on line 610 of
"/usr/share/horde/imp/lib/Application.php"]



Fatal Error:
Uncaught TypeError: Argument 1 passed to
IMP_Application::exceptionHandler() must be an instance of Exception,
instance of ParseError given in /usr/share/horde/imp/lib/Application.php:610
Stack trace:
#0 [internal function]:
IMP_Application->exceptionHandler(Object(ParseError))
#1 {main}
  thrown
In /usr/share/horde/imp/lib/Application.php on line 610

1. Horde_ErrorHandler::catchFatalError()




# it was clean before command 'webmail-install'
~# cat /var/log/messages

Mar 30 18:02:45 vmail HORDE: PHP ERROR: session_regenerate_id(): Cannot
regenerate session id - headers already sent [pid 11734 on line 277 of
"/usr/share/php/Horde/Session.php"]
Mar 30 18:02:45 vmail HORDE: PHP ERROR: Cannot modify header information -
headers already sent by (output started at
/usr/share/php/Horde/Cli.php:184) [pid 11734 on line 717 of
"/usr/share/php/Horde/Core/Auth/Application.php"]
Mar 30 18:02:45 vmail HORDE: [horde] PHP ERROR: Declaration of
Horde_Form_Type_pgp::init($gpg, $temp_dir = NULL, $rows = NULL, $cols =
NULL) should be compatible with Horde_Form_Type_longtext::init($rows = 8,
$cols = 80, $helper = Array) [pid 11734 on line 863 of
"/usr/share/php/Horde/Form/Type.php"]
Mar 30 18:02:45 vmail HORDE: [horde] PHP ERROR: Declaration of
Horde_Form_Type_image::onSubmit(&$var, &$vars) should be compatible with
Horde_Form_Type::onSubmit() [pid 11734 on line 1346 of
"/usr/share/php/Horde/Form/Type.php"]
Mar 30 18:02:45 vmail HORDE: [horde] PHP ERROR: Declaration of
Horde_Form_Type_link::init($values) should be compatible with
Horde_Form_Type::init() [pid 11734 on line 1423 of
"/usr/share/php/Horde/Form/Type.php"]
Mar 30 18:02:45 vmail HORDE: [horde] PHP ERROR: Declaration of
Horde_Form_Type_matrix::init($cols, $rows = Array, $matrix = Array,
$new_input = false) should be compatible with Horde_Form_Type::init() [pid
11734 on line 2150 of "/usr/share/php/Horde/Form/Type.php"]
Mar 30 18:02:45 vmail HORDE: [horde] PHP ERROR: Declaration of
Horde_Form_Type_enum::init($values, $prompt = NULL) should be compatible
with Horde_Form_Type::init() [pid 11734 on line 2320 of
"/usr/share/php/Horde/Form/Type.php"]
Mar 30 18:02:45 vmail HORDE: [horde] PHP ERROR: Declaration of
Horde_Form_Type_mlenum::init(&$values, $prompts = NULL) should be
compatible with Horde_Form_Type::init() [pid 11734 on line 2396 of
"/usr/share/php/Horde/Form/Type.php"]
Mar 30 18:02:45 vmail HORDE: [horde] PHP ERROR: Declaration of
Horde_Form_Type_mlenum::onSubmit(&$var, &$vars) should be compatible with
Horde_Form_Type::onSubmit() [pid 11734 on line 2396 of
"/usr/share/php/Horde/Form/Type.php"]
Mar 30 18:02:45 vmail HORDE: [horde] PHP ERROR: Declaration of
Horde_Form_Type_set::init($values, $checkAll = false) should be compatible
with Horde_Form_Type::init() [pid 11734 on line 2554 of
"/usr/share/php/Horde/Form/Type.php"]
Mar 30 18:02:45 vmail HORDE: [horde] PHP ERROR: Declaration of
Horde_Form_Type_sorter::init($values, $size = 8, $header = '') should be
compatible with Horde_Form_Type::init() [pid 

Bug#819593: ITP: golang-github-hydrogen18-stoppablelistener -- stoppable TCP listener in Go

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 782441 by -1

   Package name: golang-github-hydrogen18-stoppablelistener
Version: 0.0~git20151210
Upstream Author: Eric Urban
License: BSD-2-Clause
URL: https://github.com/hydrogen18/stoppableListener
Description: stoppable TCP listener in Go
 This library wraps an existing TCP connection object. A goroutine calling
 Accept() is interrupted with StoppedError whenever the listener is stopped
 by a call to Stop().


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

Bug#819591: ITP: golang-github-peterbourgon-diskv -- disk-backed key-value store

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 782441 by -1

   Package name: golang-github-peterbourgon-diskv
Version: 2.0.0
Upstream Author: Peter Bourgon
License: Expat
URL: https://github.com/peterbourgon/diskv
Description: disk-backed key-value store
 Diskv (disk-vee) is a simple, persistent key-value store written in the Go
 language. It starts with an incredibly simple API for storing arbitrary
 data on a filesystem by key, and builds several layers of
 performance-enhancing abstraction on top. The end result is a conceptually
 simple, but highly performant, disk-backed storage system.


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

Bug#819585: local-apt-repository: add a "suite" name to local-apt-repository.list

[Joachim Breitner]

Dear Marintxo,

thanks for the suggestion! Maybe the Release file can have a suite
entry. Or alternatively, the local-apt-repository documentation can
give instructions on how to use apt-pinning to prefer packages from the
local repository? Or maybe even do that by default?

I don’t think I’ll do a deep investigation into the possibilities soon,
but I’m happy to review and merge tested patches!

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
Debian Developer
  nome...@debian.org • https://people.debian.org/~nomeata
  XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
  https://www.joachim-breitner.de/


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

Bug#819534: libreoffice: LibreOffice fails to start

[Rene Engelhard]

Hi,

On Wed, Mar 30, 2016 at 10:28:20PM +0300, Станислав Фёдоров wrote:
> > GDB trace is attached.
> >> Which doesn't say anything.
> 
> I've attached the trace, just because I had to.

How? Yes, it's helpful, if it actually shows something.. (Which this one 
doesn't.
At all.)

> > Why on earth do people think mixing stable and testing ever is a good idea?
> > There's uptodate versions in jessie-backports for that.
> 
> Just to help others who wiil use future stable brach.

That would be by testing testing (which gets as-full released as stable, not a 
mix)
- not testing a mix of stable and testing.

> I've attached the system trace.

Which doesn't print the message from your initial report...

Regards,

Rene

Bug#819590: RFP: python3-slixmpp -- XMPP library for Python 3 using asyncio

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

Package name: python3-slixmpp
Version : 1.1
Upstream Author : Florent Le Coz 
URL : https://dev.louiz.org/projects/slixmpp
License : MIT
Programming Lang: Python
Description : XMPP library for Python 3 using asyncio

slixmpp is a friendly fork of SleekXMPP, but uses asyncio
instead of threads to handle networking.

Bug#776368: debian-maintainers: Annual ping for Denis Briand

[Denis Briand]

I'm alive :)

Denis Briand


signature.asc
Description: Digital signature

Bug#819589: RFP: python3-aioxmpp -- pure-python XMPP library using the asyncio standard library module

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

Package name: python3-aioxmpp
Version : v0.5.3
Upstream Author : Jonas Wielicki 
URL : https://github.com/horazont/aioxmpp
License : GPL3
Programming Lang: Python
Description : pure Python XMPP library for asyncio

This Python library tries to fulfil the following goals:
 - Powerful API to implement all sorts of XEPs
 - Reliable message transmission even under dire network circumstances
 - Well-tested code base

Bug#819588: openjade: Tries to open /etc/sgml/openjade1.3.cat

[Hilmar Preuße]

Package: openjade
Version: 1.4devel1-21.1
Severity: minor

Dear Maintainer,

   * What led up to the situation?

hille@sid:~ $ touch a
hille@sid:~ $ openjade -t tex -o a.tex a
openjade:/etc/sgml/catalog:10:8:E: cannot open "/etc/sgml/openjade1.3.cat" (No 
such file or directory)
openjade:E: cannot find "a.dsl"; tried "a.dsl", "/usr/local/share/sgml/a.dsl", 
"/usr/share/sgml/a.dsl"
openjade:E: specification document does not have the DSSSL architecture as a 
base architecture
openjade:/etc/sgml/catalog:10:8:E: cannot open "/etc/sgml/openjade1.3.cat" (No 
such file or directory)
openjade:/etc/sgml/catalog:10:8:E: cannot open "/etc/sgml/openjade1.3.cat" (No 
such file or directory)
openjade:a:1:0:E: end of document in prolog

Of course a is not an SGML file.  My point is that openjade tries to open a
file, it does not provide by itself.  As openjade1.3 will be removed
openjade must open /etc/sgml/openjade.cat.


Thanks,
  Hilmar
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages openjade depends on:
ii  libc6 2.22-5
ii  libgcc1   1:5.3.1-13
ii  libosp5   1.5.2-13
ii  libostyle1c2  1.4devel1-21.1
ii  libstdc++65.3.1-13
ii  sgml-base 1.26+nmu4

openjade recommends no packages.

Versions of packages openjade suggests:
ii  doc-base   0.10.7
ii  sgml-data  2.0.10

-- no debconf information

Bug#790694: PPC64: 64kb kernel pagesizes and nouveau

[Aurelien Jarno]

On 2016-03-30 16:45, Ben Hutchings wrote:
> On Wed, 2016-03-30 at 16:49 +0200, Mathieu Malaterre wrote:
> > Ben,
> > 
> > > 
> > > I saw that bug report as well.  I'm not sure what to do about it -
> > > other distributions were also using 64K pages for 64-bit PowerPC the
> > > last time I looked, and there may be good reasons to do that.
> > Would it be possible for you to dig that for us ? It appears that
> > making nouveau work with 64K page is non-trivial:
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=94757#c3
> > 
> > Which in turns means most of the userbase with PPC64 (G5 PowerMac)
> > wont be able to use X.
> 
> I am not a powerpc porter; Aurelien Jarno is the kernel maintainer
> responsible for it.

That's correct for ppc64el, but I never signed up for the powerpc port.

> I don't know about the user base, but I think most of the *development*
> effort and sponsorship of the powerpc ports now comes from IBM, and
> unfortunately they don't care about PowerMacs.

IBM doesn't really care about the powerpc port either, they do about the
ppc64el port. That said I have tracked the change to 64kB pages to the
following commit:

| commit aed63a56b189d771116f2d4b8fe10bbec528e6a2
| Author: Bastian Blank 
| Date:   Sat Aug 9 19:42:11 2014 +
|
| * debian/changelog: Update
| * debian/config/kernelarch-powerpc/config-arch-64: Set PPC_64K_PAGES.
| * debian/config/kernelarch-powerpc/config-arch-64-le: Remove overriden 
option.
|
| svn path=/dists/trunk/linux/; revision=21721

I don't really know what it has been done, so I have Cced Bastian so
that he can comment on that. It's something that can be reverted if
needed I guess.

Aurelien

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


signature.asc
Description: PGP signature

Bug#819089: FTBFS: autoreconf fails in libkmod/docs/gtk-doc.make

[Dmitry Shachnev]

Hi,

On Wed, Mar 23, 2016 at 04:41:12PM +0100, Helmut Grohne wrote:
> The attached patch fixes the build. What I cannot tell is whether
> gtk-doc is really at fault and how many other packages this affects.

[We have discussed this on IRC, but copying here for the record.]

According to gtk-doc upstream, it is not their bug:
https://bugzilla.gnome.org/show_bug.cgi?id=753348#c6

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#776728: newsbeuter: nasty memory leak in 2.8

[Manuel A. Fernandez Montecelo]

Control: reopen -1
Control: found -1 newsbeuter/2.9-2


Hi Nikos,

2016-01-03 11:30 GMT+00:00 Manuel A. Fernandez Montecelo
:
> It would be very nice to get this fixed, it's getting up to 800+MB of
> mem within hours, it seems to stabilise a bit after that.
>
> Version 2.9 was released a few weeks after this last message as
> promised, and fixes the problem, so it would be extra nice to have the
> new version!

It seems that 2.9 still uses a lot of memory (at least in my
use-case), 800MB right now after being restarted a few hours ago.

So re-opening this bug.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#819587: vite: Please consider packaging a fresh svn version

[Martin Quinson]

Package: vite
Version: 1.2+svn1430-5
Severity: wishlist

The r1430 is already almost 2 years old, and we start advising to our users to
not go for the debian package but for the svn version. This is somehow
suboptimal, and I'd be thankful if you could update the package at some point.

Btw, I'm glad you took it over, that's a very good news.

Thanks for that,
Mt


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

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

Versions of packages vite depends on:
ii  libc6 2.21-8
ii  libgcc1   1:5.3.1-8
ii  libgl1-mesa-glx [libgl1]  11.1.2-1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libopen-trace-format1 1.12.5+dfsg-1+b1
ii  libotfaux01.12.5+dfsg-1+b1
ii  libqt5core5a  5.5.1+dfsg-13
ii  libqt5gui55.5.1+dfsg-13
ii  libqt5opengl5 5.5.1+dfsg-16
ii  libqt5widgets55.5.1+dfsg-13
ii  libqt5xml55.5.1+dfsg-16
ii  libstdc++65.3.1-8

vite recommends no packages.

vite suggests no packages.

-- no debconf information

-- 
The tragedy of modern man is not that he knows less and less about the
meaning of his own life, but that it bothers him less and less.
  --- Vaclav Havel


signature.asc
Description: PGP signature

Bug#818876: Issue work around done

[Harald Hope]

I've revised the logic slightly, and the fix for this specific user's issue is now in 2.2.37. When 
or if unit193 packages that, and when or if that package gets into the appropriate debian pool, will 
determine when the debian issue itself is resolved.


This may well create fresh new issues, but that's a matter for other days.

And that's enough time on this matter.

Bug#819493: debian-security-support: FTBFS on jessie: attemps to install nonexistent security-support-ended.deb8+deb8u3 file

[Santiago Ruano Rincón]

El 30/03/16 a las 18:45, Santiago Vila escribió:
> On Wed, Mar 30, 2016 at 04:39:17PM +0200, Santiago Ruano Rincón wrote:
...
> I'm not familiar enough with this package to tell, but if that does
> what you want, yes, I suppose it would be better.
> 
> Beware, however, that in a future there might be a file named
> security-support-ended.deb10 and the sort could not work as expected.
> 
> If the release is for jessie, I would try to keep it simple:
> 
> DEBIAN_VERSION = 8
> 
> Isn't this why we have branches in git repositories?
> 
> Thanks.

I wonder if a more suitable approach, and close #762594 along, would be
to include all security-support-ended* lists files in the binary
package, and make check-support-status to evaluate the debian_version
where it runs.

Cheers,

Santiago


signature.asc
Description: PGP signature

Bug#818863: support generating rails database.yml

[Paul Gevers]

Control: tags -1 moreinfo

Hi Pirate,

On 21-03-16 05:33, Pirate Praveen wrote:
> details of this format is here
> http://rubyinrails.com/2014/01/09/database-yml-rails/
> 
> I want to use it for diaspora-common and gitlab.

Can you elaborate a bit more of what you want dbconfig-common to do for
you? Generating these files should already be trivial with the template
format of dbconfig-generate-include¹ (which is called by
dbconfig-common). See also section 3.2.1 of the develguide².

But maybe you mean something else.

Paul

¹
http://manpages.debian.org/cgi-bin/man.cgi?=dbconfig-generate-include
²
file:usr/share/doc/dbconfig-common/dbconfig-common.html/ch-develguide.html



signature.asc
Description: OpenPGP digital signature

Bug#810982: [Pkg-net-snmp-devel] Bug#810982: net-snmp: FTBFS on kfreebsd10

[Steinar H. Gunderson]

On Wed, Mar 30, 2016 at 01:37:58PM +0200, Steinar H. Gunderson wrote:
> I'll have a look at it tonight and see what I can do. Thanks for alerting me
> of it.

I made a new upload, and tested that it installs (including upgrades from the
version in testing).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#816710: lxc-debian is broken with -r squeeze

[William Alexandre Miura Gnann]

It would suffice to remove squeeze from lxc-debian's distros list.

On Sat, Mar 26, 2016 at 12:20:08PM -0300, Antonio Terceiro wrote:
> Control: tag -1 + wontfix
> 
> On Sat, Mar 26, 2016 at 09:55:12AM +0100, Evgeni Golov wrote:
> > control: found -1 lxc/1:1.1.5-1
> > 
> > Hi,
> > 
> > On Fri, Mar 04, 2016 at 01:44:17PM -0300, Will Gnann wrote:
> > 
> > >lxc-create -t debian -n anyname -- -r squeeze
> > > 
> > >Since squeeze support has ended, debian repositories do not have 
> > > squeeze packages, therefore debootstrap with http.debian.net repository 
> > > fails.
> > > 
> > >In lxc-debian, the repository http.debian.net is the default 
> > > repository. So change default repository to archive.debian.org when using 
> > > squeeze as parameter will fix it.
> > 
> > I must admit I am tempted to close this as wontfix.
> > You can pass --mirror=http://archive.debian.org/debian/ to the Debian 
> > template if you really want to create a Squeeze container.
> > But as you already said, Squeeze is EOL now and I do not think we should 
> > add complexity to the code for supporting EOLed releases.
> 
> I agree.
> 
> -- 
> Antonio Terceiro 



-- 
William Gnann - SI
Analista de Sistemas

Bug#819586: debian-installer-netboot-images: unhelpful handling of GPG errors

[Adam D. Barratt]

Source: debian-installer-netboot-images
Version: 20120712
Severity: serious
Justification: silently ignores failures, creating broken packages

Hi,

Whilst preparing the dini uploads for the upcoming point releases, on
debdiffing the binary packages against the previous versions I noticed
that one of them seemed to have lost all of its files and had an
Installed-Size of 32.

Checking the build log, I found that this was due to one of the Release
file checks failing with:

gpgv: BAD signature from "Debian Archive Automatic Signing Key
(7.0/wheezy) "

(This appears to have been an issue with a particular mirror, fwiw.)

The checks in get-images.sh do:

if gpgv --keyring /usr/share/keyrings/debian-archive-keyring.gpg 
$RELEASE_FILE.gpg $RELEASE_FILE ; then
get_di_built_using $1
get_installer $1
fi

Whilst a failure to verify the Release signature does mean that we don't
attempt to build an image using untrusted inputs, the package build
continues with no sign of a problem having occurred until the binary
packages are examined.

Regards,

Adam

Bug#819585: local-apt-repository: add a "suite" name to local-apt-repository.list

[martintxo]

Package: local-apt-repository
Version: 0.3
Severity: wishlist

Dear Maintainer,

Well, local-apt-repository works so good for me :-D But maybe we can do it
better. An example:

I'm in testing.

I need to use a old version of amule, because the one in testing have so many
bugs... So I download the following packages from snapshot.debian.org with a
web browser: amule, amule-common, amule-daemon, amule-utils, amule-utils-gui. I
move all packages to /srv/local-apt-repository/ and...

For install this packages that are oldest versions that I have in my testing
box, I need to specify the suite or the version. But in /etc/apt/sources.list.d
/local-apt-repository.list I can't see a suite name... Is only:
  deb [trusted=yes] file:///var/lib/local-apt-repository/ ./

So I install all my packages appending it version number to _all_ the package
names. Maybe there is a better mode, but I don't know...

Maybe if you can put a fake suite name, as "local-apt-repository" we can
install our packages with it.

I don't know if it is possible. If not, close this report.

Many thanks for all. Greetings. Martintxo.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=eu_ES.UTF-8, LC_CTYPE=eu_ES.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to eu_ES.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages local-apt-repository depends on:
ii  dpkg-dev 1.18.4
ii  init-system-helpers  1.29
ii  systemd  229-3

local-apt-repository recommends no packages.

local-apt-repository suggests no packages.

-- no debconf information

Bug#819580: ITP: ruby-syslog-logger -- improved Logger replacement that logs to syslog

[Jonathan Carter]

Noted, thanks.

-Jonathan

On 30/03/2016 20:50, Lucas Kanashiro wrote:

Package: wnpp
Severity: wishlist
Owner: Lucas Kanashiro 

* Package name: ruby-syslog-logger
   Version : 1.6.8
   Upstream Author : Eric Hodel, Chris Powell, Matthew Boeh, Ian Lesperance, 
Dana Danger, Brian Smith, Ashley Martens
* URL : http://github.com/ngmoco/syslog_logger
* License : Expat
   Programming Lang: Ruby
   Description : improved Logger replacement that logs to syslog

Logger::Syslog is a Logger replacement that logs to syslog. It is almost
drop-in with a few caveats. Add Logger::Syslog to your Rails production
environment to aggregate logs between multiple machines.

This particular Logger::Syslog improves the original by correctly
mapping Rails log severities to the Syslog counterparts. It also adds
the ability to select a syslog facility other than "user".


I intend to maintain this package under the umbrella of Debian Ruby team. This
package is a new dependency of new chef's release.

Bug#819584: eog fails to display JPG's

[Mikko Rapeli]

Package: eog
Version: 3.18.2-1
Severity: normal

Dear Maintainer,

With JPG's from my Sony camera eog only displays a gray screen. Metadata
from the files is displayed correctly. Firefox, GIMP etc display these
files correctly on screen.

Example JPG file: https://mcfrisk.kapsi.fi/temp/DSC06824.JPG

Screenshot from eog: 
https://mcfrisk.kapsi.fi/temp/eog_screenshot_DSC06754_displayed_as_gray_only.png

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Foreign Architectures: armhf

Kernel: Linux 4.3.3 (SMP w/2 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 eog depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gir1.2-gtk-3.0   3.18.9-1
ii  gir1.2-peas-1.0  1.16.0-1+b1
ii  gsettings-desktop-schemas3.18.1-1
ii  libatk1.0-0  2.18.0-1
ii  libc62.22-4
ii  libcairo-gobject21.14.6-1
ii  libcairo21.14.6-1
ii  libexempi3   2.3.0-2
ii  libexif120.6.21-2
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libgirepository-1.0-11.46.0-4
ii  libglib2.0-0 2.48.0-1
ii  libgnome-desktop-3-123.18.2-1
ii  libgtk-3-0   3.18.9-1
ii  libjpeg62-turbo  1:1.4.2-2
ii  liblcms2-2   2.6-3+b3
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpeas-1.0-01.16.0-1+b1
ii  librsvg2-2   2.40.13-3
ii  libx11-6 2:1.6.3-1
ii  shared-mime-info 1.5-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages eog recommends:
ii  librsvg2-common  2.40.13-3
ii  yelp 3.16.1-1

eog suggests no packages.

-- no debconf information

Bug#819583: ITP: ruby-proxifier -- add support for HTTP or SOCKS proxies and allow one to force TCPSocket to use proxies

[Lucas Kanashiro]

Package: wnpp
Severity: wishlist
Owner: Lucas Kanashiro 

* Package name: ruby-proxifier
  Version : 1.0.3
  Upstream Author : Samuel Kadolph 
* URL : https://github.com/samuelkadolph/ruby-proxifier
* License : Expat
  Programming Lang: Ruby
  Description : add support for HTTP or SOCKS proxies and allow one to 
force TCPSocket to use proxies

Proxifier enable ruby programmers to use HTTP or SOCKS proxies
interchangeably when using TCPSockets. Either manually with
`Proxifier::Proxy#open` or by `require "proxifier/env"`.

   
Allows one to use ruby code that doesn't user proxies for users that
have to use proxies. The pruby and pirb executables are simple wrappers
for  their respective ruby executables that support proxies from
environment variables.


I intend to maintain this package under the umbrella of Debian Ruby team. This
package is a new dependency of new chef's release.

Bug#815618: ovmf: Please someone create a DFSG-free ovmf variant

[Francesco Poli]

On Wed, 30 Mar 2016 17:19:04 +0800 Paul Wise wrote:

> Control: tags -1 + fixed-upstream

Hurray!   :-)

> 
> On Fri, 26 Feb 2016 09:07:03 +0800 Paul Wise wrote:
> 
> > He has replied to me today to say that they are aware of the issue and
> > are working with Microsoft to rectify the issue soon. We'll see :)
> 
> Their work has paid off and there is a new FatPkg under the 2-clause
> BSD license, thanks to Microsoft agreeing to the change:
> 
> http://thread.gmane.org/gmane.comp.bios.edk2.devel/9930/focus=9956
> https://twitter.com/tianocore/status/715016134982930432?s=09

If I understand correctly, this means that a new upstream version of
ovmf will soonish be released without any non-free restrictions. And
that this new version will be packaged for inclusion in Debian main.

If this is confirmed, then, wow!, it is a great outcome.
Thanks a lot to anyone who helped, and, thank you Microsoft [*].

[*] it feels a bit awkward to say this, but... credit where credit is
due...

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


pgppjDiAVGqdi.pgp
Description: PGP signature

Bug#819576: linux-image-4.4.0-0.bpo.1-amd64: Brightness slowdown - Changing brightness takes some seconds and causes system slowdown

[Ben Hutchings]

Control: tag -1 moreinfo

On Wed, 2016-03-30 at 14:14 -0300, Leonardo Santana Vieira wrote:
> Package: src:linux
> Version: 4.4.6-1~bpo8+1
> Severity: important
> 
> Dear Maintainer,
> 
> After kernel upgrade, changing brightness takes some seconds and causes system
> slowdown if i try to change more than one level at a time. This problem does
> not happen in the other kernel packages i have installed(3.16, 4.3). I'm using
> Gnome desktop, the problem happens when i try the change through the menu at
> the top bar and especially if i try using fn keys to do it. If a hold fn+f5 or
> f6 all the way to minimum or maximum, the action causes severe slowdown in the
> system making it unusable for some time. I have theses modules installed in 
> all
> the kernel packages as can be seen below the result of "dkms status" command.
>
> bbswitch, 0.8, 3.16.0-4-amd64, x86_64: installed
> bbswitch, 0.8, 4.3.0-0.bpo.1-amd64, x86_64: installed
> bbswitch, 0.8, 4.4.0-0.bpo.1-amd64, x86_64: installed
> nvidia-current, 352.79, 3.16.0-4-amd64, x86_64: installed
> nvidia-current, 352.79, 4.3.0-0.bpo.1-amd64, x86_64: installed
> nvidia-current, 352.79, 4.4.0-0.bpo.1-amd64, x86_64: installed
> virtualbox, 5.0.16, 3.16.0-4-amd64, x86_64: installed
> virtualbox, 5.0.16, 4.3.0-0.bpo.1-amd64, x86_64: installed
> virtualbox, 5.0.16, 4.4.0-0.bpo.1-amd64, x86_64: installed
[...]

Please test without these modules installed.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

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

Bug#819550: linux-image-4.4.0-0.bpo.1-rt-amd64: boot stall while trying 4.4 rt amd64 kernel

[Ben Hutchings]

Control: severity -1 important
Control: tag -1 moreinfo

On Wed, 2016-03-30 at 12:49 +0200, gregory bahde wrote:
> Package: linux-image-4.4.0-0.bpo.1-rt-amd64
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>    * What led up to the situation?
> installing rt 4.4
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
>    * What was the outcome of this action?
>    * What outcome did you expect instead?
> locked at startup
[...]

You need to provide a boot log, and the version of the package you
installed (not just the name).

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

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

Bug#819505: gtk3-nocsd: dont works in apps launched from mate menu

[Martintxo]

Hello. Many thanks for the fast response... Now all is OK. See below...

2016/03/29 22:30 (ar.) eguna,
Christian Seiler (e)k idatzi zuen:
> 
> What happens if you try to start gedit via the menu?  

Ok. I install gedit. Then close the session and re-login. If I start gedit from
the menu, it appears without the mate titlebar. If I start it from
mate-terminal it appears with the correct mate titlebar :-/

I can confirm, also, that gedit is working as expected (with the wm title bar)
in Xfce and Lxde... but not in (my) Mate...

> Could you give me the following output?
> dpkg -l gnome-disk-utility gtk3-nocsd libgtk3-nocsd0
> mate-desktop-environment  

martintxo@debian:~$ dpkg -l gnome-disk-utility gtk3-nocsd libgtk3-nocsd0
mate-desktop-environment 
Nahia=Unknown/Install/Remove/Purge/Hold
| Egoera=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(bat ere ez)/Hold/Reinst-required/X=both-problems
(Status,Err:uppercase=bad)
||/ Izena  Bertsioa   ArkitekturaAzalpena
+++-==-==-==-==
ii  gnome-disk-utility 3.18.3.1-1 i386   manage and configure disk
ii  gtk3-nocsd 2-1allDisable Gtk+ 3 client side
ii  libgtk3-nocsd0:i38 2-1  i386   Library to disable Gtk+ 3 client
ii mate-desktop-envir 1.12.0+1   all MATE Desktop Environment
 
> Also, did you attempt to configure gtk3-nocsd yourself to any
> extent? If so, how? Or did you _just_ install the package? Did you
> re-login after installing gtk3-nocsd?  

No, I dont configure nothing, just install the packages and read the docs... I
restart the pc an try diferent DE in some days...

...

Well, I now updating all the packages (apt-get update, apt-get upgrade, apt-get
dist-upgrade). I had the system without update from 2 weeks or so. In the
process I see that mate-settings-daemon have be updated...

At the end I restart the pc, start gedit... and... Bingo !!!. Now gtk3-nocsd is
working fine. Maybe it was the previous version of mate-settings-daemon ??.

In the apt/term.log, I can see:

.../mate-settings-daemon_1.12.1-2_i386.deb deskonprimitzeko prestatzen...
mate-settings-daemon (1.12.1-2) deskonprimitzen (1.12.1-1) gainean...
.../mate-settings-daemon-common_1.12.1-2_all.deb deskonprimitzeko prestatzen...
mate-settings-daemon-common (1.12.1-2) deskonprimitzen (1.12.1-1) gainean...

So, the change in mate-settings-daemon is from 1.12.1-1 to 1.12.1-2... In the
changelog:
http://metadata.ftp-master.debian.org/changelogs/main/m/mate-settings-daemon/mate-settings-daemon_1.12.1-2_changelog
I can see that there are some patch for the xcursor... Maybe that is :-D

You can close this report for me. Many thanks for all, and excuse this "false"
report. Greetings. Martintxo.


Sustrai Erakuntza: respuesta jurídico-técnica a proyectos insostenibles.
  proiektu jasangaitzei erantzun juridiko-teknikoa.
  http://www.fundacionsustrai.org
  http://www.sustraierakuntza.org

Bug#790690: Powermac G5 7,2 Nvidia GeForce 6800 GT graphics issues

[Ben Hutchings]

On Wed, 2016-03-30 at 16:51 +0200, Mathieu Malaterre wrote:
> Control: found -1 3.16.0-4
[...]

That is not a version number we've ever used.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.


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

Bug#819582: dput-ng: dcut manpage incorect, cancel --filename should be cancel --file

[Colin Tuckley]

Package: dput-ng
Version: 1.10
Severity: minor

The man page for dcut says that the only valid option for the 'cancel' command 
is:

-f, --filename=FILENAME

this is incorrect the option is actually:

-f, --file=FILENAME


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

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

Versions of packages dput-ng depends on:
ii  python-dput  1.10
pn  python:any   

Versions of packages dput-ng recommends:
ii  bash-completion  1:2.1-4.2

dput-ng suggests no packages.

-- no debconf information

Bug#819004: gsoap: please package version 2.8.29

[Carsten Schoenert]

Hello,

On Tue, Mar 22, 2016 at 07:54:33PM +0100, Carsten Schoenert wrote:
> Source: gsoap
> Version: 2.8.28
> Severity: wishlist
> 
> Hello,
> 
> there is a new upstream version 2.8.29 available, please consider to
> package this version.

I was getting some information that a issue that is around since 2.8.24
in gsoap while building the Zarafa Communication Platform will be fixed
in the next release 2.8.30.
So please keep this report open until 2.8.30 will be packaged.

>From a other email communication ...

> The upcoming 2.8.30 update will fix the problem by checking
> structs/classes union members for nested members and does not add
> constructors in those cases:
> 
> Saving soapStub.h annotated copy of the source interface file
> Saving soapH.h serialization functions to #include in projects
>
> test236.h(15): *WARNING*: struct 'xsd__base64Binary' cannot be assigned
> a default constructor because it is directly or indirectly used as a member 
> of union '_act'
>
>
> test236.h(15): *WARNING*: struct '_moveCopy' cannot be assigned a default 
> constructor because it is directly or indirectly used as a member of union 
> '_act'
>
> This compiles cleanly.
>
> - Robert

The ZCP has a ITP visible on
  http://bugs.debian.org/658433

Thanks
Carsten

Bug#818876: checked, not likely

[Harald Hope]

I took a closer look, and reviewed enough user data sets to refresh my memory about reality re 
distro id methods.


Here's the deal: inxi deals with the world as it actually exists, not as pedantic rules would like 
the world to be. The empirical reality of how absurdly inconsistent and filthy the system data inxi 
has to process is is something I've grown painfully aware of ever since starting inxi. Any notion 
that bsds or gnu/linuxes follow consistent methods and rules is a total fantasy, and inxi lives 
outside of that fantasy, in the real world. I strive for very high accuracy, not very  high 
following rules.


The biggest GNU/Linux distribution in the world only shows its correct id in /etc/issue. This was, 
incidentally, the second distribution to package inxi. We all dislike that distribution intensely, 
for a host of excellent reasons, or should, but the fact is, it's the biggest one out there for user 
desktops. It's not ubuntu.


It includes debian_version and os-release, both point to different distributions, and both are wrong 
in terms of correctly id'ing that distribution.


It does not have a unique way of identifying it prior to the id process 
starting.

So we have Adam, one single person, versus possibly 100s of thousands of users.

I'm going to look at the problem for a bit more, but as it stands, the reasons for making inxi use 
the detection methods it uses were based on empirical reality and facts, and those are always what 
determines actions I take for improving it.


So I'm obviously not changing a thing in this case until I find a way that does not negatively 
impact potentially hundreds of thousands of users just to make Adam happy.


Since the literal issue is correctly handled, so to speak, by simply not showing the distro id when 
data corruption is detected, I believe the single place I can inject a fix is IF data shows as 
corrupted, and only if, I can then switch in to a repeat of the os-release test, and grab the data 
from the os-release file, if it exists, but if and only if the data was corrupted. I can also 
improve the data corruption test to check for unexpected characters that point towards corruption 
having occurred, using adam's debugger data sample as a guide.


That's as close as I can come to the desired outcome of making adam happy but not messing up 
everyone else's output in the process, by making its distro id wrong.


so that's what I'll do. And it will also make inxi slightly better overall, 
which is always nice.

That will be in the next inxi update, which should be 2.2.37 I think.

Bug#433568: add vlan support

[Ben Hutchings]

On Wed, 2016-03-30 at 10:26 -0400, Lennart Sorensen wrote:
> On Wed, Mar 30, 2016 at 03:11:03PM +0100, Dimitri John Ledkov wrote:
> > 
> > Hi,
> > 
> > On Sat, 12 Mar 2016 13:49:57 +0100 Tom H  wrote:
> > > 
> > > You don't need vlan; iproute2's ip can do it:
> > > 
> > > ip link add link eth0 name vlan9 type vlan id 9
> > > or
> > > ip link add link eth0 name eth0.9 type vlan id 9
> > > 
> > > 
> > I know that. vlan package is needed for the ifupdown hooks to parse
> > vlan stanza from /etc/network/interfaces and hence configure vlan id.
> > Or am I missing something?
> Currently the vlan package provides such hooks.  No reason one could
> not add such hooks to the iproute2 package or even extend ifupdown to
> handle it itself.  Using the vlan package is certainly not efficient
> compared to using the ip command for the job.  This is also true for
> bridge-utils as far as I know, where I think iproute2 can also completely
> replace that.

I agree with this.  Debian-installer should not create a network
configuration that depends on tools that have been deprecated for over
a decade.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

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

Bug#819555: pcscd: cyberJack pp_a2 init failed with pcscd_1.8.16-1

[veco41]

  
  
.
> 
> This is a problem in the REINER SCT driver.
> 
> If this driver comes from the libifd-cyberjack6 Debian package
[1] as it looks like then the bug should be reassigned to this
package.
> Just tell me and I will do the reassignement.
> 
> Bye
> 
> [1] https://packages.debian.org/sid/libifd-cyberjack6
> 
> -- 
> Dr. Ludovic Rousseau

yes please - I you think the driver is responsible for the problem
> ii  libifd-cyberjack6 3.99.5final.sp09-1

  

Bug#819581: battery-stats: does not detect missing battery, collect-csv fails

[William Altaffer]

Package: battery-stats
Version: 0.5.1-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

email every 10 minutes after installing battery-stats , with the following
content:

  /usr/share/battery-stats/collect-csv: line 86: cd: BAT*: No such file or
  +directory


Laptop does not have battery installed.  If battery is not present, then the
directory:

  /sys/class/power_supply/BAT*

will not be present.  Script does not check for that condition.

Note, if the battery is installed, then  /sys/class/power_supply/BAT*  is
present and no errors (or emails) generated.




-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
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 battery-stats depends on:
ii  gzip   1.6-5
ii  logrotate  3.8.7-2

Versions of packages battery-stats recommends:
ii  gnuplot  4.6.6-3
ii  python   2.7.11-1

battery-stats suggests no packages.

-- no debconf information

Bug#819474: ldap-account-manager: Fragile postinst script

[Roland Gruber]

Hi Oliver,

On 29.03.2016 11:22, Oliver Elphick wrote:
> Postinst script failure, because apache2 service not running, then leads to
> failure on subsequent occasions because a symbolic link created by the script
> now exists.  The script needs better handling of possible error conditions.

thanks for your feedback. This will be fixed in the 5.4 release.


-- 

Best regards

Roland



signature.asc
Description: OpenPGP digital signature

Bug#798492: ITA: pcsxr -- Sony PlayStation emulator

[James Cowgill]

Control: retitle -1 ITA: pcsxr -- Sony PlayStation emulator
Control: owner -1 !

Hi,

I can take a look at this package. It'll probably be maintained within
the Games team again.

James

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

Bug#819485: routino: At airports routino often can not find the route.

[Andrew M. Bishop]

>> Package: routino
>> Version: 3.1.1-2
>> Severity: normal
>> 
>> At airports routino often can not find the route. Reproduce:
>> 
>> 1. Open http://www.routino.org/uk-leaflet/router.html
>> 2. Set point "1": -0.44628 E / 51.45842 N
>> 3. Set point "2": any. For example: -0.43684 E / 51.45502 N
>> 4. Click "Shortest Route"
>> 5. Get:

>> Loaded Files: nodes, segments, ways & relations
>> Found Closest Point: Waypoint 1
>> Waypoint 1 is node 10966453: -0.446248 51.458374 = 0.003 km
>> Found Closest Point: Waypoint 2
>> Waypoint 2 is segment 13674333 (node 10967217 -> 10967267): -0.436377
>> 51.455728 = 0.000 km
>> Routing from waypoint 1 to waypoint 2
>> Found Start Route: Nodes checked = 4 - Fail
>> Error: Cannot find initial section of route compatible with profile.

This is not a Routino bug, it is a bug in the Openstreetmap data that
Routino is using.

The road that has been selected for the start point is marked as
one-way and is a dead-end.  If you follow the road (in the only
direction allowed) you will come to the end where you can go no
further.

You can see this more easily in this zoomed in map:

http://www.openstreetmap.org/#map=18/51.45887/-0.44572

Routino cannot calculate a route where there is no viable road.


It could be argued that Routino should remove one-way highways that
lead into a dead-end and one-way highways that start from a dead-end
but that is a feature request, not a bug.  Routino does make efforts
to remove highways that cannot be used for routing but one-way
highways like this are not included.

-- 
Andrew.
--
Andrew M. Bishop   http://www.routino.org/

Bug#819580: ITP: ruby-syslog-logger -- improved Logger replacement that logs to syslog

[Lucas Kanashiro]

Package: wnpp
Severity: wishlist
Owner: Lucas Kanashiro 

* Package name: ruby-syslog-logger
  Version : 1.6.8
  Upstream Author : Eric Hodel, Chris Powell, Matthew Boeh, Ian Lesperance, 
Dana Danger, Brian Smith, Ashley Martens
* URL : http://github.com/ngmoco/syslog_logger
* License : Expat
  Programming Lang: Ruby
  Description : improved Logger replacement that logs to syslog

Logger::Syslog is a Logger replacement that logs to syslog. It is almost
drop-in with a few caveats. Add Logger::Syslog to your Rails production
environment to aggregate logs between multiple machines.

This particular Logger::Syslog improves the original by correctly
mapping Rails log severities to the Syslog counterparts. It also adds
the ability to select a syslog facility other than "user".


I intend to maintain this package under the umbrella of Debian Ruby team. This
package is a new dependency of new chef's release.

Bug#819514: RFS: emacs-buttercup/1.5-1 -- behaviour-driven testing for Emacs Lisp packages

[PICCA Frederic-Emmanuel]

uploaded

Cheers

Fred

Bug#795555: Do you use busybox?

[Jochen Pawletta]

Hi

Regarding your boot-problem, do you use busybox?
If yes look at my problem which is resolved ...:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787554


Jochen

-- 
ZX81 - C64 - Amiga - x86-Linux - iMac (OS X)

Bug#818876: finally

[Harald Hope]

If I were you adam I'd stop trying to interpret things, you aren't very good at it, not in the 
failed attempt to guess at the kfreebsd logic, and not in this case. Just provide the data that is 
requested and leave it at that, saves us a lot of time. The debugging information you finally 
provided me, which I shouldn't have had to ask for twice, shows me the source of the issue clearly.


Now, the problem here is, that, this had escaped my memory, that debian's default /etc/issue is in 
fact far superior in general in terms of output than the /etc/debian_version file is, no matter what 
your pedantic view of the question is, the fact is, the default values stored there are almost 
always and in most cases better than the data stored in /etc/debian_version, which is why it's used 
for debian.


So I was wrong, /etc/issue for debian and ubuntu is the preferred source, but I'll switch this based 
on the reasoning below.


Since you are the first person ever to take issue with this, so to speak, I'm not super sure I 
should do anything about this, because MOST users will get better data and results from that source 
than from /etc/debian_version.


I can't guess what you stuck in your /etc/issue, but there can be an argument made to extend the 
checks of /etc/issue slightly in this case, though it's hard to make this type of change, I'm 
certainly not going to make it worse for most people just to make one single issue reporter happy.


So it's the old thing, the good of the many outweighs the good of the one, in 
this  case.

But there is another way I can see, because basically now the os-release stores the default 
/etc/issue value in PRETTY_NAME, and now that os-release is more common (this logic was written LONG 
before os-release came into being), I think the solution is to just switch to using the pretty name 
value of os-release in debian/duvian/ubuntu's cases if my data shows that's consistently good.


Now, of course, this will immediately trigger a cascade of errors where people expected to see x and 
suddenly see y, totally unpredictable, which is what happens when you change core things, 
particularly only for a single person, a risky proposition, though I can check some of my os-release 
data from user datasets I've gathered over the past 4 years or so, that should be enough.


This option didn't exist before because it took a long time for os-release to filter down and become 
standard in almost all extent debian/ubuntu versions.


So that seems like a good fix, but that's if any only if os-release is basically consistent and 
usable, ie, it always contains the same data for almost all users as /etc/issue did. If it doesn't 
in some cases, then I'd have to make the changes more granular. If I find enough cases where 
os-release values are not good, then I'll have to probably just ignore this issue and leave it as it 
is, because I'm not going to mess things up for more than 1 person just to make 1 person happy.


So we'll see how this goes.

Bug#801177: [pkg-gnupg-maint] Bug#801177: Any updates on this?

[Daniel Kahn Gillmor]

On Wed 2016-03-30 09:46:00 -0400, Adam Baxter  wrote:
> Ran into this - it's an annoying bug on space constrained devices. What
> needs to be done for it to be fixed?

https://bugs.debian.org/801177 should already be resolved in debian
testing, because the dependency order for gnupg-agent lists
pinentry-curses first.

This is actually the same bug as https://bugs.debian.org/753163.  i'm
trying to merge them now.

--dkg

Bug#819486: routino: At parks routino often can not find the route.

[Andrew M. Bishop]

>> Package: routino
>> Version: 3.1.1-2
>> Severity: normal
>>
>> Reproduce:
>> 
>> 1. Open http://www.routino.org/uk-leaflet/router.html
>> 2. Set point "1": -0.73458 E / 51.37529 N
>> 3. Set point "2": any. For example: -0.06579 E / 51.47898 N
>> 4. Click "Shortest Route"
>> 5. Get:

>> Loaded Files: nodes, segments, ways & relations
>> Found Closest Point: Waypoint 1
>> Error: Cannot find node close to specified point 1.

This is not a bug in Routino.

The route that has been asked for starts in the middle of an area with
no roads and asks for transport by motorcar.  The nearest road is
more than 1 km from the first waypoint and Routino has a limit of 1 km
when searching for the nearest highway.  To find a route a starting
point closer to the nearest accessible highway should be selected.

It could be argued that Routino should search further but in most
cases it does not make sense to choose a starting point that is so far
from the given waypoint.

-- 
Andrew.
--
Andrew M. Bishop   http://www.routino.org/

Bug#819579: Short description continues into long description

[Josh Triplett]

Package: abi-monitor
Version: 1.7-1
Severity: normal

Policy 3.4.2. "The extended description":
> Do not try to continue the single line synopsis into the extended
> description.  This will not work correctly when the full description
> is displayed, and makes no sense where only the summary (the single
> line synopsis) is available.

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

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

Bug#811073: RFS: lbfgsb/3.0-1 [ITP]

[Gianfranco Costamagna]

Hi


>http://mentors.debian.net/debian/pool/main/l/lbfgsb/lbfgsb_3.0-2.dsc
>addresses the standards-version and the dbg package. I'll have to work
>on the watch file and (if needed) the build system.


ok, let me know when the  other points are addressed, and I'll grab it :)
(please call it always -1, until it goes in unstable/new queue)

>  gfortran -g -O2 -fstack-protector-strong -fPIC -o build/lbfgsb.o -c lbfgsb.f
>so it seems the flags are taken into account. Am I mistaken?


my bad.
sorry

G.

Bug#811073: RFS: lbfgsb/3.0-1 [ITP]

[Gianfranco Costamagna]

Hi,



>I see. I was under the impression that was only to be used when files
>are excluded for copyright reasons. I repackaged the upstream tarball
>because it included binaries (compiled from the source, one presumes)
>and some metadata - not necessarily things that are problematic in a
>copyright sense.


you can add a comment saying the reason for the exclude.
If there are no copyright issues instead of dfsg you should use "ds" (Debian 
Source)
suffix, and mangle debian/watch accordingly.

>This'll be more work, so I'll have to postpone it a bit. The build
>seems a bit trivial for a whole generic system to be added, doesn't
>it?


also adding a new target to the current Makefile can be a good compromise


>I think they'll be useful, yes. I'll get around to adding that.


an autopkgtest is also really helpful. and trivial to implemement
Ghislain added it to almost every package he maintains, so I think
you can take is work as starting point.

G.

Bug#819514: RFS: emacs-buttercup/1.5-1 -- behaviour-driven testing for Emacs Lisp packages

[Sean Whitton]

control: severity -1 normal
control: retitle -1 RFS: emacs-buttercup/1.5-1 -- behaviour-driven testing for 
Emacs
 Lisp packages

Apologies: this is a new version, not an ITP.

Changes since the last upload:

  * New upstream version.
  * Drop patch backporting a fix present in this version.
  * Refresh remaining patch.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#819493: debian-security-support: FTBFS on jessie: attemps to install nonexistent security-support-ended.deb8+deb8u3 file

[Santiago Ruano Rincón]

El 29/03/16 a las 20:39, Moritz Mühlenhoff escribió:
> On Tue, Mar 29, 2016 at 05:13:51PM +0200, Santiago Ruano Rincón wrote:
... 
> Feel free to make code changes in collab-maint along with an upload
> to unstable.
> 

Thanks! Pushed and uploaded,

Santiago


signature.asc
Description: PGP signature

Bug#819570: reportbug: replyto option in config file ignored

[Ian Zimmerman]

On 2016-03-30 17:04 +0100, Sandro Tosi wrote:

> this is a rather old version, did you try on a more recent one?

This is the only version available in wheezy; I run wheezy for what are
good reasons to me, so no, I can't test a more recent one.

Even if I tweaked my apt config to make a newer one available, it would
pull in the world [1] from jessie, forcing me to upgrade to jessie in
all but name.  Maybe this would be a good package to put in the
backports repo.

[1]-->more specifically, the python (sic) package, nonexistent in wheezy.

-- 
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.

Bug#819500: general: Debian 8.3 CLI reboot using "init 6" shows username & password in plain text.

[Santiago Vila]

On Wed, Mar 30, 2016 at 06:57:39AM +1300, beagleburt wrote:
> Package: general
> Severity: normal
> 
> Dear Maintainer,
> 
> * CLI command "shutdown -r now" USUALLY does not work, since systemd replaced
> sysvinit in Debian 8 "jessie".
> Posted problem on http://www.linuxquestions.org/questions/debian-26/used-to-
> shutdown-reboot-from-cli-but-since-systemd-replaced-init-shutdown-cmnd-
> broke-4175575779/ got advice to try commmand "init 6". When I try it, I 
> USUALLY
> arrive - eventually - at a console login that reports errors - but amongst the
> confusing information are the username & password IN PLAIN TEXT! I also had a
> single occurrence of my root password split over two lines also in plain text!
> Basically the reboot & shutdown commands from the CLI are REALLY buggy!
> 
> Another respondent to my query on LQ.org suggested using: "systemctl reboot"
> this resulted eventually in poweroff/shutdown.
> 
> The MOST annoying part of this bug is its variability: OCCASSIONALLY the
> commands work ok! But USUALLY not! Also SOMETIMES on booting-up again after an
> unwanted forced-shutdown, the machine powers off without warning USUALLY 
> before
> the graphical Login appears & ONCE after an apparently successful login?

Hi.

If the machine powers off without warning, it is quite likely that you
have a hardware problem.

Hardware problems are often random and unpredictable, but they are not
software bugs, so they do not usually have a place in the Debian bug system.

I would start by checking memory with the memtest86+ package. After
installing the package, you have to reboot and choose the new GRUB
menu entry that it's added automatically.

Also, I would try to install Debian in a different computer and
configure it identically. If you experience similar problems, then
yes, it could be a bug. But if the problem vanishes, you would have a
good confirmation that your hardware is faulty (random power offs
are already a sign for that).

If you need more help, please ask in debian-user mailing list.

Thanks.

Bug#819493: debian-security-support: FTBFS on jessie: attemps to install nonexistent security-support-ended.deb8+deb8u3 file

[Santiago Vila]

On Wed, Mar 30, 2016 at 04:39:17PM +0200, Santiago Ruano Rincón wrote:
> What about this?
> 
> diff --git a/debian/rules b/debian/rules
> index 10e034a..3fefda0 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -1,6 +1,11 @@
>  #!/usr/bin/make -f
>  
> -DEBIAN_VERSION ?= $(shell LANG=C dpkg -l base-files | awk '($$1=="ii"){print 
> $$3}' | cut -d. -f1 | cut -d+ -f1)
> +NEXT_VERSION_ID=$(shell ls -w1 ./security-support-ended.deb* | sort -n | 
> tail -n1 | awk -F "deb" '{print $$2}')
> +
> +DEBIAN_VERSION ?= $(shell cat /etc/debian_version | grep '[0-9.]' | cut -d. 
> -f1)
> +ifeq (,$(DEBIAN_VERSION))
> +  DEBIAN_VERSION=$(NEXT_VERSION_ID)
> +endif
>  

I'm not familiar enough with this package to tell, but if that does
what you want, yes, I suppose it would be better.

Beware, however, that in a future there might be a file named
security-support-ended.deb10 and the sort could not work as expected.

If the release is for jessie, I would try to keep it simple:

DEBIAN_VERSION = 8

Isn't this why we have branches in git repositories?

Thanks.

Bug#811073: RFS: lbfgsb/3.0-1 [ITP]

[Gard Spreemann]

On Friday 25 March 2016 18:56:40 Gianfranco Costamagna wrote:
> something needs changes:
> - std-version= 3.9.7
> - no watch file?
> - no sane build system, why are you building the library such way?
> you seem to use just two files in your library, why everything is dropped?
> I don't think flags in rules are actually evaluated, because you don't set
> them - dbg package is useless now that we have ddbg automatic generation.
> 
> Please address/comment/fix the above, and I'll do another spin

http://mentors.debian.net/debian/pool/main/l/lbfgsb/lbfgsb_3.0-2.dsc
addresses the standards-version and the dbg package. I'll have to work
on the watch file and (if needed) the build system.

As for the flags: When I debuild, I see

  gfortran -g -O2 -fstack-protector-strong -fPIC -o build/lbfgsb.o -c lbfgsb.f

so it seems the flags are taken into account. Am I mistaken?


Thanks again for the help.

Best,
Gard

Bug#811073: RFS: lbfgsb/3.0-1 [ITP]

[Gard Spreemann]

On Wednesday 30 March 2016 14:27:45 Gianfranco Costamagna wrote:
> HI,
> 
> >I didn't make one since upstream's tarball (at least for the latest
> >version) contains precompiled binaries, as well as a few files outside
> >of any directory (a little tarbomb). It is my understanding that these
> >need to be stripped out of the Debian source. Should I make a script
> >for that and have uscan run it?
> >
> >Upstream has a very slow release cycle, and it is my impression that
> >the library is more or less "done". Is a watch file still important?
> 
> Filex-Excluded copyright keyword might become handy.

I see. I was under the impression that was only to be used when files
are excluded for copyright reasons. I repackaged the upstream tarball
because it included binaries (compiled from the source, one presumes)
and some metadata - not necessarily things that are problematic in a
copyright sense.

> please consider, other people might have to understand how did you
> do the work, and redo it.

That makes a lot of sense, yes.

> >There is no build system upstream. How should I best approach this
> >issue?
> 
> add one :)

This'll be more work, so I'll have to postpone it a bit. The build
seems a bit trivial for a whole generic system to be added, doesn't
it?

> >- blas.f: We use the system libblas instead of this bundled copy.
> 
> nice indeed
> 
> >- driver*.f*: These are demonstration files for how to use the
> >
> >   library, and are therefore not compiled. Should they be installed
> >   as example source files somewhere?
> 
> a package-examples might be trivial to add now, but you are the maintainer
> you have to know your users' expectations. If you think an example
> packages is useful you can add it.

I think they'll be useful, yes. I'll get around to adding that.

Bug#816446: nginx: Please use systemd confinement features

[Moritz Muehlenhoff]

On Tue, Mar 01, 2016 at 02:35:39PM -0800, Michael Lustfield wrote:
> Control: tags -1 + wontfix
> 
> I have three significant issues with adding systemd confinement to
> nginx out of the box:

I disagree with these:
 
> 1) This will introduce significant differences between debian servers
> running systemd and every single other init system that debian
> supports.

systemd is the default init system since jessie and we cannot limit
features used in init scripts to the least common denominator. In fact
we already have a lot of feature disparaties with sysvinit not 
providing many features present in systemd.
 
> 2) Anyone using systemd would have an out of the box nginx
> installation that would not match reasonable expectations.

Why would this not match reasonable expections? Upstream doesn't
even provide a systemd unit, so Debian's doesn't behave different
in that regard.

All the features used in Nicolas' patch are standard systemd unit
features, I see no reason not to use them by default.
 
> Users should be able to install nginx and have it behave exactly as
> expected. 

And these expectations include a high level of security.

Cheers,
Moritz

Bug#819577: libreoffice-calc: Crash after runtime error in LibreOffice Basic after changing Code

[lopiuh]

Package: libreoffice-calc
Version: 1:5.1.2~rc1-1
Severity: normal

Dear Maintainer,

having a (short) libreoffice Basic Macro with a runtime error. Changing several 
lines of Code, while runtime error dialog is displayed, LibreOffice Calc 
crashes after pressing OK in the runtime error dialog.

1) execute Macro with option explicit and not declared variable
2) runtime error is displayed (don't close error dialog)
3) change Macro (add lines)
4) close runtime error dialog
5) LibreOffice Calc crashes

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

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

Versions of packages libreoffice-calc depends on:
ii  coinor-libcbc32.8.12-1+b1
ii  coinor-libcoinmp1v5   1.7.6+dfsg1-2
ii  libboost-iostreams1.58.0  1.58.0+dfsg-5+b1
ii  libc6 2.22-4
ii  libetonyek-0.1-1  0.1.6-1
ii  libgcc1   1:5.3.1-13
ii  libicu55  55.1-7
ii  liblcms2-22.6-3+b3
ii  libmwaw-0.3-3 0.3.7-1
ii  libodfgen-0.1-1   0.1.6-1
ii  liborcus-0.10-0v5 0.9.2-4
ii  libreoffice-base-core 1:5.1.2~rc1-1
ii  libreoffice-core  1:5.1.2~rc1-1
ii  librevenge-0.0-0  0.0.4-4
ii  libstdc++65.3.1-13
ii  libwps-0.4-4  0.4.3-1
ii  libxml2   2.9.3+dfsg1-1
ii  lp-solve  5.5.0.13-7+b2
ii  uno-libs3 5.1.2~rc1-1
ii  ure   5.1.2~rc1-1
ii  zlib1g1:1.2.8.dfsg-2+b1

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
pn  ocl-icd-libopencl1  

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.3
ii  fonts-opensymbol  2:102.7+LibO5.1.2~rc1-1
ii  libboost-date-time1.58.0  1.58.0+dfsg-5+b1
ii  libc6 2.22-4
ii  libcairo2 1.14.6-1
ii  libclucene-contribs1v52.3.3.4-4.1
ii  libclucene-core1v52.3.3.4-4.1
ii  libcmis-0.5-5v5   0.5.1-2
ii  libcups2  2.1.3-4
ii  libcurl3-gnutls   7.47.0-1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.106-1
ii  libdconf1 0.24.0-2
ii  libeot0   0.01-3
ii  libexpat1 2.1.1-1
ii  libexttextcat-2.0-0   3.4.4-1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6.3-3
ii  libgcc1   1:5.3.1-13
ii  libgl1-mesa-glx [libgl1]  11.1.2-1
ii  libglew1.13   1.13.0-2
ii  libglib2.0-0  2.48.0-1
ii  libgltf-0.0-0v5   0.0.2-4+b1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgraphite2-31.3.7-1
ii  libharfbuzz-icu0  1.0.1-1+b1
ii  libharfbuzz0b 1.0.1-1+b1
ii  libhunspell-1.3-0 1.3.3-4
ii  libhyphen02.8.8-2
ii  libice6   2:1.0.9-1+b1
ii  libicu55  55.1-7
ii  libjpeg62-turbo   1:1.4.2-2
ii  liblangtag1   0.5.7-2
ii  liblcms2-22.6-3+b3
ii  libldap-2.4-2 2.4.42+dfsg-2+b2
ii  libmythes-1.2-0   2:1.2.4-1
ii  libneon27-gnutls  0.30.1-3
ii  libnspr4  2:4.12-1
ii  libnss3   2:3.23-1
ii  libodfgen-0.1-1   0.1.6-1
ii  libpcre3  2:8.38-3.1
ii  libpng12-01.2.54-4
ii  librdf0   1.0.17-1+b1
ii  libreoffice-common1:5.1.2~rc1-1
ii  librevenge-0.0-0  0.0.4-4
ii  libsm62:1.2.2-1+b1
ii  libssl1.0.2   1.0.2g-1
ii  libstdc++65.3.1-13
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxml2   2.9.3+dfsg1-1
ii  libxrandr22:1.5.0-1
ii  libxrender1   1:0.9.9-2
ii  libxslt1.11.1.28-2.1
ii  uno-libs3 5.1.2~rc1-1
ii  ure   5.1.2~rc1-1
ii  zlib1g1:1.2.8.dfsg-2+b1

-- no debconf information

Bug#815915: lsinitramfs fails to properly skip the padding after each cpio archive

[Henrique de Moraes Holschuh]

(note: I am not subscribed to this bug report. If you want a reply from
me, please keep me Cc'd).

The padding between the component initramfs images that make up a
"hybrid initramfs" is a sequence of zeros, and it is aligned to the cpio
block/record size boundary.  There are several valid block sizes for
cpio, e.g. 512 (used by iucode v1.0 and earlier, and cpio default) or
1024, which iucode-tool v1.1 and later uses (as a defensive measure).

I can revert the 1024-byte block size in iucode-tool to 512 bytes, but
that's neither here nor there: it would just work around the bug in
lsinitramfs.  It would be better to fix lsinitramfs (assuming this isn't
fixed already in unstable).


Now, to the root cause of the breakage:

The heuristics initramfs-tools "lsinitramfs" uses (used?) to locate the
next initramfs are incomplete (it does not skip over the padding at the
end of each initramfs) and causes zcat to crash (which is likely a bug
in zcat itself).  It will work fine for 512-byte cpio block size, but
not for 1024-byte block size (and also likely not for other block
sizes).

lsinitramfs needs to skip all zero bytes (or dwords) to locate the next
initramfs segment, instead of assuming a cpio block size of 512 bytes.

And zcat should not crash if it gets a file that begins with a lot of
zeroes before the compressed data... it should either abort with an
error (invalid file), or skip the zeroes without crashing.  But that's a
separate bug.


For the record, a full account of how the kernel parses and loads an
initramfs (which is how lsinitramfs should behave in an ideal world):


EARLY cpio loader (lib/earlycpio.c, loads the microcode data and ACPI
table override data): always skips zero DWORDs (4 bytes) before any cpio
header, including the first.  So, it will just concatenate every
non-compressed cpio archive and skip any dword-aligned zero padding
before, after, or between cpio archive headers (and, therefore, also
between cpio archives).

Note: the early cpio loader does not care for subdirectories, it can
find data by the whole path, and that's how microcode is loaded. This
means the cpio archive with microcode does not need to have any of the
subdirectories inside, it doesn't matter to the kernel. I didn't check
how the ACPI table override loader behaves.

LATE cpio loader (init/initramfs.c, loads the real initramfs):
  1. Skips any zero bytes before the compressed or uncompressed data
  (thus, skips any padding between cpio archives).

  2. Unpacks any compressed or uncompressed cpio archive it finds,
  concatenating the contents (thus, it *will* also unpack
  the microcode in the first cpio archive, and this file will be
  available inside the initramfs).

  3. It *depends* on subdirectories being created *first* before any
  files inside them. If this is not done, it will ignore the file
  (so you could have data in the early initramfs that is "invisible"
  for the late cpio loader).

  4. It does NOT skip inital zero-padding on the *decompressed* data
  (i.e. if you compress a cpio archive, it must not have
  any initial zero padding).

  5. It skips any zero padding at the end (compressed or not), but the
  zeros must *end* at a DWORD boundary.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

Bug#815804: info about the bug

[Jean-Marc]

Hi Ben,

I discussed with Maderios regarding this bug (I know him from the 
debian-user-french list).

He told me he is not able to reproduce it because he de-installed Debian from 
his machine.

Do you think it should stay open ?

Regards,

Jean-Marc 


pgpA9fSMTousA.pgp
Description: PGP signature

Bug#819343: ITP: r-cran-dplyr -- A Grammar of Data Manipulation for GNU R

[Dirk Eddelbuettel]

On 30 March 2016 at 19:01, Andreas Tille wrote:
| On Wed, Mar 30, 2016 at 07:02:04AM -0500, Dirk Eddelbuettel wrote:
| > 
| > | Could you please explain what size exactly is doubled?  As far as I
| > | understood r-cran-bh would be just a wrapper for the Debian packaged
| > | libboost.
| > 
| > Nope. As I explained to you before and in this thread, there is downside in
| > differing from what is on CRAN.
| 
| OK.  At a second look I noticed how simple it is to replace BH by the
| Debian packaged boost.  I think I've got the downside but to my opinion

Yes, it is a simple sed call on DESCRIPTION, coupled with a Build-Depends.

But -- you risk creating different packages, creating different behaviour and
possibly very different to track bugs.

Having thought about this for a bit, I came to the conclusion that I'd rather
package r-cran-bh.

| its way more sensible to avoid code duplication as a general rule and
| run the accompanying test suite of the packages to ensure that
| everything works as expected.
| 
| In other words I do not need the r-cran-bh package as a predependency
| of my packages any more.

Entirely your call, but as I state above, one that I would NOT make.

One of the strongest things about R is the consistent reliability across
installation.  You are starting to differ here.   It may not matter most of
the time, only to all of sudden become an issue -- that may be hard to track
form someone not familiar with these details.

In my view saving 5mb in the archive is not worth it.

Dirk 

| 
| Kind regards
| 
| Andreas. 
| 
| -- 
| http://fam-tille.de

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#819576: linux-image-4.4.0-0.bpo.1-amd64: Brightness slowdown - Changing brightness takes some seconds and causes system slowdown

[Leonardo Santana Vieira]

Package: src:linux
Version: 4.4.6-1~bpo8+1
Severity: important

Dear Maintainer,

After kernel upgrade, changing brightness takes some seconds and causes system
slowdown if i try to change more than one level at a time. This problem does
not happen in the other kernel packages i have installed(3.16, 4.3). I'm using
Gnome desktop, the problem happens when i try the change through the menu at
the top bar and especially if i try using fn keys to do it. If a hold fn+f5 or
f6 all the way to minimum or maximum, the action causes severe slowdown in the
system making it unusable for some time. I have theses modules installed in all
the kernel packages as can be seen below the result of "dkms status" command.

bbswitch, 0.8, 3.16.0-4-amd64, x86_64: installed
bbswitch, 0.8, 4.3.0-0.bpo.1-amd64, x86_64: installed
bbswitch, 0.8, 4.4.0-0.bpo.1-amd64, x86_64: installed
nvidia-current, 352.79, 3.16.0-4-amd64, x86_64: installed
nvidia-current, 352.79, 4.3.0-0.bpo.1-amd64, x86_64: installed
nvidia-current, 352.79, 4.4.0-0.bpo.1-amd64, x86_64: installed
virtualbox, 5.0.16, 3.16.0-4-amd64, x86_64: installed
virtualbox, 5.0.16, 4.3.0-0.bpo.1-amd64, x86_64: installed
virtualbox, 5.0.16, 4.4.0-0.bpo.1-amd64, x86_64: installed



-- Package-specific info:
** Version:
Linux version 4.4.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.4.6-1~bpo8+1 (2016-03-20)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.4.0-0.bpo.1-amd64 
root=UUID=34333935-6a2e-401e-8284-fbd915a5c247 ro quiet

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[3.046002] [drm:cpt_irq_handler [i915]] *ERROR* PCH transcoder A FIFO 
underrun
[3.088769] clocksource: Switched to clocksource tsc
[3.290615] Adding 11718652k swap on /dev/sda2.  Priority:-1 extents:1 
across:11718652k FS
[3.339649] uvcvideo: Found UVC 1.00 device USB Camera (13d3:5165)
[3.350828] input: USB Camera as 
/devices/pci:00/:00:1a.0/usb3/3-1/3-1.3/3-1.3:1.0/input/input18
[3.350904] usbcore: registered new interface driver uvcvideo
[3.350904] USB Video Class driver (1.1.1)
[3.572536] pstore: Registered efi as persistent store backend
[3.587952] Console: switching to colour frame buffer device 170x48
[3.590360] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[3.601464] intel_rapl: Found RAPL domain package
[3.601467] intel_rapl: Found RAPL domain core
[3.601468] intel_rapl: Found RAPL domain uncore
[3.691816] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT 
filesystems, filesystem will be case sensitive!
[3.710231] psmouse serio4: elantech: assuming hardware version 4 (with 
firmware version 0x361f01)
[3.723702] psmouse serio4: elantech: Synaptics capabilities query result 
0x00, 0x15, 0x0c.
[3.737244] psmouse serio4: elantech: Elan sample query result 03, 23, 75
[3.805084] input: ETPS/2 Elantech Touchpad as 
/devices/platform/i8042/serio4/input/input12
[3.969421] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: 
(null)
[4.014334] systemd-journald[209]: Received request to flush runtime journal 
from PID 1
[4.015494] ip_tables: (C) 2000-2006 Netfilter Core Team
[4.023753] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[4.033615] ip6_tables: (C) 2000-2006 Netfilter Core Team
[4.133437] RPC: Registered named UNIX socket transport module.
[4.133441] RPC: Registered udp transport module.
[4.133442] RPC: Registered tcp transport module.
[4.133443] RPC: Registered tcp NFSv4.1 backchannel transport module.
[4.136723] FS-Cache: Loaded
[4.143627] FS-Cache: Netfs 'nfs' registered for caching
[4.150812] Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
[4.227984] vboxdrv: Found 4 processor cores
[4.230014] bbswitch: version 0.8
[4.230022] bbswitch: Found integrated VGA device :00:02.0: 
\_SB_.PCI0.GFX0
[4.230028] bbswitch: Found discrete VGA device :01:00.0: 
\_SB_.PCI0.PEG0.PEGP
[4.230040] ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type 
mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[4.230149] bbswitch: detected an Optimus _DSM function
[4.230161] bbswitch: Succesfully loaded. Discrete card :01:00.0 is on
[4.232850] bbswitch: disabling discrete graphics
[4.232864] ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type 
mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[4.243924] vboxdrv: TSC mode is Invariant, tentative frequency 1696141449 Hz
[4.243927] vboxdrv: Successfully loaded version 5.0.16_Debian (interface 
0x0024)
[4.251583] VBoxNetFlt: Successfully started.
[4.259276] VBoxNetAdp: Successfully started.
[4.267229] VBoxPciLinuxInit
[4.270773] vboxpci: IOMMU not found (not registered)
[4.453681] r8169 :04:00.2: firmware: direct-loading firmware 
rtl_nic/rtl8411-1.fw
[4.542816] r8169 

Bug#819088: xapers/bibtex.py:6 "from pybtex.core import Entry, Person" -> ImportError: No module named core

[Jameson Graef Rollins]

tag 819088 confirmed patch
thanks

On Wed, Mar 23 2016, Daniel Kahn Gillmor  wrote:
> I just upgraded from pybtex 0.18-1 to 0.19-1
>
> now, when i try to "xapers add --file=foo.pdf", i get:
>
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/runpy.py", line 163, in _run_module_as_main
> mod_name, _Error)
>   File "/usr/lib/python2.7/runpy.py", line 111, in _get_module_details
> __import__(mod_name)  # Do not catch exceptions initializing package
>   File "/usr/lib/python2.7/dist-packages/xapers/__init__.py", line 21, in 
> 
> from database import Database
>   File "/usr/lib/python2.7/dist-packages/xapers/database.py", line 26, in 
> 
> from documents import Documents, Document
>   File "/usr/lib/python2.7/dist-packages/xapers/documents.py", line 27, in 
> 
> from bibtex import Bibtex
>   File "/usr/lib/python2.7/dist-packages/xapers/bibtex.py", line 6, in 
> 
> from pybtex.core import Entry, Person
> ImportError: No module named core

It looks like pybtex moved some things around.  The attached patch seems
to fix the problem.  I'll try to push out a new release soon, but it
won't happen until next week at the earliest.

jamie.

diff --git a/lib/xapers/bibtex.py b/lib/xapers/bibtex.py
index c2a9eda..a2e1309 100644
--- a/lib/xapers/bibtex.py
+++ b/lib/xapers/bibtex.py
@@ -23,8 +23,8 @@ import sys
 import io
 import json
 import pybtex
-from pybtex.core import Entry, Person
 from pybtex.bibtex.utils import split_name_list
+from pybtex.database import Entry, Person
 from pybtex.database.input import bibtex as inparser
 from pybtex.database.output import bibtex as outparser
 


signature.asc
Description: PGP signature

Bug#819575: booth: Bad title and description

[Peter Gervai]

Source: booth
Severity: minor

"   Paxos-based daemon to manage multi-site clusters "

As far as I observe this is misleading as booth uses
Raft in contrast to Paxos, and Raft was explicitely
created to prevent the complexity of Paxos.

Same goes for the package description.


"Booth is based on the Raft consensus algorithm."
Source: https://github.com/ClusterLabs/booth

Thanks,
Peter

Bug#819343: ITP: r-cran-dplyr -- A Grammar of Data Manipulation for GNU R

[Andreas Tille]

On Wed, Mar 30, 2016 at 07:02:04AM -0500, Dirk Eddelbuettel wrote:
> 
> | Could you please explain what size exactly is doubled?  As far as I
> | understood r-cran-bh would be just a wrapper for the Debian packaged
> | libboost.
> 
> Nope. As I explained to you before and in this thread, there is downside in
> differing from what is on CRAN.

OK.  At a second look I noticed how simple it is to replace BH by the
Debian packaged boost.  I think I've got the downside but to my opinion
its way more sensible to avoid code duplication as a general rule and
run the accompanying test suite of the packages to ensure that
everything works as expected.

In other words I do not need the r-cran-bh package as a predependency
of my packages any more.

Kind regards

Andreas. 

-- 
http://fam-tille.de

Bug#819573: libacr38u: specified group 'pcscd' unknown

[Laurent Bigonville]

Hey,

Well I'm alive, but there was no upstream update that's why the pkg has 
not been touched for a long time.


If you want you can push a NMU with this fix, my gpg key in the archive 
is currently expired.


Cheers,

Laurent Bigonville

Le 30/03/16 18:28, Ludovic Rousseau a écrit :

Package: libacr38u
Version: 1.7.11-1
Severity: normal
Tags: patch

Hello,

The libacr38u package provides the file
/lib/udev/rules.d/92-libacr38u.rules to change the group of the device
file to "pcscd". This is no more needed since pcsc-lite 1.8.8 released
in January 2013.

The use of the non-existing pcscd group will even generate an error in the
logs:
Reading rules file: /lib/udev/rules.d/92-libacr38u.rules specified group 
'pcscd' unknown

Please remove the file debian/libacr38u.udev and upload a new version of
the libacr38u package.

I note that the Debian package has not been updated since August 2011 so
I do not expect a fix of this bug "soon" :-(

Thanks

-- System Information:
Debian Release: 8.3
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Bug#819397: src:ncurses: Add udeb support to libtinfo5

[Sven Joachim]

Control: severity -1 wishlist
Control: tags -1 + moreinfo

On 2016-03-28 09:39 +0900, Roger Shimizu wrote:

> Package: src:ncurses
> Severity: normal
> Tags: patch, d-i
> X-Debbugs-Cc: rogershim...@gmail.com
>
> Dear Maintainer,
>
> I'm trying to port GNU/screen to debian-installer [0].
> GNU/screen depends on your library, so enclosed the patch I created to
> make those udeb support.
>
> I hope you can merge my patch soon. Thank you!

There are various things wrong with it, unfortunately.

> +Package: libtinfo5-udeb
> +XC-Package-Type: udeb

Please use Package-Type rather than XC-Package-Type.
See "lintian-info -t xc-package-type-in-debian-control".

> +Section: debian-installer
> +Architecture: any
> +Pre-Depends: ${misc:Pre-Depends}

Uhm, why Pre-Depends?

> +Multi-Arch: same

It does not really make sense to mark udebs as "Multi-Arch: same" since
you won't be using more than one architecture in the installer.

> +Depends: ${misc:Depends}
> +Description: shared low-level terminfo library for terminal handling - udeb
> + The ncurses library routines are a terminal-independent method of
> + updating character screens with reasonable optimization.
> + .
> + This package contains the stripped-down udeb version of shared low-level
> + terminfo library.
> +
>  Package: libncurses5
>  Architecture: any
>  Pre-Depends: ${misc:Pre-Depends}
> diff --git a/debian/libtinfo5-udeb.install.in 
> b/debian/libtinfo5-udeb.install.in
> new file mode 100644
> index 000..b0b4373
> --- /dev/null
> +++ b/debian/libtinfo5-udeb.install.in
> @@ -0,0 +1,2 @@
> +usr/lib/${DEB_HOST_MULTIARCH}/libtinfo.so.*  lib/${DEB_HOST_MULTIARCH}
> +usr/lib/${DEB_HOST_MULTIARCH}/libtic.so.*

I would just install all libraries into lib, and then you don't need to
use a libtinfo5-udeb.install.in file.

Most importantly, you need to generate udeb lines in the libtinfo5
shlibs file, so that udebs with programs linked against libtinfo depend
on libtinfo5-udeb rather than libtinfo5.  To achieve that, pass
"--add-udeb" in the dh_makeshlibs call for libtinfo5 in debian/rules.

Cheers,
   Sven

Bug#819574: mysql-workbench: Server logs menu option freezes the application

[Leonardo Santana Vieira]

Package: mysql-workbench
Version: 6.2.3+dfsg-7
Severity: normal

Dear Maintainer,

Everytime i try to see the log of my local development mysql-server through
mysql-workbench, the app freezes and i have to kill it to close it. mysql-
server configuration is the default where the error log is sent to syslog and
the other logs are inactive.



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

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

Versions of packages mysql-workbench depends on:
ii  libatkmm-1.6-12.22.7-2.1
ii  libc6 2.19-18+deb8u3
ii  libcairo2 1.14.0-2.1
ii  libcairomm-1.0-1  1.10.0-1.1
ii  libctemplate2 2.2-4
ii  libgcc1   1:4.9.2-10
ii  libgdal1h 1.10.1+dfsg-8+b3
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u4
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libglib2.0-0  2.42.1-1
ii  libglibmm-2.4-1c2a2.42.0-1
ii  libgnome-keyring0 3.12.0-1+b1
ii  libgtk2.0-0   2.24.25-3
ii  libgtkmm-2.4-1c2a 1:2.24.4-1.1
ii  libmysqlclient18  5.5.47-0+deb8u1
ii  libmysqlcppconn7  1.1.3-6
ii  libodbc1  2.3.1-3
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangomm-1.4-1  2.34.0-1.1
ii  libpcre3  2:8.35-3.3+deb8u2
ii  libpcrecpp0   2:8.35-3.3+deb8u2
ii  libpython2.7  2.7.9-2
ii  libsigc++-2.0-0c2a2.4.0-1
ii  libstdc++64.9.2-10
ii  libtinyxml2.6.2   2.6.2-2
ii  libuuid1  2.25.2-6
ii  libvsqlitepp3 0.3.13-3
ii  libx11-6  2:1.6.2-3
ii  libxml2   2.9.1+dfsg1-5+deb8u1
ii  libzip2   0.11.2-1.2
ii  mysql-workbench-data  6.2.3+dfsg-7
ii  python-mysql.connector1.2.3-2
ii  python-paramiko   1.15.1-1
ii  python-pexpect3.2-1
ii  python-pyodbc 3.0.6-2
ii  python-pysqlite2  2.6.3-3
ii  python2.7 2.7.9-2
pn  python:any

Versions of packages mysql-workbench recommends:
ii  mysql-client 5.5.47-0+deb8u1
ii  mysql-client-5.5 [virtual-mysql-client]  5.5.47-0+deb8u1
ii  mysql-utilities  1.3.5-2
ii  ttf-bitstream-vera   1.10-8

Versions of packages mysql-workbench suggests:
ii  gnome-keyring  3.14.0-1+b1

-- no debconf information

Bug#812087: [pcscd] takes 100 % cpu

[Ludovic Rousseau]

Le 30/03/2016 18:39, Eric Valette a écrit :

On 30/03/2016 17:51, Ludovic Rousseau wrote:

Le 29/03/2016 10:38, Eric Valette a écrit :



You are also using the Broadcom Corp 5880 reader.

For now people with the issue are using:
- Broadcom Corp 5880 0a5c/5800 (Eric) & (Johnny Ubuntu bug 1551897)
- Broadcom BCM5880 0a5c/5804 (Gustavo)
- Yubico Yubikey NEO U2F+CCID 1050/0115 (Philippe) & (Casey Ubuntu bug
1551897)

The Broadcom Corp 5880 0a5c/5800 and the Yubico Yubikey NEO U2F+CCID
1050/0115 both have only 1 CCID interface.
So the problem may not be related to a composite device.

What is the problem with the Broadcom and Yubico devices?
I should receive a Yubikey NEO device soon so I should be able to
reproduce the problem and work on it.


I'm affraid I'm lost. There is a BCM 5880 on my PC yes, that I never use. As my 
normal key is on a USB stick.

And the problem occurs when I'm plugin a regular USB mass storage key that is 
not by any mean a crypto keys. So I do not catch why the BCM 5880 could be the 
problem.

Could you explain a bit more.


I can't explain. I just note what is common in the different cases.
I have no idea what is wrong.

Bye

--
Dr. Ludovic Rousseau

Bug#819533: maim: please make the description clearer

[Patrick O'Doherty]

Thanks for the feedback folks. I'm planning to address this as follows:

* package slop - this is in progress at the moment
* cut a new release of maim with both an  updated description and also a
"Recommends: slop" addition.

p

Justin B Rye:
> Package: maim
> Followup-For: Bug #819533
> 
> Seconded.
> 
>> The synopsis has a typo, "screenshts". But I'm mainly filing a bug for
>> the extended description, which left me rather non-plussed; here's
>> what I'd like to find out without having to look at maim's web site:
>>
>> * is it command-line or GUI driven?
>> * what's slop? is it packaged in Debian?
>> * in what way is maim better than scrot?
> 
> Or indeed
>   * in what way is maim better than import (in imagemagick)?
> 
> There's a ruby-slop, but apparently you're talking about the slop that
> exists only on GitHub.  Looking at the upstream description leaves me
> wondering:
> 
>   * in what way is slop better than xwd (in x11-apps)?
> 

Bug#812087: [pcscd] takes 100 % cpu

[Eric Valette]

On 30/03/2016 17:51, Ludovic Rousseau wrote:

Le 29/03/2016 10:38, Eric Valette a écrit :

On 03/26/2016 02:01 PM, Ludovic Rousseau wrote:


In pcsc-lite 1.8.16 (that should arrive in Debian testing on Monday 28th
March 2016) I fixed a bug related to SCardCancel() and
SCardGetStatusChange().
Maybe that would fix the problem you have.


No it does not fix it


Please upgrade to pcsc-lite 1.8.16 and tell me if you still have the
problem or not?


Do you know what application is using pcscd?
To list all the applications using libpcsclite you can use:
$ sudo lsof /usr/lib/x86_64-linux-gnu/libpcsclite.so.1


lsof /usr/lib/x86_64-linux-gnu/libpcsclite.so.1
COMMAND PID USER  FD   TYPE DEVICE SIZE/OFFNODE NAME
SACSrv 1359 root memREG8,342848 1046702
/usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0
firefox-e 20538 ceva6380 memREG8,342848 1046702
/usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0



In addition here is the new log


Thanks

You are also using the Broadcom Corp 5880 reader.

For now people with the issue are using:
- Broadcom Corp 5880 0a5c/5800 (Eric) & (Johnny Ubuntu bug 1551897)
- Broadcom BCM5880 0a5c/5804 (Gustavo)
- Yubico Yubikey NEO U2F+CCID 1050/0115 (Philippe) & (Casey Ubuntu bug
1551897)

The Broadcom Corp 5880 0a5c/5800 and the Yubico Yubikey NEO U2F+CCID
1050/0115 both have only 1 CCID interface.
So the problem may not be related to a composite device.

What is the problem with the Broadcom and Yubico devices?
I should receive a Yubikey NEO device soon so I should be able to
reproduce the problem and work on it.


I'm affraid I'm lost. There is a BCM 5880 on my PC yes, that I never 
use. As my normal key is on a USB stick.


And the problem occurs when I'm plugin a regular USB mass storage key 
that is not by any mean a crypto keys. So I do not catch why the BCM 
5880 could be the problem.


Could you explain a bit more.

-- eric