Bug#809367: libqt5gui5: XEMBED interop with gtksocket broken

[Dmitry Shachnev]

Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-50212

Hi Leon,

On Tue, Dec 29, 2015 at 04:35:28PM -0500, Leon Bottou wrote:
> This bug appears when one embeds a QWindow inside a GTK socket container
> using the functions QWindow::setParent and QWindow::fromWinId().
> According to the doc, the size of the QWindow should track the size of the 
> container.
> This used to work with Qt-5.2 and no longer works with this version of Qt.

I don't think I know anything about XEmbed, so let's wait for upstream to
look at this issue. I have marked this bug as forwarded accordingly.

P.S. pygtk in the example? seriously? :)

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#809389: libvirt-daemon-system: enable libvirtd through socket activation

[Ritesh Raj Sarraf]

Package: libvirt-daemon-system
Version: 1.2.21-2
Severity: wishlist

Hello,

Do you think it'd make sense to have the libvirtd.socket activated by
default. libvirt can be used by users as a Workstation Hypervisor
replacement like VirtualBox and VMWare Workstation.

Having the daemon running all the time, when it can do the same through
systemd socket activation, might be more efficient.

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

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser  3.113+nmu3
ii  gettext-base 0.19.6-1
ii  init-system-helpers  1.24
ii  libapparmor1 2.10-2+b1
ii  libaudit11:2.4.4-4
ii  libblkid12.27.1-1
ii  libc62.21-6
ii  libcap-ng0   0.7.7-1
ii  libdbus-1-3  1.10.6-1
ii  libdevmapper1.02.1   2:1.02.114-1
ii  libnl-3-200  3.2.26-1
ii  libnl-route-3-2003.2.26-1
ii  libnuma1 2.0.11-1
ii  librados20.80.10-2
ii  librbd1  0.80.10-2
ii  libselinux1  2.4-3
ii  libsystemd0  228-2+b1
ii  libvirt-clients  1.2.21-2
ii  libvirt-daemon   1.2.21-2
ii  libvirt0 1.2.21-2
ii  libxml2  2.9.3+dfsg1-1
ii  libyajl2 2.1.0-2
ii  logrotate3.8.7-2
ii  policykit-1  0.105-14

Versions of packages libvirt-daemon-system recommends:
ii  bridge-utils  1.5-9
ii  dmidecode 3.0-2
ii  dnsmasq-base  2.75-1
ii  ebtables  2.0.10.4-3
ii  iproute2  4.3.0-1
ii  iptables  1.4.21-2+b1
ii  parted3.2-12
pn  pm-utils  

Versions of packages libvirt-daemon-system suggests:
pn  apparmor
pn  auditd  
pn  nfs-common  
pn  radvd   
ii  systemd 228-2+b1
ii  systemtap   2.9-2

-- Configuration Files:
/etc/libvirt/qemu.conf [Errno 13] Permission denied: u'/etc/libvirt/qemu.conf'
/etc/libvirt/qemu/networks/default.xml [Errno 2] No such file or directory: 
u'/etc/libvirt/qemu/networks/default.xml'

-- no debconf information

Bug#809388: evince: evince aborts after a few seconds without an error message

[Janusz S. Bień]

Package: evince
Version: 3.18.2-1
Severity: normal

I'm working on a rather sophisticated document with LuaLateX using PDF
Optional Content Groups (OCG), cf.

https://bitbucket.org/jsbien/parkosz-traktat/downloads/ParkoszLatinPolish1.pdf

(the source is available in the repository).

Evince often aborts without an error message. Looks like switching the
windows is one of the factors which trigger this, but in general I can't
see any regularities.

Tt is especially annoying when using AUC-TeX, so I mentioned the problem
first on the AUC-TeX list

http://thread.gmane.org/gmane.emacs.auctex.general/5810/focus=5812

but then nobody was able to reproduce my problem.

Best regards

Janusz

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

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

Versions of packages evince depends on:
ii  evince-common  3.18.2-1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  libatk1.0-02.18.0-1
ii  libc6  2.19-22
ii  libcairo-gobject2  1.14.4-1
ii  libcairo2  1.14.4-1
ii  libevdocument3-4   3.18.2-1
ii  libevview3-3   3.18.2-1
ii  libgdk-pixbuf2.0-0 2.32.3-1
ii  libglib2.0-0   2.46.2-3
ii  libgtk-3-0 3.18.6-1
ii  libpango-1.0-0 1.38.1-1
ii  libsecret-1-0  0.18.3-1
ii  shared-mime-info   1.5-2

Versions of packages evince recommends:
ii  dbus-x11  1.10.6-1

Versions of packages evince suggests:
ii  gvfs  1.26.2-1
ii  nautilus  3.18.4-1
ii  poppler-data  0.4.7-6
pn  unrar 

-- no debconf information

-- 
   ,   
Prof. dr hab. Janusz S. Bien -  Uniwersytet Warszawski (Katedra Lingwistyki 
Formalnej)
Prof. Janusz S. Bien - University of Warsaw (Formal Linguistics Department)
jsb...@uw.edu.pl, jsb...@mimuw.edu.pl, http://fleksem.klf.uw.edu.pl/~jsbien/

Bug#809333: musixtex: Bogus file /usr/share/texmf/fonts/map/dvips/musixtex-fonts/' in package

[Norbert Preining]

Hi Bob,

> Got it. Thanks for the report. Likely the result of hitting
> the ' key instead of Enter. It seems the tds zip doesn't
> have it.
> 
> musixtex-fonts is pretty stable. Does this warrant an
> update?

No, no new release necessary. I think you might upload a new
zip to CTAN telling them simply to replace the one there
with the new one (without the ').

Thanks

Norbert


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

Bug#809386: iceweasel: leftover legacy config file

[Mike Hommey]

On Wed, Dec 30, 2015 at 06:22:11AM +0100, Christoph Anton Mitterer wrote:
> On Wed, 2015-12-30 at 14:04 +0900, Mike Hommey wrote:
> > │   ├── debsearch.xml
> > This file still exists.
> Yes, I've seen it shortly after... and just didn't want to make more
> noise in the bug. =)
> 
> 
> > > │   └── opensearch_html.xml
> > 
> > This file has never been part of iceweasel. So either you placed it
> > here
> > and you don't remember, or some other package did.
> Then it was rather some other package (which in turn didn't clean up),
> cause the file apparently contained some stuff for DuckDuckGo and I've
> never used that...
> 
> 
> > 
> > > └── locale
> > > └── en-US
> > > 
> > > As before, the two regular files were neither created nor modified
> > > by
> > > myself, so they and the empty dirs should be be cleaned up properly
> > > in
> > > a future package version :-)
> > 
> > Seems like this should be handled by dpkg itself in a better way, or
> > debhelper, because iceweasel is merely using dpkg-maintscript-helper
> > through dh_installdeb.
> 
> Hmm quite often, when dpkg-maintscript-helpers handly legacy config
> files, I see a message first that the config file "has been moved out
> of the way"... and only at the end there's the actual remove (as it was
> here as well).
> Could it possibly be, that some step or parameter might have been
> forgotten?

I don't think so.

Mike

Bug#809386: iceweasel: leftover legacy config file

[Christoph Anton Mitterer]

On Wed, 2015-12-30 at 14:04 +0900, Mike Hommey wrote:
> │   ├── debsearch.xml
> This file still exists.
Yes, I've seen it shortly after... and just didn't want to make more
noise in the bug. =)


> > │   └── opensearch_html.xml
> 
> This file has never been part of iceweasel. So either you placed it
> here
> and you don't remember, or some other package did.
Then it was rather some other package (which in turn didn't clean up),
cause the file apparently contained some stuff for DuckDuckGo and I've
never used that...


> 
> > └── locale
> > └── en-US
> > 
> > As before, the two regular files were neither created nor modified
> > by
> > myself, so they and the empty dirs should be be cleaned up properly
> > in
> > a future package version :-)
> 
> Seems like this should be handled by dpkg itself in a better way, or
> debhelper, because iceweasel is merely using dpkg-maintscript-helper
> through dh_installdeb.

Hmm quite often, when dpkg-maintscript-helpers handly legacy config
files, I see a message first that the config file "has been moved out
of the way"... and only at the end there's the actual remove (as it was
here as well).
Could it possibly be, that some step or parameter might have been
forgotten?


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#809386: iceweasel: leftover legacy config file

[Mike Hommey]

On Wed, Dec 30, 2015 at 05:29:35AM +0100, Christoph Anton Mitterer wrote:
> Just noted that there's more:
> Unpacking iceweasel (43.0.2-1) over (38.5.0esr-1) ...
> dpkg: warning: unable to delete old directory 
> '/etc/iceweasel/searchplugins/locale/en-US': Directory not empty
> dpkg: warning: unable to delete old directory 
> '/etc/iceweasel/searchplugins/locale': Directory not empty
> ...
> and only later on:
> ...
> Removing obsolete conffile 
> /etc/iceweasel/searchplugins/locale/en-US/amazondotcom.xml ...
> Removing obsolete conffile /etc/iceweasel/searchplugins/locale/en-US/bing.xml 
> ...
> Removing obsolete conffile /etc/iceweasel/searchplugins/locale/en-US/ddg.xml 
> ...
> Removing obsolete conffile /etc/iceweasel/searchplugins/locale/en-US/eBay.xml 
> ...
> Removing obsolete conffile 
> /etc/iceweasel/searchplugins/locale/en-US/google.xml ...
> Removing obsolete conffile 
> /etc/iceweasel/searchplugins/locale/en-US/twitter.xml ...
> Removing obsolete conffile 
> /etc/iceweasel/searchplugins/locale/en-US/wikipedia.xml ...
> Removing obsolete conffile 
> /etc/iceweasel/searchplugins/locale/en-US/yahoo.xml ...
> 
> 
> with the following left back:
> $ tree /etc/iceweasel/searchplugins/
> /etc/iceweasel/searchplugins/
> ├── common
> │   ├── debsearch.xml

This file still exists.

> │   └── opensearch_html.xml

This file has never been part of iceweasel. So either you placed it here
and you don't remember, or some other package did.

> └── locale
> └── en-US
> 
> As before, the two regular files were neither created nor modified by
> myself, so they and the empty dirs should be be cleaned up properly in
> a future package version :-)

Seems like this should be handled by dpkg itself in a better way, or
debhelper, because iceweasel is merely using dpkg-maintscript-helper
through dh_installdeb.

Mike

Bug#809300: util/pkg-list lists udeb dependencies for excluded udebs

[Cyril Brulebois]

Hi,

Martin Michlmayr  (2015-12-28):
> The following workaround works for me but I'm not sure if it's the
> right approach.
> 
> diff --git a/build/util/pkg-list b/build/util/pkg-list
> index 29c56c9..6ef74b8 100755
> --- a/build/util/pkg-list
> +++ b/build/util/pkg-list
> @@ -101,9 +101,13 @@ sub collectpackage {
>   }
>   else {
>   my $package=$line;
> +if (exists $exclude->{$package}) {
> +  debug 0, "ignored skipped $package";
> +} else {
>   $collect->{$package}=1;
>   debug 0, "adding $package";
>   collectdeps($package, $collect, $postponed);
> +}
>   }
>  }

I'm travelling these days so can't really look, but it would be nice if
someone could double check what happens in d-i daily builds before/after
such a change.

Probably easiest by logging in on dillon and diffing files there. Feel
free to poke me after a commit so that I can look into doing so.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#809386: iceweasel: leftover legacy config file

[Christoph Anton Mitterer]

Just noted that there's more:
Unpacking iceweasel (43.0.2-1) over (38.5.0esr-1) ...
dpkg: warning: unable to delete old directory 
'/etc/iceweasel/searchplugins/locale/en-US': Directory not empty
dpkg: warning: unable to delete old directory 
'/etc/iceweasel/searchplugins/locale': Directory not empty
...
and only later on:
...
Removing obsolete conffile 
/etc/iceweasel/searchplugins/locale/en-US/amazondotcom.xml ...
Removing obsolete conffile /etc/iceweasel/searchplugins/locale/en-US/bing.xml 
...
Removing obsolete conffile /etc/iceweasel/searchplugins/locale/en-US/ddg.xml ...
Removing obsolete conffile /etc/iceweasel/searchplugins/locale/en-US/eBay.xml 
...
Removing obsolete conffile /etc/iceweasel/searchplugins/locale/en-US/google.xml 
...
Removing obsolete conffile 
/etc/iceweasel/searchplugins/locale/en-US/twitter.xml ...
Removing obsolete conffile 
/etc/iceweasel/searchplugins/locale/en-US/wikipedia.xml ...
Removing obsolete conffile /etc/iceweasel/searchplugins/locale/en-US/yahoo.xml 
...


with the following left back:
$ tree /etc/iceweasel/searchplugins/
/etc/iceweasel/searchplugins/
├── common
│   ├── debsearch.xml
│   └── opensearch_html.xml
└── locale
└── en-US

As before, the two regular files were neither created nor modified by
myself, so they and the empty dirs should be be cleaned up properly in
a future package version :-)

Thanks,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#809387: ITP: select2.js -- jQuery based replacement for select boxes

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: select2.js
  Version : 4.0.1~dfsg1-1
  Upstream Author :  Kevin Brown, Igor Vaynberg, and Select2 contributors
* URL : https://github.com/select2/select2
* License : Expat
  Programming Lang: Javascript
  Description :  jQuery based replacement for select boxes

This is needed for Mailpile
-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#809386: iceweasel: leftover legacy config file

[Christoph Anton Mitterer]

Package: iceweasel
Version: 43.0.2-1
Severity: normal


Hi.

Apparently, iceweasel once contained the conffile:
/etc/iceweasel/iceweaselrc
which no longer seems to be part of the package, but
which wasn't properly cleaned up so far.

Could you please repeat that in one of the followin
uploads using the maint scripts, so that users won't
have that stale config file laying around forever.

Thanks,
Chris.

Bug#808538: RFS: corebird

[Paul Wise]

On Wed, Dec 30, 2015 at 2:16 AM, Philip Rinn wrote:

> I removed the "--parallel" now.

If the upstream build system supports parallel builds, you are just
wasting buildd time by removing that option, please put it back in.

The only reason that it isn't the default yet is because not all
upstream build systems work when run in parallel mode.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#808613: RFS: re2c/0.15.3-1 [ITA] -- tool for generating fast C-based recognizers

[Paul Wise]

On Wed, Dec 30, 2015 at 12:30 AM, Adam Borowski wrote:

> Debugging the failure requires access to a machine, real or emulated, of one
> of architectures that fail.  I suspect that you have no mips, powerpc,
> s390x, hppa or sparc64 machines lying around -- and access to Debian's
> porterboxes is restricted to DDs only which makes using them greatly
> unconvenient.  Thus, I'd strongly recommend using qemu.

Temporary access to Debian porterboxen can be arranged:

https://dsa.debian.org/doc/guest-account/

qemu is probably quicker to setup though, but may be slower.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#808846: abook in Testing

[Denis Briand]

tags 808846 pending
thanks

Hello,
It will be uploaded soon (few days)
regards

Denis Briand


signature.asc
Description: PGP signature

Bug#749079: src:msgpack: New upstream release fixes compilation on ARM (and more)

[James McCoy]

On Wed, Dec 30, 2015 at 08:09:23AM +0530, Jonas Smedegaard wrote:
> Quoting Tomasz Buchert (2015-12-30 07:53:37)
> > this package looks a bit unmaintained. I've prepared a new release of 
> > version 1.3.0 which is in /git/collab-maint/msgpack-ng.git for you to 
> > try. I've done a lot of changes and now it is nearly lintian clean + 
> > supports multi-arch.
> >
> > According to mia-query, Taku hasn't been active for some time.
> > What should we do?
> 
> You can make an NMU of your new release if you feel confident that it 
> does not introduce new bugs and have been careful to keep packaging 
> changes to a minimum (i.e. the normal for NMUs).
> 
> Also, it would then make sense to get in touch with the MIA team to 
> start the process on either (preferrably) finding a way to get in touch 
> with current maintainer or else have someone else take over.

I've tried to contact Taku a couple times (both via this bug and
privately) and emailed MIA about it.  MIA seems a little MIA since there
haven't been any updated to the db.

I had been planning on taking over msgpack, but hadn't finished working
on it yet.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#809365: call stack added

[ChenQin]

Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x74e5a5c8 in strncasecmp () from /usr/lib/x86_64-linux-gnu/libasan.so.0
gdb-peda$ bt
#0  0x74e5a5c8 in strncasecmp () from 
/usr/lib/x86_64-linux-gnu/libasan.so.0
#1  0x00474954 in maker_number (make=0x0) at maker_generic.c:741
#2  process_makernote (inptr=inptr@entry=0x6036fd80, 
byteorder=byteorder@entry=0x4d4d, maker_entry=maker_entry@entry=0x789f80 
, fileoffset_base=fileoffset_base@entry=0xc, 
max_offset=max_offset@entry=0x332303c, 
summary_entry=summary_entry@entry=0x60280001fb40, 
parent_name=parent_name@entry=0x6006efe0 "JPEG.APP1.Ifd0.Exif", 
indent=indent@entry=0x8) at maker_generic.c:137
#3  0x004448f4 in process_exif_ifd (inptr=inptr@entry=0x6036fd80, 
byteorder=byteorder@entry=0x4d4d, exif_offset=, 
fileoffset_base=fileoffset_base@entry=0xc, max_offset=max_offset@entry=0x63c, 
summary_entry=summary_entry@entry=0x60280001fb40, 
parent_name=parent_name@entry=0x6004dfd0 "JPEG.APP1.Ifd0", 
ifdnum=ifdnum@entry=0x0, indent=0x8, indent@entry=0x6) at process.c:1958
#4  0x0043c6be in process_tiff_ifd (inptr=inptr@entry=0x6036fd80, 
byteorder=, ifd_offset=0x8, 
fileoffset_base=fileoffset_base@entry=0xc, max_offset=0x63c, 
max_offset@entry=0x0, summary_entry=, 
summary_entry@entry=0x60280001fcc0, 
parent_name=parent_name@entry=0x6004dff0 "JPEG.APP1", 
ifdtype=ifdtype@entry=0x0, ifdnum=ifdnum@entry=0x0, 
subifdnum=subifdnum@entry=0x, indent=0x6, indent@entry=0x4) at 
process.c:674
#5  0x004478bd in process_app1 (inptr=inptr@entry=0x6036fd80, 
app1_offset=app1_offset@entry=0x2, tag=tag@entry=0xffe1, 
summary_entry=summary_entry@entry=0x60280001fcc0, 
parent_name=parent_name@entry=0x502600 "JPEG", indent=indent@entry=0x2) at 
process.c:3893
#6  0x0044a56e in process_jpeg_segments 
(inptr=inptr@entry=0x6036fd80, marker_offset=, 
tag=, tag@entry=0xffd8, data_length=data_length@entry=0x0, 
summary_entry=summary_entry@entry=0x60280001fcc0, 
parent_name=parent_name@entry=0x502600 "JPEG", prefix=prefix@entry=0x502540 
"@", indent=indent@entry=0x0) at process.c:3082
#7  0x00403a5d in main (argc=, argv=0x7fffe838) at 
main.c:210
#8  0x74798a40 in __libc_start_main () from 
/lib/x86_64-linux-gnu/libc.so.6
#9  0x00405d69 in _start ()

Bug#809385: fbi: Please build ida from fbida now that libmotif is free

[G.raud]

Package: fbi
Version: 2.09-1+b1
Severity: wishlist

I can build fbida 2.10
(https://www.kraxel.org/releases/fbida/fbida-2.10.tar.gz) with motif
enabled on Debian jessie.  Please enable libmotif during the
configuration so that the program ida is built.

Regards,

-- 
G.raud Meyer

Bug#749079: src:msgpack: New upstream release fixes compilation on ARM (and more)

[Jonas Smedegaard]

Quoting Tomasz Buchert (2015-12-30 07:53:37)
> On 20/09/15 23:03, James McCoy wrote:
>> On Fri, May 23, 2014 at 10:21:27PM +0200, Jonas Smedegaard wrote:
>>> New upsstream release 0.5.8 was announced here: 
>>> https://github.com/msgpack/msgpack-c/releases
>>>
>>> That release includes a bugfix for ARM (already fixed in code copy 
>>> in Perl module Data::MessagePack) and seemingly numerous other fixes 
>>> for 32bit archs.  Hence I dare raise severity of this bugreport.
>>
>> A few more releases have happened in the interim, one of which is 
>> needed for a project I'm working on packaging.
>>
>> Taku, will you have time to work on this soon, or would you welcome 
>> some help with the package?

> this package looks a bit unmaintained. I've prepared a new release of 
> version 1.3.0 which is in /git/collab-maint/msgpack-ng.git for you to 
> try. I've done a lot of changes and now it is nearly lintian clean + 
> supports multi-arch.
>
> According to mia-query, Taku hasn't been active for some time.
> What should we do?

You can make an NMU of your new release if you feel confident that it 
does not introduce new bugs and have been careful to keep packaging 
changes to a minimum (i.e. the normal for NMUs).

Also, it would then make sense to get in touch with the MIA team to 
start the process on either (preferrably) finding a way to get in touch 
with current maintainer or else have someone else take over.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#809384: ITP: list.js -- perfect library for adding search, sort, filters and flexibility to HTML elements

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: list.js
  Version : 1.1.1~dfsg1-1
  Upstream Author : Jonny Strömberg 
* URL : https://github.com/javve/list.js
* License : Expat
  Programming Lang: Javascript
  Description : perfect library for adding search, sort, filters and
flexibility to HTML elements

This is needed for Mailpile
-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#749079: src:msgpack: New upstream release fixes compilation on ARM (and more)

[Tomasz Buchert]

On 20/09/15 23:03, James McCoy wrote:
> On Fri, May 23, 2014 at 10:21:27PM +0200, Jonas Smedegaard wrote:
> > New upsstream release 0.5.8 was announced here:
> > https://github.com/msgpack/msgpack-c/releases
> > 
> > That release includes a bugfix for ARM (already fixed in code copy in
> > Perl module Data::MessagePack) and seemingly numerous other fixes for
> > 32bit archs.  Hence I dare raise severity of this bugreport.
> 
> A few more releases have happened in the interim, one of which is needed
> for a project I'm working on packaging.
> 
> Taku, will you have time to work on this soon, or would you welcome some
> help with the package?
> 
> Cheers,
> -- 
> James
> GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Hi All,
this package looks a bit unmaintained. I've prepared a new release
of version 1.3.0 which is in /git/collab-maint/msgpack-ng.git for
you to try. I've done a lot of changes and now it is nearly lintian clean
+ supports multi-arch.

According to mia-query, Taku hasn't been active for some time.
What should we do?

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#809204: busybox is required but not installed

[積丹尼 Dan Jacobson]

> "BH" == Ben Hutchings  writes:
>> OK, but you are still going to run into problems if the user has set
>> 
>> # apt-config dump|egrep Rec\|Sugg
>> APT::Install-Recommends "false";
>> APT::Install-Suggests "0";

BH> Users that do that need to accept that they will encounter errors like
BH> this.

OK, but I am sure yours is the very first package to "lower the
barrier" of
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
in that way.

In the past an entire working Debian could be completely installed counting on 
only
Depends.

Or maybe
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
needs to have some additional explanation about special cases like this?

Bug#809383: mention explicitly double listing: Depends, Recommends, Suggests

[積丹尼 Dan Jacobson]

Package: debian-policy
Severity: wishlist

On
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
please add an explicit statement:

A package listed in Depends must not also be listed in Suggests or
Recommends.

Or

A package listed in Depends may also be listed in Suggests or
Recommends.

E.g.,

$ apt-cache show initramfs-tools-core | grep busy
Depends: klibc-utils (>= 2.0-1~), cpio, kmod | module-init-tools, udev, 
klibc-utils (>= 2.0.4-1.2~) | busybox (>= 1:1.01-3) | busybox-initramfs | 
busybox-static
Recommends: busybox (>= 1:1.01-3) | busybox-initramfs | busybox-static

Also clarify there if a package can be listed both in Suggests and
Recommends. In fact perhaps add a table, showing for all of them
(Enhances, etc.) which can be combined with which...

Bug#807040: general: System hangs and then restarts (kernel panic)

[Nigra Truo]

So I was forced to downgrade to Debian Wheezy and I had some people that
were constantly telling me that this must be a hardware issue, and it is
not. Wheezy works perfectly on this laptop, no crashes, no nothing, stable
as a rock.
Now I still have an image on a seperate harddisk to troubleshoot this, as I
obviously don't like to just have to skip Jessie and wait for a few years,
while running the old obsolete Debian.
Is there any way this bug will be attempted to fix or will Debian Jessie
just not run on a Lenovo T61 Laptop ever?

Thanks,

Markus

On Wed, Dec 23, 2015 at 3:28 PM, Nigra Truo  wrote:

> Hi,
>
> Sorry, I was getting a little negative, this is really hard. I appreciate
> any help you can give.
> If I had the kernel logs, could you do something with them and help
> determine what crashed.
> I set up kexec, kdump to collect the logs.
>
> Thanks,
>
> Markus
>
> On Tue, Dec 22, 2015 at 3:57 AM, Nigra Truo  wrote:
>
>> Hi Sven,
>>
>>
>>
>> On Mon, Dec 21, 2015 at 1:55 PM, Sven Joachim  wrote:
>>
>>> On 2015-12-11 08:20 +0100, Adam Borowski wrote:
>>>
>>> > On Thu, Dec 10, 2015 at 07:17:43PM -0800, Nigra Truo wrote:
>>> >> That does not work neither unfortunately. I installed the proprietary
>>> >> driver and now X crashes. At least the whole machine does not crash,
>>> but I
>>> >> can open a Desktop, KDE or Gnome, then open an app, maximize the
>>> window and
>>> >> I get a prompt crash.
>>> >
>>> > Oif.  I'm afraid I can't help you further here -- I'm a mere user when
>>> it
>>> > comes to X drivers.  I could help with installing a newer version or an
>>> > alternate driver, but for more, we need actual driver guys :(
>>>
>>> Problem is, there is no such person in Debian for the nouveau driver.
>>>
>>
>> Who will fix this then when nobody is in charge then?
>> This problem is a huge disaster, I had about 25 restarts today already
>> and can't work like this and will need to downgrade to have a stable system
>> to work and troubleshoot this on the side on a test harddisk, as a test
>> system as a system of this instable magnitude needs to be treated.
>>
>>
>>
>>>
>>> >> The unability to get logs in the Kernel Panic is a huge problem, I
>>> can't
>>> >> believe that this his still not solved, that there is no automatic
>>> >> mechanism, to at least see what caused the panic or, for the matter,
>>> >> logging that ANY panic has occurred. Right now, the most serious of
>>> errors
>>> >> does not have any accounting whatsoever.
>>
>> >
>>> > When the kernel panics, most of its facilities are considered dead.
>>> Doing
>>> > something as complex as a filesystem write would require temporarily
>>> > ignoring the panic, with a huge risk of data corruption.  A generally
>>> pretty
>>> > bad idea.
>>>
>>
>> I don't know how Windows does it, but it does remember that there was a
>> bluescreen. If Windows can, so can Linux.
>> Right now, I can't stop my system from restarting, I don't know what the
>> hell is restarting it, if it is the watchdog service, which I deactivated
>> in the kernel (and it still restarts), when I push some keys, it shows the
>> kernel panic and shows the message "rebooting in 30 seconds" and when I do
>> a google search, there is absolutely no reference or documentation about
>> what that is, what is causing it and WHO is doing it, why the reboot?
>> As of Debian Wheezy, there as absolutely no restarting when the kernel
>> paniced and that is the way it needs to be.
>> Now with the new kernel, it just restarts, and could easily go into a
>> reboot loop, endlessly restarting. Also, it does not show anything in the
>> logs, there is absolutely nothing on the system that shows the system had a
>> panic or that it even crashed, which is totally horrendous, considering
>> that you could have data loss and never know about it. I don't understand
>> why this is solved so pathetically and half baked in the kernel.
>>
>> I wrote a little tool some years ago, when I was astonished at this, that
>> does a really "complex" (I'm purposefully sarcastic here) functionality,
>> that can tell if the system crashed, by removing a file when shutting down
>> gracefully. If the file is there still when starting up, the system crashed
>> in a panic.
>> Now, 5 years later, I'm amazed and shocked that I seem to be the only
>> person on earth that can actually tell that there has been a panic on my
>> system.
>> Due to this annoying auto restart, transparency has been lost and your
>> system could restart 40 times on a server and have massive data loss,  you
>> would never know it.
>>
>>  As you can see, I'm not happy about this whole mess. I now spend up to
>> 20 hours troubleshooting this problem and am no closer to solve this except
>> knowing that I will have to downgrade if I want to use my laptop to work
>> again.
>>
>>
>> >
>>> > Thus, you'd need to pass the remaining piece of the log somehow.  Ways
>>> to do
>>> > so include:
>>> > * a serial console.  My main desktop box happens to include a real

Bug#809382: add Table of Contents or some way to get at anchors

[積丹尼 Dan Jacobson]

Package: debian-policy
Severity: wishlist

User browses
https://www.debian.org/doc/debian-policy/ch-relationships.html

User sees
7.2 Binary Dependencies - Depends, Recommends, Suggests, Enhances, Pre-Depends

User would like to make a URL that directly links to that section.

In fact

https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

is what he wants.

Alas he needs to explore the HTML source of
https://www.debian.org/doc/debian-policy/ch-relationships.html to
construct it.

Bug#809381: ITP: typeahead.js -- fast and fully-featured autocomplete library

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: typeahead.js
  Version : 0.11.1~dfsg1-1
  Upstream Author : Twitter, Inc
* URL : http://twitter.github.io/typeahead.js/
* License : Expat
  Programming Lang: Javascript
  Description : fast and fully-featured autocomplete library

This is needed for Mailpile



signature.asc
Description: OpenPGP digital signature

Bug#809204: busybox is required but not installed

[Ben Hutchings]

On Wed, 2015-12-30 at 08:16 +0800, 積丹尼 Dan Jacobson wrote:
> > > > > > "BH" == Ben Hutchings  writes:
> 
> BH> Wrong, initramfs-tools-core does (and initramfs-tools used to do so
> BH> directly).
> 
> OK, but you are still going to run into problems if the user has set
> 
> # apt-config dump|egrep Rec\|Sugg
> APT::Install-Recommends "false";
> APT::Install-Suggests "0";

Users that do that need to accept that they will encounter errors like
this.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.

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

Bug#809380: RFP: xul-ext-dns-cache -- allows to disable/enable or manually flush the DNS Cache of Firefox

[Christoph Anton Mitterer]

Package: wnpp
Severity: wishlist

* Package name: xul-ext-dns-cache
  Version : 1.8.1.1
  Upstream Author : Dominik Jungowski
* URL : https://addons.mozilla.org/de/firefox/addon/dns-cache/
* License : MPL 1.1
  Programming Lang: XUL/JavaScript
  Description : allows to disable/enable or manually flush the DNS Cache of 
Firefox

The internal DNS cache of FF is a disesase... it breaks all kinds of stuff as 
it doesn't
follow the rules of DNS (e.g. TTLs).
This plugin allows to easily get rid of that misfeature.

Bug#809379: xul-ext-pentadactyl: compatibility broken with iceweasel 43

[Brian Paterni]

Package: xul-ext-pentadactyl
Version: 1.2~hg7166-1
Severity: important

Dear Maintainer,

xul-ext-pentadactyl is now incompatible with iceweasel 43 (recently uploaded to
unstable)



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

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

Versions of packages xul-ext-pentadactyl depends on:
ii  iceweasel  43.0.2-1

xul-ext-pentadactyl recommends no packages.

xul-ext-pentadactyl suggests no packages.

Bug#688741: (no subject)

[Jaakov]

found 688741 gdm3/3.14.1-7
thanks
# It is there in stable...

Bug#809324:

[Dionisio E Alonso (Baco)]

I can confirm the error. I've already experienced that even when Linux
4.3 was in either experimental or unstable, but couldn't do further
tests because it I don't use that workstation everyday.

regards,
-- 
Dionisio

Bug#809296: Thanks for the quick action!

[Markus Koschany]

Am 30.12.2015 um 01:40 schrieb Frank McCormick:
> Appreciate it...even if I am one of the few running wbar :)

You're welcome. :)




signature.asc
Description: OpenPGP digital signature

Bug#809296: Thanks for the quick action!

[Frank McCormick]

Appreciate it...even if I am one of the few running wbar :)

--
Do not handicap your children by making their lives easy.
 -- Robert Heinlein--Time Enough For Love--

Bug#809378: linux-libc-dev missing direct rendering manager headers

[Nebuchadnezzar III]

Package: linux-libc-dev
Version: 3.16.7-ckt20-1+deb8u1
Severity: normal

Dear Maintainer,

I wanted to write some C code to learn the Direct Rendering Manager interface,
without using libdrm. Googling found me this tutorial [1]. I didn't get very far
because I was missing . "Userspace headers from the Linux kernel" are
both provided by linux-libc-dev and present in the include/uapi directory of the
linux-headers of /usr/src. My /usr/src/linux-headers-3.16.../include/uapi has
nine directories: asm-generic, drm, linux, mtd, rdma, scsi, sound, video, and
xen. All of these except drm and scsi are in linux-libc-dev, and libc6 has scsi.
Extensive googling has led me to believe that no Debian package other than the
linux-headers has the drm headers, and none have them in /usr/include. It seems
like this package should include the drm headers.

Thank you for your consideration.

[1]: http://betteros.org/tut/graphics1.php#dumb
[2]: 
https://web.archive.org/web/20150815051638/http://betteros.org/tut/graphics1.php

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

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

-- no debconf information

Bug#809377: ITP: jquery-ui-touch-punch.js -- duck punch for adding touch events to jQuery UI

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: jquery-ui-touch-punch.js
  Version : 0.0~git20141218.2.4bc0091+dfsg1-1
  Upstream Author : Dave Furfero 
* URL : https://github.com/furf/jquery-ui-touch-punch
* License : Expat
  Programming Lang: Javascript
  Description : duck punch for adding touch events to jQuery UI

This is needed for Mailpile

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#809204: busybox is required but not installed

[積丹尼 Dan Jacobson]

> "BH" == Ben Hutchings  writes:

BH> Wrong, initramfs-tools-core does (and initramfs-tools used to do so
BH> directly).

OK, but you are still going to run into problems if the user has set

# apt-config dump|egrep Rec\|Sugg
APT::Install-Recommends "false";
APT::Install-Suggests "0";

Bug#570492: aptitude: TUI reselects just removed packages for installation

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo unreproducible


Hi Sven,

2010-02-19 09:20 Sven Joachim:

Package: aptitude
Version: 0.6.1.5-2
Severity: normal

Start aptitude as a normal user and select a package (preferably a leaf
package) for removal or purge.  Press 'g' twice and become root, press
'g' twice again to actually remove the package.

Now aptitude will display "Will use kB of disk space", and if you
press 'g' again you'll notice that the just removed package is marked
for installation.


I cannot reproduce this with 0.7.5, the version currently in unstable.
Can you still reproduce it nowadays?

There have been changes related to this in the last few versions which
maybe fixed this behaviour, for example:


0.7.5

 * Save state before package reconfiguration (to not be lost) (Closes: #474876)

0.7.3

 * Update internal state for upgrades/downgrades with target version after the
   action is performed (Closes: #787658, #714429)

   Thanks to David Kalnischkies and Julian Andres Klode from APT team for their
   help, clues and patience.  It took some serious effort to get to this fix,
   which in the end is quite modest in terms of code changes.

   Internal state was neither reset nor written to disk until other packages'
   states changed, so aptitude marked the same action on the packages as
   pending to be performed again and again (but the action had already been
   taken, so there was no observable effect in terms of installations).

   However, this meant that the packages that were downgraded to older versions
   when newer were still available (e.g., mixing stable and unstable), was not
   shown as "Upgradable" neither in the current sessions nor in subsequent
   sessions (under Upgradable subtree in interactive mode; or command line like
   "aptitude search ~U"), until the file pkgstates was written to disk because
   of changes in other packages.


Maybe other previous changes in the 0.6.* series, after the version in
which you reported it, fixed this as well.

Unless you can reproduce it, I guess that some other change fixed this
problem without this bug being closed.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#809296: wbar-config in same package garbles the config file.

[Markus Koschany]

Control: tags -1 confirmed
Control: reassign -1 wbar-config

Am 29.12.2015 um 03:48 schrieb Frank McCormick:
> Package: wbar
> Version: 2.3.4-4
> Severity: normal
> 
> Making changes to the wbar configuration using wbar-config garbles the second 
> line
> of the $HOME/.wbar file which normally contains the parameters to wbar.
> Running wbar after that places the wbar image in a seemingly arbitrary manner 
> on
> the screen.
> 
> I haven't run wbar for sometime and this behavior just started so it might
> be changes in one of the other libraries wbar depands on. Just a guess.

Hello,

thanks for the report. It seems the clang-FTBFS.patch introduced this
regression and I am going to revert it.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#809347: [Aptitude-devel] Bug#809347: mention try second identical run

[積丹尼 Dan Jacobson]

MAFM>  safe-upgrade && full-upgrade
MAFM>  ...

MAFM>  If no s are listed on the command line, aptitude will attempt
MAFM>  to upgrade every package that can be upgraded. Otherwise, aptitude
MAFM>  will attempt to upgrade only the packages which it is instructed to
MAFM>  upgrade. The s can be extended with suffixes in the same
MAFM>  manner as arguments to aptitude install, so you can also give
MAFM>  additional instructions to aptitude here; for instance, aptitude
MAFM>  safe-upgrade bash dash- will attempt to upgrade the bash package and
MAFM>  remove the dash package.

Well this should also mention how
# aptitude safe-upgrade
# aptitude safe-upgrade

or

# aptitude full-upgrade
# aptitude full-upgrade

will do more sometimes than just the single versions.
Because else the reader must somehow read between the lines to figure it
out.
It would be nice if all children would know that flushing the toilet
twice sometimes helps, but some will just give up after the first
failure.

Especially upon seeing
"E: Unable to correct for unavailable packages"
they might abandon hope. So maybe that should also say
"E: Unable to correct for unavailable packages. Maybe try running again..."

Bug#808949: [pkg-lynx-maint] Bug#808949: Bug#808949: U+200F RIGHT-TO-LEFT MARK shows up on screen

[積丹尼 Dan Jacobson]

Yes, I don't see the point of

https://phabricator.wikimedia.org/T9945

In xterm, do you see two dotted boxes when you do
$ unicode U+200E; unicode U+200F
Boxes not seen in emacs shell window.
So maybe this is an xterm bug.

Wait. See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408835

Bug#804888: djview plugin unusable in debian testing...

[Leon Bottou]

Rethreading to l...@bottou.org






On 12/29/15, 6:28 PM, "Leon Bottou"  wrote:

>I've already reported a bug against qt5 for this  with a little test case.
>
>
>
>And also a bug upstream referencing the debian bug...
>
>- L.
>
>
>
>
>
>On 12/29/15, 5:12 PM, "Barak A. Pearlmutter"  wrote:
>
>>So maybe the best thing would be to file a bug against qt5, fix things
>>in this package by using qt4, and filing a wishlist bug against this
>>package to use qt5, with a "blocked by" referring to the qt5 bug
>>report above. That way when the qt5 issue is resolved the wishlist bug
>>will be unblocked and notifications will flow...

Bug#779490: Any progress on three.js?

[David Bremner]

"W. Martin Borgert"  writes:

> On 2015-08-21 18:33, David Bremner wrote:
>> If someone else wants to pick up what is in collab-maint and run
>> with it (i.e. change maintainer and re-upload, perhaps with the JS
>> team), I would be happy to let it go.
>
> OK, I gave it another try. I added the missing copyright,
> used the latest upstream, and removed more non-source files.
> It's in NEW, again. Thanks for your work, David!

Great, thanks for picking up the job.

David

Bug#809347: [Aptitude-devel] Bug#809347: mention try second identical run

[Manuel A. Fernandez Montecelo]

2015-12-29 17:55 Axel Beckert:

Hi Jidanni,

積丹尼 Dan Jacobson wrote:

Aptitude has a neat feature that I am not sure is documented on the man
page:

In the case that some of the packages cannot be retrieved, a second run
of aptitude will install the ones that can!


Indeed.


So perhaps on the man page mention that a second identical run of e.g.,
safe-upgrade, full-upgrade, will proceed to install available packages
that a first run couldn't.


But safe-upgrade and full-upgrade are the wrong examples. They do this
anyway. Also "apt upgrade" and friends do this. That's the idea of all
"upgrade" subcommands: Upgrade (more or less) all upgradable
packages -- independent of if there was a try to upgrade them before.

The nice thing is that aptitude stores installation wishes in general
and the next action will also fulfil them.

E.g. if for "aptitude install pkg1 pkg2" the installation of pkg2
fails, another "aptitude install" without further parameters will try
to install pkg2 again.


All this is documented in the man page, I think:


 install
 ...

 As a special case, “install” with no arguments will act on any
 stored/pending actions.

 Note

 Once you enter Y at the final confirmation prompt, the “install”
 command will modify aptitude's stored information about what actions
 to perform.

 Therefore, if you issue (e.g.) the command “aptitude install foo bar”
 and then abort the installation once aptitude has started downloading
 and installing packages, you will need to run “aptitude remove foo
 bar” to cancel that order.


 safe-upgrade && full-upgrade
 ...

 If no s are listed on the command line, aptitude will attempt
 to upgrade every package that can be upgraded. Otherwise, aptitude
 will attempt to upgrade only the packages which it is instructed to
 upgrade. The s can be extended with suffixes in the same
 manner as arguments to aptitude install, so you can also give
 additional instructions to aptitude here; for instance, aptitude
 safe-upgrade bash dash- will attempt to upgrade the bash package and
 remove the dash package.



Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#809376: [request-tracker-maintainers] Bug#809376: rt4-fcgi: support systemd init natively

[Dominic Hargreaves]

On Tue, Dec 29, 2015 at 11:29:41PM +, Dominic Hargreaves wrote:
> Package: rt4-fcgi
> Version: 4.2.12-4
> Severity: wishlist
> Tags: patch
> Control: submitter -1 cl...@netsandbox.de
> 
> - Forwarded message from Christian Loos  -
> 
> Date: Fri, 18 Dec 2015 15:56:49 +0100
> From: Christian Loos 
> To: d...@earth.li, rt-users 
> Subject: rt4 fcgi systemd service unit file
> 
> Hi Dominic,
> 
> I noticed that you still use an init script for your rt4-fcgi Debian
> package in jessie. I've created a systemd service unit file [1], which
> works fine for me. Maybe you can update your package with this one.
> 
> Chris
> 
> [1] https://gist.github.com/cloos/abbadf961558bb9cdc7e

Hi Chris,

Thanks for this. I noticed that your service unit file does not include
any mention of a dependency on mysql or postgresql; something that was
recently added to the init script exactly for systemd compatibility.
Do you know if this should be added to the unit file too?

Cheers,
Dominic.

Bug#809376: rt4-fcgi: support systemd init natively

[Dominic Hargreaves]

Package: rt4-fcgi
Version: 4.2.12-4
Severity: wishlist
Tags: patch
Control: submitter -1 cl...@netsandbox.de

- Forwarded message from Christian Loos  -

Date: Fri, 18 Dec 2015 15:56:49 +0100
From: Christian Loos 
To: d...@earth.li, rt-users 
Subject: rt4 fcgi systemd service unit file

Hi Dominic,

I noticed that you still use an init script for your rt4-fcgi Debian
package in jessie. I've created a systemd service unit file [1], which
works fine for me. Maybe you can update your package with this one.

Chris

[1] https://gist.github.com/cloos/abbadf961558bb9cdc7e


- End forwarded message -

Bug#804888: djview plugin unusable in debian testing...

[Leon Bottou]

I've already reported a bug against qt5 for this  with a little test case.



And also a bug upstream referencing the debian bug...

- L.





On 12/29/15, 5:12 PM, "Barak A. Pearlmutter"  wrote:

>So maybe the best thing would be to file a bug against qt5, fix things
>in this package by using qt4, and filing a wishlist bug against this
>package to use qt5, with a "blocked by" referring to the qt5 bug
>report above. That way when the qt5 issue is resolved the wishlist bug
>will be unblocked and notifications will flow...

Bug#498039: Charset fixed in new upstream version

[Anthony DeRobertis]

Package: fontconfig
Version: 2.11.0-6.3
Followup-For: Bug #498039

FYI, this bug is fixed in new upstream versions 2.11.91 and newer. Would
be nice to get a new version into stretch.

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

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

Versions of packages fontconfig depends on:
ii  dpkg   1.18.3
ii  fontconfig-config  2.11.0-6.3
ii  libc6  2.21-4
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.6.1-0.1

fontconfig recommends no packages.

fontconfig suggests no packages.

-- no debconf information

Bug#784850: bug closed

[Cesar Chaparro]

This is bug 11271
https://bugzilla.samba.org/show_bug.cgi?id=11271

Solved deleting
"disable spoolss = yes" in smb.conf

Consider the bug closed.

Bug#784850: bug closed

[Cesar Chaparro]

This is bug 11271
https://bugzilla.samba.org/show_bug.cgi?id=11271

Solved deleting
"disable spoolss = yes" in smb.conf

Consider the bug closed.

Bug#738469: RFA: twinkle -- Voice over Internet Protocol (VoIP) SIP Phone

[Peter Colberg]

Dear Debian VoIP team,

Twinkle, a graphical SIP client, has recently been resurrected upstream
with a port to Qt 5 [1]. I have packaged twinkle 1.9.0 for Debian [2],
which has been uploaded by the previous maintainer, Clint Adams.

[1] http://twinkle.dolezel.info/
[2] https://bugs.debian.org/797159

Going forward, what do you think of maintaining twinkle under the
umbrella of the pkg-voip team? I am not a DD/DM and would require
sponsorship for uploads. So far I gained packaging experience thanks
to Graham Inggs and Sébastien Villemot from the Debian Julia team [3].

The twinkle package is maintained in a git repository [4].

[3] https://qa.debian.org/developer.php?login=peter%40colberg.org&comaint=yes
[4] https://anonscm.debian.org/cgit/users/pc-guest/twinkle.git

My alioth username is pc-guest.

Regards,
Peter

Bug#809375: ITP: ngs-sdk -- Next Generation Sequencing language Bindings

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: ngs-sdk
  Version : 1.2.3
  Upstream Author : National Center for Biotechnology Information
* URL : https://github.com/ncbi/ngs
* License : public domain
  Programming Lang: C
  Description : Next Generation Sequencing language Bindings
 NGS is a new, domain-specific API for accessing reads, alignments and
 pileups produced from Next Generation Sequencing. The API itself is
 independent from any particular back-end implementation, and supports
 use of multiple back-ends simultaneously. It also provides a library for
 building new back-end "engines". The engine for accessing SRA data is
 contained within the sister repository ncbi-vdb.
 .
 The API is currently expressed in C++, Java and Python languages. The
 design makes it possible to maintain a high degree of similarity between
 the code in one language and code in another - especially between C++
 and Java.


Remark: This package is a new dependency of the sra-sdk package and
maintained by the Debian Med team at
  git://anonscm.debian.org/debian-med/ngs-sdk.git

Bug#809184: "aptitude changelog" aborts with "Illegal instruction"

[Manuel A. Fernandez Montecelo]

2015-12-29 17:48 Bjarni Ingi Gislason:

On Mon, Dec 28, 2015 at 10:25:07AM +0800, Paul Wise wrote:

On Mon, 28 Dec 2015 01:57:25 + Bjarni Ingi Gislason wrote:

>   aptitude changelog apt ...

Does this always produce the same outcome?



 Yes, at least three times.


>   Output was "Illegal instruction" with a return value of 132.
...
> Architecture: i386 (i586)

There are some things that would help the aptitude maintainers figure
out what the problem is:

Send the output of this command:

cat /proc/cpuinfo



processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 8
model name  : AMD-K6(tm) 3D processor
stepping: 12
cpu MHz : 331.579
cache size  : 64 KB
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr cx8 pge mmx syscall 3dnow k6_mtrr 
vmmcall
bogomips: 663.15
clflush size: 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:


Enable the debug repo, install debug symbols, gdb and make a backtrace:

Create this file:

/etc/apt/sources.list.d/04-debian-debug.sources



 Error from apt-get.

 The line must end with ".list"


Put this line in it:

deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main



 Error from apt-get.

 The URL may not end with "/".


Update the apt cache:

sudo apt-get update

Install the gdb debugger and debug symbols:

sudo apt-get install gdb aptitude-dbg libapt-pkg5.0-dbgsym libboost1.58-dbg 
libc6-dbg libncursesw5-dbg libgcc1-dbg libsqlite3-0-dbg libstdc++6-5-dbg 
libtinfo5-dbg libxapian22v5-dbg

Run the debugger and get a crash trace:

gdb -batch -n -ex 'set height 0' -ex run -ex bt -ex 'thread apply all bt full' 
--args aptitude changelog apt



 Running just "aptitude" shows no error (no command issued except "q").

 Running "aptitude changelog" (no furter arguments) returns normally
with no output.

 Running "aptitude changelog apt" in a writable directory gives a core
dump.

 "gdb --core=core" shows:

Script started on þri 29. des 2015, kl. 04.08.33 GMT
$ gdb --core=core
GNU gdb (Debian 7.10-1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
[New LWP 4270]
[New LWP 4261]
[New LWP 4268]
Core was generated by `aptitude changelog apt'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0xb6f5216f in ?? ()
[Current thread is 1 (LWP 4270)]
(gdb) quit
$ exit
exit

Script done on þri 29. des 2015, kl. 04.10.11 GMT


 The gdb trace reports:


Script started on þri 29. des 2015, kl. 04.11.05 GMT
$ gdb -batch -n -ex 'set height 0' -ex run -ex bt -ex 'thread apply all bt 
full' --args aptitude changelog apt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xb435bb40 (LWP 4317)]
[New Thread 0xb3b5bb40 (LWP 4318)]
[New Thread 0xb335bb40 (LWP 4319)]
[New Thread 0xb2b5bb40 (LWP 4320)]

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0xb335bb40 (LWP 4319)]
0xb7bf216f in boost::filesystem::path::m_parent_path_end 
(this=this@entry=0xb335afc4) at libs/filesystem/src/path.cpp:348
348 libs/filesystem/src/path.cpp: No such file or directory.
#0  0xb7bf216f in boost::filesystem::path::m_parent_path_end 
(this=this@entry=0xb335afc4) at libs/filesystem/src/path.cpp:348
#1  0xb7bf238a in boost::filesystem::path::parent_path 
(this=this@entry=0xb335afc4) at libs/filesystem/src/path.cpp:353
#2  0xb7beb3f8 in boost::filesystem::detail::create_directories (p=..., ec=0x0) 
at libs/filesystem/src/operations.cpp:940
#3  0x801b5e51 in boost::filesystem::create_directories (p=...) at 
/usr/include/boost/filesystem/operations.hpp:523
#4  get_download_cache () at ../../../../src/generic/apt/apt.cc:571
#5  0x801da21a in aptitude::(anonymous 
namespace)::download_thread::cache_lookup_thread::process_job 
(job=std::shared_ptr (empty) 0xb5f020b0, this=0xb335b308) at 
../../../../src/generic/apt/download_queue.cc:567
#6  aptitude::util::job_queue_thread >::run (this=this@entry=0xb5f06304) at 
../../../../src/generic/util/job_queue_thread.h:206
#7  0x801dafc4 in aptitude::util::job_queue_thread >::bootstrap::operator() (this=) at ../../../../src/generic/util/job_queue_thread.h:80
#8  
cwidget::t

Bug#809374: ITP: jquery-slugify.js -- Just another another (another) url slug creation plugin for jQuery

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: jquery-slugify.js
  Version : 1.2.3~dfsg1-1
  Upstream Author : Florian Reiss
* URL : https://github.com/madflow/jquery-slugify
* License : Expat
  Programming Lang: Javascript
  Description : Just another another (another) url slug creation
plugin for jQuery.

This is needed for Mailpile

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#779490: Any progress on three.js?

[W. Martin Borgert]

On 2015-08-21 18:33, David Bremner wrote:
> If someone else wants to pick up what is in collab-maint and run
> with it (i.e. change maintainer and re-upload, perhaps with the JS
> team), I would be happy to let it go.

OK, I gave it another try. I added the missing copyright,
used the latest upstream, and removed more non-source files.
It's in NEW, again. Thanks for your work, David!

Bug#809296: config file example

[Frank McCormick]

I have attached a sample of what wbar-config does to my $HOME/.wbar file 
after

I hit reload.




.wbar
Description: Binary data

Bug#807358: locales: /usr/sbin/locale-gen: line 62: 31200 Killed (64 Mb RAM)

[Aurelien Jarno]

On 2015-12-08 09:41, Aurelien Jarno wrote:
> control: tag -1 + moreinfo
> 
> On 2015-12-07 22:57, Jari Aalto wrote:
> > Package: locales
> > Version: 2.19-22
> > Severity: important
> > 
> > Unable to install package "locales" or generate locales manually on
> > x86 with 64 Mb and plenty of free swap. Output of htop(1):
> > 
> >   CPU[|||  11.1%] Tasks: 38, 0 
> > thr; 1 running
> >   Mem[|||29/56MB] Load average: 
> > 0.17 2.59 2.14
> >   Swp[||21/760MB] Uptime: 634 
> > days(!), 20:34:35
> >  
> > 
> >   $ locale-gen
> >   Generating locales (this might take a while)...
> >   en_US.UTF-8.../usr/sbin/locale-gen: line 62: 31200 Killed
> > localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias 
> > $locale
> >  done
> >  Generation complete.
> > 
> > System has only en_US.UTF-8 activated:
> > 
> >  $ grep -v '#' /etc/locale.gen
> >  en_US.UTF-8 UTF-8
> > 
> > Debug listing:
> > 
> > 
> >   $ sh -x locale-gen
> >   [...]
> >   + '[' -f /usr/local/share/i18n/locales/en_US ']'
> >   + localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias 
> > en_US.UTF-8
> >   /usr/sbin/locale-gen: line 62: 31157 Killed  localedef -i 
> > $input -c -f $charset -A /usr/share/locale/locale.alias $locale
> >   + :
> >   + echo ' done'
> > done
> >   [...]
> >   Killed
> > 
> > Manual try:
> > 
> >   $ localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias 
> > en_US.UTF-8
> >   <... time passes>
> >   Killed
> 
> localedef definitely needs more than 64MB of RAM, that said with
> 760MB swap it should run fine.
> 
> If the program gets killed, there is not a lot we can do on the libc
> side, that's clearly a problem on your system.
> 
> > I don't have possibilities to install any trace tools in this low
> > memory system.
> 
> I guess you can get some information from the kernel (using dmesg) about
> why localedef gets killed. You should also look how the overcommit is
> configured on your system:
> 
> https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

Any news on that? Can you provide the output of dmesg?

Aurelien

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

Bug#809373: RM: wesnoth-1.13 -- ROM; to be maintained in experimental instead

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: rho...@debian.org

Please remove wesnoth-1.13 from unstable. This package is not suitable
for release, since it's the development branch of wesnoth;
wesnoth-1.12 is the current stable branch that is suitable to be
included in a stable release. We intend to maintain development
branches of wesnoth in experimental only from now on. Thanks!

(rhonda, if you have any additional rationale to add, please feel free to do so)

Regards,
Vincent

Bug#809372: rakudo: perl6-valgrind-m yields "failed to load library 'dynext/libperl6_ops_moar.so'"

[Vincent Lefevre]

Control: retitle -1 rakudo: perl6-gdb-m and perl6-valgrind-m yield "failed to 
load library 'dynext/libperl6_ops_moar.so'"

On 2015-12-29 23:32:28 +0100, Vincent Lefevre wrote:
> When I run perl6-valgrind-m, I get:
> 
> [...]
> Unhandled exception: failed to load library 'dynext/libperl6_ops_moar.so'
>at :1  
> (/usr/share/perl6/runtime/perl6.moarvm::81)
> [...]
> 
> while the /usr/lib/perl6/runtime/dynext/libperl6_ops_moar.so file
> is present. Perhaps something wrong in some library path setting?

Ditto with perl6-gdb-m.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#809372: rakudo: perl6-valgrind-m yields "failed to load library 'dynext/libperl6_ops_moar.so'"

[Vincent Lefevre]

Package: rakudo
Version: 2015.11-1
Severity: normal

When I run perl6-valgrind-m, I get:

[...]
Unhandled exception: failed to load library 'dynext/libperl6_ops_moar.so'
   at :1  
(/usr/share/perl6/runtime/perl6.moarvm::81)
[...]

while the /usr/lib/perl6/runtime/dynext/libperl6_ops_moar.so file
is present. Perhaps something wrong in some library path setting?

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, 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 rakudo depends on:
ii  moarvm  2015.11-1
ii  nqp 2015.11-1
ii  rakudo-lib  2015.11-1

rakudo recommends no packages.

Versions of packages rakudo suggests:
ii  valgrind  1:3.11.0-1

-- no debconf information

Bug#734442: patch

[Eric Dorland]

* Alexey Sokolov (ale...@asokolov.org) wrote:
> Hi Eric,
> Does the service file need to be different from the included one?
> (https://github.com/znc/znc/blob/master/znc.service.in)

Currently it does, because the patch as is creates a _znc user rather
than znc to avoid namespace collision. It also uses the --datadir flag
to avoid the .znc directory. It also uses ConditionFileNotEmpty to
prevent startup if it's not configured. We don't have to do these
things but they all seem useful to me. There's really room to go
further with various systemd protection settings, but I didn't want to
overcomplicate the diff.

> Also please check the recent discussion about it at
> https://github.com/znc/znc/issues/1165

Thanks for pointing this out. There's a lot of issues to intermixed in
this bug report. It looks like the reason they reverted the --datadir
change was because it broke existing users, which is fair but we
don't have that problem in Debian. I think having a unified unit file
would be good but I don't think that should tie hands against good
improvements.

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93


signature.asc
Description: PGP signature

Bug#809371: rakudo provides several executables but a single man page for perl6 only

[Vincent Lefevre]

Package: rakudo
Version: 2015.11-1
Severity: minor

There is a lack of documentation.

  man perl6
  man perl6-debug-m
  man perl6-gdb-m
  man perl6-m
  man perl6-valgrind-m

all give the perl6 man page, so that one doesn't the differences
between these executables.

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, 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 rakudo depends on:
ii  moarvm  2015.11-1
ii  nqp 2015.11-1
ii  rakudo-lib  2015.11-1

rakudo recommends no packages.

Versions of packages rakudo suggests:
ii  valgrind  1:3.11.0-1

-- no debconf information

Bug#809367:

[Leon Bottou]

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

Bug#806815: pkg-lirc team seems unmaintained

[Gianfranco Costamagna]

Hi all, sorry for the long delay.

Some new points for Alec (added him in the loop, and also the RFS bug

@Alec, please look at the review below, it is really complete, and report back 
when you have addressed the points.

@Alexander, can you please make Stefan admin of pkg-lirc?
this way Stefan will make the final decision about accepting/rejecting new 
members according to the quality of the new
lirc packages.

(EDIT: he is already an admin, thanks a lot!)

@Stefan, would you please help and review the package on mentors (after the 
points below are fixed?)
I can sponsor the package, but I'll leave to you any final decision about this 
sponsoring.

@Alec, I can follow up on libirman if needed, just ask me, I'll wait for 
objections there :)

thanks a lot to you all,

have a nice new year!

Gianfranco



Il Lunedì 21 Dicembre 2015 7:19, Stefan Lippers-Hollmann  ha 
scritto:
Hi

[ it's late and I'll be on the road again for the next couple of days 
  before christmas, so I might miss some finer details of this mail, 
  although it already got longer than I hoped ]

On 2015-12-18, Gianfranco Costamagna wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi Ector, Sven and Stefan,
> 
> I write to you because $somebody (upstream) is doing a lot of work, to
> fix lirc and libirman packages, and to finally put them again
> 
> into a good state.

I certainly didn't have a lot time since early summer (which is slowly
normalizing), but I don't quite agree that the lirc packaging would be
in a bad state - at least not from a Debian centric look (I certainly
understand that lirc upstream wants the latest and greatest and might 
disagree). 

We certainly are behind the current upstream version (and it looks worse
than it is, as 0.9.0~pre1 with the upstream patches included in the Debian
package is actually equivalent to the released version of 0.9.0, except 
for the version bump and tiny, no-op, build-system tweaks), but the post
0.9.1 upstream changes are extremely disruptive, they are good (and many
of them have been needed), but very disruptive (liblirc{,}-client0 is
no more --> transition (sourceful uploads) of all rdeps needed, the new 
plugin structure needs checking with multi-arch, .la removal (static 
linking), new/ different config file format). While we need to update, 
doing this in a hurry simply isn't an option - and there isn't really a 
problem with the current lirc version in Debian.

At least the current version of lirc 0.9.0~pre1 builds in current 
unstable, works with all kernels >= 2.6.37 (including linux-next), is
compatible with Debian's userland (unstable and experimental) and doesn't
really have any important bugs that would need quick attention.

> In order to make the packages "upgradable" he created an upgrade
> script, converting stuff from the old and Debian specific configuration

Until lirc >= 0.9.1, this config migration was a headache[0] for me 
(especially as the packaging svn already did a migration to a different
config file/ ~format (/etc/default/lirc.conf) on request of the previous
upstream, Jarod Wilson, before this new /etc/lirc/lirc_options.conf was
even under consideration); fortunately this never hit the archive. But 
with lirc >= 0.9.2, the library split changes are actually worse to get 
sorted.

> to the new upstream and fedora configuration (this will drop the long
> old debian delta, even if it will be a little painful, or at least
> manual).
> 
> I asked him to join the team, but I failed so far, because seems that
> the team is almost not active anymore.

I can't help with that, as I'm just a member of pkg-lirc and not an 
admin.

> So I'm asking you permission to NMU the packages (there is still a lot
> of work to do, and they won't be ready for some time), or (better
> solution for sure)

It took me a while to find the actual thing supposed as a lirc NMU, but
I strongly advise against uploading lirc_0.9.4~alpha-1.1.dsc from 
mentors[1]. As I've just found it, I can't claim to have given it a 
proper review yet, nor have I tested the actual upgrade helpers, but from
a very first glance (in the order I've found it, unsorted).

- major library transition (needs a migration approval from the release 
  team and serious checking with liblircclient-dev's reverse
  build-dependencies in Debian
- debian/control is pretty much butchered up, those things (besides
  needlessly changing the package split in several areas) aren't exactly
  serious - and easily fixable, but the current changes under proposal 
  are bad.
- weird/ useless debian/install (the source creates multiple binaries, so
  this gets ignored)
- the Breaks/ Replaces logic is broken and against Debian policy.
- debian/copyright, while better (not better, just updated for post 
  0.9.0) than the current version in the archive, it is a regression 
  compared to the current state in the packaging svn (I have the changes
  needed for 0.9.1 locally (svn is just bad for testing incomplete 
  changes), b

Bug#804888: djview plugin unusable in debian testing...

[Barak A. Pearlmutter]

So maybe the best thing would be to file a bug against qt5, fix things
in this package by using qt4, and filing a wishlist bug against this
package to use qt5, with a "blocked by" referring to the qt5 bug
report above. That way when the qt5 issue is resolved the wishlist bug
will be unblocked and notifications will flow...

Bug#809370: ITP: lios -- Linux intelligent OCR solution

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 

* Package name: lios
  Version : 2.0
  Upstream Author : Nalin.x.Linux 
* URL : http://sourceforge.net/projects/lios
* License : GPL-3
  Programming Lang: Python
  Description : Linux intelligent OCR solution


lios provides a graphical interface on top of the Cuneiform and
Tesseract OCR backends to make OCR processing easier for impaired users,
with full autorotation, brightness optimization, rectangle selection,
audio feedback, etc.

Bug#804888: djview plugin unusable in debian testing...

[Leon Bottou]

The upstream code for djview has been improved.
However the core of this problem is bug  
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809367 in Stretch's Qt-5.5.1.

Absent a Qt fix, we have two ugly workarounds:

  *   Compiling djview4 using Qt-4.8 instead of Qt-5.
  *   Have djview4 recognize the buggy versions of Qt-5 and use the supposedly 
obsolete Xt embedding protocol instead of XEMBED.


P.s. -- this is a djview4 issue.

- L.

Bug#809369: mu-cade: ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in _dNormalize4

[Markus Koschany]

Package: mu-cade
Version: 0.11.dfsg1-8+b2
Severity: grave

I have just noticed that mu-cade in testing and unstable is unusable
because it crashes on startup with

ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in _dNormalize4() 
[odemath.h:42]
[1]1120 abort (core dumped)  mu-cade

I assume the bug surfaced because of the transition to libode4.

Markus

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

Kernel: Linux 4.3.0-1-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 mu-cade depends on:
ii  libbulletml0v50.0.6-6.1
ii  libc6 2.21-4
ii  libgcc1   1:5.3.1-4
ii  libgl1-mesa-glx [libgl1]  11.0.8-1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libode4   2:0.13.1+git20150309-2
ii  libsdl-mixer1.2   1.2.12-11+b1
ii  libsdl1.2debian   1.2.15-12
ii  mu-cade-data  0.11.dfsg1-8

mu-cade recommends no packages.

mu-cade suggests no packages.

-- no debconf information

Bug#809359: long-term redmine debian packaging

[Antoine Beaupré]

Hi!

["out of date redmine" bug report in CC. this is a followup email to
the generic "we're going to LTS redmine!" notification which expands on
the situation and hopefully the future of the Redmine packaging]

I am trying to figure out how to maintain Redmine in the long term,
especially in the older debian releases (squeeze, wheezy and yes,
eventually jessie!). I have so far taken the near monastic approach of
trying to backport every patch i could get my hand on back into squeeze
and wheezy, but it's been a slow and difficult process.

Fortunately, a lot of the security issues seem to have been appearing
after 1.0, so squeeze is often not vulnerable. In other cases, issues
have been fixed in squeeze, but *not* in wheezy, sid or even jessie,
which I think is a fairly serious problem.

As part of my LTS work, I am trying to prepare uploads to fix most if
not all of the open vulnerabilities in Redmine. I have therefore
reviewed all open security issues in Redmine, well documented here:

https://security-tracker.debian.org/tracker/source-package/redmine

Here's the summary of the progress so far:

 * CVE-2015-8537: wheezy and up, patch available in #807826
 * CVE-2015-8477: squeeze and wheezy, patch available in github, needs
   testing
 * CVE-2015-8474: squeeze and wheezy, patch to be ported, depends on
   CVE-2014-1985
 * CVE-2015-8473: wheezy and up, patch to be ported
 * CVE-2015-8346: fixed in squeeze only! patch to be ported
 * CVE-2014-1985: squeeze and wheezy, patch to be ported
 * CVE-2012-2054: squeeze only, patch to be ported
 * CVE-2012-0327: squeeze only, patch impossible to find (!)

All the details are in the security tracker, but basically, we need
better coordination if we want to get rid of those issues more reliably
in the future.

What I would recommend, at this point, would be to ship patches for the
issues we can backport (which is most of the above), but only as a short
term fix. Our strategy clearly is not working if we can't get a recent
release in sid / testing *and* a secure stable version in stable/LTS.

I will try to do those uploads by the end of the month, or at least send
debdiffs in various places. I have already documented a bunch of patches
and diffs in the above CVEs.

In the long term, I think it may be better to use a strategy similar to
MySQL or other more monolithic packages in the future. It has been
easier to cherry-pick patches in recent CVEs, but it's still hard work
that we can't seem to keep up with. By keeping up with upstream releases
(pinned against the proper Rails release of course), our jobs would be
much easier.

This would mean getting 3.5 or 3.6 into shape for stretch and/or
jessie. Is there anything blocking that?

By the way, backporting the patches is real detective work if the patch
is not clearly identified in the CVE. Tracking that through the loops of
SVN mystery is absolutely terrible. I made a home-grown script to
untangle all this stuff because I couldn't figure out the SVN repository
(either it's been too long or what i want i not possible, i am not
sure):

http://src.anarc.at/scripts.git/blob_plain/HEAD:/redmine-svn-inspector

yeah, I know, that's horrible - any improvements would of course be
welcome. maybe i just missed something.

Thanks for any feedback and happy holidays

a.
-- 
Si l'image donne l'illusion de savoir
C'est que l'adage pretend que pour croire,
L'important ne serait que de voir
- Lofofora

Bug#809367:

[Leon Bottou]

Reported upstream: https://bugreports.qt.io/browse/QTBUG-50212

Bug#809328: lxde-common: package should not depend on a specific window manager

[Andriy Grytsenko]

control: reassign -1 lxde-metapackages 6

Thank you very much for making such suggestion, the lxde actually can be
ran without openbox, yes.

Unfortunately, this exact suggestion is wrong as lxde-common is not a
WM-independent package, it actually isn't a common package needed to run
with any WM but is an x-session package for openbox session, it should
have been named openbox-lxde-session in the first place but due to some
historical reasons is named lxde-common. Actually it even would not work
without openbox until user makes some changes but to make those changes
user should start openbox session first. It's why the lxde-common package
depends on openbox.

To make it possible to use another WM with LXDE the hard dependency on
lxde-common should be removed from lxde metapackage and replaced with
lxde-common|x-session-manager then you can create another session file
instead of /usr/share/xsessions/LXDE.desktop (which uses executables
/usr/bin/openbox-lxde and /usr/bin/startlxde from lxde-common package).
I mean just clone lxde-common files set, modify & rename these mentioned
files and you're done for another WM.

Since said hard dependency on lxde-common in regards of this report is a
bug of lxde-metapackages, I reassign the report to that package.

Although if you would like to reuse /etc/xdg/{lxpanel,pcmanfm}/ files and
wallpapers from lxde-common package then let us know, please, it is still
possible to split said package to create an openbox-lxde-session with all
openbox/lxsession related files in it and leave independent files alone.

Bug#804888: djview plugin unusable in debian testing...

[Leon Bottou]

Not a simple one.
We would have to try embedding a window and observe the discrepancy 
between the size reported by xwininfo and the size reported by the qt program.
This seems very complex (and requires a X server..)

Happy new year, btw :-)

- L.




On 12/29/15, 4:48 PM, "Barak A. Pearlmutter"  wrote:

>Is there any reliable way to test for the buggy version of Qt-5?
>Because if there is we could do something in debian/rules or some
>place like that to fall back to Qt-4.8 iff Qt-5 is unavailable or
>buggy.

Bug#804888: djview plugin unusable in debian testing...

[Barak A. Pearlmutter]

Is there any reliable way to test for the buggy version of Qt-5?
Because if there is we could do something in debian/rules or some
place like that to fall back to Qt-4.8 iff Qt-5 is unavailable or
buggy.

Bug#658120: Another patch source...

[Marco Gaiarin]

I'm asking too to add EFI boot support; another patch (but, probably
the same) came from RH-based distro:


http://pkgs.fedoraproject.org/cgit/cdrkit.git/tree/cdrkit-1.1.9-efi-boot.patch

Please, add EFI boot support! Thanks.

Bug#809349: /sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/liblmdb.so.0 is not a symbolic link

[Aurelien Jarno]

control: reassign -1 lmdb
control: forcemerge 808785 -1

On 2015-12-29 17:52, shirish शिरीष wrote:
> Package: libc-bin
> Version: 2.22-0experimental1
> Severity: normal
> 
> Dear Maintainer,
> While upgrading today got the above thing.
> 
> Processing triggers for libc-bin (2.22-0experimental1) ...
> /sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/liblmdb.so.0 is not a
> symbolic link
> 
> Dunno if it's a bug or just something informative.

It's a bug in the liblmdb0 package. Reassigning the bug.

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

Bug#689230: virtuoso 7.1 to Debian proper [Was: Bug#689230: new version is needed!]

[Kjetil Kjernsmo]

Hi all!

Just a little nudge here again! 

Ubuntu 16.04 (which is a Long Term Support release) has a Debian Import 
Freeze on the February 18th, and for Virtuoso 7.2 to make it in, it should 
have an update in Debian well before that. 

I'm neither an Ubuntu or Virtuoso user, but I think it is important for 
both that it goes in there. :-)

Cheers,

Kjetil

Bug#809368: handbrake: Regular -> Normal -> Subtitle List -> Add All -> Encode Failed

[David Christensen]

Package: handbrake
Version: 0.9.9+svn6422+dfsg1-2
Severity: minor

Dear Maintainer,

I am attempting to rip a DVD movie.  There seems to be a problem
around chapters 21-22.  If I select:

Presets List -> Regular -> Normal

Subtitle Defaults -> Add All

HandBrake stops, the status bar says "Encode Failed", and the Activity
window says:

[12:45:51] gtkgui: HandBrake rev0 (2014100499) - Linux x86_64 - 
http://handbrake.fr
[12:45:51] hb_init: starting libhb thread
[12:45:51] hb_init: starting libhb thread
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
[13:15:57] CPU: Intel(R) Core(TM) i7-2600S CPU @ 2.80GHz
[13:15:57]  - Intel microarchitecture Sandy Bridge
[13:15:57]  - logical processor count: 8
[13:15:57] OpenCL: library not available
[13:15:57] hb_scan: path=/dev/sr0, title_index=0
index_parse.c:191: indx_parse(): error opening /dev/sr0/BDMV/index.bdmv
index_parse.c:191: indx_parse(): error opening /dev/sr0/BDMV/BACKUP/index.bdmv
bluray.c:2356: nav_get_title_list(/dev/sr0) failed
[13:15:57] bd: not a bd - trying as a stream/file instead
[13:15:57] dvd: Region mask 0xff
[13:15:57] dvd: Warning, DVD device has no region set
libdvdnav: Using dvdnav version 5.0.1
libdvdnav: DVD disk reports itself with Region mask 0x00fe. Regions: 1

libdvdread: Attempting to retrieve all CSS keys
libdvdread: This can take a _long_ time, please be patient

libdvdread: Get key for /VIDEO_TS/VIDEO_TS.VOB at 0x0167
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_01_0.VOB at 0x00057cba
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_01_1.VOB at 0x00057d75
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_02_0.VOB at 0x00057e42
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_02_1.VOB at 0x00057efd
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_03_0.VOB at 0x0006199b
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_03_1.VOB at 0x00064868
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_04_0.VOB at 0x003a3641
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_04_1.VOB at 0x003a36fc
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_05_0.VOB at 0x003a5367
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_05_1.VOB at 0x003a54ee
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_06_0.VOB at 0x003a55cc
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_06_1.VOB at 0x003a5687
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_07_0.VOB at 0x003a6363
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_07_1.VOB at 0x003a641e
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_08_0.VOB at 0x003a64eb
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_08_1.VOB at 0x003a65a6
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_09_0.VOB at 0x003a6731
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_09_1.VOB at 0x003a6736
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_10_0.VOB at 0x003a8b13
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_10_1.VOB at 0x003a8b18
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_11_0.VOB at 0x003a8fad
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_11_1.VOB at 0x003a8fb2
libdvdread: Elapsed time 0
libdvdread: Found 11 VTS's
libdvdread: Elapsed time 0
[13:15:58] scan: DVD has 17 title(s)
[13:15:58] scan: scanning title 1
[13:15:58] scan: opening IFO for VTS 1
[13:15:58] scan: duration is 00:00:00 (500 ms)
[13:15:58] scan: ignoring title (too short)
[13:15:58] scan: scanning title 2
[13:15:58] scan: opening IFO for VTS 2
[13:15:58] scan: duration is 00:02:01 (121834 ms)
[13:15:58] pgc_id: 1, pgn: 1: pgc: 0x7fb17401c650
[13:15:58] scan: vts=2, ttn=1, cells=0->1, blocks=0->39526, 39527 blocks
[13:15:58] scan: checking audio 1
[13:15:58] scan: id=0x80bd, lang=English (AC3), 3cc=eng ext=1
[13:15:58] scan: checking subtitle 1
[13:15:58] scan: id=0x20bd, lang=English (Closed Caption), 3cc=eng ext=5
[13:15:58] scan: title 2 has 2 chapters
[13:15:58] scan: chap 1 c=0->0, b=0->39339 (39340), 121333 ms
[13:15:58] scan: chap 2 c=1->1, b=39340->39526 (187), 500 ms
[13:15:58] scan: aspect = 1.3
[13:15:58] scan: scanning title 3
[13:15:58] scan: opening IFO for VTS 3
[13:15:58] scan: duration is 02:01:00 (7260734 ms)
[13:15:58] pgc_id: 1, pgn: 1: pgc: 0x7fb17401d000
[13:15:58] scan: vts=3, ttn=1, cells=0->50, blocks=187->3403170, 3402984 blocks
[13:15:58] scan: checking audio 1
[13:15:58] scan: id=0x80bd, lang=English (AC3), 3cc=eng ext=1
[13:15:58] scan: checking audio 2
[13:15:58] scan: id=0x81bd, lang=Francais (AC3), 3cc=fra ext=1
[13:15:58] scan: checking audio 3
[13:15:58] scan: id=0x82bd, la

Bug#804149: fixed in sudo 1.8.15-1

[Ben Hutchings]

On Fri, 2015-12-25 at 04:35 +, Ben Hutchings wrote:
> On Fri, 2015-12-25 at 03:09 +, Ben Hutchings wrote:
> > On Fri, 2015-12-25 at 02:53 +, Ben Hutchings wrote:
> > > Control: reopen -1
> > > 
> > > On Thu, 24 Dec 2015 05:19:31 + Bdale Garbee  wrote:
> > > > Source: sudo
> > > > Source-Version: 1.8.15-1
> > > > 
> > > > We believe that the bug you reported is fixed in the latest version of
> > > > sudo, which is due to be installed in the Debian FTP archive.
> > > [...]
> > > 
> > > As Raphael already explained, the upstream change doesn't fix this.
> > 
> > It *does* add a new configuration option, sudoedit_checkdir, which if
> > enabled will defeat this attack.  However, the upstream default is that
> > it's disabled.  Perhaps this should be changed in the Debian package?
> 
> Actually, that option doesn't work either.

Attaching my fixes for sudoedit_checkdir.  I intend to NMU with these
changes later this week if I don't hear any objections.

Ben.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.Description: CVE-2015-5602: Fix directory writability checks for sudoedit.
Bug: https://bugzilla.sudo.ws/show_bug.cgi?id=707
Bug-Debian: https://bugs.debian.org/804149
Author: Ben Hutchings 

This prevents access to a file in a writable directory *or* accessed
through a symlink in a writable directory.

--- a/src/sudo_edit.c
+++ b/src/sudo_edit.c
@@ -248,46 +248,52 @@ dir_is_writable(struct stat *sb, uid_t u
 static int
 sudo_edit_open_nonwritable(char *path, int oflags, mode_t mode)
 {
-char *base, *dir;
+#ifndef O_NOFOLLOW
+error(1, "%s: Can't check writability without O_NOFOLLOW", __func__);
+#else
+char *sep;
 struct stat sb;
-int dfd, fd;
+int dfd, subdfd, fd;
+int is_writable;
 debug_decl(sudo_edit_open_nonwritable, SUDO_DEBUG_EDIT)
 
-base = strrchr(path, '/');
-if (base != NULL) {
-	*base++ = '\0';
-	dir = path;
+if (path[0] == '/') {
+	dfd = open("/", O_RDONLY);
+	++path;
 } else {
-	base = path;
-	dir = ".";
-}
-#ifdef O_PATH
-if ((dfd = open(dir, O_PATH)) != -1) {
-	/* Linux kernels < 3.6 can't do fstat on O_PATH fds. */
-	if (fstat(dfd, &sb) == -1) {
-	close(dfd);
-	dfd = open(dir, O_RDONLY);
-	if (fstat(dfd, &sb) == -1) {
-		close(dfd);
-		dfd = -1;
-	}
-	}
+	/* XXX It doesn't make any sense to allow editing relative paths */
+	dfd = open(".", O_RDONLY);
 }
-#else
-if ((dfd = open(dir, O_RDONLY)) != -1) {
+if (dfd == -1)
+	debug_return_int(-1);
+
+for (;;) {
+	/*
+	 * Look up one component at a time, avoiding symbolic links in
+	 * writable directories
+	 */
+
 	if (fstat(dfd, &sb) == -1) {
 	close(dfd);
-	dfd = -1;
+	debug_return_int(-1);
 	}
+	is_writable = dir_is_writable(&sb, user_details.uid, user_details.gid,
+  user_details.ngroups, user_details.groups);
+
+	sep = strchr(path, '/');
+	if (sep == NULL)
+	break;
+	*sep = '\0';
+	subdfd = openat(dfd, path, O_RDONLY | (is_writable ? O_NOFOLLOW : 0), 0);
+	*sep = '/';			/* restore path */
+	close(dfd);
+	if (subdfd == -1)
+	debug_return_int(-1);
+	path = sep + 1;
+	dfd = subdfd;
 }
-#endif
-if (base != path)
-	base[-1] = '/';			/* restore path */
-if (dfd == -1)
-	debug_return_int(-1);
 
-if (dir_is_writable(&sb, user_details.uid, user_details.gid,
-	user_details.ngroups, user_details.groups)) {
+if (is_writable) {
 	close(dfd);
 	errno = EISDIR;
 	debug_return_int(-1);
@@ -296,6 +302,7 @@ sudo_edit_open_nonwritable(char *path, i
 fd = openat(dfd, path, oflags, mode);
 close(dfd);
 debug_return_int(fd);
+#endif
 }
 
 #ifdef O_NOFOLLOW
Description: CVE-2015-5602: Enable sudoedit directory writability checks by default
Bug: https://bugzilla.sudo.ws/show_bug.cgi?id=707
Bug-Debian: https://bugs.debian.org/804149
Author: Ben Hutchings 

--- a/plugins/sudoers/defaults.c
+++ b/plugins/sudoers/defaults.c
@@ -504,6 +504,7 @@ init_defaults(void)
 	goto oom;
 def_set_utmp = true;
 def_pam_setcred = true;
+def_sudoedit_checkdir = true;
 
 /* Finally do the lists (currently just environment tables). */
 if (!init_envtables())
--- a/doc/sudoers.cat
+++ b/doc/sudoers.cat
@@ -1280,7 +1280,7 @@ SSUUDDOOEERRSS OOPPTTIIOONN
it is run by root.  On many systems, this option
requires that the parent directory of the file to be
edited be readable by the target user.  This flag is
-   _o_f_f by default.
+   _o_n by default.
 
  sudoedit_follow   By default, ssuuddooeeddiitt will not follow symbolic links
when opening files.  The _s_u_d_o_e_d_i_t___f_o_l_l_o_w option can be
--- a/doc/sudoers.man.in
+++ b/doc/sudoers.man.in
@@ -2720,7 +2720,7 @@ by the invoking user unless it is run by
 On many systems, this option requires that the parent directory
 of the file to 

Bug#809367: libqt5gui5: XEMBED interop with gtksocket broken

[Leon Bottou]

Package: libqt5gui5
Version: 5.5.1+dfsg-10
Severity: normal

This bug appears when one embeds a QWindow inside a GTK socket container
using the functions QWindow::setParent and QWindow::fromWinId().
According to the doc, the size of the QWindow should track the size of the 
container.
This used to work with Qt-5.2 and no longer works with this version of Qt.

Here are the replication instructions:

* The following python program creates a window with a gtk socket
  and prints the window id of the socket

---
#!/usr/bin/env python

import gtk, sys, string

class Socket:
def __init__(self):
window = gtk.Window() 
window.set_default_size(200, 200) 
socket = gtk.Socket()
window.add(socket)
print(socket.get_id())
window.connect("destroy", lambda w: gtk.main_quit())
socket.connect("destroy", lambda w: gtk.main_quit())
socket.connect("plug-added", self.plugged_event)
socket.connect("plug-removed", self.unplugged_event)
window.show_all()

def plugged_event(self, widget):
print "A plug has been inserted."

def unplugged_event(self, widget):
print "A plug has been removed."
return True

Socket()
gtk.main()
---

* The following Qt program tries to embed itself
  into the container whose id is passed on the command line.

---
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
  QApplication app(argc,argv);
  long wid = app.arguments().at(1).toLong(0,0);
  QLabel *lbl = new QLabel();
  lbl->setText("here");
  lbl->setAlignment(Qt::AlignCenter);
  lbl->winId();
  QWindow *wlbl = lbl->windowHandle();
  wlbl->setParent(QWindow::fromWinId(wid));
  lbl->show();
  app.exec();
}
---

* To reproduce, open a terminal window, run "gtksocket.py"
  and record the printed socket window id. This creates
  a toplevel window containing the socket. In a second terminal window,
  run "plug ".
  The label text "here" appears in socket window.

* Under Qt-5.2, the label text appears in the middle of
  the window because the QLabel widget has the same size
  as the gtksocket window.  Resizing the gtksocket window
  keeps the text "here" in the middle of the window because
  the QLabel widget size tracks that of the socker.

* Under Qt-5.5.1+dfsg-10, the label text appears in the top left
  corner of the window and stays there. Using program "xwininfo"
  shows that the size of the underlying X11 window effectively
  tracks the size of the gtksocket. But it appears that
  the size of the QWindow and of the associated QLabel
  remains stuck to its initial value.


As a consequence, XEMBED interop is broken in this version of Qt.




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

Kernel: Linux 4.3.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 libqt5gui5 depends on:
ii  fontconfig   2.11.0-6.3
ii  libc62.21-4
ii  libegl1-mesa [libegl1-x11]   11.0.8-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6.1-0.1
ii  libgl1-mesa-glx [libgl1] 11.0.8-1
ii  libglib2.0-0 2.46.2-1
ii  libharfbuzz0b1.0.1-1+b1
ii  libinput10   1.1.3-1
ii  libjpeg62-turbo  1:1.4.1-2
ii  libmtdev11.1.5-1
ii  libpng12-0   1.2.54-1
ii  libqt5core5a [qtbase-abi-5-5-1]  5.5.1+dfsg-10
ii  libqt5dbus5  5.5.1+dfsg-10
ii  libqt5network5   5.5.1+dfsg-10
ii  libstdc++6   5.3.1-4
ii  libudev1 228-2+b1
ii  libx11-6 2:1.6.3-1
ii  libxkbcommon00.5.0-1
ii  libxrender1  1:0.9.9-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages libqt5gui5 recommends:
ii  libqt5svg5 5.5.1-2
ii  libqt5xcbqpa5  5.5.1+dfsg-10

Versions of packages libqt5gui5 suggests:
pn  libqt5libqgtk2 
pn  qt5-image-formats-plugins  
pn  qtwayland5 

-- no debconf information

Bug#809366: ITP: qtip2.js -- qTip plugin for the ever popular jQuery framework

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: qtip2.js
  Version : 3.0.2~dfsg1-1
  Upstream Author : Craig Michael Thompson
* URL : https://github.com/qTip2/qTip2
* License : Expat
  Programming Lang: Javascript
  Description : qTip plugin for the ever popular jQuery framework

This is needed for Mailpile
-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#809362: ITP: opendht -- lightweight C++11 distributed hash table implementation

[Tomasz Buchert]

On 29/12/15 20:24, Dimitri John Ledkov wrote:
> Hello,
> 
> On 29 December 2015 at 20:03, Tomasz Buchert  wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Tomasz Buchert 
> >
> > * Package name: opendht
> >   Version : v0.5
> >   Upstream Author : 2014-2015 Savoir-Faire Linux Inc.
> > * URL : https://github.com/savoirfairelinux/opendht
> > * License : GPL3, MIT
> >   Programming Lang: C++
> >   Description : lightweight C++11 Distributed Hash Table implementation
> >
> > A lightweight C++11 Distributed Hash Table implementation originally
> > based on https://github.com/jech/dht by Juliusz Chroboczek.
> > .
> >   * Light and fast C++11 Kademlia DHT library
> >   * Distributed shared key->value data-store
> >   * Clean and powerful distributed map API with storage
> > of arbitrary binary values of up to 128 KB
> >   * Optional public key cryptography layer providing data signature
> > and encryption (using GnuTLS)
> >   * IPv4 and IPv6 support
> >
> 
> Software in general is weightless, unless, of course one prints a
> hardcopy book of it via a publisher (e.g. MIT Press) and takes it
> across the border. (
> https://en.wikipedia.org/wiki/Pretty_Good_Privacy#Criminal_investigation
> )
> 
> Yet pretty much every project on github claims to be "lightweight", "fast", 
> etc.
> 
> Would it hurt to drop "lightweight", "light and fast" etc? Do these
> adjectives have any meaning really?

Hi Dimitri,
"lightweight" has a meaning: "of light weight" :)
But, granted, it may be dropped since, as you said, the word is overused
to the extent that became meaningless.

Thanks,
Tomasz

> 
> -- 
> Regards,
> 
> Dimitri.
> 


signature.asc
Description: PGP signature

Bug#740340: Still present in Debian Stable

[Markus Koschany]

On Tue, 29 Dec 2015 16:49:53 + pioruns  wrote:
> Hello,
> 
> I can confirm this bug is still present in widelands version 1:18-3+b1,
> which is most current one for Debian Jessie. There is no other version
> in jessie/backports.
> Any plans that this could be imported to Debian?
> 
> Thank you.

Hello,

I have checked the upstream bug report and it looks like they fixed that
in their VCS. However the diff is huge and they haven't made a new
stable release yet.

https://bugs.launchpad.net/widelands/+bug/1286576

We need a targeted patch for the current stable release. If you or
someone else could come up with such a patch, I am willing to ask the
release team for an inclusion into Jessie.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox

[KANAVATH Rashad]

Quoting Ghislain Vaillant :


On 29/12/15 10:09, Rashad Kanavath wrote:

Hi Ghislain,

debian policy for shared library says each library must be in a seperate
package [1].


The following citation from the very link you provided is far from  
the definition I know of "must":


I didn't mean RTFM (Read the fine manual). When I was having initial  
package review, I was asked to move shared libs into separate  
packages. I initially had separated qt and python stuff only.


"If you have several shared libraries built from the same source  
tree, you may lump them all together into a single shared library  
package provided that all of their SONAMEs will always change  
together."



OTB is well modularaized since 5.0.0. This allows external apps or
libaries to use have some of the otb libs not all

For instance,
monteverdi required only a small subset of libs:
  OTBApplicationEngine
  OTBQtWidget
  OTBImageIO
  OTBVectorDataIO
  OTBTestKernel
  OTBCarto
  OTBProjection
  OTBStatistics

So splitting a shared library is useful there. It also aslo true for
remote modules. If anyone want to write a remote module that depends on
two other modules OTBCommon, OTBTestKernel. he don't need to drag in all
dependencies for that.


The modularization of OTB follows pretty much what ITK does from the  
distant look I had of it, and I am familiar with how VTK / ITK is  
packaged in Debian. Still neither of both were  modularized too much  
besides the separation of the Python and Qt specific stuff, in order  
to reduce (co)maintenance burden. Again, you're the maintainer and  
the final decision is totally yours here.


yes. modularization of otb follows that of itk.



Besides, all the modules you provide seem to qualify for the case I  
cited above (same goes for ITK / VTK), hence my suggestion to place  
them in a common shlib package. Since you assumed that the policy  
"forced" you to do otherwise, I understand why you considered my  
advice defensively.


Not exactly. If there is some issue with the current state of  
packaging, I am okay to fix it.


ofcourse, going back to single libs is easy but a lot of work will be wasted.
But I don't have a problem with that. sorry If I sounded defensive to  
your comments, it may be because i was doing a single shared libs at  
first and then I decided to split them.



And in future otb may have more modules. If there is a problem with
split up libraries, I can change it and make it simply libotb and
libotb-dev


I can't comment on the "simplicity" of the conversion. Perhaps you  
have more experience on this aspect of packaging than I do.


On a side note, by contributing to other packages than I personally  
maintain, I can tell you one thing: the more complicated the  
packaging, the least I have been inclined to invest time in  
co-maintenance. That is likely to apply to others.


I guess maintaining the symbols file is easier when packages are  
separated. And before I start, I looked into other packaging works in  
DebianGIS. All of them follow this way. So I stick to that.


The complexity of maintenance you were mentioning was also similar as  
in the case of qgis.



What do you think?


Not that it matters anymore, since your source package has now been  
sponsored. Good luck with the rest though.


Thanks. I appreciate your feedback and possible interest in  
maintaining the package.



Ghis

Bug#809337: Upstream bug created

[Alexander Barton]

Hello Thomas!

Am 29.12.2015 um 19:19 schrieb Thomas Liske :

> On Tue, Dec 29, 2015 at 04:58:34PM +0100, Alexander Barton wrote:
> > Okay, I tried to diagnose this a little bit further and created an
> > upstream bug for this issue -- most probably this has nothing todo with
> > the Debian package per se. See:
> 
> this silly bug was introduced upstream in 2010-03 and is now fixed
> upstream. For more details see:
> 
> https://github.com/DE-IBH/imvirt/issues/14

Any chance to get this fixed in Jessie?

Thanks!
Alex

Bug#809361: librdf-ns-curated-perl: Should be arch: all, not arch: any

[Dagfinn Ilmari Mannsåker]

Dagfinn Ilmari Mannsåker  writes:

> This is a pure-perl module, so it should be Architecture: any, not
> Architecture: all, which wastes buildd capacity and archive space.

Typo: It should be Architecture: all, as indicated in the subject.

-- 
- Twitter seems more influential [than blogs] in the 'gets reported in
  the mainstream press' sense at least.   - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
  to a mainstream media article.  - Calle Dybedahl

Bug#705092: Current state of this bug?

[Robin Roth]

Dear all,

what's the current state of this bug? Can't one make silversearcher-ag
conflict with python-ase and get rid of this?

Cheers,
Robin



signature.asc
Description: OpenPGP digital signature

Bug#809365: exifprobe: segfault on some invalid jpegs

[James Cowgill]

Package: exifprobe
Severity: important
Version: 2.0.1-6

Hi,

The attached jpegs cause exifprobe to segfault.

This bug is forwarded from this email to pkg-multimedia-maintainers:
https://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-December/049019.html

The above mail also contains the output of exifprobe with address
sanitizer enabled, but not with debug symbols so it's probably not too
helpful.

Thanks,
James

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

Bug#809364: ITP: autosize.js -- small, stand-alone script to automatically adjust textarea height to fit text

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: autosize.js
  Version : 3.0.14
  Upstream Author : Jack Moore 
* URL : https://github.com/jackmoore/autosize
* License : Expat
  Programming Lang: Javascript
  Description : small, stand-alone script to automatically adjust
textarea height to fit text

This is needed for Mailpile



signature.asc
Description: OpenPGP digital signature

Bug#789536: findutils: find -name pattern does not match when same pattern matches in shell

[Norman Ramsey]

 > On 2015-06-22 Norman Ramsey  wrote:
 > > Package: findutils
 > > Version: 4.4.2-9+b1
 > > Severity: normal
 > 
 > > Dear Maintainer,
 > 
 > > What led up to the situation is a faulty library resulted in some file
 > > names that had DEL and other ugly characters embedded.  In trying to
 > > track down these files, I used find(1), but didn't find anything.
 > > Very surprising.
 > 
 > > Further investigation reveals that find(1) is failing to match pattern
 > > '*l_y_i_n*' when the shell does:
 > 
 > >   : nr@homedog 12294 ; find . -name '*l_y_i_n*'
 > >   : nr@homedog 12295 ; echo *l_y_i_n*  
 > >   ��F_l_y_i_n_g_ _C_o_l_o_r_s
 > >   : nr@homedog 12296 ; echo *l_y_i_n* | od -a
 > >   000 del   ~   F   _   l   _   y   _   i   _   n   _   g   _  sp   _
 > >   020   C   _   o   _   l   _   o   _   r   _   s  nl
 > >   034
 > [...]
 > 
 > Hello,
 > 
 > I am sorry, but this specific example works for me:

I apologize---I sent you a bad bug report.
I had not realized that 'od -a' ignores the high bit.
Please forgive me.

I can reproduce the issue by setting the first byte of 
the filename to \xFF rather than \x7F.



Norman




: nr@homedog 10282 ;  touch "`printf '\xFF~F_l_y_i_n_g_
  Colors
  '`"
: nr@homedog 10283 ; ls -l
total 0
-rw-rw-r-- 1 nr nr 0 Dec 29 15:07 ?~F_l_y_i_n_g_?Colors
-rw-rw-r-- 1 nr nr 0 Dec 29 15:02 ?~F_l_y_i_n_g_? > _C_o_l_o_r_s
: nr@homedog 10284 ; find . -name '*l_y_i*'
./?~F_l_y_i_n_g_? > _C_o_l_o_r_s
: nr@homedog 10285 ; find . -name '*l_y_i*' | od -a -t x1
000   .   / del   ~   F   _   l   _   y   _   i   _   n   _   g   _
 2e  2f  7f  7e  46  5f  6c  5f  79  5f  69  5f  6e  5f  67  5f
020  nl  sp   >  sp   _   C   _   o   _   l   _   o   _   r   _   s
 0a  20  3e  20  5f  43  5f  6f  5f  6c  5f  6f  5f  72  5f  73
040  nl
 0a
041
: nr@homedog 10287 ; for i in *; do echo "$i" | od -a -t x1; done
000 del   ~   F   _   l   _   y   _   i   _   n   _   g   _  nl   C
 ff  7e  46  5f  6c  5f  79  5f  69  5f  6e  5f  67  5f  0a  43
020   o   l   o   r   s  nl
 6f  6c  6f  72  73  0a
026
000 del   ~   F   _   l   _   y   _   i   _   n   _   g   _  nl  sp
 7f  7e  46  5f  6c  5f  79  5f  69  5f  6e  5f  67  5f  0a  20
020   >  sp   _   C   _   o   _   l   _   o   _   r   _   s  nl
 3e  20  5f  43  5f  6f  5f  6c  5f  6f  5f  72  5f  73  0a
037

Bug#809362: ITP: opendht -- lightweight C++11 distributed hash table implementation

[Dimitri John Ledkov]

Hello,

On 29 December 2015 at 20:03, Tomasz Buchert  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Tomasz Buchert 
>
> * Package name: opendht
>   Version : v0.5
>   Upstream Author : 2014-2015 Savoir-Faire Linux Inc.
> * URL : https://github.com/savoirfairelinux/opendht
> * License : GPL3, MIT
>   Programming Lang: C++
>   Description : lightweight C++11 Distributed Hash Table implementation
>
> A lightweight C++11 Distributed Hash Table implementation originally
> based on https://github.com/jech/dht by Juliusz Chroboczek.
> .
>   * Light and fast C++11 Kademlia DHT library
>   * Distributed shared key->value data-store
>   * Clean and powerful distributed map API with storage
> of arbitrary binary values of up to 128 KB
>   * Optional public key cryptography layer providing data signature
> and encryption (using GnuTLS)
>   * IPv4 and IPv6 support
>

Software in general is weightless, unless, of course one prints a
hardcopy book of it via a publisher (e.g. MIT Press) and takes it
across the border. (
https://en.wikipedia.org/wiki/Pretty_Good_Privacy#Criminal_investigation
)

Yet pretty much every project on github claims to be "lightweight", "fast", etc.

Would it hurt to drop "lightweight", "light and fast" etc? Do these
adjectives have any meaning really?

-- 
Regards,

Dimitri.

Bug#809293: linux-image-3.16.0-4-amd64: network regression in 3.16.7-ckt20-1+deb8u1 breaks ipv6 ike/ipsec negotiations

[Noah Meyerhans]

On Mon, Dec 28, 2015 at 03:22:52PM -0800, Noah Meyerhans wrote:
> Following the recent kernel security update, racoon(8) from ipsec-tools
> can no longer negotiate an IPSec security association with an ipv6 peer.
> IPv4 does not appear affected.
> 
> Racoon logs the following:
> Dec 28 13:20:42 amarth racoon: ERROR: recvmsg (Resource temporarily 
> unavailable)
> Dec 28 13:20:42 amarth racoon: ERROR: failed to receive isakmp packet at 
> isakmp.c:238: Resource temporarily unavailable
> 
> This happens when trying to read an IKE (udp port 500) message from the
> peer.
> 
> Downgrading to 3.16.7-ckt11-1+deb8u3 resolves the problem.

git-bisect of the debian packaging repo suggests that the problem was
introduced in 3.16.7-ckt17.

Looking at the git logs for that release, the only commit that is
obviously related to ipv6 and udp is f3106f:
Author: Eric Dumazet 
Date:   Tue Jul 14 08:10:22 2015 +0200

ipv6: lock socket in ip6_datagram_connect()

commit 03645a11a570d52e70631838cb786eb4253eb463 upstream.

ip6_datagram_connect() is doing a lot of socket changes without
socket being locked.

This looks wrong, at least for udp_lib_rehash() which could corrupt
lists because of concurrent udp_sk(sk)->udp_portaddr_hash accesses.

But I haven't tested anything yet...

noah

Bug#809363: libreoffice-gtk3: Scrolling down using touchpad results in scrolling (mostly) up

[Stefano Costa]

Package: libreoffice-gtk3
Version: 1:5.1.0~rc1-1
Severity: normal

Dear Maintainer,

since (I believe) the latest 5.1 RC version, LibreOffice started behaving in
an unexpected way when scrolling through documents with the touchpad (Thinkpad 
X250
FWIW). This happens in Writer, Calc and all other apps in the same way: I scroll
down and the view is scrolled up. All other programs work perfectly (GNOME 3).
There is no difference between a standard GNOME session and a Wayland session.

I tried downgrading to LO 5.0 and it works well. I also tried removing 
libreffice-gtk3
and libreoffice-gtk seems to work well, too. LO 5.1 RC from libreoffice.org 
works well,
but I'm not sure which GTK version it uses.

So I think the culprit is libreoffice-gtk3. Let me me repeat the issue:

- I open a new or existing document
- using the touchpad, I scroll down
- the view is not scrolled down
- I can scroll down using the scroll bars, or even using an external mouse wheel
- if I'm below the top, the view will scroll up to the top
- all other programs will scroll perfectly 

Thank you,
steko


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

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

Versions of packages libreoffice-gtk3 depends on:
ii  libatk1.0-0   2.18.0-1
ii  libc6 2.21-6
ii  libcairo-gobject2 1.14.4-1
ii  libcairo2 1.14.4-1
ii  libdbus-1-3   1.10.6-1
ii  libdbus-glib-1-2  0.102-1
ii  libgcc1   1:5.3.1-4
ii  libgdk-pixbuf2.0-02.32.3-1
ii  libgl1-mesa-glx [libgl1]  11.0.8-1
ii  libglew1.13   1.13.0-2
ii  libglib2.0-0  2.46.2-3
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgtk-3-03.18.6-1
ii  libice6   2:1.0.9-1+b1
ii  libpango-1.0-01.38.1-1
ii  libpangocairo-1.0-0   1.38.1-1
ii  libreoffice-core  1:5.1.0~rc1-1
ii  libsm62:1.2.2-1+b1
ii  libstdc++65.3.1-4
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  uno-libs3 5.1.0~rc1-1
ii  ure   5.1.0~rc1-1

Versions of packages libreoffice-gtk3 recommends:
ii  libreoffice-style-tango  1:5.1.0~rc1-1

libreoffice-gtk3 suggests no packages.

-- no debconf information

Bug#809355: [Letsencrypt-devel] Bug#809355: letsencrypt: should delegate dir management (e.g. /etc/letsencrypt) to dpkg

[Francois Marier]

On 2015-12-29 at 20:15:31, Leo Antunes wrote:
> letsencrypt creates /etc/letsencrypt and /var/log/letsencrypt when first
> run, instead of having dpkg manage them. This means purging the package
> won't get rid of these folders.

I've added a postrm script to clean up these directories. This should remove
the need to patch the upstream source.

Francois

-- 
http://fmarier.org/

Bug#797159: Update twinkle to QT5

[Peter Colberg]

On Tue, Dec 29, 2015 at 06:03:45PM +, Clint Adams wrote:
> In a few minutes I'll upload your package to unstable with you as
> Maintainer and you can do what you like from then on.

Thank you for the upload!

Peter

Bug#809362: ITP: opendht -- lightweight C++11 distributed hash table implementation

[Tomasz Buchert]

Package: wnpp
Severity: wishlist
Owner: Tomasz Buchert 

* Package name: opendht
  Version : v0.5
  Upstream Author : 2014-2015 Savoir-Faire Linux Inc.
* URL : https://github.com/savoirfairelinux/opendht
* License : GPL3, MIT
  Programming Lang: C++
  Description : lightweight C++11 Distributed Hash Table implementation

A lightweight C++11 Distributed Hash Table implementation originally
based on https://github.com/jech/dht by Juliusz Chroboczek.
.
  * Light and fast C++11 Kademlia DHT library
  * Distributed shared key->value data-store
  * Clean and powerful distributed map API with storage
of arbitrary binary values of up to 128 KB
  * Optional public key cryptography layer providing data signature
and encryption (using GnuTLS)
  * IPv4 and IPv6 support


Cheers,
Tomasz

Bug#809356: gnome-themes-standard-data: left over legacy files

[Dmitry Shachnev]

On Tue, Dec 29, 2015 at 08:55:02PM +0100, Christoph Anton Mitterer wrote:
> Well if that file "belongs" to gnome-themes-standard-data than it
> should probably simply remove the alternative in the maintainer scripts
> in the maintainer scripts.
> Otherwise that symlink will remain forever.
>
> I've just seem that the dir itself would be still part of adwaita-icon-
> theme, even though empty.
>
> But the index.theme seems to be some stale leftover file, isnt't it?

No, it has just been moved from gnome-themes-standard to adwaita-icon-theme
(because that's where the icons really live), which is a hard dependency.
That file is not stale.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#809361: librdf-ns-curated-perl: Should be arch: all, not arch: any

[Dagfinn Ilmari Mannsåker]

Package: librdf-ns-curated-perl
Version: 0.002-1
Severity: normal

Dear Maintainer,

This is a pure-perl module, so it should be Architecture: any, not
Architecture: all, which wastes buildd capacity and archive space.

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

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

Bug#809360: liblwp-useragent-chicaching-perl: Should be arch: all, not arch: any

[Dagfinn Ilmari Mannsåker]

Package: liblwp-useragent-chicaching-perl
Version: 0.03-1
Severity: normal

Dear Maintainer,

This is a pure-perl module, so it should be Architecture: all, not
Architecture: any, which wastes buildd capacity and archive space.

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

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

Bug#809356: gnome-themes-standard-data: left over legacy files

[Christoph Anton Mitterer]

On Tue, 2015-12-29 at 22:46 +0300, Dmitry Shachnev wrote:
> I think that's unavoidable. That directory contains a file created by
> update-alternatives (which is called by postinst), thus dpkg doesn't
> know
> about it. I think you can simply ignore this warning.
Well if that file "belongs" to gnome-themes-standard-data than it
should probably simply remove the alternative in the maintainer scripts
in the maintainer scripts.
Otherwise that symlink will remain forever.

I've just seem that the dir itself would be still part of adwaita-icon-
theme, even though empty.

But the index.theme seems to be some stale leftover file, isnt't it?


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#809359: redmine is outdated in Debian

[Antoine Beaupré]

Source: redmine
Severity: grave

It seems Redmine Debian package is seriously outdated in Debian. It
shouldn't be shipped as such into Stretch, in my opinion, as it does
not seem to follow any upstream stable branch (2.6, 3.0, or 3.1).

I am also puzzled as to why this was shipped in Jessie in the first
place, let alone shipped in a proposed-stable-update...

There are several security issues still affecting all debian releases,
including squeeze-lts, wheezy, jessie and sid.

https://security-tracker.debian.org/tracker/source-package/redmine

redmine was removed from stretch, but it seems to me that an official
release should be shipped in Debian stable releases. And followed as
much as possible!

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

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

Bug#809358: ITP: jquery-timer.js -- setTimeout equivalent with more options for jquery

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: jquery-timer.js
  Version : 0.0~git20150215.0.233601d~dfsg1-1
  Upstream Author : Jason Chavannes 
* URL : https://github.com/jchavannes/jquery-timer
* License : Expat
  Programming Lang: Javascript
  Description : setTimeout equivalent with more options for jquery

This is needed for Mailpile

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#785149: NVME and the Debian Installer 8.2.0

[Jeremy Ellison]

I was trying to get a new NVME drive working and install Debian Stable on
it. I realized after my first failure that my image might be too old, and
got a copy of 8.2.0. It also failed on the grub-installer. I see there has
been some success since I last checked, is there any version of the stable
install image I should keep an eye out for so I can finish my install?