Bug#824677: aiccu: please depend on iproute2 instead of iproute transitional package

[Andreas Henriksson]

Hello Jeroen Massar.

Thanks for your quick reply.

On Wed, May 18, 2016 at 09:49:45PM +0200, Jeroen Massar wrote:
> Would love to update this, but unfortunately we do not get commit-alike
> access..

We should solve this. I'm sure we can work something out. Having the
package unmaintained isn't optimal for anyone.

> 
> Thus please do a NMU for that simple fix, as no Debian Developer is
> currently assigned to the aiccu package... ;(
> 
> If somebody can sponsor uploads though, we would love to know about that.

I should be able to sponsor, but I'm not a very good mentor because
of lack of time. AIUI getting sponsored is now a more formalized process
where you can actually file a bug report about needing a sponsor...

Please see [1] and [2].

[1] 
https://wiki.debian.org/DebianMentorsFaq#What_happens_if_I_can.27t_find_a_sponsor.3F
[2] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;dist=unstable


Regards,
Andreas Henriksson

Bug#822745: wxwidgets3.0: Please build XML documentation for wxWidgets

[Olly Betts]

On Thu, May 19, 2016 at 12:13:13AM -0400, Scott Talbert wrote:
> For Fedora, they are built as a separate binary package, which is
> about 4MB in size.

Probably worth splitting then.

> The other option would be to package the interface headers (and then
> the Phoenix package could generate the XML documentation itself), if
> you think that sounds like a better option.

That does seem more flexible in the ways it allows these interface
headers to be used.  It'd certainly be undesirable to end up having
to ship them in multiple formats if another package wants to use
them directly.

Cheers,
Olly

Bug#823493: Cubieboard2 also affected

[Andre Heider]

Hi,

there's finally a v4.5 fix available, see [0]:

> v4 fixes for 4.5 are here:
>
> https://patchwork.ozlabs.org/patch/598195/ (revert)
> https://patchwork.ozlabs.org/patch/598196/

Those two didn't make it to v4.5.5, but please incude these, stmmac is
broken for 5 debian kernel releases already.

Thanks,
Andre

[0] https://www.spinics.net/lists/netdev/msg369626.html

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[lumin]

Control: block -1 by 799262

one more functional blocker, python3-opencv

opencv is (I guess) frequently used by caffe users, Debian
should have python3-opencv if we provide python3-caffe.

when is the EOL of python2.x? I forgot it.
If it is not 2017, can we first upload python2-caffe-* ?
I'll bump it in the future upload.

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Christian PERRIER]

Quoting Ole Streicher (oleb...@debian.org):

> The "standard" task is IMO one of the concepts in this step that
> actually *nobody* understands: I myself don't know what it means, and
> all the people I asked (when I presented the current scheme of
> installing the blends) have no idea what happens if they (de)select this.

Longstanding "issue". It installs packages of priority "standard", so
that brings us to the definition of these "standard" packages. IIRC
(but I even don't remember where it lies) I spent hours thinking about
the "right" way to translate the "standard" task name into French.

Anyway, the "standard" tasks I was talking about are the other tasks
in tasksel, not "standard" itself.


> > I still remember Joey's objections about *not* having users forced
> > to choose between desktop environmentsbecause, contrary to what
> > the average geek thinks, most people have no idea about what is a
> > desktop environment. So, just imagine if we present them with
> > "Hamradio", "NeuroDebian", "Debian Med" and such a list of unsorted
> > strange things.
> 
> So, if the average user doesn't have a glue about a Desktop environment,
> why is it offered in the installation by default? You seem to contradict
> to your own arguments here.

Because there has always been a contradiction..:-)

In the past, precisely for these reasons, the D.E. tasks were not
presented to users. However, over time, we had more and more and more
requests to allow this and it finally got enabled, but nnot really
with great enthusiasm...:-). This is kinda acknowledging that, indeed,
Debian installations from scratch with user's manual interaction is
now more something that skilled users are doing (let's face reality :
is Debian really used and installed by unskilled users
nowadays...certainly not).

So, more or less, we currently already are in a kind of compromise
which will never satisfy everybody

About the name of the "Debian Blends" menu entry : I have no intent to
rename the project, but more to present users with a meaningful
choice. Holger's suggestion in this thread seems to be the way to go
--> keep "Debian Blends" but explain in a few words what it is.



signature.asc
Description: PGP signature

Bug#799262: request +1 for python3-opencv

[lumin]

request +1 for python3-opencv

Bug#824719: swh-lv2 : new upstream release

[trebmuh]

Package: swh-lv2
Version: 1.0.15+git20151104~repack0-1

Dear debian maintainers,

there is a new 1.0.16 version upstream : 
https://github.com/swh/lv2/releases


HTH
Olivier

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[lumin]

Control: block -1 by 795841
Control: block 788539 by 795841

On Wed, 2016-05-18 at 21:12 +, Gianfranco Costamagna wrote:
> Hi Lumin,
> 
> >Thank you James, I've solved this problem.
> I don't want to do the final checks until Ghislain gives me his personal ack, 
> but
> I see that the python3 dependencies might be fixed with not-much effort.
> 
> issues I would like to see fixed or answered:
> python/requirements.txt <-- please check for missing runtime dependencies.

debhelper will pick them up as python package dependencies:
  dh_python2 --requires=python/requirements.txt

> why some of them are outside that shlibs:Depends and not picked up 
> automatically?
> talking about
> python-skimage and python-protobuf

I don't remember why I put python-skimage there but I remember
that python-protobuf was put there as explicit remind for me,
indicating that protobuf is the blocker of python3-caffe-*.

> e.g. you can't run cython if you don't put it on build-dependencies.
> also all the requiremends, need to be in build-dependencies in order to be 
> picked up
> by python:Depends correctly.

Python modules listed in requirements are not required at runtime,
except for numpy and boost-python. I noticed that dh_python2
complains about "unused python:Depends" but the resulting python
package dependency is correct:

>   Depends: libcaffe-cpu1 (= 1.0.0~rc3-1), python-skimage, python-protobuf, 
> cython, ipython, python (<< 2.8), python (>= 2.7~), python-dateutil, 
> python-gflags, python-h5py, python-leveldb, python-matplotlib, 
> python-networkx, python-nose, python-numpy (>= 1:1.8.0), 
> python-numpy-abi9, python-pandas, python-pil, python-scipy, python-six, 
> python-yaml, python:any (>= 2.7.5-5~), libboost-python1.55.0, 
> libboost-system1.55.0, libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libgoogle-glog0, 
> libprotobuf9, libpython2.7 (>= 2.7), libstdc++6 (>= 4.2.1)

Why should runtime deps be added into build-dep, which are useless
unless I provide python-caffe-* testsuite.

> for the python3 porting:
> protobuf is python3 ready 
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795841
> what about helping the maintainer in uploading it?

Really ready?
I looked into the packaging repo, both master and package-3.x branch
and I see no python3-protobuf package listed there.

http://anonscm.debian.org/cgit/pkg-protobuf/pkg-protobuf.git/tree/debian/control?h=master
http://anonscm.debian.org/cgit/pkg-protobuf/pkg-protobuf.git/tree/debian/control?h=packaging-3.x

The caffe package was ever blocked by 
* the GCC-4 -> GCC-5 transition and dependency library ABI bump
* CUDA 6.5 -> 7.0 bump
* CUDA 7.0 -> 7.5 bump
and now it is blocked by
* python3-protobuf
if python3 is really required.

> for skimage:
> the package has two RC bugs, both fixed upstream 
> #788965, #794859.
> you need to fix all the dependencies if you really want your package in 
> Stretch!
> (btw for skimage, the new release fixes all the RC bugs
> I also asked why it hasn't been packaged yet
> https://github.com/scikit-image/scikit-image/issues/2091
> )

It seems that skimage is not a blocker of Caffe.

$ apt list python3-skimage* -a
Listing... Done
python3-skimage/stable,unstable,now 0.10.1-2 all [installed]

Bug#824717: [pkg-go] Bug#824717: FTBFS on armhf (failing tests)

[Dmitry Smirnov]

On Thursday, 19 May 2016 12:28:08 AM AEST Alexandre Viau wrote:
> There seems to be issue on building golang-gogoprotobuf on armhf.

Unfortunately this is a known issue:

  https://github.com/gogo/protobuf/issues/164


> Only a
> few tests are missing, we should contact upstream on this, or disable
> tests on some architectures?

I suppose we could re-introduce something like 

   https://anonscm.debian.org/cgit/pkg-go/packages/golang-gogoprotobuf.git/
commit/?id=db21b343e5b44b6493fdfac2aaf4e7e31c0ce07e

limited to "armhf" architecture. The reason why I did not do it is because I 
think there is a reasonable suspicion that there is a bug affecting "armhf" 
and ignoring it may be a wrong thing to do...


> This is blocking InfluxDB from migrating to testing.

Not only InfluxDB, mate. :)

-- 
All the best,
 Dmitry Smirnov.

---

I believe in only one thing: liberty; but I do not believe in liberty
enough to want to force it upon anyone.
-- H. L. Mencken


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

Bug#823478: python3-protobuf3

[Jonathon Love]

hi,

so the advice i received regarding the name was that i must get it 
renamed upstream[1]. i don't think this will be possible because:


 - upstream is an established package, present in PYPI and macports
 - the developer is MIA

(additionally, the official Protocol Buffers 3 supports Python 3 [2] and 
should be coming to debian soon[3]. as the main point of this package 
was to allow the use of protocol buffers with Python 3, this reduces the 
need for this package).


hence, i propose to withdraw the package, the RFS and the ITP. also 
happy to proceed, the work is basically done, but i can't see a way to 
make it work.


with thanks

jonathon


[1] https://lists.debian.org/debian-mentors/2016/05/msg00462.html
[2] https://lists.debian.org/debian-mentors/2016/05/msg00491.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795841

Bug#734597: litecoin: Litecoin still builds with system LevelDB

[Dmitry Smirnov]

On Monday, 10 February 2014 11:56:48 AM AEST Scott Howard wrote:
> At some point we should move to system libraries and help bitcoin
> developers with the appropriate tests and mechanisms so they can trust
> system libraries as well. I don't think we are at that point yet.

I think it is not about trust. It would be crazy to build private version of 
let's say MySQL and let Litecoin to link it statically. As far as I'm aware 
Litecin just stores raw key/value data without any advanced features like 
triggers or stored procedures. They could have used file system to store that 
(although it probably wouldn't be very efficient). Therefore there is a 
little risk of using system LevelDB library that at least runs its own post-
build tests suite on every re-build.

I have no confidence in upstream ability to effectively track updates in 
bundled libraries.

I hope it makes sense.

-- 
All the best,
 Dmitry Smirnov.

---

Reality is that which, when you stop believing in it, doesn't go away.
-- Philip K. Dick


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

Bug#824718: nethogs remains broken in Jessie

[Martin Maney]

Package: nethogs
Version: 0.8.0-1
Severity: grave
Tags: patch
Justification: renders package unusable

Bug has already been fixed in NMU upload for stretch & unstable, but nethogs
still crashes in Jessie.  Patch is in #808433, which perhaps oughtn't have been
closed quite so soon.


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

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

Versions of packages nethogs depends on:
ii  libc62.19-18+deb8u4
ii  libgcc1  1:4.9.2-10
ii  libncurses5  5.9+20140913-1+b1
ii  libpcap0.8   1.6.2-2
ii  libstdc++6   4.9.2-10

nethogs recommends no packages.

nethogs suggests no packages.

-- no debconf information

Bug#819615: RFS: spin/6.4.5-1 [ITP] -- formal software verification tool

[Tom Lee]

Cheers for the review Mattia! I'll look into all of this. A few comments:

On Sun, May 15, 2016 at 9:19 AM, Mattia Rizzolo  wrote:

> ...
> * d/patches/01_makefile_fixes.patch:
>   + Probably use += instead of ?= in the first CFLAGS?
>   + I'd rather use install(1) instead of cp(1)
>   + Really forward at least the DESTDIR/INSTALL change
>

Yes, thanks for reminding me -- do intend to follow up with upstream. I'm
curious if this makefile was perhaps written for some crusty old version of
make that doesn't do well with the "optional assignment" syntax used for
DESTDIR/INSTALL. I had similar questions about the use of cp vs. install.
I'll see if upstream has any strong attachment to any of this.


> * d/patches/02_manpage_fixes.patch:
>   + what's blocking you from forwarding this patch?
>

Nothing at all, it just hasn't been done yet.


> * d/rules:
>   + get rid of all those useless comments
>   + DPKG_EXPORT_BUILDFLAGS and the inclusion of buildflags.mk is
> useless, please read debhelper(7)
>   + trailing whitespace at line 22
>   + what's wrong with using --sourcedirectory on the dh(1) call instead
> of overriding everything like that?
>

Oh much better idea, didn't know I could do that.


>   + I'd avoid that "INSTALL=install -D" by patching correctly the
> makefile to default INSTALL on install(1) instead of cp(1) (as I
> said above)
>

Sure.

Thanks again!

Bug#824717: FTBFS on armhf (failing tests)

[Alexandre Viau]

Source: golang-gogoprotobuf
Version: 0.2-4
Severity: important
Justification: fails to build from source

Hello,

There seems to be issue on building golang-gogoprotobuf on armhf. Only a
few tests are missing, we should contact upstream on this, or disable
tests on some architectures?

This is blocking InfluxDB from migrating to testing.

Cheers,

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



signature.asc
Description: OpenPGP digital signature

Bug#824137: texlive-fonts-extra-doc: trying to overwrite '/usr/share/doc/texlive-doc/latex/mweights/README' from texlive-latex-extra-doc 2015.20160320-1

[Norbert Preining]

Hi Philipp,

sorry for the late reply, I was fighting with a more severe
bug, a FTBFS on some architectures.

> Is there any timetable on when that may be? I'd very much like to use
> the current verwsion of texlive-*.

Just install with dpkg -i --force-overwrite , or firt install the new
package texlive-latex-extra-doc manually, and then texlive-fonts-extra-doc
should help, too.

So no need to worry and hurry.


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#821442: GRANT OFFER

[Black,Kenneth]

Hello Dear, On behalf of my family and I, $2m  Grant to you from Mr Pedro 
Quezada, Email. (qpedro...@gmail.com) For More Info

Bug#822745: wxwidgets3.0: Please build XML documentation for wxWidgets

[Scott Talbert]

On Wed, 18 May 2016, Olly Betts wrote:


I would like to request that the XML documentation be built and packaged
for wxWidgets.  I am planning to work on packaging wxPython Phoenix,
which uses the wxWidgets XML interface documentation as the input for
its build process.

If you're OK with this request, I can provide a patch for this.


Seems reasonable to include them if they're useful.

How large are these files?

I'm wondering if it makes sense to just add them to the existing -dev
package, or if we should create a new binary package for them.

Once you've used them, you'll presumably then want the headers and
libraries, so -dev seems like it would work for users of them.


For Fedora, they are built as a separate binary package, which is about 
4MB in size.


The other option would be to package the interface headers (and then the 
Phoenix package could generate the XML documentation itself), if you think 
that sounds like a better option.


Scott

Bug#824683: [PKG-Openstack-devel] Bug#824683: keystone: CVE-2016-4911: Incorrect Audit IDs in Keystone Fernet Tokens can result in revocation bypass

[Salvatore Bonaccorso]

Hi Thomas,

On Thu, May 19, 2016 at 12:21:28AM +0200, Thomas Goirand wrote:
> On 05/18/2016 06:55 PM, Salvatore Bonaccorso wrote:
> > Source: keystone
> > Version: 2:9.0.0-1
> > Severity: grave
> > Tags: security patch upstream
> > 
> > Hi,
> > 
> > the following vulnerability was published for keystone.
> > 
> > CVE-2016-4911[0]:
> > Incorrect Audit IDs in Keystone Fernet Tokens can result in revocation 
> > bypass
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2016-4911
> > [1] https://bugs.launchpad.net/keystone/+bug/1577558
> > 
> > Regards,
> > Salvatore
> 
> Hi Salvatore,
> 
> It is my view that this bug doesn't deserve Severity: grave, as Fernet
> Tokens aren't the default in Keystone (it defaults to UUID tokens, and
> Fernet Tokens are a very new thing).
> 
> Your thoughts?

Thanks for your feedback. Wanted to be rather safe than sorry.

> Anyway, Keystone in Stable isn't affected (it doesn't have the feature),
> and never the less, I'll update the package in Sid/Testing.

I can confirm that it should only affect 9.0.0, so sid. Could you
upload the isolated fix? I will then update the tracker information
once it enters the archive.

Thanks!

Regards,
Salvatore

Bug#807006: closed by Michael Tokarev <m...@tls.msk.ru> (Bug#807006: fixed in qemu 1:2.6+dfsg-1)

[John Paul Adrian Glaubitz]

On 05/18/2016 11:25 PM, Michael Tokarev wrote:
>> It might not be the best idea to close Debian bugs anonymously, e.g.
>> merely by referencing their bug numbers without an actual message.
> 
> "Anonymously" is definitely not the correct word here.
> 
> Unfortunately my time limit for releasing 2.6 is way past all boundaries.
> Your patches for more accurate messages are welcome, too.

I just don't think it's a good approach to close bugs in a changelog by
solely referencing by their bug numbers. There should be at least a
short message like "Fix FTBFS on sparc64 due to wrong linker options.",
then it's less likely that you close the wrong bugs accidentally.

Did you check for other accidentally closed bugs in any case?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#824716: ITP: mshr -- generates simplicial DOLFIN meshes in 2D and 3D

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: mshr
  Version : 1.6.0
  Upstream Author : Benjamin Kehlet 
* URL : http://fenicsproject.org/
* License : GPL3+, LGPL
  Programming Lang: C++, Python
  Description : generates simplicial DOLFIN meshes in 2D and 3D

 mshr is the mesh generation component of FEniCS. It generates
 simplicial DOLFIN meshes in 2D and 3D from geometries described by
 Constructive Solid Geometry (CSG) or from surface files, utilizing
 CGAL and Tetgen as mesh generation backends.
 .
 Maintained by the Debian Science Team 

 Upstream source: https://bitbucket.org/fenics-project/mshr
 Debian source: 
https://anonscm.debian.org/git/debian-science/packages/fenics/mshr.git/

Bug#824702: apt: Incorrect translation in apt list --upgradable ru_RU.UTF8 locale

[Yuri Kozlov]

В Wed, 18 May 2016 23:19:21 +0200
Julian Andres Klode  пишет:

> On Wed, May 18, 2016 at 11:27:59PM +0300, oleg wrote:
> > Package: apt
> > Version: 1.2.12
> > Severity: minor
> > 
> > Dear Maintainer,
> > in ru_RU.UTF8 locale is incorrect translation, for example:
> > 
> > vim/unstable 2:7.4.1829-1 amd64 [upgradable from: 2:7.4.1689-3]
> > vim/unstable 2:7.4.1829-1 amd64 [может быть обновлён до:
> > 2:7.4.1689-3]
> > 
> > correct is something like «может быть обновлён с:»
> 
> Adding debian-l10n-russ...@lists.debian.org to the loop.

Im working on fixed version.

-- 
Best Regards,
Yuri Kozlov

Bug#821532: mlmmj-php-web, mlmmj-php-web-admin: PHP 7.0 Transition

[Chris Knadle]

I have a patch to switch mlmmj to use PHP 7.0 instead of PHP 5 (that change
is trivial -- literally php5 -> php), but I'm running into a snag testing
the resulting binary packages: trying to load Apache2 with PHP 7.0 fails to
start with the error message:

  "Apache is running as threaded MPM, but your PHP module is not compiled
   to be threadsafe.  You need to recompile PHP."

and looking at the README.Debian.gz for libapache2-mod-php7.0, the document
only discusses PHP 5.  :-/  I'm having a look at the php7.0 source
package... libapache2-mod-php.postinst.extra seems to test for mpm but I'm
suspecting that this needs tweaking for how Apache2 is currently packaged in
Sid.  ('a2query -M' returns 'event' which is not a case that's being looked
for, and Apache2 isn't split into mpm/prefork packages anymore.)

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us




signature.asc
Description: OpenPGP digital signature

Bug#736515: openntpd: Does not survive IP address update by dhclient

[Antoine Beaupré]

Package: openntpd
Version: 20080406p-10
Followup-For: Bug #736515

i think ifupd is not the right place to solve this. avahi does this in
/etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd.

I'm trying this script here:

#!/bin/sh

case "$reason" in
MEDIUM|ARPCHECK|ARPSEND|NBI)
;;

PREINIT|BOUND|RENEW|REBIND|REBOOT|STOP|RELEASE)
service openntpd force-reload
;;

EXPIRE|FAIL|TIMEOUT)
service openntpd force-reload
;;
esac

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (1, 'testing')
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)

Versions of packages openntpd depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.22
ii  libc62.19-18+deb8u4
ii  libssl1.0.0  1.0.1k-3+deb8u5
ii  netbase  5.3

openntpd recommends no packages.

openntpd suggests no packages.

-- no debconf information

Bug#482999: The behavior of `jobs -p` is definitely, without a doubt, a bug

[Eric Blake]

On 05/18/2016 06:03 PM, Geoff Nixon wrote:
> Again, speaking for myself, I think the standard is actually pretty clear 
> here.
> Referring again to the "Shell Command Language" page:
> 
> The format for grouping commands is as follows:
> (compound-list)
> Execute compound-list in a *subshell environment*...
> 
> That is, I believe the behavior of bash and busybox does not fully adhere to 
> the
> the standard; pdksh, ksh93, mksh, yash, and oksh are compliant.
> 
>> Personally, I feel that even if your interpretation is wrong (and I'm 
>> not saying it is), it is still less undesirable than dash's current 
>> behaviour. If there's a reasonable chance a patch for it would be 
>> accepted, I'd be willing to try to make it so. 
> 
> Agreed. I'd very much like to see a patch for this; and I certainly hope it
> would be accepted!
> 
> At the *very, very least*, I think the fact that `jobs -p` can have stdout
> redirected to a file, yet cannot be used in a pipeline, is most definitely 
> bug. Can you think of any other command where stdout can be redirected to a 
> file
> but cannot be piped?

http://austingroupbugs.net/view.php?id=53

The trap command is in the same boat as jobs, where redirecting to a
file is different than execution in a subshell, and where the shell may
special case (but perhaps by lexical analysis only) that if a subshell
is about to run where only the single command is being executed, then it
can behave as if that single command were in the context of the parent
instead of being a true subshell, precisely for the purpose of giving
output that would otherwise be lost.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Bug#749887: (no subject)

[Alexandre Viau]

On 18/05/16 09:28 PM, Antoine Beaupré wrote:
> I may have missed a part of the discussion, but it would be great if the
> source package be available somewhere for people to review or use in
> case you disappear (which i've seen happen way too often in ITPs :)

- https://anonscm.debian.org/cgit/pkg-go/packages/syncthing.git

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



signature.asc
Description: OpenPGP digital signature

Bug#749887: (no subject)

[Antoine Beaupré]

On 2016-05-18 21:17:43, Alexandre Viau wrote:
> Hello,
>
> On 18/05/16 01:08 PM, Gordon Ball wrote:
>> Good news. Is there anything I can do to help beyond what you can get
>> from my previous packaging efforts?
>
> Thank you for offering but there is nothing to do.
>
> All there is to do for now is wait for some dependencies to be ACCEPTed
> from NEW.
>
> I'll be uploading Syncthing no later than 24 hours after those
> dependencies make it to the archive.

I may have missed a part of the discussion, but it would be great if the
source package be available somewhere for people to review or use in
case you disappear (which i've seen happen way too often in ITPs :)

a.
-- 
À force de ne jamais réfléchir, on a un bonheur stupide
- Jean Cocteau

Bug#749887: (no subject)

[Alexandre Viau]

Hello,

On 18/05/16 01:08 PM, Gordon Ball wrote:
> Good news. Is there anything I can do to help beyond what you can get
> from my previous packaging efforts?

Thank you for offering but there is nothing to do.

All there is to do for now is wait for some dependencies to be ACCEPTed
from NEW.

I'll be uploading Syncthing no later than 24 hours after those
dependencies make it to the archive.

Cheers,

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



signature.asc
Description: OpenPGP digital signature

Bug#824715: wine32-tools: wineg++ does not link with stdc++

[Javier Serrano Polo]

This is a problem with the new files under /usr/bin.
The /usr/bin/winegcc script does not invoke /usr/lib/wine/wineg++ if it
is called with /usr/bin/wineg++.


smime.p7s
Description: S/MIME cryptographic signature

Bug#765000: update 765000

[J Mo]

Looks like this may be one or more of the following upstream bugs

https://bugs.kde.org/show_bug.cgi?id=345234

https://bugs.kde.org/show_bug.cgi?id=349673

Bug#439888: frobby

[Doug Torrance]

On Wed, May 18, 2016, 7:12 AM Axel Beckert > wrote:


   As far as I heard, all required dependencies are now packaged in
   Debian.

   Is there anything else which is holding back an upload to Debian? 



Yes, unfortunately.

Upstream currently builds its own version of several libraries. Of 
course, the Debian Macaulay2 package should use existing Debian packages 
of these libraries.  For the most part, this isn't a problem.  But 
there's one big issue currently getting in the way. Upstream uses a 
patched version of mpir, a gmp replacement, to get around some memory 
allocation issues.  And so building Macaulay2 with Debian's gmp package 
results in some segfaults when Macaulay2 calls functions from pari, 
another library which deals with gmp and memory allocation.


Upstream is working on the gmp issue (see [1]).  There's some discussion 
about the Debian packaging progress at [2].  And my work thus far is at [3].


Thanks for your interest!

Doug

[1] https://github.com/Macaulay2/M2/issues/285
[2] https://github.com/Macaulay2/M2/issues/286
[3] https://github.com/d-torrance/M2

Bug#814051: Planned NMU

[Norbert Preining]

Hi Max,

> I've converted this into a regular upload. Somehow I missed the

Great, big thanks

> exiv2 bug reports. In general, I'm fine with NMU's, direct with a
> maintainer ack or delayed according to the severity.

WIll try to remember in case I find a bug againa ;-)

All the best

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#824715: wine32-tools: wineg++ does not link with stdc++

[Javier Serrano Polo]

Package: wine32-tools
Version: 1.8.2-1
Severity: minor

Unlike g++, wineg++ does not implicitly link with stdc++; it did in
version 1.8.1-2. Now one has to include the "-lstdc++" linking flag. Is
this the intended behavior from upstream?


smime.p7s
Description: S/MIME cryptographic signature

Bug#482999: The behavior of `jobs -p` is definitely, without a doubt, a bug

[Geoff Nixon]

 On Wed, 18 May 2016 14:03:59 -0700 Harald van Dijk  
wrote  
> Hi, 
> 
> On 13/05/16 04:06, Geoff Nixon wrote: 
> > Let me start with a couple of corrections to that previous thread. 
> > 
> > 
> > 1. The line: jobs -p > /tmp/pids # this works 
> > 
> > Does *not*, in fact, work. Meaning there is *no* instance in which it 
> works. 
> 
> This should work just fine. Do you have a short test script where it 
> does not work for you? 

Sorry, you are absolutely right, this does *does* work. I could have sworn it
didn't when I tried before, but perhaps I was conflating it with something like
`jobs -p | tee /tmp/pids`, which doesn't work.

> > But they do not. The present behavior is to simply dump the process 
> IDs directly 
> > to the TTY, it seems. Which is not, at all, what the specification 
> dictates. 
> 
> That's not what happens. While there are a lot of contexts where you can 
> reasonably argue that jobs -p should output PIDs to stdout and where 
> dash doesn't, when it doesn't, it doesn't output anything. It doesn't 
> somehow start dumping PIDs elsewhere. 

Indeed, you are correct again; my mistake. Due to my incorrect conclusion
(that `jobs -p > /tmp/pids` fails), along with the fact that the
output of `jobs` fails in a pipeline, I drew the incorrect assumption that the
output of `jobs` *never* was sent to stdout. Apologies.

> > In review, a subshell inherits a duplicate of the parent environment, 
> which 
> > includes the asynchronous list of background tasks, and the shell 
> environment is 
> > *explicitly* not to be changed, unless otherwise specified. Which it 
> is not. 
> 
> This is the main point of your message...

Yes, that is the core of my argument.

>  and it's reasonable, but it's 
> not clearly right or clearly wrong. ksh and mksh agree with your 
> interpretation. bash comes across as inconsistent (but there may be a 
> logic that's simply not immediately obvious). dash disagrees with your 
> interpretation, and zsh appears to disagree as well. 
> 
> sleep 1 & 
> echo $(jobs -p) 
> (jobs -p) 
> jobs -p 
> 
> ksh and mksh print the PID thrice. 
> bash prints the PID twice, it omits it in (jobs -p). 
> dash prints the PID once. 
> zsh is a bit unclear since its -p option has a more limited effect, but 
> appears to work like dash, only printing one (non-empty) line of output. 

Oops! I somehow forgot to include the results of my tests with other
shells. You are correct, and in addition to what you mention above: pdksh, oksh,
and yash all also exhibit the "thrice" behavior, while busybox's ash
(at least my old 1.20.0 version) exhibits the same behavior as bash -- that is,
`(jobs -p)` does not work, but the others do.

I don't think zsh should be considered here, since it is explicitly
documented that `jobs -p` does something entirely different (process groups):
http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html

> Your logic relies on the list of jobs being a property of the 
> environment. That's a reasonable interpretation, but not the only one. 
> Another interpretation is the environment that started a job being a 
> property of the job. In that interpretation, that information is not 
> part of the environment and hence not copied when duplicating the 
> environment.

While it's not really worth bickering about, I do in fact believe my
"interpretation" is *specified*. It's not on the `jobs` page, but in
"Shell Command Language", where it dictates that the environment includes:
" - Process IDs of the last commands in asynchronous lists known to this
shell environment".

> And it wouldn't be the first time that the "Application 
> Usage" section of a utility contradicts the normative requirements. 

True ;)

> That said, it does seem extremely likely that trivial examples such as 
> echo $(jobs -p) 
> are intended to work the way you expect, regardless of whether the 
> standard manages to state the requirements correctly. Other cases are 
> not so clear, not when looking at the standard, and also not when 
> looking at what other shells do. This makes it difficult to come up with 
> a complete fix.

Again, speaking for myself, I think the standard is actually pretty clear here.
Referring again to the "Shell Command Language" page:

The format for grouping commands is as follows:
(compound-list)
Execute compound-list in a *subshell environment*...

That is, I believe the behavior of bash and busybox does not fully adhere to the
the standard; pdksh, ksh93, mksh, yash, and oksh are compliant.

> Personally, I feel that even if your interpretation is wrong (and I'm 
> not saying it is), it is still less undesirable than dash's current 
> behaviour. If there's a reasonable chance a patch for it would be 
> accepted, I'd be willing to try to make it so. 

Agreed. I'd very much like to see a patch for this; and I certainly hope it
would be accepted!

At the *very, very least*, I think the fact that `jobs -p` can have 

Bug#824673: wine32-development-tools:i386 cannot be installed on amd64

[Javier Serrano Polo]

winegcc from wine64-tools produces a 32-bit object if "-m32" is
specified, as expected. wine64-tools needs to be installed manually to
avoid the 64-bit libwine-dev.

gcc-multilib cannot have Multi-Arch set to "foreign" or "allowed". That
would allow gcc-multilib:any. It would mean that a powerpc system could
use the i386 gcc-multilib to produce ppc64 binaries.

"-m32" is really necessary in amd64 to compile 32-bit programs. This
could be mentioned in a README, but this is like gcc-multilib: winegcc
works like gcc.

Regarding perl, you may want to see https://bugs.debian.org/824696 .
perl is needed for winemaker.


smime.p7s
Description: S/MIME cryptographic signature

Bug#824196: [Pkg-clamav-devel] Bug#824196: clamav-daemon: clamd crashes daily

[Will Aoki]

On Tue, May 17, 2016 at 10:18:48AM -0600, Will Aoki wrote:
> error code will be available once I run it again without nohup.

It's still running, but some console output from this test run is
interesting, showing it running out of file descriptors:

ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() failed:
ERROR: accept() 

Bug#821925: smokeping.cgi not accessible

[Antoine Beaupré]

On 2016-05-18 19:07:20, Stephen Cooper wrote:
> Merci
>
> If it works once you have installed it without having to edit apache config 
> files with no guidance, you may consider it fixed.

Well, I consider it fixed now because I'm publishing a fixed package.

By the way, next time it would be useful for me if you paste
configuration samples and explain a bit more how you fixed the
problem. It is also useful for everyone as a workaround!

Thanks for reporting the bug!

A.
-- 
Premature optimization is the root of all evil
- Donald Knuth

Bug#824714: RFS: testu01/1.2.3+ds-2 [Refreshment] - testing suite for uniform random number generators

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Sponsors,

I am looking for a sponsor for the Debian package testu01 [1], an 
applied
mathematical suite for testing URNG. This very version is a refreshment 
of
the Debian material.

Thanks in advance,
Jerome

[1] https://anonscm.debian.org/cgit/debian-science/packages/testu01.git/

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

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (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: sysvinit (via /sbin/init)

Bug#824713: RFS: rhythmbox-plugin-alternative-toolbar/0.17.1-1

[David Mohammed]

Package: sponsorship-requests
Severity: wishlist

Dear Mentors,

I am looking for a sponsor for my package
"rhythmbox-plugin-alternative-toolbar"

* Package name: rhythmbox-plugin-alternative-toolbar
  Version : 0.17.1-1
  Upstream Author : David Mohammed 
* URL : https://github.com/fossfreedom/alternative-toolbar
* License : GPL3+
  Section : gnome

It builds the binary package:

rhythmbox-plugin-alternative-toolbar - Enhanced play controls and
interface for Rhythmbox

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

  http://mentors.debian.net/package/rhythmbox-plugin-alternative-toolbar


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

dget -x 
http://mentors.debian.net/debian/pool/main/r/rhythmbox-plugin-alternative-toolbar/rhythmbox-plugin-alternative-toolbar_0.16.3-1.dsc

  More information about rhythmbox-plugin-alternative-toolbar can be
obtained from https://github.com/fossfreedom/alternative-toolbar.
  Additionally I have a blog post about this work here:
https://xpressubuntu.wordpress.com/2015/11/02/rhythmbox-alternative-toolbar-updated/

Notes - this is an update to my previous version v0.16.3 that is in unstable

 - https://packages.debian.org/sid/rhythmbox-plugin-alternative-toolbar

Changes since the last upload:
 * New upstream release. (Closes: #824708)
- Option for dark theme
- Display Browse Categories horizontally or vertically
- Display app-menu correctly in budgie-desktop
- Updated translations from Launchpad.net
- correctly toggle search button via CTRL+F
- option to force the display of the app-menu if required

Tests Run:
grep -riE 'fixme|todo|hack|xxx' .
suspicious-source
pyflakes .
pyflakes3 .
pep8 --ignore W191 .
find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec msgfmt
--check --check-compatibility --check-accelerators
--output-file=/dev/null {} \;

from the built and installed package:

adequate rhythbox-plugin-alternative-toolbar

Regards,
David Mohammed (fossfreedom)

Bug#821925: smokeping.cgi not accessible

[Stephen Cooper]

Merci

If it works once you have installed it without having to edit apache config 
files with no guidance, you may consider it fixed.

Sent from Mail for Windows 10

From: Antoine Beaupré
Sent: Thursday, 19 May 2016 8:01 AM
To: Stephen Cooper; 821...@bugs.debian.org
Subject: Re: Bug#821925: smokeping.cgi not accessible

Control: tag -1 +pending

On 2016-04-27 09:45:27, Stephen Cooper wrote:
> I fixed this myself.
>
> The CGI module was not enabled by the package setup, the URL in File general 
> was not correct (inserted “cgi-bin”) – this should be handled by package 
> configuration, not left broken
>
> Modified the access control lists in the apache.conf

Hi,

I have downgraded the severity of this bug from 'grave' to 'normal'
because, as you can see, the package is usable with minimal
configuration.

The README.Debian file even mentions some issues with automatic
configuration...

I have made the following change to fix the permission issue you have
noticed:

http://anonscm.debian.org/cgit/collab-maint/smokeping.git/commit/?id=581973c272e3dfbe83b585536187764c5f4615a4

I have also made sure the package enables the CGI module on install. I
am not sure this is the best solution, but it's all I could think of
now.

This will be shipped in the next upload.

A.

-- 
Music gives a soul to the universe, wings to the mind, flight to the
imagination and life to everything
 - Plato

Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Chris Lamb]

Hi, please do not CC me in further replies. Many thanks.  -lamby

On Wed, 18 May 2016, at 07:50 PM, Santiago Vila wrote:
> On Wed, May 18, 2016 at 08:12:52PM +0200, Markus Koschany wrote:
> > Am 18.05.2016 um 19:35 schrieb Santiago Vila:
> > > Just take a look at the countless FTBFS bugs filed by reproducible
> > > builds people. They are almost always serious, but many of them fail
> > > to meet the condition that the FTBFS has to happen in the official
> > > buildds.
> > 
> > Every RC bug filed by the reproducible build folks is always
> > reproducible in a clean chroot. I have seen many of those reports. I
> > have fixed many of them.
> 
> A clean chroot, but a "not clean environment", so to speak.
> 
> My point is that adding extra packages is just another way to make the
> environment "not clean".
> 
> Our build system should be ready for any sort of "not cleanliness",
> not only the ones that result from defining environment variables.
> 
> > > Example 1: A package which fails to build under a given locale.
> > > Official autobuilders have LANG=C, but failing to build from source
> > > when LANG=fr_FR is also considered serious.
> > 
> > > Example 2: A package fails to build in a strange timezone. Official
> > > autobuilders have TZ=UTC, but failing to build from source when TZ is
> > > different is also considered serious.
> > 
> > No. These two examples are reproducible build issues but are not RC.
> 
> Ok, let's provide bug numbers.
> 
> FTBFS under some locales:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795731
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808454
> 
> Both are "Severity: serious" because they are FTBFS.
> 
> FTBFS under some timezones:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795690
> 
> Also "Severity: serious" because it's FTBFS.
> 
> > [...]
> > > We want everybody to be able to build packages and have the same result,
> > > not just in the official buildds.
> > 
> > No. We are talking about sensible defaults. For the majority of people
> > this bug is a non-issue.
> 
> I build a lot of packages. debhelper is used by a lot of packages.
> Since I don't want to waste disk I/O, I have debhelper in my chroot
> installed by default. This makes automake to be installed by default.
> 
> I would say this is a more than sensible default for anybody who build
> a lot of packages.
> 
> > [...]
> > > They have not, otherwise we would not have invented build-conflicts.
> > 
> > Build-Conflicts is not a Policy requirement. We talked about that before.
> 
> Yes, and I said that your interpretation of policy in this paragraph
> is extremely narrow.
> 
> Of course it is not a policy requirement. If your package does not
> need any build-depends or build-conflicts, why would you add one?
> 
> Let me quote it again, with emphasis on two other words:
> 
>   Source packages that *require* certain binary packages to be installed
>   or *absent* at the time of building the package can declare
>   relationships to those binary packages.
> 
> I think we can agree that the package being discussed *requires*
> automake to be absent.
> 
> How does a *requirement* (that automake is absent) suddenly becomes optional?
> 
> Please don't say that policy says "can". This just means that you can
> use those fields if your package needs them.
> 
> Once that it's known that the package needs them (either build-depends
> or build-conflicts), they are *required*, not optional.
> 
> Thanks.


Regards,

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

Bug#824712: RFH: smokeping

[Antoine Beaupré]

Package: wnpp
Severity: normal

I need help maintaining the smokeping package. I do not really use it
anymore and i'd be happy to help people to sponsor it. There's a bunch
of obscure bugs all over the place, and while I think the package
mostly works, it's just a wild guess since well, I'm not using it
right now.

Bug#824683: [PKG-Openstack-devel] Bug#824683: keystone: CVE-2016-4911: Incorrect Audit IDs in Keystone Fernet Tokens can result in revocation bypass

[Thomas Goirand]

On 05/18/2016 06:55 PM, Salvatore Bonaccorso wrote:
> Source: keystone
> Version: 2:9.0.0-1
> Severity: grave
> Tags: security patch upstream
> 
> Hi,
> 
> the following vulnerability was published for keystone.
> 
> CVE-2016-4911[0]:
> Incorrect Audit IDs in Keystone Fernet Tokens can result in revocation bypass
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2016-4911
> [1] https://bugs.launchpad.net/keystone/+bug/1577558
> 
> Regards,
> Salvatore

Hi Salvatore,

It is my view that this bug doesn't deserve Severity: grave, as Fernet
Tokens aren't the default in Keystone (it defaults to UUID tokens, and
Fernet Tokens are a very new thing).

Your thoughts?

Anyway, Keystone in Stable isn't affected (it doesn't have the feature),
and never the less, I'll update the package in Sid/Testing.

Cheers,

Thomas Goirand (zigo)

Bug#824642: Doesn't detect glade files for whatever reason

[Daiki Ueno]

Santiago Vila  writes:

> Hello Wouter. Considering that Debian gettext does not deviate from
> upstream a lot (you will see that the number of patches is really
> small), this would be most probably an upstream bug.

Yes, it's a known regression in upstream.  I am now preparing 0.19.8,
but for the meantime you can find a patch:
http://lists.gnu.org/archive/html/bug-gettext/2016-01/msg9.html
http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=21ca680c

Regards,
-- 
Daiki Ueno

Bug#821044: wheezy-pu: package zendframework/1.11.13-1.1+deb7u6

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2016-05-14 at 18:52 -0400, David Prévot wrote:
> Hi,
> 
> > Assuming that the resulting package has been tested on wheezy, please go
> > ahead.
> 
> It just got accepted into oldstable-proposed-updates->oldstable-new,
> thanks (and yes, I do use it in some boxes).

Flagged for acceptance.

Regards,

Adam

Bug#821042: jessie-pu: package zendframework/1.12.9+dfsg-2+deb8u6

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2016-05-14 at 18:43 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2016-04-14 at 18:06 -0400, David Prévot wrote:
> > As agreed with the security team, I’d like to fix another potential
> > entropy vulnerability has been fixed in zendframework.
> > 
> > The fix also gets rid of openssl_random_pseudo_bytes() introduced in the
> > previous ZF2015-09 fix, and I also added a regression fix from the
> > CVE-2015-7695 (ZF2015-08) patch (this one was introduced in DSA-3369-1).
> 
> Apologies for the delay in getting back to you. Please go ahed.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#822481: jessie-pu: package wmforecast/0.8-1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2016-05-14 at 17:49 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2016-04-24 at 17:47 -0400, Doug Torrance wrote:
> > In March 2016, Yahoo! changed their weather API in a non-backwards 
> > compatible
> > way.  This made wmforecast, a Window Maker dockapp which relies on this API
> > to display weather information, nonfunctional.
> > 
> > A new release, version 0.10, was prepared to fix this problem, and 
> > additional
> > improvements were made in 0.11, now available in stretch.
> > 
> > However, jessie still has version 0.8.  I have backported the appropriate
> > changes from 0.10 and 0.11 into a small patch which makes version 0.8
> > functional.  I would like to propose that the jessie wmforecast package be
> > updated with these changes.
> 
> ++url = wstrdup("https://query.yahooapis.com/v1/public/yql?q=;
> ++  "select%20*%20from%20weather.forecast%20where%20woeid");
> + if (strcmp(prefs->woeid_or_zip,"w") == 0) {
> +-url = wstrappend(url,"=");
> ++url = wstrappend(url, "%20%3D%20");
> + url = wstrappend(url, prefs->woeid);
> + }
> + else {
> +-url = wstrappend(url,"=");
> ++url = wstrappend(url, "%20in%20(select%20woeid%20from%20"
> ++ "geo.places(1)%20where%20text%3D%22");
> 
> I really do hope the API isn't just literally executing those strings...
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#823609: jessie-pu: package openssl/1.0.1t-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2016-05-15 at 21:57 +0200, Kurt Roeckx wrote:
> On Sun, May 15, 2016 at 08:09:06PM +0100, Adam D. Barratt wrote:
> > On Wed, 2016-05-11 at 23:48 +0200, Sebastian Andrzej Siewior wrote:
> > > control: retitle -1 jessie-pu: package openssl/1.0.1t-1+deb8u2
> > > 
> > > On 2016-05-06 16:07:15 [+0200], Kurt Roeckx wrote:
> > > 
> > > > So I've prepared an update for jessie with version
> > > 
> > > I prepared an u2 which updates some certs for the testsuite. The old
> > > expired yesterday and so the testsuite fails and the package won't
> > > build. New ones are valid till May 26 17:28:31 2023.
> > 
> > Please go ahead.
> 
> 1.0.1t-1+deb8u2 has been uploaded.

Flagged for acceptance.

Regards,

Adam

Bug#823752: jessie-pu: package xarchiver/1:0.5.4-1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2016-05-15 at 00:22 +0200, Markus Koschany wrote:
> Am 14.05.2016 um 19:02 schrieb Adam D. Barratt:
> > Control: tags -1 + confirmed
> > 
> > On Sun, 2016-05-08 at 15:57 +0200, Markus Koschany wrote:
> >> I would like to update xarchiver in Jessie because of bug
> >>
> >> https://bugs.debian.org/822115
> > 
> > +  * Add cancel-extraction-crash.patch.
> > +When using the "extract here" feature of Xarchiver's Thunar plugin, the
> > +attempt to cancel the extraction could crash the application or even 
> > the
> > +whole desktop session. (Closes: #802019)
> > 
> > The different bug numbers there briefly confused me; for the record,
> > they're merged with each other.
> > 
> > Please go ahead.
> > 
> > Regards,
> > 
> > Adam
> 
> Uploaded.

Flagged for acceptance.

Regards,

Adam

Bug#820822:

[Fabián Inostroza]

No need to uninstall the package libvdpau-va-gl1, you can select other
video output in the settings.

mplayer works ok using vdpau acceleration, so I think that it's a vlc bug.

Bug#824042: [Pkg-clamav-devel] Bug#824042: gets into kill/restart loop

[Sebastian Andrzej Siewior]

On 2016-05-12 19:47:17 [-0300], Felipe Sateler wrote:
> > This functionality will come with systemd 230:
> > https://github.com/systemd/systemd/pull/3148 , so nothing out of the
> > box yet.
> >
> > A more involved solution (but working right now) would be to have
> > OnFailure=clamav-failed.service and have clamav-failed.service stop
> > the socket.
> 
> For clarification: this would stop the socket only on failure. A
> simpler solution that would stop the socket always would be to have
> 
> ExecStopPost=/bin/systemctl --no-block stop clamav-daemon.socket
> 
> On the service. If clamav-daemon never exits on its own, then this
> might be a better solution

Thank you very much for your feedback.
So there is something Joey can try/use for now. In the longterm we need
think if we want to keep the socket activation. I think it was
introduced so freshclam can kick clamd to start after initial
instalation (once the virus database was donwloaded). Sadly it did not
work as expected because systemd evalutated the "condition" only once.
>From the bug history it is fixed for systemd in unstable but not stable.

Now with the background of getting killed repeatedly by OOM it makes me
wonder if we still want that. Adding RestartOnFailure with a delay of 1
minute or so to clamav-daemon.service would probably do the job, too.

Sebastian

Bug#824707: systemd: I get fsck's every other boot: due to systemd-timesyncd not updating hwclock?

[Martin Pitt]

Manuel Bilderbeek [2016-05-18 23:06 +0200]:
> The whole thing reminds me of bug #755722. But that says that 
> systemd-timesyncd
> does write to the hwclock apparently not?

timesyncd does *not* write to the hw clock directly. The kernel has
done that by itself now every 11 minutes for a fair while now, if the
hw clock is in UTC. (If it's not, then timesyncd tells the kernel to
not sync). See manager_adjust_clock() in

  
https://github.com/systemd/systemd/blob/master/src/timesync/timesyncd-manager.c#L314

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#804384: smokeping: README.Debian quite outdated

[anarcat]

On Sat, Nov 07, 2015 at 10:28:55PM +, Jonathan Dowland wrote:
> Package: smokeping
> Version: 2.6.11-1
> Severity: normal
> 
> hi,
> 
> /usr/share/doc/smokeping/README.Debian is quite outdated now:

Yes, it is.

> > After installing the package you have to edit the file 
> > /etc/smokeping/config to set your preferences. You can follow
> > the example provided.
> 
> the config file now is just a list of includes of other files,
> there is no longer really an example to follow.

Hmm... well, what's wrong with following those include files?

> > ln -s /etc/smokeping/apache2.conf /etc/apache2/conf.d/smokeping
> > invoke-rc.d apache2 restart
> 
> I see #760474 already reported complains that the above is not right because
> conf.d no longer exists; however, now /etc/smokeping/apache2.conf is gone
> too.

I simply removed that reference from the README and reshuffled it a bit.

> Finally it would be quite nice to include lighttpd/fastcgi auto-configuration.

Please file this as a seperate wishlist.

Patches are, obviously, welcome. :) I need help maintaining this
package...

A.
-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker


signature.asc
Description: Digital signature

Bug#821925: smokeping.cgi not accessible

[Antoine Beaupré]

Control: tag -1 +pending

On 2016-04-27 09:45:27, Stephen Cooper wrote:
> I fixed this myself.
>
> The CGI module was not enabled by the package setup, the URL in File general 
> was not correct (inserted “cgi-bin”) – this should be handled by package 
> configuration, not left broken
>
> Modified the access control lists in the apache.conf

Hi,

I have downgraded the severity of this bug from 'grave' to 'normal'
because, as you can see, the package is usable with minimal
configuration.

The README.Debian file even mentions some issues with automatic
configuration...

I have made the following change to fix the permission issue you have
noticed:

http://anonscm.debian.org/cgit/collab-maint/smokeping.git/commit/?id=581973c272e3dfbe83b585536187764c5f4615a4

I have also made sure the package enables the CGI module on install. I
am not sure this is the best solution, but it's all I could think of
now.

This will be shipped in the next upload.

A.

-- 
Music gives a soul to the universe, wings to the mind, flight to the
imagination and life to everything
 - Plato

Bug#824551: cinnamon-settings-daemon: please consider to cherry-pick 0677dbf4e9fead24b6dbbf2465ee3f0609c54865

[Christoph Anton Mitterer]

Hey Margarita

On Wed, 2016-05-18 at 20:42 +, Margarita Manterola wrote:
> Actually, the patch is to the cinnamon package.  I wonder why you 
> reported this to cinnamon-settings-daemon, which is not affected 
> by this change :).
+
On Wed, 2016-05-18 at 19:51 +, Margarita Manterola wrote:
> This commit is not enough.
sorry, I was on the subway and haven't had the time to check
properly... and later on I simply forgot O:-)


> I'll be doing this changes and the corresponding uploads, including
> setting 
> the overlay scrollbars to default to false instead of true.
Nice :) Thanks
I think it makes sense to disable it per default, since in my personal
opinion the whole thing is just a big misfeature for the desktop -
similar as CSDs.

Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#824711: coin3: the debian/copyright file incorrectly labels the license texts

[Francesco Poli (wintermute)]

Package: coin3
Version: 3.1.4~abc9f50+dfsg1-1
Severity: important
Tags: patch

Hello and thanks for maintaining Coin3 in Debian!

I noticed that the debian/copyright file incorrectly labels the quoted
license texts.

According to the machine-readable format specification [1], the two
quoted licenses should be labeled BSD-3-clause and Expat, respectively.

[1] 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-specification

I am attaching a patch that fixes the debian/copyright file.
Please apply it, if you agree.

Thanks for your time.
Bye. 


copyright.diff.gz
Description: application/gzip

Bug#824710: Missing build-dependency on libgwengui-gtk2-dev

[Micha Lenk]

Source: gnucash
Source-Version: 1:2.6.12-1
Tags: patch
Severity: serious
Justification: fails to build from source


Dear Gnucash maintainer,

in a recent upload the Gwenhywfar library added support for Qt 5. As
this is the fourth GUI framework that is supported by the Gwenhywfar
library, I redesigned the Debian binary package layout a bit so that
each supported GUI framework library now has its own -dev package. To
not break existing packages, the old binary package libgwenhywfar60-dev
still exists as a meta package that pulls in all the -dev packages
through its dependencies.

This package split aims at making the life easier for maintainers that
maintain a package that build-depends on the Gwenhywfar library. If you
want to benefit from the new package layout, you need to tweak the
build-dependencies of the gnucash package. Depending on the used GUI
framework, a libgwengui-*-dev package is needed as build-dependency
(e.g. libgwengui-gtk2-dev for the Gtk framework). Please note that from
now on (starting with libaqbanking 5.6.10-4) a build-dependency on
libaqbanking-dev will not be sufficient anymore to get all Gwen-GUI
development files installed.

Please consider the attached patch to change the build-dependencies of
the gnucash package accordingly.

Best regards,
Micha

diff --git a/debian/control b/debian/control
index e621fe0..ebaa854 100644
--- a/debian/control
+++ b/debian/control
@@ -14,6 +14,7 @@ Build-Depends: debhelper (>= 9), intltool, pkg-config, dh-autoreconf, dh-python,
  libgnomecanvas2-dev,
  libgoffice-0.8-dev,
  libgtk2.0-dev (>= 2.24),
+ libgwengui-gtk2-dev,
  libofx-dev,
  libwebkitgtk-dev,
  libxml2-dev,

Bug#824196: [Pkg-clamav-devel] Bug#824196: clamav-daemon: clamd crashes daily

[Sebastian Andrzej Siewior]

control: tags -1 + moreinfo

On 2016-05-17 10:18:48 [-0600], Will Aoki wrote:
> It doesn't dump core. Memory grows very slightly over time. The very end
> of the debug log and a journal of memory use are attached; error code
> will be available once I run it again without nohup.

it seems to grow a little and get back. So it does not look like leak.

> > If you manage to give me something to reproduce it locally (like a VM
> > image) I might try it when I have some time.
> 
> I'll see if I can put a test case together.

okay, thanks.

Sebastian

Bug#824707: systemd: I get fsck's every other boot: due to systemd-timesyncd not updating hwclock?

[Michael Biebl]

Am 18.05.2016 um 23:35 schrieb Michael Biebl:
> fsck.ext[234] should no longer run an fsck because of that.
> Which version of e2fsprogs have you installed?
> 
> What are the contents of /etc/adjtime?


See also /usr/share/doc/initramfs-tools/NEWS.Debian.gz

initramfs-tools (0.119) unstable; urgency=medium

  * The initramfs will now run fsck on the root filesystem before
mounting it.  If the chosen init program is systemd and there is a
separate /usr filesystem, it will also fsck and mount /usr.
  * If /usr is a separate filesystem on a RAID device and the INITRDSTART
setting in /etc/default/mdadm is not 'all', you will need to change it
to include that device.
  * If /usr is a separate filesystem on an LVM logical volume, and the
line for /usr in /etc/fstab specifies the device by UUID or LABEL,
you must change this line to specify the device using the format
/dev/mapper/VG-LV or /dev/VG/LV.
  * It is no longer possible to bind-mount the /usr filesystem.
  * If the RTC (real time clock) is set to local time and the local time is
ahead of UTC, e2fsck will print a warning during boot about the time
changing backward (bug #767040).  You can disable this by putting the
following lines in /etc/e2fsck.conf:
[options]
broken_system_clock=1
[As of e2fsprogs version 1.42.13 this message is informational, and
 no configuration change is required.]

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



signature.asc
Description: OpenPGP digital signature

Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))

[Anton Zinoviev]

On Wed, May 18, 2016 at 01:33:06PM -0300, Felipe Sateler wrote:
> 
> Ok. I see that the rules file appears to invoke the scripts in /etc
> directly. Is this intended

Yes.  The keyboard is configured by /lib/console-setup/keyboard-setup.sh 
and the font by the scripts in /etc.

Notice that /lib/console-setup/console-setup.sh does not run the scripts 
in /etc at all.  If necessary it runs setupcon.

> (IOW, shouldn't they invoke the wrappers at /lib/console-setup)?

Although setupcon is an universal and reliable tool, this cames at a 
price --- it is slow.  Many people have complained that console-setup 
slows down the boot and thats the only reason I decided to use scripts 
in /etc instead of setupcon.

By the way, the only thing /lib/console-setup/console-setup.sh does in 
addition to the scripts in /etc is to rebuild the scripts in /etc if 
necessary.  And it is necessary to rebuild these scripts only if the 
sysadmin modifies the console configuration by hand and doesn't run 
`setupcon --save-only` afterwards.  In this case the wrapper will 
rebuild the scripts in /etc during the first reboot.

> But upstream systemd and udev have pushed for mounting /usr in the 
> initramfs for a long time,

Is there a place where one can learn about such things?

> Note that because it has no WantedBy line, this service will not be
> actually executed during boot. If the service should run as part of
> normal system boot, it should have either WantedBy=sysinit.target or
> WantedBy=multi-user.target.
> Services WantedBy=sysinit.target will be pulled in both single user
> and multi user boots. Services in multi-user.target will only be
> pulled in multi user boots.

OK, then it has to be WantedBy=multi-user.target.  Rebuilding the 
scripts in /etc is not something we want in single user mode.

Anton Zinoviev

Bug#823513: clamav-freshclam: freshclam fails to download daily.cvd and clamav do not start

[Sebastian Andrzej Siewior]

On 2016-05-06 23:51:13 [+0200], Sebastian Andrzej Siewior wrote:
> > Update failed. Your network may be down or none of the mirrors listed in
> > /etc/clamav/freshclam.conf is working. Check
> > http://www.clamav.net/doc/mirrors-faq.html for possible reasons.
> 
> To get rid of the "Ignoring mirror … due to previous errors" you need to
> either wait or remove /var/lib/clamav/mirrors.dat - that is where it
> information comes from.
> Then you can try again and show what goes wrong.

One thing that comes to mind is that it could blacklist the two servers
if they did not have the signatures *yet*
I assume the problem is gone, can you please confirm?

Sebastian

Bug#824709: python-certbot: The cron file for certbot missing two items

[Michael Merten]

Package: python-certbot
Version: 0.6.0-1
Severity: normal

Dear Maintainer,

The cron file for certbot (/etc/cron.d/certbot) is missing the cron
username and
the -e switch for the perl command.  I changed it from:

* */12 * * * perl 'sleep int(rand(3600))'; certbot -q renew

To:

* */12 * * * root perl -e 'sleep int(rand(3600))'; certbot -q renew

and it seems to be working now.

Thank you,
Michael Merten


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

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

Versions of packages python-certbot depends on:
ii  python-acme0.6.0-1
ii  python-configargparse  0.10.0-2
ii  python-configobj   5.0.6-2
ii  python-cryptography1.3.1-2
ii  python-dialog  3.3.0-2
ii  python-mock1.3.0-2.1
ii  python-openssl 16.0.0-1
ii  python-parsedatetime   1.4-1
ii  python-pkg-resources   20.10.1-1
ii  python-psutil  4.1.0-1
ii  python-rfc3339 1.0-4
ii  python-six 1.10.0-3
ii  python-tz  2015.7+dfsg-0.1
ii  python-zope.component  4.2.2-1
ii  python-zope.interface  4.1.3-1+b1
pn  python:any 

Versions of packages python-certbot recommends:
ii  certbot [letsencrypt]  0.6.0-1

python-certbot suggests no packages.

-- no debconf information


0x50CE4373.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#824707: systemd: I get fsck's every other boot: due to systemd-timesyncd not updating hwclock?

[Michael Biebl]

Am 18.05.2016 um 23:06 schrieb Manuel Bilderbeek:
> Package: systemd
> Version: 229-5
> Severity: important
> 
> Dear Maintainer,
> 
> Before I start: I'm doing a daily dist-upgrade in testing.
> 
> Since about a week I'm getting fsck's every other boot. I see this when 
> booting:
> 
> (notice that the system time is incorrect, see below when it's corrected)
> 
> mei 19 16:42:35 sonata systemd-fsck[341]: /dev/sda1: Superblock last write 
> time (Fri Jul 29 10:54:06 2016,
> mei 19 16:42:35 sonata systemd-fsck[341]: now = Thu May 19 16:42:35 
> 2016) is in the future.
> mei 19 16:42:35 sonata systemd-fsck[341]: FIXED.
> 
> ... 4 minutes fsck ...
> 
> mei 19 16:46:49 sonata systemd-fsck[341]: /dev/sda1: 858066/3055616 files 
> (7.5% non-contiguous), 8046780/12207384 blocks
> mei 19 16:46:50 sonata systemd[1]: Started File System Check on /dev/sda1.
> ei 19 16:46:50 sonata systemd[1]: Mounting /media/olddisk1...
> mei 19 16:46:50 sonata systemd[1]: Mounted /media/olddisk1.
> mei 19 16:46:50 sonata kernel: EXT4-fs (sda1): mounted filesystem with 
> ordered data mode. Opts: (null)
> mei 19 16:46:50 sonata systemd-fsck[346]: /dev/sda6: Superblock last mount 
> time (Fri Jul 29 10:54:06 2016,
> mei 19 16:46:50 sonata systemd-fsck[346]: now = Thu May 19 16:46:50 
> 2016) is in the future.
> mei 19 16:46:50 sonata systemd-fsck[346]: FIXED.


fsck.ext[234] should no longer run an fsck because of that.
Which version of e2fsprogs have you installed?

What are the contents of /etc/adjtime?

In any case, that sounds like a e2fsprogs related problem.

Regards,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#807006: closed by Michael Tokarev <m...@tls.msk.ru> (Bug#807006: fixed in qemu 1:2.6+dfsg-1)

[Michael Tokarev]

18.05.2016 22:21, John Paul Adrian Glaubitz wrote:
> Control: reopen -1
> 
> I'm sorry, but this has not been fixed [1]. In fact, this particular
> patch hasn't even merged in the git repository of qemu [2].

Yes, my bad, I looked in the wrong branch and thought
the patch is applied.

> It might not be the best idea to close Debian bugs anonymously, e.g.
> merely by referencing their bug numbers without an actual message.

"Anonymously" is definitely not the correct word here.

Unfortunately my time limit for releasing 2.6 is way past all boundaries.
Your patches for more accurate messages are welcome, too.

Thanks,

/mjt

Bug#824708: ITP: rhythmbox-plugin-alternative-toolbar -- Enhanced play controls and interface for Rhythmbox

[foss.freedom]

Package: wnpp
Severity: wishlist

Owner: David Mohammed 

Package name: rhythmbox-plugin-alternative-toolbar
Version: 0.17.1
Upstream Author : David Mohammed (fossfreedom)
URL: https://github.com/fossfreedom/alternative-toolbar
License: GPL 3+
Programming Lang: Python
Description: Enhanced play controls and interface for Rhythmbox
This plugin provides a visual new graphical interface to Rhythmbox.
 New play-controls are provided and dynamical change either by user
 choice or when using a different desktop-environment.
 .
 A GNOME-Shell based headerbar interface is available which integrates
 Rhythmbox with other new GNOME based applications.
 .
 For non-headerbar compatible desktops, compact playcontrols toolbar is
 used which gives Rhythmbox a sleek new interface.
 .
 New music control capabilities are provided - keyboard seek control
 through music tracks as well as repeat-one track.
 .
 The sidebar has been given a visual reworking with new icons and
 interface that integrates Rhythmbox with other GNOME applications
 .
 The plugins window has been revamped to give a consistent look with
 the latest GTK-3 based applications.

Bug#824695: phonon4qt5-backend-vlc: List of mime types do not match the ones in the vlc desktop file

[Petter Reinholdtsen]

[Diederik de Haas]
> phonon-backend-vlc 0.9.0-1 just got accepted to unstable and the git repo has 
> the latest sources which is probably more useful to check (again).
> https://anonscm.debian.org/cgit/pkg-kde/kde-std/phonon-backend-vlc.git/

I checked by checking out the git source of vlc and fetching the source
of the backend package, and running these commands in the vlc source:

  sed 's/ *#.*//' share/vlc.desktop.mimetypes|sort -u > foo
  grep / ../phonon-backend-vlc-0.8.2/MimeTypes.cmake | \
awk '{print $1}' | sort -u > bar
  comm -23 foo bar
  comm -13 foo bar

-- 
Happy hacking
Petter Reinholdtsen

Bug#823275: libjs-angularjs: Minified files are empty

[Xavier]

On 02/05/2016 22:38, Xavier Guimard wrote:
> Package: libjs-angularjs
> Version: 1.5.3-2
> Severity: important
> 
> Hi,
> 
> since uglify is disabled in debian/rules, package contains empty minified
> files.
> 
> Regards,
> Xavier

Hello,

here is a proposed patch

Regards,
Xavier
diff --git a/debian/changelog b/debian/changelog
index f624d85..ad67e56 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+angular.js (1.5.3-3) UNRELEASED; urgency=medium
+
+  * Restore minification (Closes: #823275)
+
+ -- Xavier Guimard   Wed, 18 May 2016 23:19:09 +0200
+
 angular.js (1.5.3-2) unstable; urgency=low
 
   * Upload to unstable.
diff --git a/debian/rules b/debian/rules
index 0a717c6..d02feaa 100755
--- a/debian/rules
+++ b/debian/rules
@@ -46,7 +46,7 @@ override_dh_auto_build:
 			-e 's/"NG_VERSION_CODENAME"/$(CODENAME)/' \
 >$(CURDIR)/debian/build/angular.js
 	# angular.min.js
-	#uglifyjs $(CURDIR)/debian/build/angular.js \
+	uglifyjs $(CURDIR)/debian/build/angular.js \
 		>$(CURDIR)/debian/build/angular.min.js
 
 	# angular-animate.js
@@ -55,7 +55,7 @@ override_dh_auto_build:
 		sed -e 's/"NG_VERSION_FULL"/$(VERSION)/' \
 			>$(CURDIR)/debian/build/angular-animate.js
 	# angular-animate.min.js
-	#uglifyjs $(CURDIR)/debian/build/angular-animate.js \
+	uglifyjs $(CURDIR)/debian/build/angular-animate.js \
 		>$(CURDIR)/debian/build/angular-animate.min.js
 
 	# angular-aria.js
@@ -64,7 +64,7 @@ override_dh_auto_build:
 		sed -e 's/"NG_VERSION_FULL"/$(VERSION)/' \
 			>$(CURDIR)/debian/build/angular-aria.js
 	# angular-aria.min.js
-	#uglifyjs $(CURDIR)/debian/build/angular-aria.js \
+	uglifyjs $(CURDIR)/debian/build/angular-aria.js \
 		>$(CURDIR)/debian/build/angular-aria.min.js
 
 	# angular-cookies.js
@@ -73,7 +73,7 @@ override_dh_auto_build:
 		sed -e 's/"NG_VERSION_FULL"/$(VERSION)/' \
 			>$(CURDIR)/debian/build/angular-cookies.js
 	# angular-cookies.min.js
-	#uglifyjs $(CURDIR)/debian/build/angular-cookies.js \
+	uglifyjs $(CURDIR)/debian/build/angular-cookies.js \
 		>$(CURDIR)/debian/build/angular-cookies.min.js
 
 	# angular-messages.js
@@ -82,7 +82,7 @@ override_dh_auto_build:
 		sed -e 's/"NG_VERSION_FULL"/$(VERSION)/' \
 			>$(CURDIR)/debian/build/angular-messages.js
 	# angular-messages.min.js
-	#uglifyjs $(CURDIR)/debian/build/angular-messages.js \
+	uglifyjs $(CURDIR)/debian/build/angular-messages.js \
 		>$(CURDIR)/debian/build/angular-messages.min.js
 
 	# angular-message-format.js
@@ -91,7 +91,7 @@ override_dh_auto_build:
 		sed -e 's/"NG_VERSION_FULL"/$(VERSION)/' \
 			>$(CURDIR)/debian/build/angular-message-format.js
 	# angular-message-format.min.js
-	#uglifyjs $(CURDIR)/debian/build/angular-message-format.js \
+	uglifyjs $(CURDIR)/debian/build/angular-message-format.js \
 		>$(CURDIR)/debian/build/angular-message-format.min.js
 
 	# angular-mocks.js
@@ -100,7 +100,7 @@ override_dh_auto_build:
 		sed -e 's/"NG_VERSION_FULL"/$(VERSION)/' \
 			>$(CURDIR)/debian/build/angular-mocks.js
 	# angular-mocks.min.js
-	#uglifyjs $(CURDIR)/debian/build/angular-mocks.js \
+	uglifyjs $(CURDIR)/debian/build/angular-mocks.js \
 		>$(CURDIR)/debian/build/angular-mocks.min.js
 
 	# angular-resource.js
@@ -109,7 +109,7 @@ override_dh_auto_build:
 		sed -e 's/"NG_VERSION_FULL"/$(VERSION)/' \
 			>$(CURDIR)/debian/build/angular-resource.js
 	# angular-resource.min.js
-	#uglifyjs $(CURDIR)/debian/build/angular-resource.js \
+	uglifyjs $(CURDIR)/debian/build/angular-resource.js \
 		>$(CURDIR)/debian/build/angular-resource.min.js
 
 	# angular-route.js
@@ -124,7 +124,7 @@ override_dh_auto_build:
 		sed -e 's/"NG_VERSION_FULL"/$(VERSION)/' \
 			>$(CURDIR)/debian/build/angular-route.js
 	# angular-route.min.js
-	#uglifyjs $(CURDIR)/debian/build/angular-route.js \
+	uglifyjs $(CURDIR)/debian/build/angular-route.js \
 		>$(CURDIR)/debian/build/angular-route.min.js
 
 	# angular-sanitize.js
@@ -136,7 +136,7 @@ override_dh_auto_build:
 		sed -e 's/"NG_VERSION_FULL"/$(VERSION)/' \
 			>$(CURDIR)/debian/build/angular-sanitize.js
 	# angular-sanitize.min.js
-	#uglifyjs $(CURDIR)/debian/build/angular-sanitize.js \
+	uglifyjs $(CURDIR)/debian/build/angular-sanitize.js \
 		>$(CURDIR)/debian/build/angular-sanitize.min.js
 
 	# angular-touch.js
@@ -148,7 +148,7 @@ override_dh_auto_build:
 		sed -e 's/"NG_VERSION_FULL"/$(VERSION)/' \
 			>$(CURDIR)/debian/build/angular-touch.js
 	# angular-touch.min.js
-	#uglifyjs $(CURDIR)/debian/build/angular-touch.js \
+	uglifyjs $(CURDIR)/debian/build/angular-touch.js \
 		>$(CURDIR)/debian/build/angular-touch.min.js
 
 	# angular-loader.js
@@ -162,7 +162,7 @@ override_dh_auto_build:
 		sed -e 's/"NG_VERSION_FULL"/$(VERSION)/' \
 			>$(CURDIR)/debian/build/angular-loader.js
 	# angular-loader.min.js
-	#uglifyjs $(CURDIR)/debian/build/angular-loader.js \
+	uglifyjs $(CURDIR)/debian/build/angular-loader.js \
 		>$(CURDIR)/debian/build/angular-loader.min.js
 
 	# angular-scenario.js

Bug#824706: RM: pepperflashplugin-nonfree [i386] -- RoQA; ANAIS

[Kristian Klausen]

Package: ftp.debian.org
Severity: normal


Hello

I did a NMU package of pepperflashplugin-nonfree which Gianfranco Costamagna 
sponsored.
Among the 3 RC bugs I fixed, I fixed #816848 by dropping i386.
As Google has dropped 32 bit Google Chrome on Linux, we can't provide a 32 bit 
pepperflash any longer.

So if you could please remove i386 from unstable.


I'm not aware of any reverse dependencies.



- Kristian
  

Bug#824702: apt: Incorrect translation in apt list --upgradable ru_RU.UTF8 locale

[Julian Andres Klode]

On Wed, May 18, 2016 at 11:27:59PM +0300, oleg wrote:
> Package: apt
> Version: 1.2.12
> Severity: minor
> 
> Dear Maintainer,
> in ru_RU.UTF8 locale is incorrect translation, for example:
> 
> vim/unstable 2:7.4.1829-1 amd64 [upgradable from: 2:7.4.1689-3]
> vim/unstable 2:7.4.1829-1 amd64 [может быть обновлён до:
> 2:7.4.1689-3]
> 
> correct is something like «может быть обновлён с:»

Adding debian-l10n-russ...@lists.debian.org to the loop.

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

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

Bug#824586: networkmanager-qt: FTBFS: dh_makeshlibs: failing due to earlier errors

[Maximiliano Curia]

¡Hola Chris!

El 2016-05-17 a las 20:05 +0100, Chris Lamb escribió:
Source: networkmanager-qt 
Version: 5.16.0-1 
Severity: serious 
Justification: fails to build from source 
User: reproducible-bui...@lists.alioth.debian.org 
Usertags: ftbfs 
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org


[Lots of Wimax symbols removed]

This is due to a change in network-manager 1.2.

Fixing this bug requires a binnmu to plasma-nm, but I'm planning to upload the 
newer versions of networkmanager-qt and plasma-nm soonish, and the problem 
will fix itself by then.


Happy hacking,
--
"Las computadoras son inútiles, solo pueden darte respuestas."
-- Pablo Picasso
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Bug#824695: phonon4qt5-backend-vlc: List of mime types do not match the ones in the vlc desktop file

[Diederik de Haas]

On Wednesday 18 May 2016 21:28:51 Petter Reinholdtsen wrote:
> Package: phonon4qt5-backend-vlc
> Version: 0.8.2-1
> 
> When comparing the list of MIME types in
> phonon-backend-vlc-0.8.2/MimeTypes.cmake with the file
> share/vlc.desktop.mimetypes in the vlc upstream git, the list of MIME
> types do mot match each other.  

phonon-backend-vlc 0.9.0-1 just got accepted to unstable and the git repo has 
the latest sources which is probably more useful to check (again).
https://anonscm.debian.org/cgit/pkg-kde/kde-std/phonon-backend-vlc.git/

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

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[Gianfranco Costamagna]

Hi Lumin,

>Thank you James, I've solved this problem.
I don't want to do the final checks until Ghislain gives me his personal ack, 
but
I see that the python3 dependencies might be fixed with not-much effort.

issues I would like to see fixed or answered:
python/requirements.txt <-- please check for missing runtime dependencies.


why some of them are outside that shlibs:Depends and not picked up 
automatically?
talking about
python-skimage and python-protobuf

e.g. you can't run cython if you don't put it on build-dependencies.
also all the requiremends, need to be in build-dependencies in order to be 
picked up
by python:Depends correctly.

for the python3 porting:
protobuf is python3 ready 

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795841
what about helping the maintainer in uploading it?


for skimage:
the package has two RC bugs, both fixed upstream 
#788965, #794859.
you need to fix all the dependencies if you really want your package in Stretch!
(btw for skimage, the new release fixes all the RC bugs
I also asked why it hasn't been packaged yet
https://github.com/scikit-image/scikit-image/issues/2091
)

Gianfranco

Bug#824695: phonon4qt5-backend-vlc: List of mime types do not match the ones in the vlc desktop file

[Maximiliano Curia]

Control: tag -1 + upstream
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=363240

¡Hola Petter!

El 2016-05-18 a las 21:28 +0200, Petter Reinholdtsen escribió:
Package: phonon4qt5-backend-vlc 
Version: 0.8.2-1


When comparing the list of MIME types in 
phonon-backend-vlc-0.8.2/MimeTypes.cmake with the file 
share/vlc.desktop.mimetypes in the vlc upstream git, the list of MIME 
types do mot match each other.  These ones are missing in the phonon 
backend build rules:



Should these two list be synced?


I'm not sure, so I've forwarded the bug upstream, the upstream bug can be 
tracked: https://bugs.kde.org/show_bug.cgi?id=363240


The list of MIME types in the upstream git repository was recently 
extended, but I was not aware of the list of MIME types in the phonon 
backend when doing so.


AFAICS, the mimetypes in the backends are used by phonon to know the 
backend capabilities, I'm not sure if this has any user facing effect.


Happy hacking,
--
"If a pickpocket meets a saint, he sees only his pockets."
-- Kegley's Law
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Bug#824704: Needs to be updated for gnome-shell 3.20

[Michael Biebl]

Control: reassign -1 gnome-shell-extension-redshift 3.18.1-1


Re-assigning to the correct package name

On Wed, 18 May 2016 22:50:03 +0200 Michael Biebl  wrote:
> Package: gnome-shell-extenstion-redshift
> Version: 3.18.1-1
> Severity: serious
> 
> Hi,
> 
> gnome-shell has been updated to version 3.20 in unstable.
> Your package declares a dependency on gnome-shell << 3.19 and is therefor
> no longer installable.
> Please update gnome-shell-extension-redshift to support gnome-shell
> 3.20.
> 
> Regards,
> Michael
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (200, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> 

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



signature.asc
Description: OpenPGP digital signature

Bug#823217: libmouse-perl: Mouse generates a 'No package name defined' under ModPerl::Registry

[Xavier]

Hi all,

I've removed tag "moreinfo" since upstream author can reproduce the bug.

Regards,
Xavier

Bug#818540: fix for 818540 never made it into Debian?

[Kristian Klausen]

Hi Dan
 
Google has dropped 32 bit support for Chrome on Linux
See bug 816848 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816848), I'm 
not sure why the i386 package is still present.
 
 
- Kristian


> Subject: Bug#818540: fix for 818540 never made it into Debian?
> From: jida...@jidanni.org
> To: klausenb...@hotmail.com
> CC: 818...@bugs.debian.org
> Date: Thu, 19 May 2016 04:20:33 +0800
>
> https://packages.debian.org/search?keywords=pepperflashplugin-nonfree
> shows you only updated non - i386 :-(
>
  

Bug#824668: gmt: please make the build reproducible (timestamps)

[Sebastiaan Couwenberg]

On 05/18/2016 06:44 PM, Alexis Bienvenüe wrote:
> Le 18/05/2016 17:36, Bas Couwenberg a écrit :
>> The transition to GDAl 2.1.0 is almost complete (#823335). I'll upload a
>> new GMT revision that includes the upstreamed patch after GDAL 2.1.0 is
>> in testing.
> 
> Great, thanks!

I've also forwarded your patch in the upstream issue for the earlier
patch. They may want to consider it because your solution also works on
Windows.

 http://gmt.soest.hawaii.edu/issues/905

Kind Regards,

Bas

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

Bug#824705: Please update build-dependency on Gwenhywfar

[Micha Lenk]

Source: kmymoney
Source-Version: 4.6.6-3
Tags: patch


Dear KMymoney maintainer,

in the a recent upload the Gwenhywfar library added support for Qt 5. As
this is the fourth GUI framework that is supported by the Gwenhywfar
library, I redesigned the Debian binary package layout a bit so that
each supported GUI framework library now has its own -dev package. To
not break existing packages, the old binary package libgwenhywfar60-dev
still exists as a meta package that pulls in all the -dev packages
through its dependencies.

This package split aims at making the life of maintainers easier that
maintain a package that build-depends on the Gwenhywfar library. If you
want to benefit from the new package layout, you need to tweak the
build-dependencies of the kmymoney package. All packages linking against
the Gwenhywfar library will need a build-dependency on
libgwenhywfar-core-dev. Depending on the used GUI framework, another
libgwengui-*-dev package is needed as build-dependency (e.g.
libgwengui-qt4-dev for the Qt 4 framework).

Please consider the attached patch to change the build-dependencies of
the kmymoney package accordingly.

Best regards,
Micha
Index: debian/control
===
--- debian/control	(revision 20477)
+++ debian/control	(working copy)
@@ -5,7 +5,7 @@
 Uploaders: Mark Purcell , Fathi Boudra 
 Build-Depends: debhelper (>= 9), cmake, pkg-kde-tools (>= 0.9.0),
  kdelibs5-dev (>= 4:4.4.4), kdepimlibs5-dev (>= 4:4.4.4), shared-mime-info,
- libaqbanking-dev (>= 5.6.1beta), libgwenhywfar60-dev | libgwenhywfar-dev, 
+ libaqbanking-dev (>= 5.6.1beta), libgwenhywfar-core-dev, libgwengui-qt4-dev,
  libboost-graph-dev, libgpgme11-dev, libalkimia-dev,
  libical-dev, libofx-dev, libgmp-dev,
  pkg-config,

Bug#824704: Needs to be updated for gnome-shell 3.20

[Michael Biebl]

Package: gnome-shell-extenstion-redshift
Version: 3.18.1-1
Severity: serious

Hi,

gnome-shell has been updated to version 3.20 in unstable.
Your package declares a dependency on gnome-shell << 3.19 and is therefor
no longer installable.
Please update gnome-shell-extension-redshift to support gnome-shell
3.20.

Regards,
Michael


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

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

Bug#803013: Delegate=yes

[Tomasz Janowski]

Hello Martin,

Thank you for your response. My point is that the issue originally reported in 
this bug is serious and it was swiftly corrected by Red-Hat and systemd 
developers. Debian maintainers decided to take no action and it appears that 
the stable distribution will have a buggy version of systemd until the next 
major release. What is even more interesting, the original post about the 
problem comes with a simple patch  that when applied removes the problem 
completely. Is  that patch incorrect? It works for me so far.

Now, it is not possible to use the stable Debian with the SLURM scheduler that 
controls jobs using cgroups, since systemd will destroy SLURM's memory 
controller configuration every time it is restarted, via the sequence:

systemctl daemon-reload
systemctl restart any.service

In my case adding user accounts requires performing exactly these two steps, 
due to systemd.automount. I cannot do it when jobs are running and even 
installing new software is risky, as a package scripts can reload systemd 
followed by restarting a service.

Best,
Tomasz


From: Martin Pitt 
Sent: Wednesday, May 18, 2016 4:35 PM
To: Tomasz Janowski; 803...@bugs.debian.org
Subject: Re: Bug#803013: Delegate=yes

Hello Tomasz,

Tomasz Janowski [2016-05-18 10:53 -0400]:
>  I did not fully understand this, but what is the reason that Delegate=yes is
> not available in Jessie? It was fixed upstream.

This wasn't really planned -- it just so happened that the Delegate=
option was added after 215, i. e. after the Jessie release.

Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#824551: cinnamon-settings-daemon: please consider to cherry-pick 0677dbf4e9fead24b6dbbf2465ee3f0609c54865

[Margarita Manterola]

Control: reassign -1 cinnamon 3.0.2-1
Control: retitle -1 cinnamon: allow disabling gtk-scrollbars (and disable them 
by default)

El Martes 17 Mayo 2016 14:23 CEST, Christoph Anton Mitterer 
 Ha escrito:
Hi,

> Package: cinnamon-settings-daemon
> Version: 3.0.1-2

Actually, the patch is to the cinnamon package.  I wonder why you
reported this to cinnamon-settings-daemon, which is not affected
by this change :).

Anyway, working on this, should be ready soon.

--
Regards,
Marga

Bug#803013: Delegate=yes

[Martin Pitt]

Hello Tomasz,

Tomasz Janowski [2016-05-18 10:53 -0400]:
>  I did not fully understand this, but what is the reason that Delegate=yes is 
> not available in Jessie? It was fixed upstream.

This wasn't really planned -- it just so happened that the Delegate=
option was added after 215, i. e. after the Jessie release.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#824703: file: magic entry to recognize Matlab V5 files

[Stephen Crowley]

Package: file
Version: 1:5.25-2
Severity: wishlist

Dear Maintainer,

please add the following entries to recognize Matlab V5/V4 file
formats which are documented at 

https://maxwell.ict.griffith.edu.au/spl/matlab-page/matfile_format.pdf

0x7e string IM Matlab V5
0x7e string MI Matlab V5

One is little indian version, one is big endian

the null terminated character string from 0 to 124 bytes should be
reported by libmagicfile as additional info, its a descriptive field
indicating the program that wrote the file, but I was unable to
quickly figure out the syntax for that

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/32 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 file depends on:
ii  libc6  2.22-7
ii  libmagic1  1:5.25-2
ii  zlib1g 1:1.2.8.dfsg-2+b1

file recommends no packages.

file suggests no packages.

-- no debconf information

--
The information contained in this communication may be confidential and/or 
legally privileged. If you are not the intended recipient, please contact the 
sender and destroy all copies of this message and any attachments. Any 
disclosure, copying, distribution or taking any action in reliance on this 
information other than by the intended recipient is strictly prohibited and may 
be unlawful. Canaccord Genuity Inc. is required by regulation to review and 
store both outgoing and incoming electronic correspondence. E-mail 
transmissions cannot be guaranteed to be secure, timely or error-free. This 
communication is not an offer or solicitation to buy or sell any security or 
other investment product. Additional information, including disclosures 
regarding securities under research coverage, is available at 
http://www.canaccordgenuity.com/en/Our-Company/Research/  . Any information 
regarding specific investment products is subject to change without notice. 
Canaccord Genuity Inc. - Member FINRA
 /SIPC.

Bug#791662: aptitude: debdelta integration

[Yuri D'Elia]

On Wed, May 18 2016, Julian Andres Klode  wrote:
> On Wed, May 18, 2016 at 01:59:22PM +0200, A Mennucc1 wrote:
>> But keep in mind that debdelta is integrated in 'cupt' that is another
>> package manager, similar to 'aptitude'.

The main selling point of aptitude for me is the sophisticated curses
interface and it's preview. I wouldn't bother using aptitude if it
wasn't for it's TUI (in fact, I use apt-get directly in other
scenarios).

> 1. An index of all deltas (probably per-arch) with checksums for them
>(basically that's old hash, new hash, delta hash, and size. hashes
> should be SHA256 or SHA512). Preferably also Package, Version,
>Old-Version, Architecture fields.
> 2. A release file signing the index

Do we need all of those? A reconstructed package is byte-for-byte
identical to the package already in the pool. We can verify the
authenticity using the original archive signature before installing it.

I don't know if debdelta has already delta checksums themselves (mainly
to prevent corruption over transfer).

Please correct me if I'm wrong.

> We want to have that for security reasons (we do not
> want to trust unsigned data), and of course for progress display
> (we need to know how many files to fetch and how large they are).

This should also be already available.

> I'm still not sure if debdelta is the right approach, or if we can
> come up with something faster.

Downloading deltas is a CPU/space tradeoff. Over a fast link, rebuilding
the package with the delta is going to take longer than simply
redownloading it in full.

Which is the main reason we need a controllable switch in the frontend.

Bug#824702: apt: Incorrect translation in apt list --upgradable ru_RU.UTF8 locale

[oleg]

Package: apt
Version: 1.2.12
Severity: minor

Dear Maintainer,
in ru_RU.UTF8 locale is incorrect translation, for example:

vim/unstable 2:7.4.1829-1 amd64 [upgradable from: 2:7.4.1689-3]
vim/unstable 2:7.4.1829-1 amd64 [может быть обновлён до:
2:7.4.1689-3]

correct is something like «может быть обновлён с:»



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.5\.0-2-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";

Bug#816607: http://charls.codeplex.com/workitem/10742

[Victor Derks]

Hi Sjors and Mathieu,

I found the problem why the output of the decoded image by the original
loco implementation and charls were not identical. This issue was caused by
a defect in the charls test applications that creates the .pnm file. With
the repaired test application the imaged can be encoded and decoded
identical to the original input file. The charls library itself was ok
after the initial fix.

I have tagged the branches as 1.1.0 and 2.0.0.

Victor








On Wed, Apr 27, 2016 at 2:43 PM, Mathieu Malaterre  wrote:

> Hi Victor,
>
> On Wed, Mar 30, 2016 at 11:53 PM, Victor Derks  wrote:
> > Hi Sjors,
> >
> > I pushed the fix to the master and 1.x-master branch on github.
> >
> > The sample file can now be encoded to JPEG-LS and back to the .pnm
> format.
> > If I decode it back with CharLS the image is however not 100% identical.
> If
> > I decode it back with the ITU LOCO exe, the original and the
> encoded\decoded
> > files are identical.
> > So the encoding to JPEG-LS seems to be ok, but there seems another issue
> in
> > the charls decoding process (maybe the fact the width is odd of this
> sample
> > image?).
> >
> > Will keep you posted
>
> Hum your patch make the attached DICOM file works. So indeed it does
> solve some issues.
>

Bug#818540: fix for 818540 never made it into Debian?

[積丹尼 Dan Jacobson]

https://packages.debian.org/search?keywords=pepperflashplugin-nonfree
shows you only updated non - i386 :-(

Bug#818540: fix for 818540 never made it into Debian?

[積丹尼 Dan Jacobson]

I see Date: Fri, 13 May 2016 14:44:52 +0200
but the new package is nowhere to be found. Not in
http://incoming.debian.org/debian-buildd/pool/contrib/
either.

Bug#824701: btrbk: Btrbk should recommend package pv

[Vincent Meurisse]

Package: btrbk
Version: 0.23.1-1
Severity: minor

Dear Maintainer,

After installing btrbk on a clean system, the following command results
in a warning and the option is ignored

# btrbk run --progress
WARNING: Found option "--progress", but required executable "pv" does
not exist on your system. Please install "pv".

Btrbk should probably recommend or suggest the package pv.

-- 
Vincent

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (700, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages btrbk depends on:
ii  btrfs-tools  4.4.1-1.1~bpo8+1
ii  perl 5.20.2-3+deb8u4

btrbk recommends no packages.

Versions of packages btrbk suggests:
ii  openssh-client  1:6.7p1-5+deb8u2

-- no debconf information

Bug#823264: Bug#824673: wine32-development-tools:i386 cannot be installed on amd64

[Jens Reyer]

control: block 823264 by 824673

Hi,

[ This has already been requested/asked in #823264 (reported against
wine). Added to CC now, but please send answers only to #824673.
Blocking that bug by this one here, because we usually fix stuff in
wine-development first. ]

I wonder if it's really necessary to use wine32-tools at all. Or is
winegcc from wine64-tools, with gcc-multilib installed, producing the
same results if "-m32" is specified?

If we indeed need wine32-tools:

For the dependeny on gcc the following had been suggested:

 gcc | gcc-multilib:amd64 [i386]

I successfully tested this here, but I'm not sure if specifying a
specific package arch this way (":amd64") is allowed. Further
gcc-multilib has no Multi-Arch field, while I'd expect "m-a:foreign" or
at least "allowed" for this to work. I'll ask the multi-arch folks about
that soon.

Is it really necessary to explicitly specify "-m32" for compiling 32-bit
apps on amd64 with wine32(-development)-tools?
If yes, I wonder if this should be mentioned either in the README, or
added with some logic to the winegcc wrapper script.

We also discussed a possible multi-arch dependency on perl in #823264. I
just noticed in dh_perl(1) that ${perl:Depends} gets resolved to perl
*or* perlapi, while no other alternative value is mentioned there. So we
may use:

 ${perl:Depends} | perl:any [i386]

We may even use "perl:any" only, but I'd like to keep the variable in
order to notice if anything changes there. Some way for dh_perl to
handle this would be preferable.
Or we depend on perl:any and recommend ${perl:Depends}.

However I'd like to first know for what exactly perl is needed, and if
perl:any would work for wine, or if native (i386) perl is needed for at
least some things. Anyone?


Greets
jre

Bug#752891: fixed in systemtap 3.0-3

[Breno Leitao]

   * Build for any architecture. This includes arm64, ppc64el and s390x.
 Closes: #752891.


I understand that this bugs is still not fixed in ppc64el, due to 
systemtap-runtime not being built for ppc64el.


The problem could be seen as:

  $ sudo apt-get install systemtap
  

  The following packages have unmet dependencies:
   systemtap : Depends: systemtap-runtime (= 3.0-3) but it is not installable


Looking at systemtap package, I still see:

   Package: systemtap-runtime
   ...
   Architecture: i386 amd64 ia64 s390 powerpc powerpcspe arm armel armeb armhf

That said, I still think you should enable systemtap-runtime for ppc64el. I 
attached a patch that do so.


I am reopening this bug.

--- debian/control.old	2016-05-18 15:53:08.401334286 -0400
+++ debian/control	2016-05-18 15:53:17.861518710 -0400
@@ -61,7 +61,7 @@ Package: systemtap-runtime
 Replaces: systemtap (<< 0.0.20081220-1)
 Breaks: systemtap (<< 0.0.20081220-1)
 Suggests: systemtap
-Architecture: i386 amd64 ia64 s390 powerpc powerpcspe arm armel armeb armhf
+Architecture: i386 amd64 ia64 s390 powerpc ppc64el powerpcspe arm armel armeb armhf
 Depends: ${shlibs:Depends}, ${misc:Depends}, adduser
 Description: instrumentation system for Linux (runtime component)
  This package contains staprun program that can be used to run

Bug#824551: cinnamon-settings-daemon: please consider to cherry-pick 0677dbf4e9fead24b6dbbf2465ee3f0609c54865

[Margarita Manterola]

severity 824551 important
retitle 824551 cinnamon-settings-daemon: allow disabling gtk-scrollbars (and 
disable them by default)

clone 824551 -1 -2
reassign -1 cinnamon-session 3.0.0-1
retitle -1 cinnamon-session: Add support for disabling gtk overlay scrollbars

reassign -2 cinnamon-desktop 3.0.1-1
retitle -2 cinnamon-desktop: Update schema to include new gtk-overlay-scrollbar

thanks

 > Please consider to cherry-pick upstream commit:
> 0677dbf4e9fead24b6dbbf2465ee3f0609c54865

This commit is not enough.  This is just the dialog that allows you to set the
value, but we also need to add the support for actually doing something with it,
which was committed at:
https://github.com/linuxmint/cinnamon-session/commit/96f25057cac202e13c338886d00bc0383394ad26

And the updated schema at:
https://github.com/linuxmint/cinnamon-desktop/commit/9076d6217ae8a7a5b427c29f95c183b48ee0d751

I'll be doing this changes and the corresponding uploads, including setting
the overlay scrollbars to default to false instead of true.

Cheers,

--
Marga

Bug#824698: redir: New upstream, and new release(s)

[Joachim Nilsson]

Package: redir
Version: 2.2.1-13
Severity: wishlist
Tags: upstream

Dear Maintainer,

recently I picked up maintenance of redir and there are now
two new releases available:

https://github.com/troglobit/redir/releases

v2.3: Integrates (almost) all Debian patches.  I've tried
to be very careful with both correct attribution and to
describe what the patches does, to ease your burden of
upgrading, should you chose to do so.

v3.0: Overhaul and simplification of command line syntax,
massive code simplification and cleanup.  With fixes to
some really nasty bugs found by Coverity Scan.

Cheers
 /Joachim

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

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

Bug#821811: samba: badlock patch breaks trust relationship

[Antoine Beaupré]

On 2016-04-29 08:55:43, Santiago Ruano Rincón wrote:
> Dear Samba maintainers,
>
> Any updates about this bug?
>
> LTS Team, anyone could help to handle it?
>
> According to comment#17 in
> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1572122
> Andreas Schneider prepared a fix for 3.6.25.

Hi again!

Should the LTS team prepare a regression update to the wheezy version at
least?

It seems things have been resolved on the Ubuntu side of things.

A.

-- 
We live in capitalism. Its power seems inescapable.  So did the divine
right of kings. Any human power can be resisted and changed by human
beings. Resistance and change often begin in art, and very often in
our art—the art of words. - Ursula Le Guin

Bug#824677: aiccu: please depend on iproute2 instead of iproute transitional package

[Jeroen Massar]

On 2016-05-18 18:46, Andreas Henriksson wrote:
> Package: aiccu
> Version: 20070115-15.3
> Severity: normal
> 
> Dear Maintainer,
> 
> Please update the aiccu package dependencies to use 'iproute2' instead
> of the transitional package 'iproute'.
> 
> The transition from the old iproute package name to iproute2 happened in
> Debian Jessie, so the transitional package are now ready to be removed.
> If your package is not updated by then it'll become uninstallable (and
> thus RC-buggy).

Would love to update this, but unfortunately we do not get commit-alike
access..

Thus please do a NMU for that simple fix, as no Debian Developer is
currently assigned to the aiccu package... ;(

If somebody can sponsor uploads though, we would love to know about that.

Greets,
 Jeroen

Bug#824696: debhelper: dh_perl should report perl:any when unversioned

[Javier Serrano Polo]

Package: debhelper
Version: 9.20160403
Severity: wishlist
Tags: patch

Unversioned dependencies (no binary modules) should be architecture
independent (perl:any).
--- a/dh_perl	2016-04-03 10:17:54.0 +
+++ b/dh_perl	2016-05-18 19:02:27.0 +
@@ -126,10 +126,14 @@
 unless $version;
 			$version = ">= $version";
 		}
-		
+
+		# unversioned dependency should be architecture independent
+		my $perlarch = $perl;
+		$perlarch .= ':any' unless length($version);
+
 		# no need to depend on an un-versioned perl-base -- it's
 		# essential
-		addsubstvar($package, "perl:Depends", $perl, $version)
+		addsubstvar($package, "perl:Depends", $perlarch, $version)
 			unless $perl eq 'perl-base' && ! length($version);
 
 		# add perlapi- for XS modules and other modules


smime.p7s
Description: S/MIME cryptographic signature

Bug#824697: confuse: New upstream release, v3.0

[Joachim Nilsson]

Source: confuse
Severity: wishlist
Tags: upstream

Dear Maintainer,

there are two new upstream releases available at Martin's new
location for libConfuse, at GitHub

v2.8: A few fixes and some new features

v3.0: Major changes, including ABI bump, library no longer asserts(),
but returns error code(s), support for handling unknown options for
future proofing a parser, and more.

For the full details of the changes, please see the ChangeLog for
each release 

Cheers
 /Joachim

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

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

Bug#824689: [Build-common-hackers] Bug#824689: cdbs: syntax error in perl-makemaker.mk

[Jonas Smedegaard]

Quoting Niko Tyni (2016-05-18 20:09:57)
> Many packages are failing to build on current sid with these symptoms:
> 
>   /bin/sh: 1: Syntax error: ")" unexpected
>   /usr/share/cdbs/1/class/perl-makemaker.mk:47: recipe for target 'Makefile' 
> failed
>   make: *** [Makefile] Error 2
>   dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> This seems to be a regression in cdbs 0.4.133, commit
> https://anonscm.debian.org/cgit/collab-maint/cdbs.git/commit/?id=c0098c1979699fdb8099183ccf48455c009a71ac
> 
> -   $(error DEB_BUILDDIR and DEB_SRCDIR must be the same for Perl builds))
> +   $(error DEB_BUILDDIR and DEB_SRCDIR must be the same \
> +   for Perl builds)))
> 
> Note the added closing parenthesis.

Thanks for reporting!

Fixed package is being built now...

 - 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#824695: phonon4qt5-backend-vlc: List of mime types do not match the ones in the vlc desktop file

[Petter Reinholdtsen]

Package: phonon4qt5-backend-vlc
Version: 0.8.2-1

When comparing the list of MIME types in
phonon-backend-vlc-0.8.2/MimeTypes.cmake with the file
share/vlc.desktop.mimetypes in the vlc upstream git, the list of MIME
types do mot match each other.  These ones are missing in the phonon
backend build rules:

application/mpeg4-iod
application/mpeg4-muxcodetable
application/mxf
application/ram
application/sdp
application/vnd.apple.mpegurl
application/vnd.ms-asf
application/vnd.ms-wpl
application/vnd.rn-realmedia-vbr
application/x-extension-m4a
application/x-flac
application/x-matroska
application/x-quicktime-media-link
application/x-shockwave-flash
application/xspf+xml
audio/aac
audio/ac3
audio/AMR
audio/AMR-WB
audio/dv
audio/eac3
audio/flac
audio/m4a
audio/mp1
audio/mp2
audio/mpegurl
audio/mpg
audio/ogg
audio/opus
audio/scpls
audio/vnd.dolby.heaac.1
audio/vnd.dolby.heaac.2
audio/vnd.dolby.mlp
audio/vnd.dts
audio/vnd.dts.hd
audio/x-aac
audio/x-gsm
audio/x-mp1
audio/x-mp2
audio/x-mpg
audio/x-ms-asf
audio/x-ms-asx
audio/x-ms-wax
audio/x-musepack
audio/x-pn-realaudio
audio/x-scpls
audio/x-shorten
audio/x-speex
audio/x-tta
audio/x-vorbis
audio/x-wavpack
image/vnd.rn-realpix
misc/ultravox
text/google-video-pointer
text/x-google-video-pointer
video/3gp
video/dv
video/fli
video/mp2t
video/mp4v-es
video/vnd.divx
video/vnd.mpegurl
video/vnd.rn-realvideo
video/x-avi
video/x-flc
video/x-fli
video/x-mpeg2
video/x-ms-asf-plugin
video/x-ms-asx
video/x-ms-wm
video/x-ms-wmx
video/x-nsv
video/x-ogm+ogg
video/x-theora
video/x-theora+ogg
x-content/audio-cdda
x-content/audio-player
x-content/video-dvd
x-content/video-svcd
x-content/video-vcd
x-scheme-handler/icy
x-scheme-handler/icyx
x-scheme-handler/mms
x-scheme-handler/mmsh
x-scheme-handler/rtmp
x-scheme-handler/rtp
x-scheme-handler/rtsp

While these are missing in the vlc upstream git reposiory:

application/x-annodex
audio/168sv
audio/8svx
audio/aiff
audio/mpeg2
audio/mpeg3
audio/prs.sid
audio/vnd.rn-realmedia
audio/x-16sv
audio/x-8svx
audio/x-basic
audio/x-mpeg2
audio/x-mpeg3
audio/x-ogg
audio/x-speex+ogg
image/ilbm
image/png
image/x-ilbm
image/x-png
video/anim
video/avi
video/mkv
video/mng
video/mpg
video/x-flic
video/x-mng
video/x-ms-wma
video/x-quicktime

Should these two list be synced?

The list of MIME types in the upstream git repository was recently
extended, but I was not aware of the list of MIME types in the phonon
backend when doing so.

-- 
Happy hacking
Petter Reinholdtsen

Bug#807006: closed by Michael Tokarev <m...@tls.msk.ru> (Bug#807006: fixed in qemu 1:2.6+dfsg-1)

[John Paul Adrian Glaubitz]

Control: reopen -1

I'm sorry, but this has not been fixed [1]. In fact, this particular
patch hasn't even merged in the git repository of qemu [2].

It might not be the best idea to close Debian bugs anonymously, e.g.
merely by referencing their bug numbers without an actual message.

Adrian

> [1]
https://buildd.debian.org/status/fetch.php?pkg=qemu=sparc64=1%3A2.6%2Bdfsg-1=1463590883
> [2] https://patchwork.ozlabs.org/patch/620832/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#824693: ocaml: Enable native compilers in ppc64el starting at version 4.03

[Breno Leitao]

Package: ocaml
Version: 4.02.3-6
Severity: important
Tags: patch

Currently, the package ocaml-native-compilers is not being built for ppc64el
because the patch to enable it still not available in version 4.02.3.

Starting at version 4.03, the patch to enable native compiler on ppc64el is
integrated into the source code (SVN revision 16374) and [1], thus, I would
like to have package omcal-native-compilers targeting ppc64el.

OcamL native compiler is required to be enable in order to enable hhvm package,
which build-depends on ocaml-native-compilers.

The patches to enable ocaml-native-compilers package to be built on ppc64el
when using version 4.03 is attached.

[1] https://github.com/ocaml/ocaml/pull/225

PS: I may backport the upstream patches to 4.02 if you think that 4.03 will not
make Debian soon.
--- debian/native-archs.old	2016-05-18 14:32:35.755331340 -0400
+++ debian/native-archs	2016-05-18 14:33:21.220295272 -0400
@@ -1 +1 @@
-amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-i386 kfreebsd-amd64 lpia powerpc sparc
+amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-i386 kfreebsd-amd64 lpia powerpc ppc64el sparc
--- debian/natdynlink-archs.old	2016-05-18 14:32:56.627773846 -0400
+++ debian/natdynlink-archs	2016-05-18 14:33:10.268063067 -0400
@@ -1 +1 @@
-amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-i386 kfreebsd-amd64 lpia powerpc sparc
+amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-i386 kfreebsd-amd64 lpia powerpc ppc64el sparc
--- debian/control.old	2016-05-18 14:49:33.897048690 -0400
+++ debian/control	2016-05-18 14:49:45.753301569 -0400
@@ -146,7 +146,7 @@ Description: Runtime system for OCaml by
  you do not require any graphical capabilities for your runtime.
 
 Package: ocaml-native-compilers
-Architecture: amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-i386 kfreebsd-amd64 lpia powerpc sparc
+Architecture: amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-i386 kfreebsd-amd64 lpia powerpc ppc64el sparc
 Depends:
  ocaml-nox (= ${binary:Version}),
  gcc, binutils,