Bug#817782: apticron: Anacron job 'cron.daily' error downloading files

[Norbert Schulz]

Hi Tiago,

the end of LTS for Debian squeeze will be the reason. The bug can be closed.

Thanks.

Norbert



Tiago Bortoletto Vaz schrieb:
> Hi Nobert,
> 
> On Thu, Mar 10, 2016 at 09:17:35AM +0100, Norbert Schulz wrote:
>> Package: apticron
>> Version: 1.1.42
>> Severity: normal
>>
>>
>> Since some days files for updating the system are not found:
>>
>> /etc/cron.daily/apticron:
>> W: error downloading  
>> http://http.debian.net/debian/dists/squeeze-lts/Release  Unable to find 
>> expected entry  main/binary-amd64/Packages in Meta-index file (malformed 
>> Release file?)
> 
> Maybe because of this: 
> https://www.decadent.org.uk/ben/blog/debian-lts-work-february-2016.html ?
> 
> Bests,
> 

Bug#761676: lvm2: lvs output format too long wraps on standard sized terminals

[Bob Proulx]

severity 761676 wishlist
thanks

Zdenek Kabelac wrote:
> Bob Proulx wrote:
> > Since the latest update the "lvs" command now emits output lines that
> > are so long that they wrap on standard sized terminals.
> 
> see the 'lvm.conf'report { compact_output = 1 }
> 
> I'd consider the problem as solved...
> Please close

Oh!  I had never heard of that option before.  I tried it.  It isn't
perfect but it is good enough.  Thank you very much for telling me
about that option!

It would be great if this were the default option.  And with that I
have converted this to a wishlist.  Please set compact_output=1 as the
default option so that it isn't required for everone to maintain a
locally modified lvm.conf file past package upgrades.

Thanks!
Bob

Bug#817862: Please document which packages this package can replace

[Timo Aaltonen]

11.03.2016, 06:42, Josh Triplett kirjoitti:
> Source: xserver-xorg-input-libinput
> Severity: wishlist
> 
> The driver in this package can replace the one in
> xserver-xorg-video-libinput, and xserver-xorg-video-mouse already
> shouldn't get used on current Linux systems.  However, does this package
> replace xserver-xorg-video-evdev, or should systems leave that package
> installed to handle certain types of devices?  Does
> xserver-xorg-video-libinput handle keyboards, or only mice?
> 
> Please consider expanding the description to document this.

" This package provides the driver for input devices using libinput library.
 It can handle keyboards, mice and touchpads, and essentially replaces the
 separate -evdev and -synaptics drivers."

something like that? Wacom support isn't done yet, that'll come later.


-- 
t

Bug#817871: haskell-mode: Could you package the latest version 13.18

[picca]

Package: haskell-mode
Version: 13.14.2-1
Severity: wishlist

Dear Maintainer,

Everythings i sin the title :)

thanks for your work

Frederic

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

Kernel: Linux 4.4.0-1-686 (SMP w/1 CPU core)
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 haskell-mode depends on:
ii  emacs46.1
ii  emacs24  24.5+1-6+b1

Versions of packages haskell-mode recommends:
ii  ghc  7.10.3-7

haskell-mode suggests no packages.

-- no debconf information

Bug#817870: openssh-server: GSSAPIKeyExchange is broken

[Gábor]

Package: openssh-server
Version: 1:7.2p2-1
Severity: normal

Dear Maintainer,

After upgrading to 7.2, GSSAPIKeyExchange no longer works:

debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1p2 Debian-2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 
Debian-1
debug1: match: OpenSSH_7.2p2 Debian-1 pat OpenSSH* compat 0x0400
debug1: Authenticating to host:22 as 'user'
debug1: Offering GSSAPI proposal: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==,gss-gex-sha1-bontcUwnM6aGfWCP21alxQ==,gss-group1-sha1-bontcUwnM6aGfWCP21alxQ==,gss-group14-sha1-bontcUwnM6aGfWCP21alxQ==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group1-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q==
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client chacha20-poly1...@openssh.com  none
debug1: kex: client->server chacha20-poly1...@openssh.com  none
debug1: Doing group exchange

debug1: Calling gss_init_sec_context
debug1: Delegating credentials
debug1: Received GSSAPI_COMPLETE
debug1: Calling gss_init_sec_context
debug1: Delegating credentials
Disconnecting: Hash's MIC didn't verify

Turning off GSSAPIKeyExchange allows me to log in. The other direction (7.2
client, 7.1 server) works as expected. The same version of Kerberos libraries
are used on both sides.

Gabor

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

Kernel: Linux 4.4.4 (SMP w/4 CPU cores; PREEMPT)
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 openssh-server depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.58
ii  dpkg   1.18.4
ii  init-system-helpers1.29
ii  libaudit1  1:2.4.5-1+b1
ii  libc6  2.22-2
ii  libcomerr2 1.42.13-1
ii  libgssapi-krb5-2   1.13.2+dfsg-5
ii  libkrb5-3  1.13.2+dfsg-5
ii  libpam-modules 1.1.8-3.2
ii  libpam-runtime 1.1.8-3.2
ii  libpam0g   1.1.8-3.2
ii  libselinux12.4-3+b1
ii  libssl1.0.21.0.2g-1
ii  libsystemd0229-2
ii  libwrap0   7.6.q-25
ii  lsb-base   9.20160110
ii  openssh-client 1:7.2p2-1
ii  openssh-sftp-server1:7.2p2-1
ii  procps 2:3.3.11-3
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages openssh-server recommends:
ii  ncurses-term  6.0+20160213-1
ii  xauth 1:1.0.9-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  rssh  
pn  ssh-askpass   
pn  ufw   

-- debconf information:
  openssh-server/permit-root-login: false

Bug#817847: AW: Re: Bug#817847: /usr/sbin/fai-make-nfsroot: Getting error at fai-setup -v : chmod: fehlender Operand nach "a+r"

[Thomas Lange]

> On Fri, 11 Mar 2016 07:16:37 +0100, Daniel Fischer  said:

> i already had done this.
Did you also add this line to /etc/fai/apt/sources.list?
   ^^^
-- 
regards Thomas

Bug#795492: New upstream series (soname 2.5), please package it

[Zhang Jingqiang]

Package: http-parser
Followup-For: Bug #795492

Still no activities?
The upstream URL now becomes https://github.com/nodejs/http-parser,
so it may be better to package this by the JS packaging team.


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

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

Bug#814456: RFS: pam-ufpidentity/1.0-1 [ITP] -- UFP Identity PAM Module

[Richard Levenberg]

New package has been uploaded to:
http://mentors.debian.net/package/pam-ufpidentity

with the following changes:
 * SINGLE changelog entry - Initial release (Closes: #813073)
 * same names for same names for copyright and upstream owner AND control
 * vcs stuff without ";a=summary"
 * Makefile: the clean target removes the library in the root directory
 * Makefile: removed useless test

Regarding the big problem (as mentioned in previous IRC chats):

All PAM libraries are installed to /lib//security NOT /usr/lib

All PAM librares are unversioned and their sonames also reflect that.
objdump -p /lib/i386-linux-gnu/security/pam_userdb.so  | grep SONAME
  SONAME   pam_userdb.so

It also seems that DEB_HOST_MULTIARCH is defined for dh_install
   dh_install
install -d debian/pam-ufpidentity/lib/i386-linux-gnu/security
cp -a ./pam_ufpidentity.so
debian/pam-ufpidentity/lib/i386-linux-gnu/security/

Thank you for your assistance. For testing please read the included
README.md in the upstream source.

Bug#817869: tortoisehg: uninstallable with current mercurial

[Julien Cristau]

Source: tortoisehg
Version: 3.6.2-1
Severity: serious

tortoisehg has:
Depends: mercurial (>= 3.5~), mercurial (<< 3.7~)
mercurial in sid is 3.7.2, making tortoisehg uninstallable.

Cheers,
Julien

Bug#817776: [aptitude] SIGABRT when quitting curses mode after unresolvable conflicts

[Katsuhiko Nishimra]

Hi, 

On Fri, Mar 11, 2016 at 01:56:21AM +, Manuel A. Fernandez Montecelo wrote:
> 2016-03-11 1:51 GMT+00:00 Katsuhiko Nishimra :
> >>
> >> The problem is that I cannot reproduce the situation by getting the
> >> "Resolve these dependencies by hand?", so I cannot test whether it
> >> worked or not.
> > Is the fixed package or the patch available?
> > If I can get it, I'll test it and report you a result.
> 
> Yes, it is:
> 
> https://anonscm.debian.org/cgit/aptitude/aptitude.git/commit/?id=63017db3cd7593b2494d77b3f220912df21ed738

I've confirmed the SIGABRT has gone after applying this patch.

Many thanks to your resolution.

Regards,
Katsuhiko

Bug#806824: (no subject)

[Michael Biebl]

Am 11.03.2016 um 00:27 schrieb Barry Warsaw:
> On Mar 11, 2016, at 12:20 AM, Michael Biebl wrote:
> 
>> Tbh, I'm not too thrilled by hard-coding dependencies on
>> libpeas-1.0-0-python3loader in several packages.
> 
> Can you explain why?

It creates unnecessary churn and potential stale dependencies in the future.
Most importantly, this split looks like an implementation detail to me.
I don't see, why packages should add a dependency on
libpeas-1.0-0-python3loader but not libpeas-1.0-0-python2loader

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



signature.asc
Description: OpenPGP digital signature

Bug#816294: slapd segfault on update dbconfig

[Ryan Tandy]

Control: tag -1 upstream

On Thu, Mar 10, 2016 at 09:22:43PM -0800, Ryan Tandy wrote:

It looks non-trivial...


That is, it's not just a matter of a missing NULL check - I'm not sure what
syncprov_checkpoint is supposed to do in this situation.


0x7fffefac8929 in hdb_modify (op=0x7fffde00, rs=0x7fffdd90) at 
modify.c:555


Same thing with upstream git sources, RE24 and master, on unstable.

0x004e2408 in hdb_modify (op=0x7fffd9c0, rs=0x7fffd950) at 
modify.c:522
522 rs->sr_err = TXN_BEGIN( bdb->bi_dbenv, NULL, , 
tflags );
(gdb) bt
#0  0x004e2408 in hdb_modify (op=0x7fffd9c0, rs=0x7fffd950) at 
modify.c:522
#1  0x0053bddd in syncprov_checkpoint (op=0x7fffdeb0, on=0x90e390) 
at syncprov.c:1495
#2  0x00541910 in syncprov_db_close (be=0x9088d0, cr=0x0) at 
syncprov.c:3237
#3  0x004ba0e8 in over_db_close (be=0x9088d0, cr=0x0) at backover.c:180
#4  0x0043ca4d in backend_shutdown (be=0x9088d0) at backend.c:383
#5  0x00468d06 in slap_shutdown (be=0x0) at init.c:233
#6  0x00405bba in main (argc=9, argv=0x7fffe548) at main.c:1028

I do not see it with 2.4.31, though, so that gives me a basis to try 
bisecting...

Bug#817868: mirror submission for mirror.satellite-service.ru

[Maksim Sobyanin]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.satellite-service.ru
Type: leaf
Archive-architecture: amd64 i386 
Archive-ftp: /debian/
Archive-http: /debian/
IPv6: no
Archive-upstream: ftp.de.debian.org
Updates: four
Maintainer: Maksim Sobyanin 
Country: RU Russian Federation
Location: Berezniki, Perm region

Bug#816294: slapd segfault on update dbconfig

[Ryan Tandy]

Control: tag -1 confirmed
Control: found -1 2.4.42+dfsg-2

On Tue, Mar 01, 2016 at 01:58:43PM +0100, Thomas Otto wrote:

service slapd stop
rm -f /var/lib/ldap/*/*
service slapd start

... (wait some time) ...

ldapmodify ...

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcDbConfig
olcDbConfig: set_cachesize 3 0 1
olcDbConfig: set_lk_max_locks   2
olcDbConfig: set_lk_max_objects 1
olcDbConfig: set_lk_max_lockers 1500

modifying entry "olcDatabase={2}hdb,cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
additional info: failed to reopen database, rc=22


I started slapd with debug output and attach this ...

I Attach also a filterd config ...


Thank you. Reproduced using your config and the ldapmodify above.

0x7fffefac8929 in hdb_modify (op=0x7fffde00, rs=0x7fffdd90) at 
modify.c:555
555 modify.c: No such file or directory.
(gdb) bt
#0  0x7fffefac8929 in hdb_modify (op=0x7fffde00, rs=0x7fffdd90) at 
modify.c:555
#1  0x71a266c2 in syncprov_checkpoint (op=0x7fffe500, on=, 
on=)
   at ../../../../../servers/slapd/overlays/syncprov.c:1467
#2  0x71a268ec in syncprov_db_close (be=0x559b78c0, cr=)
   at ../../../../../servers/slapd/overlays/syncprov.c:3170
#3  0x555fc208 in over_db_close (be=0x559b78c0, cr=0x0) at 
../../../../servers/slapd/backover.c:176
#4  0x5559bf7b in backend_shutdown (be=0x559b78c0) at 
../../../../servers/slapd/backend.c:376
#5  0x5557272a in main (argc=, argv=) at 
../../../../servers/slapd/main.c:1022

modify.c:555 is:

   rs->sr_err = TXN_BEGIN( bdb->bi_dbenv, NULL, ,
   bdb->bi_db_opflags );

and TXN_BEGIN is:

#define TXN_BEGIN(env,p,t,f)(env)->txn_begin((env), p, t, f)

but:

(gdb) p bdb->bi_dbenv
$4 = (DB_ENV *) 0x0

On a simpler setup, just a single hdb database with the syncprov overlay 
added, I also get a crash, but with a different signature:


#0  __txn_abort_pp (txn=0x55aad940) at ../src/txn/txn.c:1022
#1  0x77996b6f in ldap_pvt_thread_pool_context_reset (vctx=0x77bd5580 
)
   at ../../../../libraries/libldap_r/tpool.c:1020
#2  0x555bc01c in slap_destroy () at 
../../../../servers/slapd/init.c:248
#3  0x55570d79 in main (argc=11, argv=) at 
../../../../servers/slapd/main.c:1034

I'm not sure what's in between #0 and #1 there - maybe bdb_reader_free.

Anyway: at this point, upstream considers the BDB and HDB backends EOL, 
provided for the convenience of existing users, but not really 
maintained any more; migrating to the new LMDB backend is encouraged.  
I'll see what I can do, but I have to warn you that I'm not optimistic 
about actually getting this fixed. It looks non-trivial...

Bug#811780: tinymux: FTBFS with GCC 6: narrowing conversion

[Stephen Dennis]

Looking forward to more packaging. Maybe become a Debian maintainer one day
if I can afford the time.
On Mar 10, 2016 7:39 PM, "Martin Michlmayr"  wrote:

> * Stephen Dennis  [2016-03-10 19:47]:
> > I'll keep trying to upload it, but all four of the files are removed.
> They
> > weren't part of the debian/patches/series file anyway. It was all cruft.
>
> Ok, it's fine.  I can run 'rm' myself.  Thanks for your patience.
>
> And thanks for fixing these issues!
>
> --
> Martin Michlmayr
> Linux for HPE Helion, Hewlett Packard Enterprise
>

Bug#817867: nvidia-graphics-drivers: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Package: nvidia-graphics-drivers
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#817864: redmine: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Source: redmine
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#817866: colplot: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Package: colplot
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#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt

[Peter Colberg]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I hope you are now as delighted as I was to finally reap the fruits of
your labour, after having waded through all the dependent packages.

I am looking for a sponsor for the package "acmetool":

  git clone https://anonscm.debian.org/git/pkg-go/packages/acmetool.git

  cd acmetool && pristine-tar checkout ../acmetool_0.0.49.orig.tar.gz

For verification, these are the current branch heads:

  git show-ref --heads
  8ae9df6d4dd330b269303b44c6b9c9f6bc3f5ce9 refs/heads/master
  7ebb219ff2f4fe4cabc603ef2f4e5155b041c772 refs/heads/pristine-tar
  1d8a3d99536b3472709a4b184afbdc8b10ebc2f6 refs/heads/upstream

It builds these binary packages:

  acmetool -- automatic certificate acquisition tool for Let's Encrypt

More information about acmetool can be obtained from

https://hlandau.github.io/acme

If you decide to sponsor this package, please change the distribution
from UNRELEASED to unstable before upload. I will import the uploaded
source package into the git repository and push a tag afterwards.

Regards,
Peter

Bug#817863: RFS: android-platform-system-core/1:6.0.1+r16-3

[殷啟聰]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "android-platform-system-core"

* Package name: android-platform-system-core
  Version : 1:6.0.1+r16-3
  Upstream Author : The Android Open Source Project
* URL : https://android.googlesource.com/platform/system/core
* License : Apache-2.0
  Section : devel

  It builds those binary packages:

adb   - Android Debug Bridge
 android-libadb - Library for Android Debug Bridge
 android-libadb-dev - Library for Android Debug Bridge - Development files
 android-libbacktrace - Android backtrace library
 android-libbacktrace-dev - Android backtrace library - Development files
 android-libbase - Android base library
 android-libbase-dev - Android base library - Development files
 android-libcutils - Android utils library for C
 android-libcutils-dev - Android utils library for C - Development files
 android-liblog - Android NDK logger interfaces
 android-liblog-dev - Android NDK logger interfaces - Development files
 android-libsparse - Android Sparse library
 android-libsparse-dev - Android Sparse library - Development files
 android-libutils - Android Utility Function Library
 android-libutils-dev - Android Utility Function Library - Development files
 android-libziparchive - Android zip archive library
 android-libziparchive-dev - Android zip archive library - Development files
 android-libzipfile - Transitional dummy package
 android-libzipfile-dev - Transitional dummy package
 android-platform-system-core-headers - Shared headers in AOSP
repository platform/system/core
 fastboot   - Android fastboot tool

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

  http://mentors.debian.net/package/android-platform-system-core


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

dget -x 
http://mentors.debian.net/debian/pool/main/a/android-platform-system-core/android-platform-system-core_6.0.1+r16-3.dsc

  More information about hello can be obtained from http://www.example.com.

  Changes since the last upload:

  * Fix package name typo: android-{zipfile=>libzipfile}(-dev)


  Regards,
   Kai-Chung Yan


-- 
/*
* 殷啟聰 | Kai-Chung Yan
* 一生只向真理與妻子低頭
* Undergraduate student in National Taichung University of Education
* LinkedIn: 
* Blog: 
*/

Bug#817862: Please document which packages this package can replace

[Josh Triplett]

Source: xserver-xorg-input-libinput
Severity: wishlist

The driver in this package can replace the one in
xserver-xorg-video-libinput, and xserver-xorg-video-mouse already
shouldn't get used on current Linux systems.  However, does this package
replace xserver-xorg-video-evdev, or should systems leave that package
installed to handle certain types of devices?  Does
xserver-xorg-video-libinput handle keyboards, or only mice?

Please consider expanding the description to document this.

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

Kernel: Linux 4.5.0-rc7-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#817008: unfulfilled dependencies

[殷啟聰]

I am confident that 24.3.3+2 solved the bug, but I prefer to wait for
the package getting accepted. Just want to be cautious :)

Bug#817861: eviacam: [INTL:ja] Japanese debconf templates translation

[Takuma Yamada]

Package: eviacam
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#817782: apticron: Anacron job 'cron.daily' error downloading files

[Tiago Bortoletto Vaz]

Hi Nobert,

On Thu, Mar 10, 2016 at 09:17:35AM +0100, Norbert Schulz wrote:
> Package: apticron
> Version: 1.1.42
> Severity: normal
> 
> 
> Since some days files for updating the system are not found:
> 
> /etc/cron.daily/apticron:
> W: error downloading  http://http.debian.net/debian/dists/squeeze-lts/Release 
>  Unable to find expected entry  main/binary-amd64/Packages in Meta-index file 
> (malformed Release file?)

Maybe because of this: 
https://www.decadent.org.uk/ben/blog/debian-lts-work-february-2016.html ?

Bests,

-- 
tiago

Bug#811780: tinymux: FTBFS with GCC 6: narrowing conversion

[Martin Michlmayr]

* Stephen Dennis  [2016-03-10 19:47]:
> I'll keep trying to upload it, but all four of the files are removed. They
> weren't part of the debian/patches/series file anyway. It was all cruft.

Ok, it's fine.  I can run 'rm' myself.  Thanks for your patience.

And thanks for fixing these issues!

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#811195: Tip

[Diederik de Haas]

On donderdag 10 maart 2016 20:00:32 CET Lisandro Damián Nicanor Pérez Meyer 
wrote:
> I'm being told that /etc/X11/xinit/xinitrc.d/ comes from Fedora and it
> seems  Debian will not source it from there. We need to put it in some
> other place.

Looks like /etc/X11/Xsession.d/ has various similar scripts and a variable 
defined in at least 1 of them is available in my current session.

Bug#817860: python-autopep8: /usr/bin/autopep8 appears to be useless without python-pep8 installed

[Clint Adams]

Package: python-autopep8
Version: 0.9.1-2

Traceback (most recent call last):
  File "/usr/bin/autopep8", line 5, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3138, 
in 
@_call_aside
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3124, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3151, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 661, 
in _build_master
ws.require(__requires__)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 962, 
in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 849, 
in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pep8>=1.4.5' distribution was not 
found and is required by autopep8

Bug#817816: System freeze with CPU hotplug

[Ben Hutchings]

Control: reopen -1
Control: severity -1 normal

On Fri, 2016-03-11 at 01:12 +0100, Harry Junior wrote:
> On Thu, 10 Mar 2016 17:34:54 + Ben Hutchings  wrote:
> > 
> > On Thu, 2016-03-10 at 17:32 +0100, Harry Junior wrote:
> > > 
> > > Package: linux-image-4.4.0-1-amd64
> > > Version: 4.4.4-1
> > > Severity: critical
> > > Justification: renders system unusable
> > > 
> > > 
> > > When I run the following commands, the system freezes:
> > > 
> > > # echo 0 | tee /sys/devices/system/cpu/cpu*/online && echo 1 | sudo
> > > tee /sys/devices/system/cpu/cpu*/online
> > > 
> > > The system freezes randomly when the CPUs are being onlined or
> > > offlined. The system is installed on a VMware virtual machine with 4
> > > processors. Here's a stacktrace of the infinite loop:
> > [...]
> > 
> > You just asked to offline all CPUs, making the system unusable. Â I
> > don't see any bug here.
> I'm sorry to disagree, but the CPU0 can't be offlined and remains online:
[...]

Depending on the configuration, it may be possible to offline CPU0.
However, I have been informed that the kernel still prevents offlining
the last CPU - or at least it is supposed to.

So I'm reopening this, but correcting the severity.  ("renders system
unusable" does *not* mean the system hangs or crashes, it means the
system becomes unbootable or otherwise persistently broken.)

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

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

Bug#811780: tinymux: FTBFS with GCC 6: narrowing conversion

[Stephen Dennis]

I'll keep trying to upload it, but all four of the files are removed. They
weren't part of the debian/patches/series file anyway. It was all cruft.

On Thu, Mar 10, 2016 at 7:38 PM, Stephen Dennis 
wrote:

> 403 forbidden
> On Mar 10, 2016 7:38 PM, "Martin Michlmayr"  wrote:
>
>> * Stephen Dennis  [2016-03-10 19:31]:
>> > Removed that cruft and re-submitted package.
>>
>> I don't see it yet but maybe it just takes some time.
>>
>> --
>> Martin Michlmayr
>> Linux for HPE Helion, Hewlett Packard Enterprise
>>
>

Bug#800242: hearse: Please migrate a supported debhelper compat level

[James Cowgill]

Control: tags -1 pending
Control: tags 290937 patch pending
Control: tags 816952 pending

Hi,

I have uploaded an NMU to fix this bug (#800242), the 64-bit support
bug (#290937) and the brazillian debconf translations bug (#816952) to
DELAYED/10.

Please tell me if you want it cancelled / delayed longer.

The NMU is attached.

Thanks,
Jamesdiff -u hearse-1.5/debian/changelog hearse-1.5/debian/changelog
--- hearse-1.5/debian/changelog
+++ hearse-1.5/debian/changelog
@@ -1,3 +1,16 @@
+hearse (1.5-8.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to debhelper compat 9. (Closes: #800242)
+  * Add support for 64-bit platforms. (Closes: #290937) (LP: #591773)
+Thanks to PJ Weisberg for the patch.
+  * Add Brazilian Portuguese debconf translations. (Closes: #816952)
+  * Small packaging cleanups:
+- Add support for the build-arch and build-indep targets.
+- Replace obsolete call to dh_clean -k with dh_prep.
+
+ -- James Cowgill   Fri, 11 Mar 2016 02:27:51 +
+
 hearse (1.5-8.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u hearse-1.5/debian/control hearse-1.5/debian/control
--- hearse-1.5/debian/control
+++ hearse-1.5/debian/control
@@ -3,11 +3,11 @@
 Priority: optional
 Maintainer: Roderick Schertler 
 Standards-Version: 3.7.2
-Build-Depends: debhelper (>= 4.1.68), perl (>= 5.6.0-16), po-debconf
+Build-Depends: debhelper (>= 9), perl (>= 5.6.0-16), po-debconf
 
 Package: hearse
 Architecture: all
-Depends: debconf (>= 1.2.0) | debconf-2.0, ${perl:Depends}, libwww-perl, nethack-common | nethack
+Depends: debconf (>= 1.2.0) | debconf-2.0, ${perl:Depends}, libwww-perl, nethack-common | nethack, ${misc:Depends}
 Description: exchange Nethack bones files with other players
  Nethack sometimes saves the level on which you die (including your
  stuff, what killed you, and your ghost) in a "bones file".  These files
diff -u hearse-1.5/debian/rules hearse-1.5/debian/rules
--- hearse-1.5/debian/rules
+++ hearse-1.5/debian/rules
@@ -11,10 +11,11 @@
 ifneq "" "$(findstring debug,$(DEB_BUILD_OPTIONS))"
 CFLAGS		+= -g
 endif
-export DH_COMPAT	:= 3
 PERL			?= perl
 
-build: $(stamp_build)
+build: build-arch build-indep
+build-arch:
+build-indep: $(stamp_build)
 $(stamp_build):
 	dh_testdir
 	$(PERL) Makefile.PL INSTALLDIRS=vendor
@@ -26,7 +27,7 @@
 $(stamp_install): $(stamp_build)
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 	$(MAKE) install DESTDIR=$(prefix)
 	cp hearse.conf $(dt)/etc/nethack
diff -u hearse-1.5/hearse hearse-1.5/hearse
--- hearse-1.5/hearse
+++ hearse-1.5/hearse
@@ -754,26 +754,6 @@
 	return;
 }
 
-# The 4 version numbers are stored by Nethack as 4 unsigned longs
-# in host byte order at the start of the file.  I don't want to
-# read them in host order, though, because that would mask byte sex
-# differences between platforms.
-#
-# If the platform's longs aren't 4 bytes, though, I've got a
-# separate problem.  I need to read the right number of bytes
-# else I'll only get part of the version data, and what I do get
-# will end up in the wrong places.  I test for this using Perl
-# 5.6's 'L!' pack format (and just hope for the best for earlier
-# versions).  I haven't actually written the code to deal with
-# this case yet (it needs special handling because there's no
-# format to read a native-sized long but with a specific byte
-# order), I just detect it and choke.
-
-my $ulong_size = eval { length pack 'L!', 0 } || 4;	# punt for Perl < 5.6
-if ($ulong_size != 4) {
-	xdie "size of unsigned long is $ulong_size rather than 4\n";
-}
-
 # struct version_info {
 # unsigned long   incarnation;/* actual version number */
 # unsigned long   feature_set;/* bitmask of config settings */
@@ -781,7 +761,7 @@
 # unsigned long   struct_sizes;   /* size of key structs */
 # };
 
-@version = unpack 'V' x HEADER_VERSION_COUNT, $data;
+@version = unpack 'L!<' x HEADER_VERSION_COUNT, $data;
 if (@version != HEADER_VERSION_COUNT) {
 	xwarn "$open_spec is too short (", length($data), ")\n";
 	return;
only in patch2:
unchanged:
--- hearse-1.5.orig/debian/compat
+++ hearse-1.5/debian/compat
@@ -0,0 +1 @@
+9
only in patch2:
unchanged:
--- hearse-1.5.orig/debian/po/pt_BR.po
+++ hearse-1.5/debian/po/pt_BR.po
@@ -0,0 +1,56 @@
+# Debconf translations for hearse.
+# Copyright (C) 2016 THE hearse'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the hearse package.
+# Adriano Rafael Gomes , 2016.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: hearse 1.5-8.2\n"
+"Report-Msgid-Bugs-To: hea...@packages.debian.org\n"
+"POT-Creation-Date: 2009-12-22 08:53-0500\n"
+"PO-Revision-Date: 2016-02-09 23:05-0200\n"
+"Last-Translator: Adriano Rafael Gomes \n"
+"Language-Team: Brazilian Portuguese 

Bug#811780: tinymux: FTBFS with GCC 6: narrowing conversion

[Martin Michlmayr]

* Stephen Dennis  [2016-03-10 19:31]:
> Removed that cruft and re-submitted package.

I don't see it yet but maybe it just takes some time.

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#811780: tinymux: FTBFS with GCC 6: narrowing conversion

[Stephen Dennis]

403 forbidden
On Mar 10, 2016 7:38 PM, "Martin Michlmayr"  wrote:

> * Stephen Dennis  [2016-03-10 19:31]:
> > Removed that cruft and re-submitted package.
>
> I don't see it yet but maybe it just takes some time.
>
> --
> Martin Michlmayr
> Linux for HPE Helion, Hewlett Packard Enterprise
>

Bug#811780: tinymux: FTBFS with GCC 6: narrowing conversion

[Stephen Dennis]

Removed that cruft and re-submitted package.

On Thu, Mar 10, 2016 at 7:10 PM, Stephen Dennis 
wrote:

> Oh, all that cruft got through. Tried the templates. Didn't work. Need
> them now.
>
> At the airport. Will touch tonight.
> On Mar 10, 2016 7:07 PM, "Martin Michlmayr"  wrote:
>
>> * Stephen Dennis  [2016-03-10 18:07]:
>> > * I did not add dh-autoreconf because as you say, the root problem is a
>> > config.{sub,guess} was stale. Unfortunately, there is code in
>> autoconf.h.in
>> > from a previous autoconf.h file which running autoreconf would step on.
>>
>> Ah, I see.  But if you're not running the tool, why do you close the
>> bug?  Oh, because you say that the autoconf scripts have been updated
>> in the tar ball.
>>
>> > * Yeah, 2.10 is out there and it works well. The problems like
>> autoconf.h.in
>>
>> Ok, makes sense.
>>
>> Anyway, in the new version, we now have:
>>
>> tinymux-2.6.5.34/debian/autoreconf.after
>> tinymux-2.6.5.34/debian/autoreconf.before
>> tinymux-2.6.5.34/debian/patches/deleteme
>>
>> which looks like cruft to me.
>>
>> Also, is tinymux-2.6.5.34/debian/patches/autoreconf-templates.diff
>> necessary and if so do you need to build-depend on something?
>> --
>> Martin Michlmayr
>> Linux for HPE Helion, Hewlett Packard Enterprise
>>
>

Bug#811780: tinymux: FTBFS with GCC 6: narrowing conversion

[Stephen Dennis]

Oh, all that cruft got through. Tried the templates. Didn't work. Need them
now.

At the airport. Will touch tonight.
On Mar 10, 2016 7:07 PM, "Martin Michlmayr"  wrote:

> * Stephen Dennis  [2016-03-10 18:07]:
> > * I did not add dh-autoreconf because as you say, the root problem is a
> > config.{sub,guess} was stale. Unfortunately, there is code in
> autoconf.h.in
> > from a previous autoconf.h file which running autoreconf would step on.
>
> Ah, I see.  But if you're not running the tool, why do you close the
> bug?  Oh, because you say that the autoconf scripts have been updated
> in the tar ball.
>
> > * Yeah, 2.10 is out there and it works well. The problems like
> autoconf.h.in
>
> Ok, makes sense.
>
> Anyway, in the new version, we now have:
>
> tinymux-2.6.5.34/debian/autoreconf.after
> tinymux-2.6.5.34/debian/autoreconf.before
> tinymux-2.6.5.34/debian/patches/deleteme
>
> which looks like cruft to me.
>
> Also, is tinymux-2.6.5.34/debian/patches/autoreconf-templates.diff
> necessary and if so do you need to build-depend on something?
> --
> Martin Michlmayr
> Linux for HPE Helion, Hewlett Packard Enterprise
>

Bug#811780: tinymux: FTBFS with GCC 6: narrowing conversion

[Martin Michlmayr]

* Stephen Dennis  [2016-03-10 18:07]:
> * I did not add dh-autoreconf because as you say, the root problem is a
> config.{sub,guess} was stale. Unfortunately, there is code in autoconf.h.in
> from a previous autoconf.h file which running autoreconf would step on.

Ah, I see.  But if you're not running the tool, why do you close the
bug?  Oh, because you say that the autoconf scripts have been updated
in the tar ball.

> * Yeah, 2.10 is out there and it works well. The problems like autoconf.h.in

Ok, makes sense.

Anyway, in the new version, we now have:

tinymux-2.6.5.34/debian/autoreconf.after
tinymux-2.6.5.34/debian/autoreconf.before
tinymux-2.6.5.34/debian/patches/deleteme

which looks like cruft to me.

Also, is tinymux-2.6.5.34/debian/patches/autoreconf-templates.diff
necessary and if so do you need to build-depend on something?
-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#817776: [aptitude] SIGABRT when quitting curses mode after unresolvable conflicts

[Manuel A. Fernandez Montecelo]

2016-03-11 1:51 GMT+00:00 Katsuhiko Nishimra :
>>
>> The problem is that I cannot reproduce the situation by getting the
>> "Resolve these dependencies by hand?", so I cannot test whether it
>> worked or not.
> Is the fixed package or the patch available?
> If I can get it, I'll test it and report you a result.

Yes, it is:

https://anonscm.debian.org/cgit/aptitude/aptitude.git/commit/?id=63017db3cd7593b2494d77b3f220912df21ed738


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#817776: [aptitude] SIGABRT when quitting curses mode after unresolvable conflicts

[Katsuhiko Nishimra]

Hi,

On Thu, Mar 10, 2016 at 11:33:55AM +, Manuel A. Fernandez Montecelo wrote:
> 
> I think that I solved the problem in a similar way as the other one.
Great, thank you for your quick fix.
> 
> The problem is that I cannot reproduce the situation by getting the
> "Resolve these dependencies by hand?", so I cannot test whether it
> worked or not.
Is the fixed package or the patch available?
If I can get it, I'll test it and report you a result.
> 
> I forcibly install and remove some packages with dpkg to conflict with
> installed ones, and then do a variety of actions (upgrades, purges etc;
> of important packages such as libc6 or systemd), using full resolver,
> safe resolver, enabling and disabling auto-fix-broken... but in all
> cases, either I get the typical prompt "Accept solution?" or the
> resolver spends lots and lots of time (> 10 minutes) trying to solve the
> problem without offering me to resolve by hand.
> 
> I cannot to afford at this moment to try too hard and risk breaking the
> system for real, so it would be very nice if you (or other readers)
> could check if this indeeds solves the situation in the next release and
> report back whether it worked or not -- I am quite confident that it
> does, so marking as +pending.
> 
> 
> ... and thanks for the detailed reports and persistence, in any case!
> 
> 
> Cheers.
> -- 
> Manuel A. Fernandez Montecelo 

Regards,
Katsuhiko

Bug#817811: qgis: FTBFS when built with dpkg-buildpackage -A (dh_install: missing files)

[Sebastiaan Couwenberg]

Control: tags - pending

Hi Santiago,

On 10-03-16 16:23, Santiago Vila wrote:
> I tried to build this package with "dpkg-buildpackage -A"
> (i.e. only architecture-independent packages), and it failed:

Thank for reporting this issue. The fixed qgis package will soon be
available in unstable.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#817857: util-linux: Depends/Breaks loop with Essential packages prevents upgrade from Jessie

[Ben Bailess]

I am seeing the same behavior. Just installed fresh from netinst today, and
tried to dist-upgrade to stretch (with the expectation I'd be moving to
sid after another reboot + dist-upgrade) and I hit the dep loop as
described above.

Tried going straight from Jessie --> sid too but ran into same error and
cannot proceed (thinking perhaps the fix had hit Sid but not stretch).

Thanks for th effort to fix.

Ben

Bug#807996: apt: "apt-get update" gives 'repository cdrom://... does not have a Release file' warning

[Igor Liferenko]

This bug report may be closed.

Bug#817859: gnutls-bin: man page formatting problems

[Alan Curry]

Package: gnutls-bin
Version: 3.3.8-6+deb8u3
Severity: minor

The man pages have some spurious "Fl"s in them. For example, in
gnutls-cli(1), one of the options appears to be:

   --tofu, - Fl -no-tofu

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

Kernel: Linux 4.3.3+ (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gnutls-bin depends on:
ii  libc6  2.19-18+deb8u3
ii  libgmp10   2:6.0.0+dfsg-6
ii  libgnutls-deb0-28  3.3.8-6+deb8u3
ii  libhogweed22.7.1-5
ii  libidn11   1.29-1+b2
ii  libnettle4 2.7.1-5
ii  libopts25  1:5.18.4-3
ii  libp11-kit00.20.7-1
ii  libtasn1-6 4.2-3+deb8u1
ii  zlib1g 1:1.2.8.dfsg-2+b1

gnutls-bin recommends no packages.

gnutls-bin suggests no packages.

-- no debconf information

Bug#811780: tinymux: FTBFS with GCC 6: narrowing conversion

[Stephen Dennis]

*Hahahah. I completely glossed over the template text. I
assumed the tool brought in just the bug titles. I have now changed
debian/changelog to describe what was changed.

* I changed debian/changelog to remove the duplicate issue.

* I did not add dh-autoreconf because as you say, the root problem is a
config.{sub,guess} was stale. Unfortunately, there is code in autoconf.h.in
from a previous autoconf.h file which running autoreconf would step on.

* Added 'New upstream release' in debian/changelog

* Yeah, 2.10 is out there and it works well. The problems like autoconf.h.in
describe above have been worked out. I'll be targeting that version next.
Two main reasons for not targeting it now: 1) I'm doing a NMU, I'm
learning, refreshing my memory, and I didn't want a large change, and 2)
TinyMUX 2.6 is the last version to be ASCII-only. Starting with TinyMUX
2.7, Unicode, modules, and SQL support appear. Before I was willing to
release that on Debian, I wanted either code mileage or the ability to
affect changes to the package quickly.

* You didn't ask, but the static PCRE3 has also been updated in later
versions. It's just too much change to take in 2.6, and there are these
other more pressing problems.

On Thu, Mar 10, 2016 at 4:47 PM, Martin Michlmayr  wrote:

> * Stephen Dennis  [2016-03-10 12:18]:
> > Trying my hand at the package because I think Noltar has moved on:
> >
> > http://mentors.debian.net/package/tinymux
>
> I have some questions and comments:
>
> * debian/changelog says "" multiple
> times.  I think you forgot to remove that.
>
> * Fix "use autotools-dev.." and Fix "run dh-autoreconf.." are actually
> the same thing, so don't list them separate.  Just list them once and
> close both bugs -- in fact, I just merged the bugs into one so just
> close the one.
>
> * It seems you didn't actually add dh-autoreconf anywhere?
>
> * Please mention "New upstream release" in the changelog (in the last
> after NMU).
>
> * I see upstream is at 2.10 now?  Why not 2.10?  Because this is a NMU
> and you want minimal changes?
>
> --
> Martin Michlmayr
> Linux for HPE Helion, Hewlett Packard Enterprise
>

Bug#817858: gnupg: tsign domain not documented

[Clint Adams]

Package: gnupg
Version: 1.4.18-7

When doing a 'tsign' in --edit-key, gpg says

Please enter a domain to restrict this signature, or enter for none.

The meaning of this does not appear to be documented.

Bug#812540: Add ARCH_HISI for Lemaker HiKey support

[Martin Michlmayr]

* Ian Campbell  [2016-01-25 09:57]:
> > Please enable it so we can add HiKey support to Debian.
> 
> I suppose it will need more than just ARCH_HISI. Are you able to identify
> the full set of options (e.g. drivers and such) which are needed to make
> useful Lemaker support? If so I'd appreciate it (if not I can probably try
> and dig those out myself, but it might take me a while to around to it).

This might be a good starting point:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1098644.html

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#817847: /usr/sbin/fai-make-nfsroot: Getting error at fai-setup -v : chmod: fehlender Operand nach "a+r"

[Thomas Lange]

> On Thu, 10 Mar 2016 22:56:47 +0100, Daniel Fischer  said:

> when i try to run fai-setup -v so i get first the error, that 
dracut-config-gernic package is not found. So i had remove it in 
/usr/sbin/fai-make-nfsroot
> then i get the error, described in the subject. Does anybody know why?

Please add the package repository of the fai project to your
sources.list files as described in http://fai-project.org/download/

-- 
regards Thomas

Bug#817857: util-linux: Depends/Breaks loop with Essential packages prevents upgrade from Jessie

[Josh Triplett]

Package: util-linux
Version: 2.27.1-5
Severity: serious

Even with util-linux 2.27.1-5, I still hit a dependency loop that caused
apt to refuse to proceed:

util-linux 2.27.1-5 Depends on init-system-helpers (>= 1.29~)
init-system-helpers 1.29 Breaks sysvinit-utils (< 2.88dsf-59.3~)
sysvinit-utils 2.88dsf-59.3 Breaks util-linux (< 2.26.2-3)

sysvinit-utils and util-linux are both Essential.

Result:

~$ sudo apt install util-linux
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  init-system-helpers libfdisk1 sysvinit-utils
Suggested packages:
  bootlogd sash dosfstools kbd | console-tools util-linux-locales
The following NEW packages will be installed:
  libfdisk1
The following packages will be upgraded:
  init-system-helpers sysvinit-utils util-linux
3 upgraded, 1 newly installed, 0 to remove and 11 not upgraded.
Need to get 0 B/1198 kB of archives.
After this operation, 930 kB of additional disk space will be used.
Do you want to continue? [Y/n]
E: This installation run will require temporarily removing the essential 
package sysvinit-utils:amd64 due to a Conflicts/Pre-Depends loop. This is often 
bad, but if you really want to do it, activate the APT::Force-LoopBreak option.
E: Internal Error, Could not early remove sysvinit-utils:amd64 (2)

Bug#817816: System freeze with CPU hotplug

[Harry Junior]

On Thu, 10 Mar 2016 17:34:54 + Ben Hutchings  wrote:
> On Thu, 2016-03-10 at 17:32 +0100, Harry Junior wrote:
>> Package: linux-image-4.4.0-1-amd64
>> Version: 4.4.4-1
>> Severity: critical
>> Justification: renders system unusable
>> 
>> 
>> When I run the following commands, the system freezes:
>> 
>> # echo 0 | tee /sys/devices/system/cpu/cpu*/online && echo 1 | sudo
>> tee /sys/devices/system/cpu/cpu*/online
>> 
>> The system freezes randomly when the CPUs are being onlined or
>> offlined. The system is installed on a VMware virtual machine with 4
>> processors. Here's a stacktrace of the infinite loop:
> [...]
> 
> You just asked to offline all CPUs, making the system unusable. Â I
> don't see any bug here.

I'm sorry to disagree, but the CPU0 can't be offlined and remains online:

$ ls -l /sys/devices/system/cpu/ | grep cpu | head -4
drwxr-xr-x 6 root root0 Mar 10 18:41 cpu0
drwxr-xr-x 6 root root0 Mar 10 18:41 cpu1
drwxr-xr-x 6 root root0 Mar 10 18:41 cpu2
drwxr-xr-x 6 root root0 Mar 10 18:41 cpu3

$ ls -l /sys/devices/system/cpu/cpu*/online
-rw-r--r-- 1 root root 4096 Mar 10 18:40 /sys/devices/system/cpu/cpu1/online
-rw-r--r-- 1 root root 4096 Mar 10 18:40 /sys/devices/system/cpu/cpu2/online
-rw-r--r-- 1 root root 4096 Mar 10 18:40 /sys/devices/system/cpu/cpu3/online

  

Bug#817856: ITP: pythonpy -- 'python -c', with tab completion and shorthand

[Tiago Ilieve]

Package: wnpp
Severity: wishlist
Owner: Tiago Ilieve 

* Package name: pythonpy
  Version : 0.4.4
  Upstream Author : Russell Stewart 
* URL : https://github.com/Russell91/pythonpy
* License : MIT
  Programming Lang: Python
  Description : 'python -c', with tab completion and shorthand

pythonpy is an utility that facilitates the usage of Python one-liners.
The command 'py' evaluates a string consisting of any Python expression.
It can do anything from simple arithmetic to complex operations,
importing modules automatically. It also comes with tab completion.

Its usage is not restricted to single expressions only. There's also the
possiblity to pipe data from stdin and to stdout, even generating
strings to be evaluated by other programs.

-

I plan to maintain this package by myself, as it is pretty simple. I'll
certainly reach the Python Applications Packaging Team (PAPT) in the
future if needed.

Bug#817568: lostirc: Removal of debhelper compat 4

[Eriberto Mota]

Control: tags 817568 patch
Control: tags 817568 pending

Hi,

I uploaded a NMU to 10-day/delay queue. Feel free to cancel this
upload if needed.

The debian/changelog is:

lostirc (0.4.6-4.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Migrated DH level to 9 to avoid a FTBFS. (Closes: #817568)
   * debian/control:
   - Added the ${misc:Depends} field.
   - Bumped Standards-Version to 3.9.7.
   * debian/watch:
   - Bumped to version 4.
   - Fixed the deprecated SF redirector method.

I attached a debdiff.

Regards,

Eriberto


lostirc.debdiff
Description: Binary data

Bug#816919: RFS: newsbeuter/2.9-1 [ITA]

[gregor herrmann]

On Thu, 10 Mar 2016 16:48:39 +0200, Nikos Tsipinakis wrote:

> > The highlighting feature seems to be broken (no idea if this is a
> > problem in newsbeuter or ncurses; I haven't retried to rebuild 2.8-2
> > to check). Too show what I mean: I have in my ~/.newsbeuter/config
> Apparently this issue was already reported and fixed upstream. Added a patch 
> and it should work as intended now.

/me tries the new version from mentors

Yay \o/
Excellent, works again. Thank you!


So I guess I should consider sponsoring this upload :)

Will take a closer look tomorrow; a first look shows that the package
might profit from some modernization (d/copyright in Copyright Format
1.0; dh(1) in debian/rules; migration to new dbgsym packages (cf.
dh_strip(1)'s --dbgsym-migration)), etc.).

lintian and blhc report:

P: newsbeuter source: no-dep5-copyright
I: newsbeuter: spelling-error-in-binary usr/bin/newsbeuter occured occurred
I: newsbeuter: hardening-no-fortify-functions usr/bin/newsbeuter
I: newsbeuter: hardening-no-fortify-functions usr/bin/podbeuter
I: newsbeuter: possible-documentation-but-no-doc-base-registration

W-dpkg-buildflags-missing|CPPFLAGS 59 (of 59) missing|


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: La Tresca: Caravanserraglio


signature.asc
Description: Digital Signature

Bug#817855: impress: crash on delete comment

[Mike Dupont]

Subject: impress: crash on delete comment
Package: libreoffice-impress
Version: 1:5.1.1~rc1-1
File: impress
Severity: important

Add comment to impress. Add new comment and then delete it. Crash.



-- 
James Michael DuPont
Kansas Linux Fest http://kansaslinuxfest.us
Free/Libre Open Source and Open Knowledge Association of Kansas
http://openkansas.us
Member of Free Libre Open Source Software Kosova http://www.flossk.org
Saving Wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com

Bug#811780: tinymux: FTBFS with GCC 6: narrowing conversion

[Martin Michlmayr]

* Stephen Dennis  [2016-03-10 12:18]:
> Trying my hand at the package because I think Noltar has moved on:
> 
> http://mentors.debian.net/package/tinymux

I have some questions and comments:

* debian/changelog says "" multiple
times.  I think you forgot to remove that.

* Fix "use autotools-dev.." and Fix "run dh-autoreconf.." are actually
the same thing, so don't list them separate.  Just list them once and
close both bugs -- in fact, I just merged the bugs into one so just
close the one.

* It seems you didn't actually add dh-autoreconf anywhere?

* Please mention "New upstream release" in the changelog (in the last
after NMU).

* I see upstream is at 2.10 now?  Why not 2.10?  Because this is a NMU
and you want minimal changes?

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#741029: equivs control file for redo(1) implementation

[Nils Dagsson Moskopp]

I created a file that can be used with the files linked at
 and the
equivs-build(1) command to build a Debian package for redo. I have
attached it to this email and also made it available on my web site
.

I have several questions regarding the equivs-build approach:

• Is it allowed by Debian policy to package a program this way? My
  implementation of redo(1) only consists of Bourne Shell scripts and
  can be packaged as-is without invoking a compiler or similar program.

• How do I find the version of coreutils my program depends on? It needs
  cut(1), md5sum(1), mv(1), rm(1), sh(1) and stat(1). Is it possible to
  do a binary search on all past Debian packages to find out which one
  lacked any of these binaries?

• Should I explain why my program suggests coreutils in the description?
  The answer is that it has more functionality on systems with shuf(1).

• How can I specify that the program is licensed AGPL-3 or later?

• Do I need to write a man page for every redo utility?

• Should redo utilities that should only be invoked from redo build
  scripts (“dofiles”) reside in “/usr/lib/redo”, not in “/usr/bin”?

• What is good or bad about the current description of the package?
-- 
Nils Dagsson Moskopp // erlehmann



pgpmAX6mJpC5R.pgp
Description: PGP signature
### Commented entries have reasonable defaults.
### Uncomment to edit them.
# Source: 
Section: devel
Priority: optional
Homepage: http://news.dieweltistgarnichtso.net/bin/redo-sh.html
Standards-Version: 3.9.2

Package: redo-sh
Version: 2016-03-02
Maintainer: Nils Dagsson Moskopp 
# Pre-Depends: 
Depends: coreutils | busybox | busybox-static
# Recommends: 
Suggests: coreutils
Provides: redo
# Replaces: 
Architecture: all
# Multi-Arch: 
# Copyright: AGPL-3
# Changelog: 
# Readme: 
# Extra-Files: 
Files: redo /usr/bin
 redo-always /usr/bin
 redo-dot /usr/bin
 redo-ifchange /usr/bin
 redo-ifcreate /usr/bin
 redo-ood /usr/bin
 redo-targets /usr/bin
 redo-sources /usr/bin
 redo-stamp /usr/bin
Description: Top-down software build system, Bourne Shell implementation
 redo is a utility which controls the generation of target files from
 source files. It determines automatically which targets need to be
 (re)created and issues commands to (re)create them. In contrast to
 the widely-used make program, redo records dependencies during the
 build. redo build scripts (“dofiles”) are shell scripts by default,
 but can be written in other languages.
 .
 For the design, see “Rebuilding target files when source files have
 changed” from Daniel J. Bernstein (DJB) .
 .
 This package contains an implementation of redo in Bourne Shell. For
 an overview of other redo implementations, see “Introduction to redo”
 
.

Bug#817854: debdiff should catch dpkg-source failure

[Martin Michlmayr]

Package: devscripts
Version: 2.16.1
Severity: minor
User: devscri...@packages.debian.org
Usertags: debdiff

This is probably a fairly unusual situation, but it would be nice if
debdiff would notice when dpkg-source fails:

65689:tbm@loric-alpo: ~/tmp/src/s] debdiff mgen_5.02.b+dfsg1-1.dsc 
mgen_5.02.b+dfsg1-2.dsc
dpkg-source: error: conflicting file sizes '1621368' and '1621292' for file 
'mgen_5.02.b+dfsg1.orig.tar.xz'
Use of uninitialized value $from in stat at /usr/share/perl/5.20/File/Copy.pm 
line 211.
Use of uninitialized value $from in string eq at 
/usr/share/perl/5.20/File/Copy.pm line 64.
Use of uninitialized value $from in -d at /usr/share/perl/5.20/File/Copy.pm 
line 96.
Use of uninitialized value $_[0] in substitution (s///) at 
/usr/share/perl/5.20/File/Basename.pm line 180.
fileparse(): need a valid pathname at /usr/share/perl/5.20/File/Copy.pm line 51.

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#806824: (no subject)

[Barry Warsaw]

On Mar 11, 2016, at 12:20 AM, Michael Biebl wrote:

>Tbh, I'm not too thrilled by hard-coding dependencies on
>libpeas-1.0-0-python3loader in several packages.

Can you explain why?


pgpHuFur8yD98.pgp
Description: OpenPGP digital signature

Bug#757790: hplip-gui: Please consider porting to python-notify2

[Julian Andres Klode]

Version: 3.15.11+repack0-1

On Mon, Aug 11, 2014 at 02:54:55PM +0400, Dmitry Shachnev wrote:
> Package: hplip-gui
> Version: 3.14.6-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> hplip-gui currently recommends python-notify, which in turn depends on
> python-gtk. Both python-gtk and python-notify are obsolete and we are
> going to remove them at some point. Also, none of these packages supports
> Python 3, so if you will ever switch to Python 3, you need to get rid
> of python-notify usage first.
> 
> The recommended alternative is python-notify2, which is a lightweight
> pure-Python interface to notification protocol. It was designed to be
> as compatible with python-notify as possible, so porting is very easy.
> 
> See http://sources.debian.net/src/python-notify2/0.3-2/notify2.py/#L18
> for details.
> 
> Another alternative will be using libnotify via gobject-introspection.
> 
> Both these alternatives are modern, supported, and Python 3 compatible.

This was fixed in 3.15.11+repack0-1

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#806824: (no subject)

[Michael Biebl]

Am 19.02.2016 um 12:52 schrieb Iain Lane:
> On Thu, Feb 18, 2016 at 09:54:25AM -0500, Barry Warsaw wrote:
>> We've gone ahead and made this transition in Ubuntu 16.04, just as described
>> here.  See LP: #1440504 for the changes we made to dependents.  I am not a
>> Gnome developer so I don't want to make the changes in Debian despite being a
>> DD, but I'm happy to help if patches are needed.
> 
> It would be good IMO if you would provide patches for this. I don't see a
> problem with us doing this transition in Debian (but others should shout if
> they disagree).


Tbh, I'm not too thrilled by hard-coding dependencies on
libpeas-1.0-0-python3loader in several packages.


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



signature.asc
Description: OpenPGP digital signature

Bug#246672: aptitude: quit directly instead of pressing a key to continue

[Manuel A. Fernandez Montecelo]

2016-03-10 18:54 martin f krafft:

also sprach Manuel A. Fernandez Montecelo  
[2016-03-10 18:04 +0100]:

I don't know if your complaint is more the speed side of reloading
the cache, or that you just don't see the need and don't want
curses to be restored just for quitting.  In the latter case,
maybe it would not be very difficult to implement what you ask,
but the reloading of the cache would continue to be there.


Shouldn't the reloading of the cache happen in the background right
away? Why do I need to hit a key for it to start. Instead, start it
right away, and let the user hit a key to continue or 'q' to quit.
If s/he continues, then the UI can pick up the background process.
If 'q' is pressed instead, say that "aptitude is shutting down"
until the background process returns.


Would be a nice idea, but aptitude is absolutely not ready to do this in
the short or medium term.  That is, not going to happen anytime soon for
this particular case.

So having that into account, what's the reply to the question above?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#733947: hplip-gui: HP Toolbox is not found in Gnome 3 Activities Overview / search after installing hplip-gui

[Julian Andres Klode]

Control: reassign -1 gnome-menus

On Thu, Jan 02, 2014 at 09:44:33AM -0500, Fabian Rodriguez wrote:
> Package: hplip-gui
> Version: 3.13.11-2
> Severity: important
> 
> Dear Maintainer,
> 
> I installed the hplip-gui package on a fresh Debian Jessie install to 
> make available the HP Toolbox for easy HP printers installation and 
> management (in particular networked multi-function printing/scanning).
> 
> After installation, however, the HP Toolbox application (hp-toolbox) 
> is not found in the Activities Overview in Gnome 3.
> 
> I would expect to find the application by searching for "toolbox", 
> "printing" or "printer". The application also lacks a menu entry when 
> using a Gnome Classic session.
> 
> I would also expect to find it under Settings > Hardware.
> 

gnome-menus blacklists the hplip applications. They should stop
doing that. hplip-gui is not installed by default (or any meta
package), and if a user installs it himself, it should be shown.

BTW: I also just updated the packaging to use upstream icons.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#811780: tinymux: FTBFS with GCC 6: narrowing conversion

[Martin Michlmayr]

Hi Ervin,

Are you ok with Stephen Dennis taking over tinymux in Debian?

Martin



* Stephen Dennis  [2016-03-10 12:18]:
> Trying my hand at the package because I think Noltar has moved on:
> 
> http://mentors.debian.net/package/tinymux

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#809318: bts: overrides user-specified value of sendmail

[Daniel Shahaf]

Osamu Aoki wrote on Thu, Mar 10, 2016 at 11:52:32 +:
> Then its fix should be "die" instead of stop doing sanity check.
> 
> What do you think of attached patch.

+1.  Your patch would resolve the issue and seems to be the least
intrusive way to do so.

One comment, below:

> - warn "BTS_SENDMAIL_COMMAND contained funny characters: 
> $cmd\nReverting to default value /usr/sbin/sendmail\n";
> - $config_vars{'BTS_SENDMAIL_COMMAND'}='/usr/sbin/sendmail';
> + die "BTS_SENDMAIL_COMMAND contained funny characters: $cmd\nPlease 
> fix configuration file.\n";

The noun phrase "configuration file" needs an article: it should say
"Please fix your configuration file" or "Please fix the configuration
file".

Thanks,

Daniel

Bug#773734: Fixed upstream

[Zdenek Kabelac]

On Sat, 04 Jul 2015 15:53:18 +0200 Jan Lentfer  wrote:

According to this link, this error has already been fixed upstream.

https://bugzilla.redhat.com/show_bug.cgi?id=1135639

I also consider this bug "serious", as the default mode should be
"writethrough" according to the man page, but due to this bug it
defaults to "writeback" and it stays "writeback" even if you specify it
differently. Also it is not easy to find out what the actual mode is. So
users might end up with writeback caches on non-redundant cache-storage,
which is going to lead to disaster.

Please upgrade to an upstream version that has the fix. Thanks!!




Yes cache support was new  at 111 age - so purely experimental.

For cache usage - newer version of lvm2 is basically mandatory.
No one is going to backport cache fixes in 2.02.111.
Close bug as problem is fixed in newer releases.

Regards

Zdenek

Bug#773731: cache_check should be on root

[Zdenek Kabelac]

On Sat, 21 Mar 2015 17:11:32 +0200 Timo Korvola  wrote:

On 21.03.2015 13:28, Bastian Blank wrote:
> The binaries from thin-provisioning-tools depends on libstdc++, so they
> must reside in /usr.

Ditto for cache_check.  This seems to be getting complicated.

In order to support cached root, cache_check and hence libstdc++ need to
be on initrd.  The boot scripts could be modified to activate all volume
groups before mounting root.  Then it should not matter if cache_check
is not on the actual root.

Another possibility would be to do fsck and mounting in three phases
instead of two: first fsck and mount root, then /usr and other
non-cached volumes and finally cached volumes.  Root and /usr could not
be cached then.

Or maybe just link statically to libstdc++.




Upstream thinprovtools now DO support  static linkage for libstdc++.
Please fix packaging and close BZ.

Regards

Zdenek

Bug#811195: Tip

[Lisandro Damián Nicanor Pérez Meyer]

I'm being told that /etc/X11/xinit/xinitrc.d/ comes from Fedora and it seems 
Debian will not source it from there. We need to put it in some other place.

-- 
Los comentarios o respuestas sobre SL en tono absolutista solo hacen aparecer
a la comunidad SL como una sarta de fanáticos que viven dentro de un
tupperware.
 Pablo Di Noto - GrULiC

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#761676: lvm2: lvs output format too long wraps on standard sized terminals

[Zdenek Kabelac]

On Mon, 15 Sep 2014 11:12:17 -0600 Bob Proulx  wrote:

Package: lvm2
Version: 2.02.111-1
Severity: normal

Since the latest update the "lvs" command now emits output lines that
are so long that they wrap on standard sized terminals.

For example previously:

# lvs
  LV   VG   Attr LSize   Pool Origin Data%  Move Log Copy%  Convert
  audio v1   -wi-ao 100.00g
  bak1  v1   -wi-ao 140.00g
  chrt  v1   -wi-ao  30.00g
  home  v1   -wi-ao 202.26g
  lcl   v1   -wi-ao  93.13g
  lcl2  v1   -wi-ao 123.83g
  root  v1   -wi-ao  16.00g
  srv   v1   -wi-ao  18.62g
  swap  v1   -wi-ao   7.45g
  test  v1   -wi-a- 100.00m
  var   v1   -wi-ao   5.59g

Now with 2.02.111-1 this output includes trailing whitespace out to
column 83 causing each line to wrap in an unpleasant way.

# lvs
  LVVG   Attr   LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync 
Convert

  audio v1   -wi-ao 100.00g

  bak1  v1   -wi-ao 140.00g

  chrt  v1   -wi-ao  30.00g

  home  v1   -wi-ao 202.26g

  lcl   v1   -wi-ao  93.13g

  lcl2  v1   -wi-ao 123.83g

  root  v1   -wi-ao  16.00g

  srv   v1   -wi-ao  18.62g

  swap  v1   -wi-ao   7.45g

  test  v1   -wi-a- 100.00m

  var   v1   -wi-ao   5.59g

This makes the output more difficult to read than before.



see the 'lvm.conf'report { compact_output = 1 }

I'd consider the problem as solved...
Please close

Regards

Zdenek

Bug#817853: totem: Please add libpeas-1.0-0-python3loader to Depends

[Barry Warsaw]

Package: totem
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

In bug #806824 I propose to split the Python loaders for libpeas into
separate binary packages.  This allows us to segregate the Python 2
and Python 3 versions, and eases the transition to a
Python-3-by-default world.  We've already made this transition in
Ubuntu.  E.g.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806824;att=1;filename=bug806824.diff;msg=15

This requires dependencies such as this package to update its Depends
in order to load the correct Python loader.

The binary packages totem and totem-plugins would need to add
libpeas-1.0-0-python3loader to Depends.


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

Kernel: Linux 4.4.0-1-amd64 (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 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
pn  gstreamer1.0-clutter
pn  gstreamer1.0-plugins-bad
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  libatk1.0-0 2.18.0-1
ii  libc6   2.22-2
ii  libcairo-gobject2   1.14.6-1
ii  libcairo2   1.14.6-1
ii  libclutter-1.0-01.24.2-1
pn  libclutter-gst-2.0-0
ii  libclutter-gtk-1.0-01.6.6-1
ii  libcogl-pango20 1.22.0-2
ii  libcogl-path20  1.22.0-2
ii  libcogl20   1.22.0-2
ii  libdrm2 2.4.67-1
ii  libegl1-mesa [libegl1-x11]  11.1.2-1
ii  libgbm1 11.1.2-1
ii  libgdk-pixbuf2.0-0  2.32.3-1.2
ii  libgirepository-1.0-1   1.46.0-4
ii  libglib2.0-02.46.2-3
ii  libgrilo-0.2-1  0.2.15-1
ii  libgstreamer-plugins-base1.0-0  1.6.3-1
ii  libgstreamer1.0-0   1.6.3-1
ii  libgtk-3-0  3.18.8-1
ii  libjson-glib-1.0-0  1.0.4-2
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  libpeas-1.0-0   1.16.0-1+b1
ii  libtotem-plparser18 3.10.6-4
pn  libtotem0   
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-62:1.6.3-1
ii  libxcomposite1  1:0.4.4-1
ii  libxdamage1 1:1.1.4-2+b1
ii  libxext62:1.3.3-1
ii  libxfixes3  1:5.0.1-2+b2
ii  libxi6  2:1.7.6-1
ii  libxkbcommon0   0.5.0-1
ii  libxml2 2.9.3+dfsg1-1
ii  libxrandr2  2:1.5.0-1
pn  python:any  
pn  totem-common

Versions of packages totem recommends:
ii  gstreamer1.0-libav 1.6.3-1
ii  gstreamer1.0-plugins-ugly  1.6.3-1
ii  gstreamer1.0-pulseaudio1.6.3-1
pn  totem-plugins  

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJW4fvHAAoJEBJutWOnSwa/5igQAK6GuC3h1CpPutAeVGUFJZj9
fWzinuXqjT7bySBUdw4ex+rDCBhtVdXSGkbJqhzdZaVF+XcYsC96ALqBl/yxRLn9
JRnifZZgCc67Oyz5NRY2KV0wg4mwoBOSnC41vlsAQCyoE87CPK8J8P1OFzqbSiCC
14dOeI5wTBI/9CEp3pQGeoMOQMDYIc//Y+OuxnKMmhi0yNsHo8CQcnt0Z76ooNvB
JMqMKavt+KEeWenrQlANDBTE3hArh7jJb7FDarKGxfC4AITOPM2HfZxYk5/l/d3t
7Zcg6vHEfPAAbIqTgcdEUYwU1C68WUafpiw4nhlGp7HpPdD0x/t0aTFlHeyIalYZ
wnGe9awCbmBi6BQgIAfRRZhV9Q1qVaxat9wgXL2Tfqz6kPx4eFLpAUzu7/cpDv3v
hdmPnzAyWBEXyss4D6hfSybm0LaURAdai6Eb+jERrhuWAl7g5zpMyeb8ubptfTKu
/SU9DI8RBR2lFd9dYqVNXDG248n0Frt/3DcJnV/VUUBpKEqNydNvjAbSWFC7wuhN
AaGhtO9nfiFTIfBggGjx5TYwfXNPgJm3Oy00ZZLK6xy2Kiq9yhjIShfNpqsmWjG2
B5bcMTljVy6E3zKN3jiy1hGx5hHPhGS/DLIZVInuc6p5ac36JYI6eW923NiqAm0o
dkwzw8pFc5GOYUQ/7P6h
=e4qm
-END PGP SIGNATURE-

Bug#806824: (no subject)

[Barry Warsaw]

I finally managed to report bugs on deja-dup, eog-plugins, gedit,
gnome-builder, gtranslator, liferea, rhythmbox, and totem.


pgpq2cruhIG61.pgp
Description: OpenPGP digital signature

Bug#817852: liferea: Please add libpeas-1.0-0-python2-loader to Depends

[Barry Warsaw]

Package: liferea
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,
In bug #806824 I propose to split the Python loaders for libpeas into
separate binary packages.  This allows us to segregate the Python 2
and Python 3 versions, and eases the transition to a
Python-3-by-default world.  We've already made this transition in
Ubuntu.  E.g.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806824;att=1;filename=bug806824.diff;msg=15

This requires dependencies such as this package to update its Depends
in order to load the correct Python loader.

liferea binary package would need to add libpeas-1.0-0-python2loader
to Depends.


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

Kernel: Linux 4.4.0-1-amd64 (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 liferea depends on:
ii  gconf-service   3.2.6-3
ii  gconf2  3.2.6-3
ii  libatk1.0-0 2.18.0-1
ii  libc6   2.22-2
ii  libcairo2   1.14.6-1
ii  libgconf-2-43.2.6-3
ii  libgdk-pixbuf2.0-0  2.32.3-1.2
ii  libglib2.0-02.46.2-3
ii  libgtk2.0-0 2.24.30-1
ii  libice6 2:1.0.9-1+b1
ii  libjson-glib-1.0-0  1.0.4-2
ii  libnotify4  0.7.6-2
ii  libpango1.0-0   1.38.1-1
ii  libsm6  2:1.2.2-1+b1
ii  libsoup2.4-12.52.2-1
ii  libsqlite3-03.11.1-1
pn  libunique-1.0-0 
ii  libwebkitgtk-1.0-0  2.4.9-3
ii  libxml2 2.9.3+dfsg1-1
ii  libxslt1.1  1.1.28-2.1
pn  liferea-data

Versions of packages liferea recommends:
ii  curl  7.47.0-1
ii  dbus  1.10.8-1
ii  dbus-x11  1.10.8-1
ii  wget  1.17.1-1+b1

Versions of packages liferea suggests:
pn  network-manager  

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJW4fCFAAoJEBJutWOnSwa/Tt8P/2lAoFyOKzecIpVPUWS8/Sdz
S8lXzn0OpLzOkppvzUxOWpDFrluQHWsBhHflhuvHlYSZ/th9LopJFjGcc0h+W9w5
E02jDgfGJ31gYI4d1l+WbiCF1It1fxvUQMe0m60ZPSuaEuIvFAOGqynEjZgkRugc
JM7f12hSnoBZwLrrCc1i32gvFhoNmqT1vFANvL+5IpbysWv8pwXDpNlLYYUQfV9X
vdMB/hX8DuGhh4l0eGJaPcFcQCk+4n1v4F0AARIv1yH+0/Q7rXuzz44dDFR1iqqJ
y72oEnMEAWASGs1h68K9STO8KoA4FaO6QthwC2gRLqlb2/WNKQcJe4PTIYJMoD4v
/yrLQD/mzkDAW7rDQm7jNlC+qt75o1eKqCceL0/N582Ia+kDg7JVl07a3psrjueS
EJ26SfFs3t+XEX1FJl4G22vlQ+nQRY+WlLWDOrXmyPVUrOuLC5LAFSucf0Qit42F
p+mpE5nbLLIumP47ZyGL94a7Ev7LTi2nJzcEdw9AsD7Jhw11PgJuiAc0nS47ZERy
yJeQLHWyZ2mxPyXo/9oD54S+5wncIw3dqm7a9HrUkLhiHrszAyLGoRSZFgMzJybO
AXBAY4hEKsQlB1/rUOCnUBQAa2FbbD9wKWNmUoWohcTsqWds57roVa+JXfm7+L0f
B/loUi/L9/zbiYJIWsCg
=nTpv
-END PGP SIGNATURE-

Bug#756560: lvm2: cache_dir /run/lvm doesn't exist, ENOENT /run/lvm/.cache

[Zdenek Kabelac]

On Wed, 30 Jul 2014 15:54:32 -0600 Jacob Anawalt  wrote:

Package: lvm2
Version: 2.02.95-8
Severity: normal

Dear Maintainer,

I have installed fresh Debian 7 systems to do some testing with and found
that the default configured cache_dir of "/run/lvm" does not exist under /run.

When I strace vgscan, it gives the ENOENT error because it cannot open
/run/lvm/.cache.

The system us using tmpfs for /run as per the Debian defaults.

I don't know what is suppose to create the lvm directory under /run
on reboot, but it seems that something, perhaps /etc/init.d/lvm2,
should to enable caching.



Upstream (original)  lvm2  stores .cache within  /etc/lvm dir which
is persistent across reboots.

Debian for unknown reason relocated this 'persistent' place to /run
which is cleared on every reboot - so losing the original purpose.

On the other hand on any modern distro which is using 'udev' scan,
this .cache file is actually not used - since the list of devices
is obtained from udev - so no big harm as the cache file is not even created...

Regards

Zdenek

Bug#814722: (no subject)

[David Demonchy]

I have the same bug in unstable branch.

i can fix this bug with a rollback the kernel (version 4.3.0-1) (testing 
branch)

Bug#817850: ITP: node-blessed -- A high-level terminal interface library for node.js.

[onovy]

Package: wnpp
Severity: wishlist
Owner: Ondřej Nový 

* Package name: node-blessed
  Version : 0.1.81
  Upstream Author : Christopher Jeffrey
* URL : https://github.com/chjj/blessed
* License : Expat
  Programming Lang: JavaScript
  Description : A high-level terminal interface library for node.js.

 Reimplement ncurses entirely by parsing and compiling terminfo and
 termcap, and exposing a Program object which can output escape sequences
 compatible with any terminal.

 Implement a widget API which is heavily optimized for terminals.

 Node.js is an event-based server-side JavaScript engine.

Bug#817849: ITP: node-blessed -- A high-level terminal interface library for node.js

[Ondřej Nový]

Package: wnpp
Severity: wishlist
Owner: "Ondřej Nový" 

* Package name: node-blessed
  Version : 0.1.81
  Upstream Author : Christopher Jeffrey
* URL : https://github.com/chjj/blessed
* License : Expat
  Programming Lang: JavaScript
  Description : A high-level terminal interface library for node.js.

 This interface have two goals:
 * Reimplement ncurses entirely by parsing and compiling terminfo and
   termcap, and exposing a Program object which can output escape sequences
   compatible with any terminal.
 * Implement a widget API which is heavily optimized for terminals.

 Node.js is an event-based server-side JavaScript engine.

Bug#817842: imagemagick & imagemagick-6.q16 packages have the same binary

[Vincent Fourmond]

  Hello,

On Thu, Mar 10, 2016 at 10:58 PM, Ross Gammon  wrote:
> Whilst debugging the two desktop menu items in imagemagick (separate bug), it
> was noticed that the two packages (imagemagick & imagemagick-6.q16) seem to
> provide the same binary, despite the q16 package being advertised as having a
> different quantum depth (16 v 8).

  Hmmm. Is it still written somewhere that the default depth is 8 ? If
yes, then clearly we should modify that.

> Also, if offering a default quantum depth package, and one with more quantum
> depth, would it be better to offer Q16 as the default, and Q32 as the option?

  That is something we'd like to do, and it's the reason why we set up
different packages with proper alternatives, but that's unfortunately
not going to happen very soon.

  Best,

  Vincent

Bug#816043: pypy: bsddb module is broken

[Stefano Rivera]

Control: tag -1 upstream
Control: retitle -1 PyPy has no _bsddb module

Hi Tristan (2016.02.26_13:35:29_-0800)
> The extension module seems to be missing:

Yep, upstream.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#817208: Cannot load library /usr/lib/kde4/kio_digikamdates.so

[Aurelien Jarno]

reassign 817208 libc6
forcemerge 817826 817208
thanks

On 2016-03-08 20:35, Ryan Kavanagh wrote:
> Package: digikam
> Version: 4:4.14.0-3
> Severity: grave
> Justification: renders package unusable
> 
> As of today, digikam no longer displays any pictures from my albums.
> 
> The following errors can be found in ~/.xsession-errors:
> 
> Could not open library '/usr/lib/kde4/kio_digikamdates.so'.
> Cannot load library /usr/lib/kde4/kio_digikamdates.so: 
> (/lib/x86_64-linux-gnu/libresolv.so.2: symbol __h_errno, version 
> GLIBC_PRIVATE not defined in file libc.so.6 with link time reference)
> Could not open library '/usr/lib/kde4/kio_digikamalbums.so'.
> Cannot load library /usr/lib/kde4/kio_digikamalbums.so: 
> (/lib/x86_64-linux-gnu/libresolv.so.2: symbol __h_errno, version 
> GLIBC_PRIVATE not defined in file libc.so.6 with link time reference)
> 

This is likely due to the upgrade to glibc 2.22. The workaround is to
restart your KDE session, we don't have any other option right now.

Aurelien

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


signature.asc
Description: PGP signature

Bug#817847: /usr/sbin/fai-make-nfsroot: Getting error at fai-setup -v : chmod: fehlender Operand nach "a+r"

[Daniel Fischer]

Package: fai-server
Version: 5.0.3
Severity: important
File: /usr/sbin/fai-make-nfsroot

Dear Maintainer,

when i try to run fai-setup -v so i get first the error, that 
dracut-config-gernic package is not found. So i had remove it in 
/usr/sbin/fai-make-nfsroot
then i get the error, described in the subject. Does anybody know why?

Greetings Daniel

-- 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=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 fai-server depends on:
ii  debootstrap  1.0.67
ii  fai-client   5.0.3
ii  xz-utils 5.1.1alpha+20120614-2+b3

Versions of packages fai-server recommends:
ii  isc-dhcp-server   4.3.1-6+deb8u2
ii  libproc-daemon-perl   0.14-2
ii  nfs-kernel-server 1:1.2.8-9
ii  openbsd-inetd [inet-superserver]  0.20140418-2
ii  openssh-client1:6.7p1-5+deb8u1
ii  openssh-server1:6.7p1-5+deb8u1
ii  tftpd-hpa 5.2+20140608-3

Versions of packages fai-server suggests:
ii  aptitude0.6.11-1+b1
ii  binutils2.25-5
pn  debmirror   
pn  grub
pn  perl-tk 
ii  reprepro4.16.0-1
ii  squashfs-tools  1:4.2+20130409-2
ii  xorriso 1.3.2-1.1

-- Configuration Files:
/etc/fai/NFSROOT changed:
PACKAGES aptitude
nfs-common fai-nfsroot module-init-tools ssh rdate lshw rpcbind
rsync lftp less dump reiserfsprogs e2fsprogs usbutils
hwinfo psmisc pciutils hdparm smartmontools parted mdadm lvm2
dnsutils ntpdate dosfstools xfsprogs xfsdump
procinfo numactl dialog
console-common kbd
iproute moreutils udev subversion
xz-utils
cupt
pxelinux syslinux-common # in jessie we need both
PACKAGES aptitude I386
grub-pc
linux-image-generic live-boot
PACKAGES aptitude AMD64
grub-pc
linux-image-generic live-boot

/etc/fai/apt/sources.list changed:
deb http://ftp.uni-kl.de/debian jessie main contrib non-free
deb http://security.debian.org/debian-security jessie/updates main contrib 
non-free

/etc/fai/nfsroot.conf changed:
FAI_DEBOOTSTRAP="jessie http://ftp.uni-kl.de/debian;
FAI_ROOTPW='testarea.61'
NFSROOT=/srv/fai/nfsroot
TFTPROOT=/srv/tftp/fai
NFSROOT_HOOKS=/etc/fai/nfsroot-hooks/
FAI_DEBOOTSTRAP_OPTS="--exclude=info --include=aptitude"
FAI_CONFIGDIR=/srv/fai/config


-- no debconf information

Bug#817848: gtranslator: Please add libpeas-1.0-0-python2loader to Depends

[Barry Warsaw]

Package: gtranslator
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

In bug #806824 I propose to split the Python loaders for libpeas into
separate binary packages.  This allows us to segregate the Python 2
and Python 3 versions, and eases the transition to a
Python-3-by-default world.  We've already made this transition in
Ubuntu.  E.g.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806824;att=1;filename=bug806824.diff;msg=15

This requires dependencies such as this package to update its Depends
in order to load the correct Python loader.

gtranslator binary package would need to add
libpeas-1.0-0-python2loader to Depends.

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

Kernel: Linux 4.4.0-1-amd64 (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)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJW4fAmAAoJEBJutWOnSwa/ynkP/i0wwwadALI8zlz3svJ3Xu2U
hHlUpRxbVkCdn+5ZvdL2/2h79tz2zJMTkg8aokdW2DrZZInmOTWHNrUnZUHgMHdy
Td9vUIyBAqxx/vh19eTMS70Qvlm5CcjwuAoLjw+omNuxap/E6muhsndGUYA+Fgpp
m9EZaXeQsCg3NrdhSitY3/JAaq+M/qAz1Zem4VHqXipPuYvIr5T5psgbv4ydivAd
JAx1Uh3WelDUSw26moUOUxZYIpyKN/pOpGDQWhABRLsPhacISHwg1Cf7HwFkum9O
/pXDKFoB+Z25y2/U2WU0aR24ve82k+KXDBj5WdC3TCdkznue9s37vIG0fHKaYRUD
NYTGz/ZLwKoaTtm26mfzqgn4O5LtPu8OW3XswF4ZuVYyZBVNcuMad5qm9aheux89
YyvSUBGntLCVn7qyT05vdMZLJ92z5YG+2iTQ/lXTlv8ZPt9cDk627bEGY/afw7Qk
DX9aRGcP9qbEjCtFvjYa7dKNXWAbATdX0LVuqoCRO25pugsZgBwtLK2GI+9Gpr1x
uUYrbLzzAm0UaAT0ho4DorRTmmHLkGyGzRi596SYiKOWNWF9Ah9HXH4ENRRIDjI0
RqhKCA2snqFUcw/IOp/JlZXwy0+Mzs3PR9vt810KZV6ixi4dHos7iFzTltq9ZzBQ
2kHWNV+6f+gin5sqaCR+
=egvc
-END PGP SIGNATURE-

Bug#817846: gnome-builder: Please add libpeas-1.0-0-python3loader to Depends

[Barry Warsaw]

Package: gnome-builder
Version: Please add libpeas-1.0-0-python3loader to Depends
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

In bug #806824 I propose to split the Python loaders for libpeas into
separate binary packages.  This allows us to segregate the Python 2
and Python 3 versions, and eases the transition to a
Python-3-by-default world.  We've already made this transition in
Ubuntu.  E.g.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806824;att=1;filename=bug806824.diff;msg=15

This requires dependencies such as this package to update its Depends
in order to load the correct Python loader.

gnome-builder binary package would need to add
libpeas-1.0-0-python3loader to Depends.

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

Kernel: Linux 4.4.0-1-amd64 (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)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJW4e/BAAoJEBJutWOnSwa/LMkQAJn3Zt39wDxql/ZGGhiB/xCj
if3aJWEMOH2JpKDOJCq81+0lOscO/c1lNSNBFjahxJbpgh3odkni1Ok5ToVzLU9a
ghbSbPUJCO9ngFy7k0kkMCRwp2SRAhD66cuZuYo13D4hVuoYDPk1vWpf8Ibg6AYm
mDy/w1sXWCe+CV5e92RGjOzWX4AwcTDKLB3hexZMdjGHY/9dofMvEq8sUCfuo9za
pfMx4fpew2oPaLAhMIJWI5mvGN5cGICoUE6gSmcjnSC066suxjUZR0dNvYxf4kiK
oNA/NdMwR2i2GMBPz89Q62mEv3GULDwZWmNutk31hs4/WrqQTGu1vfnM1f6o372r
pTrYmNk/r1Nz/dK0cVKcSM9b9Kgo/KmI4qWfmR7AuygIlU2cfWVDbnJVge5l+66W
wPKsJBbdGUTvfwPyS4RYyXVUx9blvL40fSzC3RQHgmFXFA57gtcBuFkuDbYf5TRd
GQwe3tuLq9X+CYUchqPIVge3Avo0+005C9hvRjrZ+w1S5mKWhLL5J8IbFCwhCU66
JeKmGCvSz8YGB+giNz4eVOSXCyQk9GeMSfkLSzJ7ortzMaBIT+5ES4P+3FfyZRYh
KgWU3yIV2+WtvVNqCJUPqliOLKAXTAemESPGvWhYO+373QLDSetAYr7mwN9EPZK3
YQ4EOjUQznDHNk5VO8wI
=Viya
-END PGP SIGNATURE-

Bug#817845: gedit: Please add libpeas-1.0-0-python3loader to Depends

[Barry Warsaw]

Package: gedit
Version: 3.18.3-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

In bug #806824 I propose to split the Python loaders for libpeas into
separate binary packages.  This allows us to segregate the Python 2
and Python 3 versions, and eases the transition to a
Python-3-by-default world.  We've already made this transition in
Ubuntu.  E.g.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806824;att=1;filename=bug806824.diff;msg=15

This requires dependencies such as this package to update its Depends
in order to load the correct Python loader.

gedit binary package would need to add libpeas-1.0-0-python3loader to
Depends.

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

Kernel: Linux 4.4.0-1-amd64 (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 gedit depends on:
ii  gedit-common   3.18.3-1
ii  gir1.2-glib-2.01.46.0-4
ii  gir1.2-gtk-3.0 3.18.8-1
ii  gir1.2-gtksource-3.0   3.18.2-1
ii  gir1.2-pango-1.0   1.38.1-1
ii  gir1.2-peas-1.01.16.0-1+b1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  gsettings-desktop-schemas  3.18.1-1
ii  iso-codes  3.66-1
ii  libatk1.0-02.18.0-1
ii  libc6  2.22-2
ii  libcairo-gobject2  1.14.6-1
ii  libcairo2  1.14.6-1
ii  libenchant1c2a 1.6.0-10.1
ii  libgdk-pixbuf2.0-0 2.32.3-1.2
ii  libgirepository-1.0-1  1.46.0-4
ii  libglib2.0-0   2.46.2-3
ii  libgtk-3-0 3.18.8-1
ii  libgtksourceview-3.0-1 3.18.2-1
ii  libpango-1.0-0 1.38.1-1
ii  libpangocairo-1.0-01.38.1-1
ii  libpeas-1.0-0  1.16.0-1+b1
ii  libx11-6   2:1.6.3-1
ii  libxml22.9.3+dfsg1-1
ii  python3-gi 3.18.2-2+b1
ii  python3-gi-cairo   3.18.2-2+b1
pn  python3:any

Versions of packages gedit recommends:
ii  yelp3.16.1-1
ii  zenity  3.18.1.1-1

Versions of packages gedit suggests:
pn  gedit-plugins  

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJW4e9bAAoJEBJutWOnSwa/MzgQAKu9A0h5p1lHArCw5rSj11ed
g8YjUS1IYO5phMa+DW+LFvXO6UZ1X4wBxXXxrgLquSv7iJFlQkL+3Bdb/8722rFB
Xkzr1lqGkDHz3D/9Q/tuJS7Mnm02WnQvjs4D4b9fzEPvziNO54SGqyvj+K/BmVQg
5me8FG1uT48/Z36Ez4fQJQ6qzwG1t3doBkUIg1kx+5SHD7VtUGZDsWR/izHI3rEL
uabC32M/8gn2dFehBSupeorr6brrq6SciKj7/ZxIW4ZdoNEVjBSqNUY7zX+dDJoo
TboRHohcFFNbhqbl5NoWThgNbgeK74J8Ym3Vb1JXPWP6WJY9DRBf+UicELELB2Zz
GEAPcj1h1TnCsjLblcO/jyHpQPSKzTspv7CbSB6eQFh/vmsjQWOC/4ZKmY03yXpZ
g5JPgtUGeJ9FmFj8H0sRxVBKYBDqSW0e/TDvzhhDF9I6WZ9epVzAvNSdVd2x83G7
TsxGQERscKRYcTxSI9M8jpaB39JgrpEZGcDoCjoIxkGUTEX13X2n1+c+9QP8Tcc+
jkD6ai4fBmcB4yLWIblVlPuRLCFXX/3xGmbBmrZwiJdaHSK+sBzJ6YUWmZfCxgpC
wodrakFUZ4IZJ9kgb3pZp0Zu/ok4tsLeSuRzpKK4CG583m2TwMeFWcjir8rgdh0N
vMrkWkliqssmA76AudI3
=JM3e
-END PGP SIGNATURE-

Bug#817844: eog-plugins: Please add libpeas-1.0-0-python3loader to Depends

[Barry Warsaw]

Package: eog-plugins
Version: Please add libpeas-1.0-0-python3loader to Depends
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In bug #806824 I propose to split the Python loaders for libpeas into
separate binary packages.  This allows us to segregate the Python 2
and Python 3 versions, and eases the transition to a
Python-3-by-default world.  We've already made this transition in
Ubuntu.  E.g.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806824;att=1;filename=bug806824.diff;msg=15

This requires dependencies such as this package to update its Depends
in order to load the correct Python loader.

eog-plugins binary package would need to add
libpeas-1.0-0-python3loader to Depends.

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

Kernel: Linux 4.4.0-1-amd64 (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)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJW4e76AAoJEBJutWOnSwa/MnoQAKiFpbWOcTX5SODEtzw0pNep
S36j82fP+9kKvu8pBuim0pqo6KVgg4FbYNqYD+7Hjx5/rkkbRITksaAY8qVNb6T5
Ru68hs7WOtuo8h6+qlauUq+jyQhmkyohQUKFViJWNvpRXy912PEWBFqQw833Slut
d2/0Pg2MaBpjBW+h9LROO3Rc2/1FPr9uW7sKbX7HYtMCaBPlTpePtcJ/RBzIqQnC
XsSJeLuR0MJKAEmlTq/2Z0RSX9w92d3RLco+fi2I3+d/XM9OMXkZobDh042gp7+G
MRHqGq8wmwLqSEC5MKXT3isl3ZLMULwR6plmDOgmwmKkH0L19G1TUgtFqHUkmziG
px9h/p3dozhzL4d6jY1+6+4jK6J72NJigOBdlv9wMlwkdNk0QJFmwEFZm5kp8qGR
1z6SMd6ja0Vnw9fngPo3gb5+u7pAuhyrJu4Kbksq8v10Ow+hezeUWmOf3Kf5TE0W
OvPb6vflYe1HPUOA+5T7pPaZ1XgCMqgIpdxMbAXI2NV9O/YusFAq21xwdgknFm65
RSxwwlQWFVGQ1r5Rd/K6UM/pdf0Z+UZrjilSdIwBo2tOSS1JH5NoNP3EFapnP36P
jpGoQ9YtmKPquBFSK2sj/joXEuk1aV/LQgzDU6LXn3u7uBhZnlzNFw69ud04i0Wu
HxJ+KXcc/183re8aDfwg
=k8ul
-END PGP SIGNATURE-

Bug#817842: imagemagick & imagemagick-6.q16 packages have the same binary

[Ross Gammon]

Package: imagemagick
Version: 8:6.8.9.9-5
Severity: normal

Dear Maintainer,

Whilst debugging the two desktop menu items in imagemagick (separate bug), it
was noticed that the two packages (imagemagick & imagemagick-6.q16) seem to
provide the same binary, despite the q16 package being advertised as having a
different quantum depth (16 v 8). The *-im6 binaries in /usr/bin of imagemagick
are links to binaries in /usr/lib/x86_64-linux-gnu/ImageMagick-6.8.9/bin-Q16
(on amd64).

Also, if offering a default quantum depth package, and one with more quantum
depth, would it be better to offer Q16 as the default, and Q32 as the option?

Regards,

Ross



-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
compare:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
convert:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
composite:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
conjure:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
display:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
identify:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
import:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
mogrify:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
montage:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
stream:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org

-- 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/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages imagemagick depends on:
ii  imagemagick-6.q16  8:6.8.9.9-5

imagemagick recommends no packages.

imagemagick suggests no packages.

-- no debconf information

Bug#817841: openresolv: doesn't work with multiple domains in search, they are concatenated.

[Thibaut Chèze]

Package: openresolv
Version: 3.7.3-1
Severity: important
Tags: upstream

Hi,

The problem occurs since the new /3.7.3-1/.

A way to reproduce (using bind):
 # resolvconf -a wlan0 < domain test2.example.org
> search test2.example.org. example.org. test1.example.org
> nameserver 192.168.0.1
> EOF
Failed to try-restart nscd.service: No such method 'TryRestartUnit'
See system logs and 'systemctl status nscd.service' for details.
Failed to try-restart named.service: No such method 'TryRestartUnit'
See system logs and 'systemctl status named.service' for details.
 # resolvconf -l
# resolv.conf from wlan0
domain test2.example.org
search test2.example.org. example.org. test1.example.org
nameserver 192.168.0.1

 # resolvconf -v
DOMAIN='test2.example.org'
SEARCH='vm test2.example.orgexample.orgtest1.example.org'
NAMESERVERS='192.168.0.1'
LOCALNAMESERVERS='127.0.0.1'
DOMAINS='test2.example.orgexample.orgtest1.example.org:192.168.0.1'
# cat resolvconf-zones.conf
# Generated by resolvconf
zone "test2.example.orgexample.orgtest1.example.org" {
type forward;
forward first;
forwarders {
192.168.0.1;
};
};


I think messages on /add/ are a new problem: trying to use /systemd/ to
reload /bind/ instead of /invoke-rc.d/.
I have /systemd/ intalled, but my /init/ is /sysvinit/.

Best regards,

-- System Information:
Debian Release: stretch/sid

Kernel: Linux 4.3.0-1-amd64 (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: sysvinit (via /sbin/init)

-- Configuration Files:
/etc/resolvconf.conf changed [not included]

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#817843: deja-dup: Please add libpease-1.0-0-python3loader to Depends

[Barry Warsaw]

Source: deja-dup
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

In bug #806824 I propose to split the Python loaders for libpeas into
separate binary packages.  This allows us to segregate the Python 2
and Python 3 versions, and eases the transition to a
Python-3-by-default world.  We've already made this transition in
Ubuntu.  E.g.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806824;att=1;filename=bug806824.diff;msg=15

This requires dependencies such as this package to update its Depends
in order to load the correct Python loader.

deja-dup binary package will need to add libpeas-1.0-0-python3loader
to Depends.


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

Kernel: Linux 4.4.0-1-amd64 (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)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJW4e5sAAoJEBJutWOnSwa/1IIQAK75shYibWYXlALmNyTbKYJ5
98vkTaFCC/6vKULqe+7ec1wDr+x2HmKGfPCB22KtL+u5skuYRpzROjnF26kQyiWv
uSiwjeAPMh0KOD3yWMR3jJmpKGF6MSGb7u3IIwllJVg+pmm+PHUzpz2BEfsretTM
kU+EfgagJOzRqzScqtaIE6Wi3otiMWMx33sIC0ecer01WjkaVMu9jpBmyN0/SwvO
oKYA0+2zOIFN5zKf1muS2fqP3ISX4w9p7tT/0VhGT2lf40hhicCF6jo4XlRTuPZg
D+EELlm7ELFUEIRy+sW/QTbcMKXaOq6eOOGGJUhkqPJY0cWGFcP+1F2Fi5E/lBAq
mNnMu4E2m1IamrzXR+cZQrdpk9pQzU41R4UxBIN1PWzOVChTLUr0CkiMR2Dxsgxd
omDI/l4RMKR0epPR5yJkjXdRCFpqeZFhHVmC6km5M9n/CUki4IknIgjinIfqgqMf
mrQy+EzWwWRJioRENroRioEZTvdMINbEys/FzY8bXnachyGEwNjBsTl4RHbUGJ85
xnAoclyA5uRtYEPf06eXzLrIdDQkrx0aINfka9yYJiOR5LmFHd84logvFkvtU/Dt
1YGmChHb3cgJsI35WwGhGN94vtSMnzd+MS/jGJIPwEUJoUPaCUzMSMDdRqX4Gz9e
2X+wJIOU8k3m4MMhFrvj
=79fq
-END PGP SIGNATURE-

Bug#817840: libvigraimpex: fail of test/math on mips

[Daniel Stender]

Source: libvigraimpex
Version: 1.10.0+git20160120.803d5d4-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Since 1.10.0+git20160120.803d5d4-1 the build breaks on mips [1] with a failure
of test/math:


[ 57%] Linking CXX executable test_math
cd /«BUILDDIR»/libvigraimpex-1.10.0+git20160120.803d5d4/obj/test/math && 
/usr/bin/cmake -E cmake_link_script CMakeFiles/test_math.dir/link.txt 
--verbose=1
/usr/bin/c++   -pthread -std=c++11 -W -Wall -Wextra -Wno-unused-parameter 
-Wno-sign-compare -Wno-unused-variable -Wno-type-limits -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -pipe -Wdate-time 
-D_FORTIFY_SOURCE=2 --param ggc-min-expand=20   
CMakeFiles/test_math.dir/test.cxx.o CMakeFiles/test_math.dir/testsuccess.cxx.o  
-o test_math -rdynamic 
Running test_math
cd /«BUILDDIR»/libvigraimpex-1.10.0+git20160120.803d5d4/obj/test/math && 
./run_test_math.sh
Illegal instruction
test/math/CMakeFiles/test_math.dir/build.make:123: recipe for target 
'test/math/test_math' failed
make[5]: *** [test/math/test_math] Error 1
make[5]: *** Deleting file 'test/math/test_math'


This needs to be fixed to complete the ongoing transition [2] to build on all
officially supported archs.

DS

[1] https://buildd.debian.org/status/logs.php?pkg=libvigraimpex=mips

[2] https://bugs.debian.org/815153 (transition: libvigraimpex)

-- 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=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#816982: maxima: FTBFS when built with dpkg-buildpackage -A (tests fail)

[Santiago Vila]

> Yes I've been mulling a solution, but perhaps you could suggest.
> 
> GCL is in the process of enabling full use of today's common >2Gb
> memories.  We probe brk at startup to get an effective maximum heap and
> manage accordingly.  We need to allow some fraction for subprocess gcc,
> and perhaps some consideration for other running processes, while still
> allowing the full minimal-gc power to those (e.g. ACL2) who demand it.
> I need to come up with a sane default and then provide an escape setting
> for the power user.
> 
> Each of the failures you reported were ENOMEM failures on fork for gcc
> (invoked via compile), i.e. the heap proper was handled well within the
> runtime determined limits.  I have no idea how to bound or estimate
> subprocess gcc memory usage.

I'm not a programmer myself, but if GCL_MEM_MULTIPLE is the fraction
of memory which is available for GCL, and 1.0 is the default, then GCL
may in fact consume all memory, leaving no memory at all for other
processes. I think this is definitely bad.

Maybe 0.5 would be a better default. Those who need more memory will
know how to fiddle with the variable anyway (i.e. those who need *less*
that the other half for the *other* processes will know how to
fiddle with the variable).


What I do to estimate the amount of memory a given package needs to be
built is to take this value once per second:

awk '/Committed_AS:/ { print $2 }' /proc/meminfo

I take an initial measure before building the package which I then
substract to all other values (that way the memory used by system
processes is not included).

By doing that on the maxima package I get that it needs more than
5.6 GB of RAM. I think this is definitely too much considering that I
was able to built maxima with only 2GB of RAM and 2 GB of swap in the
past.

Thanks.

Bug#812488: Debian jessie removal of certs breaks some irc chats

[Michael Fox]

Another url to test is irc.esper.net (sometimes it works and sometimes it 
doesnt because this url goes to different servers with different certs).
Can this please get an official fix soon as this is causing problems everywhere.

Bug#702586: libxml-compile-soap-perl -- module to deal with SOAP and WSDL (client side)

[Nick Morrott]

retitle 702586 ITP: libxml-compile-soap-perl -- module to deal with
SOAP and WSDL (client side)
owner 702586 !
quit

Bug#817263: I think a sourceful upload would be fastest

[Adam Borowski]

Hi!
Just a thought from the peanut gallery:

Otto, instead of having the ftpmasters dig through backups/snapshot.d.o for
all binaries and manually reinsert them as you requested, a long task they
haven't drilled at all, please make a no-change (or with your VCS tip)
sourceful upload, so they can ACCEPT it with a single command.  Human time
is costly, machine time is cheap.  The cost of such an upload would be
buildds needing to recompile mariadb on all architectures, but it's not like
we're in the week-before-freeze or just-released rush, the buildds are not
very loaded, and the electricity cost is nothing compare to what we'd pay
the ftpmasters had they demanded any reasonable rate.

-- 
A tit a day keeps the vet away.

Bug#817427: devio: Removal of debhelper compat 4

[Eriberto]

Hi,

I cancelled the previous upload and uploaded the package again to
experimental without close the bugs. I will close them when upload to
unstable. Sorry for my mistake.

New debdiff attached.

Regards,

Eriberto


2016-03-10 18:05 GMT-03:00 Eriberto Mota :
> Control: tags 817427 patch
> Control: tags 817427 pending
> Control: tags 453550 patch
> Control: tags 453550 pending
>
> Hi,
>
> I uploaded a NMU to 10-day/delay queue. Feel free to cancel this
> upload if needed.
>
> The debian/changelog is:
>
> devio (1.2-1.1) experimental; urgency=medium
>
>   * Non-maintainer upload.
>   * Migrated DH level to 9 to avoid a FTBFS. (Closes: #817427)
>   * debian/control:
>   - Added the Homepage field.
>   - Added the ${misc:Depends} field.
>   - Bumped Standards-Version to 3.9.7.
>   * debian/dirs: disabled the unused man8 dir.
>   * debian/watch:
>   - Bumped to version 4.
>   - Fixed the deprecated SF redirector method. (Closes: #453550)
>
> I uploaded to experimental because this source provides a udeb
> package. If the package builds fine, I will reupload to unstable.
>
> I attached a debdiff.
>
> Regards,
>
> Eriberto


devio.debdiff
Description: Binary data

Bug#817427: devio: Removal of debhelper compat 4

[Eriberto Mota]

Control: tags 817427 patch
Control: tags 817427 pending
Control: tags 453550 patch
Control: tags 453550 pending

Hi,

I uploaded a NMU to 10-day/delay queue. Feel free to cancel this
upload if needed.

The debian/changelog is:

devio (1.2-1.1) experimental; urgency=medium

  * Non-maintainer upload.
  * Migrated DH level to 9 to avoid a FTBFS. (Closes: #817427)
  * debian/control:
  - Added the Homepage field.
  - Added the ${misc:Depends} field.
  - Bumped Standards-Version to 3.9.7.
  * debian/dirs: disabled the unused man8 dir.
  * debian/watch:
  - Bumped to version 4.
  - Fixed the deprecated SF redirector method. (Closes: #453550)

I uploaded to experimental because this source provides a udeb
package. If the package builds fine, I will reupload to unstable.

I attached a debdiff.

Regards,

Eriberto


devio.debdiff
Description: Binary data

Bug#817246: closed by martin f krafft <madd...@debian.org> (Re: Bug#817246: gziptoany fails with signal 13 since upgrade to jessie)

[Brian Potkin]

On Thu 10 Mar 2016 at 19:18:11 +, Debian Bug Tracking System wrote:

> I am sorry for filing this bug report. Had I interpreted the signal
> correctly, then I might have looked in the right place right away…

Please do not have regrets. Bug reports are a sign of the vibrancy of
Debian.

Thank you for the investigations you undertook to resolve this bug so
quickly.

Regards,

Brian.

Bug#817263: IRC log for closed mariadb-10.0 bugs

[Adam Borowski]

Hi!
Just to save you having to dig through the bug list to see which were closed
by the removal and which were not:

23:15 < BTS> Closed #787118 in mariadb-server-10.0 by Debian FTP Masters 
 «Compile with OpenSSL (instead of YaSSL)». 
https://bugs.debian.org/787118
23:15 < BTS> Closed #793787 in mariadb-client-10.0 by Debian FTP Masters 
 «indirect dependency on libmysqlclient18». 
https://bugs.debian.org/793787
23:15 < BTS> Closed #808419 in mariadb-10.0 by Debian FTP Masters 
 «TODO: Add debconf question to make feedback plugin 
opt-in very easy». https://bugs.debian.org/808419
23:15 < BTS> Closed #808421 in mariadb-10.0 by Debian FTP Masters 
 «TODO: Implement metadata.yml (DEP12)». 
https://bugs.debian.org/808421
23:15 < BTS> Closed #797210 in mariadb-10.0 by Debian FTP Masters 
 «mariadb-server does not ship a debconf set for creating 
a adminitrative user (like mysql-server do)». https://bugs.debian.org/797210
23:15 < BTS> Closed #801959 in mariadb-10.0 by Debian FTP Masters 
 «TODO: Tag mariadb packages with debtags». 
https://bugs.debian.org/801959
23:15 < BTS> Closed #809022 in mariadb-10.0 by Debian FTP Masters 
 «TODO: Add autopkg tests to detect changes introduced by 
other uploaded packages». https://bugs.debian.org/809022
23:15 < BTS> Closed #810968 in mariadb-server-10.0 by Debian FTP Masters 
 «Logrotate exists 1 if a non-debian mysqld is running 
(e.g. containerized mysqld)». https://bugs.debian.org/810968
23:15 < BTS> Closed #808420 in mariadb-10.0 by Debian FTP Masters 
 «TODO: Implement systemd scripts». 
https://bugs.debian.org/808420
23:16 < BTS> Closed #815599 in mariadb-server-10.0 by Debian FTP Masters 
 «Postinstall script does not clear the 
mysql-server/root_password_again field». https://bugs.debian.org/815599
23:16 < BTS> Closed #814944 in mariadb-connect-engine-10.0 by Debian FTP 
Masters  «ODBC support apparently not compiled in». 
https://bugs.debian.org/814944

The appropriate mail to cont...@bugs.debian.org is already in its mail queue.

-- 
A tit a day keeps the vet away.

Bug#810506: Opinion about linux-grsec in a stable release

[Moritz Mühlenhoff]

On Wed, Mar 02, 2016 at 09:01:34PM +0100, Yves-Alexis Perez wrote:
> On mer., 2016-03-02 at 20:06 +0100, Moritz Muehlenhoff wrote:
> > Before considering that, did anyone approch grsecurity whether we can get
> > access to the grsecurity stable patches? We would most definitely have 
> > Debian
> > funds to become grsecurity sponsors to obtain access to stable patches.
> 
> I think that'd be something nice anyway, but…
> > 
> > Whether that's possible/desirable by grsecurity is the question, though:
> > Having the stable patches in Debian would make them available to the
> > general public (including those sleazy embedded companies which made them
> > change their distribution scheme).
> 
> Indeed, I didn't even bother to ask because when you gain access to the stable
> patches, you commit yourself to not make them available publicly, which is
> obviously exactly what we would do.

It's the release team's call, but IMO unless upstream changes their policy to
allow public access to stable patches again, this seems rather like a case
for a PPA or possibly backports (but they generally require backports from
what is in testing).

Cheers,
Moritz

Bug#816063: emacs24: TLS certificate validation is silently broken

[Moritz Muehlenhoff]

On Fri, Feb 26, 2016 at 09:34:33PM -0800, Nathaniel Smith wrote:
> Package: emacs24
> Version: 24.5+1-6+b1
> Severity: serious
> Tags: security
> Justification: 5(b) of https://release.debian.org/testing/rc_policy.txt
> 
> Debian's emacs builds are linked against gnutls:
> 
> (gnutls-available-p)
> t
> 
> By default, they aren't configured to validate TLS certificates,
> leaving users open to trivial MITM attacks:
> 
> (require 'gnutls)
> gnutls-verify-error
> nil
> 
> (url-retrieve-synchronously "https://wrong.host.badssl.com;)
> #
> (url-retrieve-synchronously "https://self-signed.badssl.com;)
> #
> 
> Okay, fine, but at least it is easy to turn this on:
> 
> (setq gnutls-verify-error t)
> 
> There are even some nice docs explaining how and why to do this:
>https://glyph.twistedmatrix.com/2015/11/editor-malware.html
> (Short version: if you aren't using https for the package servers --
> #797477 -- and haven't enabled TLS checking, and ever run
> package-install over coffee-shop wifi, then congratulations, you've
> just allowed anyone within wifi range to execute arbitrary code on
> your user account.)
> 
> However, Debian's emacs24 somehow manages to be so broken that turning
> on cert verification via (setq gnutls-verify-error t) *doesn't
> work*. The docs say it should work, and explain in detail how to
> configure finding the CA trust store (this is configured correctly
> out-of-the-box on Debian). And sometimes I've even had it fail on
> https://wrong.host.badssl.com after setting this (but not
> always). However, it always happily loads
> https://self-signed.badssl.com, which means it's providing no
> protection at all against MITM attacks.
> 
> Bottom line: even if you configure everything correctly, Debian's
> emacs will still happily execute whatever random code your barista
> gives you.

There don't appear to be any gnutls-specific patches in Debian's
emacs24 package, so this is most definitely an upstream bug.

Could you please report it upstream?

Cheers,
Moritz

Bug#817826: libc6: Symbol __h_errno, version GLIBC_PRIVATE, no longer exposed in libc.so.6

[Aurelien Jarno]

control: reopen -1
control: retitle -1: kdeinit4 should be restarted after glibc upgrade

On 2016-03-10 20:38, Pierre wrote:
> control: close -1
> 
> On Thursday, March 10, 2016 08:17:06 PM you wrote:
> > control: retitle -1 libc6: kmail can't find symbol __h_errno@@GLIBC_PRIVATE
> > control: tag -1 + moreinfo
> > 
> > On 2016-03-10 18:45, Pierre Ducroquet wrote:
> > > Package: libc6
> > > Version: 2.22-2
> > > Severity: important
> > > 
> > > Dear Maintainer,
> > > 
> > > After upgrading libc6 to 2.22 from 2.19 through classical apt upgrade, I
> > > noticed some applications stopped working, mainly my email client (KMail)
> > > which stopped sending emails.
> > > The following error appears now in my xsession logs :
> > > Cannot load library /usr/lib/kde4/kio_smtp.so:
> > > (/lib/x86_64-linux-gnu/libresolv.so.2: symbol __h_errno, version
> > > GLIBC_PRIVATE not defined in file libc.so.6 with link time reference)
> > The libc.so.6 exports __h_errno@@GLIBC_PRIVATE the same way in both
> > glibc 2.19 and 2.22 (and also in 2.21). So this error is clearly not a
> > missing symbol in libc.so.6.
> > 
> > Have you restarted kmail since the upgrade?
> 
> Please accept my apologies, I restarted kmail but forgot that KIO processes 
> are launched by kdeinit4, and that this process was the one to restart since 
> it forks the KIOs.

Do you know how to restart only kdeinit4 without restarting the whole
session? Or the KIOs processes only?

> Indeed there is no such problem after a complete restart of the session.

Ok. Ideally we have to find a way to fix the issue or in the worst case
display a note to the users advising them to restart the session.

I am therefore reopening the bug so that we keep track of this issue.

Thanks for you help.

Aurelien

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


signature.asc
Description: PGP signature

Bug#817839: RM: psimedia -- RoQA; depends on gstreamer 0.10

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
psimedia is one of the last three packages blocking the removal of
gstreamer 0.10, please remove it.

(It can easily re-enter once it has been ported to gstreamer 1.0)

Cheers,
Moritz

Bug#813258: [Pkg-sugar-devel] Bug#813258: sugar-record-activity: Should sugar-record-activity be removed?

[Moritz Mühlenhoff]

reassign 813258 ftp.debian.org
retitle 813258 RM: Depends on gstreamer 0.10
severity 813258 normal
thanks

On Tue, Feb 16, 2016 at 11:23:57PM +0100, Moritz Mühlenhoff wrote:
> On Sun, Jan 31, 2016 at 08:16:47AM +0530, Jonas Smedegaard wrote:
> > Quoting Moritz Muehlenhoff (2016-01-31 04:00:28)
> > > Should sugar-record-activity be removed? It depends on gstreamer, 
> > > which is scheduled for removal and there doesn't seem to be any 
> > > upstream activity to port it to modern gstreamer.
> > >
> > > Please address the outstanding bugs or reassign this to ftp.debian.org 
> > > for removal.
> > 
> > Thanks for the concern.  Upstream is quite slow but not dead, so I will 
> > keep waiting.
> 
> Ok. Since there's now only a handful of packages left using gstreamer 0.10
> I will file removal bugs for it and the remaining reverse deps in 3-4 weeks.
> 
> If sugar-record-activity can't be updated in time, it can easily re-enter
> the archive after it has been ported to gstreamer 1.0.

We're down to three remaining reverse deps of gstreamer 0.10. Doing so now.

Cheers,
Moritz

Bug#817838: RM: morituri -- RoQA; depends on gstreamer 0.10

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove morituri from unstable. It depends on gstreamer 0.10,
it's one of the three remaining rdeps blocking it's removal.

(The version in experimental has been ported to gstreamer 1.0 yet,
but isn't ready for an upload to unstable yet).

Cheers,
Moritz

Bug#817837: l2tpns: *** buffer overflow detected ***: l2tpns terminated

[Dave Reeve]

Package: l2tpns
Version: 2.2.1-1+b1
Severity: grave
Tags: patch
Justification: renders package unusable

Dear Maintainer,

Running l2tpns causes an instance crash as follows:

# l2tpns -v
*** buffer overflow detected ***: l2tpns terminated
(full trace removed as it doesn't help)

The problem exists in the ring buffer logging code.  Specially the vsprintf
is called with a length of 4095 when the size of the buffer is MAX_LOG_LENGTH
(defined as 512 in l2tpns.h).  The result is that as soon as the program is
executed it crashes as soon as a few log messages are printed.  The following
patch resolves the problem.

I also have some more minor fixes, which resolve compiler warnings.  I am happy
to share these if you let me know where to send them!

Dave 

-- Begin patch
diff --git a/l2tpns.c b/l2tpns.c
index 41e12de..2680908 100644
--- a/l2tpns.c
+++ b/l2tpns.c
@@ -268,7 +268,7 @@ void _log(int level, sessionidt s, tunnelidt t, const char 
*format, ...)
ringbuffer->buffer[ringbuffer->tail].session = s;
ringbuffer->buffer[ringbuffer->tail].tunnel = t;
va_start(ap, format);
-   vsnprintf(ringbuffer->buffer[ringbuffer->tail].message, 4095, 
format, ap);
+   vsnprintf(ringbuffer->buffer[ringbuffer->tail].message, 
MAX_LOG_LENGTH-1, format, ap);
va_end(ap);
}
 #endif
-- End patch

-- 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/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages l2tpns depends on:
ii  libc6  2.19-18+deb8u3
ii  libcli1.9  1.9.7-1

l2tpns recommends no packages.

l2tpns suggests no packages.

-- no debconf information

Bug#816982: maxima: FTBFS when built with dpkg-buildpackage -A (tests fail)

[Camm Maguire]

Greetings!

Santiago Vila  writes:

> On Wed, Mar 09, 2016 at 03:20:57PM -0500, Camm Maguire wrote:
>> Greetings!  While I still cannot reporduce this on barriere stretch,
>> please try
>> 
>> export GCL_MEM_MULTIPLE=0.2
>> 
>> before building.  Unless of course dpkg-buildpackage -A sanitizes the
>> environment, in which case please see if you can pass it on the command
>> line. 
>
> Hurrah! I confirm that the above variable makes the build to work again.
>
> [ I was using sbuild but I can always run "dpkg-buildpackage -A" by hand ]
>
> But there is a big paradox here. The machine on which it failed
> (before setting the above variable) is a QEMU/KVM virtual machine with
> 5GB of RAM and 2GB of swap.
>
> At the same time, I keep at least one successful build log for the
> same version 5.37.3-1 when the virtual machine had only 2GB of RAM
> (and the same 2GB of swap).
>
> So, it seems to me that if more available memory means the build is
> more likely to fail because of memory problems, then there is
> something fundamentally wrong in the build system.
>

Yes I've been mulling a solution, but perhaps you could suggest.

GCL is in the process of enabling full use of today's common >2Gb
memories.  We probe brk at startup to get an effective maximum heap and
manage accordingly.  We need to allow some fraction for subprocess gcc,
and perhaps some consideration for other running processes, while still
allowing the full minimal-gc power to those (e.g. ACL2) who demand it.
I need to come up with a sane default and then provide an escape setting
for the power user.

Each of the failures you reported were ENOMEM failures on fork for gcc
(invoked via compile), i.e. the heap proper was handled well within the
runtime determined limits.  I have no idea how to bound or estimate
subprocess gcc memory usage.

Take care,

> Thanks.
>
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah