Bug#793352: diffuse: [INTL:th] Please add Thai program translation.

[Theppitak Karoonboonyanan]

Package: diffuse
Version: 0.4.8-2
Followup-For: Bug #793352

Thank you for your prompt reply, and sorry for my late acknowledgement.

I've prepared another patch for additional translations as you suggested.
Please find it in the attachment.

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
Index: diffuse-0.4.8/src/usr/share/applications/diffuse.desktop
===
--- diffuse-0.4.8.orig/src/usr/share/applications/diffuse.desktop
+++ diffuse-0.4.8/src/usr/share/applications/diffuse.desktop
@@ -8,6 +8,7 @@ Name[ja]=Diffuse マージツール
 Name[ko]=Diffuse 병합도구
 Name[pl]=Diffuse Narzędzie Scalania
 Name[ru]=Diffuse Инструмент Слияния
+Name[th]=Diffuse - เครื่องมือผสานแฟ้ม
 Name[zh_CN]=Diffuse 比较合并工具
 Name[zh_TW]=Diffuse 比較合併工具
 Comment=Graphical tool for merging and comparing text files
@@ -19,6 +20,7 @@ Comment[ja]=テキストファイルをã
 Comment[ko]=텍스트 파일을 병합하고 비교하기위한 도구
 Comment[pl]=Graficzne narzędzie do łączenia i porównywania plików tekstowych
 Comment[ru]=Графический инструмент для слияния и сравнения текстовых файлов
+Comment[th]=เครื่องมือแบบกราฟิกสำหรับเปรียบเทียบและผสานแฟ้มข้อความ
 Comment[zh_CN]=图形化的比较和合并文本文件的工具
 Comment[zh_TW]=比較與合併文字檔案的圖形化工具
 Exec=diffuse -s %F
Index: diffuse-0.4.8/windows-installer/th.isl
===
--- /dev/null
+++ diffuse-0.4.8/windows-installer/th.isl
@@ -0,0 +1,7 @@
+[CustomMessages]
+ToolName=Diffuse - เครื่องมือผสานแฟ้ม
+UninstallTool=ถอดถอนเครื่องมือผสานแฟ้ม Diffuse
+OpenWithTool=เปิดด้วยเครื่องมือผสานแฟ้ม Diffuse
+MainFiles=แฟ้มหลัก
+ShellIntegration=การเชื่อมรวมกับเชลล์ของวินโดวส์
+AddToPath=เพิ่มพาธที่ติดตั้งเข้าในลำดับพาธค้นหาโปรแกรม

Bug#786119: marked as done (python-popcon: deprecation of python-support)

[Bastian Venthur]

Hi Matthias,

Thanks for fixing the Bug, however I'm not so happy with the procedure
of your NMU.

* It would have been nice if you'd have provided the patch in the
  bugtracker giving me some time to review and upload myself
* It would also have been nice if you uploaded the NMU to one of the
  delayed queues

as far as I know those are the best practices for NMUs we have right now
in Debian.

Instead, you immediately updated the package and even worse introduced a
new FTBFS bug: https://bugs.debian.org/796649, effectively forcing my
hand to take action immediately to clean up after you.


Cheers,

Bastian



Am 22.08.2015 um 11:45 schrieb Debian Bug Tracking System:
> Your message dated Sat, 22 Aug 2015 09:42:52 +
> with message-id 
> and subject line Bug#786119: fixed in python-popcon 1.1+nmu1
> has caused the Debian Bug report #786119,
> regarding python-popcon: deprecation of python-support
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 

-- 
Dr. Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org

Bug#796756: FTBFS: test_query raises PyAsn1Error

[Brian May]

On Mon, 24 Aug 2015 at 10:06 Luke Faraone  wrote:

> Source: python-tldap
> Version: 0.3.10-1
> Severity: serious
> Justification: fails to build from source
> User: python-dja...@packages.debian.org
> Usertags: django18
>

This might be a python-ldap3 bug, or a pyasn1 bug.

Have reported this bug to the upstream python-ldap3 maintainer.
https://github.com/cannatag/ldap3/issues/102

Bug#796400: [pkg-go] Bug#796400: Bug#796400: golang-github-jacobsa-ratelimit: Non-determistically FTBFS due to unreliable timing in tests

[Michael Stapelberg]

On Sun, Aug 23, 2015 at 11:47 PM, Aaron Jacobs  wrote:
> Yes, this is a test for an object whose functionality is based on wall time, 
> so
> it uses wall time. I know that makes it flaky and in general I try to avoid
> such tests, but it was a conscious decision here.

Could the timing requirements be relaxed to make it less flaky?

> The best way to deal with this may be to just delete the package. Michael, I
> apologize because I know you've spent a bunch of time on this, but it seems
> like the Debian packaging model just doesn't work out for us. (In particular:
> lack of support for vendoring and needing a separate package per tiny
> dependency.) :-(

I don’t think giving up is a good idea :). FWIW, just to be clear,
it’s not that vendoring is not supported, it’s a conscious decision by
Debian to avoid it. Also, AFAICT, other distributions (like Fedora)
are following the same model, so I don’t think Debian is different in
this regard. If you have trouble getting the software into Debian,
you’ll likely have trouble getting it into any of the other big
distributions, too.

>
> Aaron
>
> On Sun, Aug 23, 2015 at 9:08 PM, Michael Stapelberg
>  wrote:
>> Aaron, could you take a look at this problem please? It seems to me
>> like this is a shortcoming of your tests, unrelated to Debian.
>>
>> On Fri, Aug 21, 2015 at 8:44 PM, Chris Lamb  wrote:
>>> Source: golang-github-jacobsa-ratelimit
>>> Version: 0.0~git20150723.0.2ca5e0c-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
>>>
>>> Dear Maintainer,
>>>
>>> golang-github-jacobsa-ratelimit's testsuite appears to use method
>>> timing/benchmarking in such
>>> a way that it will non-deterministically FTBFS:
>>>
>>>   throttle_test.go:
>>> expected := smallerRateHz * (float64(perCaseDuration) /
>>> float64(time.Second))
>>>
>>> For example:
>>>
>>>   [..]
>>> go test -v github.com/jacobsa/ratelimit
>>>   === RUN TestThrottle
>>>   [--] Running tests from ThrottleTest
>>>   [ RUN  ] ThrottleTest.IntegrationTest
>>>   throttle_test.go:202:
>>>   Expected: greater than 135, and less than 165
>>>   Actual:   88
>>>   Test case 0. expected: 150.00
>>>
>>>   throttle_test.go:202:
>>>   Expected: greater than 180, and less than 220.03
>>>   Actual:   138
>>>   Test case 1. expected: 200.00
>>>
>>>   throttle_test.go:202:
>>>   Expected: greater than 180, and less than 220.03
>>>   Actual:   163
>>>   Test case 2. expected: 200.00
>>>
>>>   [  FAILED  ] ThrottleTest.IntegrationTest (6.031585896s)
>>>   [--] Finished with tests from ThrottleTest
>>>   [--] Running tests from ThrottledReaderTest
>>>   [ RUN  ] ThrottledReaderTest.CallsThrottle
>>>   [   OK ] ThrottledReaderTest.CallsThrottle
>>>   [ RUN  ] ThrottledReaderTest.ThrottleReturnsError
>>>   [   OK ] ThrottledReaderTest.ThrottleReturnsError
>>>   [ RUN  ] ThrottledReaderTest.CallsWrapped
>>>   [   OK ] ThrottledReaderTest.CallsWrapped
>>>   [ RUN  ] ThrottledReaderTest.WrappedReturnsError
>>>   [   OK ] ThrottledReaderTest.WrappedReturnsError
>>>   [ RUN  ] ThrottledReaderTest.WrappedReturnsEOF
>>>   [   OK ] ThrottledReaderTest.WrappedReturnsEOF
>>>   [ RUN  ] ThrottledReaderTest.WrappedReturnsFullRead
>>>   [   OK ] ThrottledReaderTest.WrappedReturnsFullRead
>>>   [ RUN  ] ThrottledReaderTest.WrappedReturnsShortRead_CallsAgain
>>>   [   OK ] ThrottledReaderTest.WrappedReturnsShortRead_CallsAgain
>>>   [ RUN  ]
>>>   ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsError
>>>   [   OK ]
>>>   ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsError
>>>   [ RUN  ]
>>>   ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsEOF
>>>   [   OK ]
>>>   ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsEOF
>>>   [ RUN  ]
>>>   ThrottledReaderTest.WrappedReturnsShortRead_SecondSucceedsInFull
>>>   [   OK ]
>>>   ThrottledReaderTest.WrappedReturnsShortRead_SecondSucceedsInFull
>>>   [ RUN  ] ThrottledReaderTest.ReadSizeIsAboveThrottleCapacity
>>>   [   OK ] ThrottledReaderTest.ReadSizeIsAboveThrottleCapacity
>>>   [--] Finished with tests from ThrottledReaderTest
>>>   [--] Running tests from TokenBucketTest
>>>   [ RUN  ] TokenBucketTest.CarefulAccounting
>>>   [   OK ] TokenBucketTest.CarefulAccounting
>>>   [--] Finished with tests from TokenBucketTest
>>>   --- FAIL: TestThrottle (6.03s)
>>>   === RUN TestThrottledReader
>>>   --- PASS: TestThrottledReader (0.00s)
>>>   === RUN TestTokenBucket
>>>   --- PASS: TestTokenBucket (0.00s)
>>>   FAIL
>>>   exit status 1
>>>   FAILgithub.com/jacobsa/ratelimit6.074s
>>>   dh_auto_test: go test -v github.com/jacobsa/ratelimit returned exit
>>>   code 1
>>>   debian/rules:6

Bug#796764: konversation: please package latest release

[Salvo Tomaselli]

Package: konversation
Version: 1.5-2
Severity: normal

Dear Maintainer,
the latest release of conversation uses Qt5, and the newer KDE libraries.

It would be nice to update it, especially because Qt4 are being phased out.

Is help needed with packaging?

Best

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

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

Versions of packages konversation depends on:
ii  kde-runtime4:4.14.2-2
ii  kdepim-runtime 4:4.14.2-3+b1
ii  kdepim-runtime-dummy [kdepim-runtime]  4:4.14.2-3
ii  konversation-data  1.5-2
ii  libc6  2.19-19
ii  libgcc11:5.2.1-15
ii  libkabc4   4:4.14.2-2+b1
ii  libkde3support44:4.14.10-3
ii  libkdecore54:4.14.10-3
ii  libkdeui5  4:4.14.10-3
ii  libkemoticons4 4:4.14.10-3
ii  libkidletime4  4:4.14.10-3
ii  libkio54:4.14.10-3
ii  libknotifyconfig4  4:4.14.10-3
ii  libkparts4 4:4.14.10-3
ii  libkresources4 4:4.14.2-2+b1
ii  libnepomuk44:4.14.10-3
ii  libnepomukutils4   4:4.14.10-3
ii  libphonon4 4:4.8.3-1
ii  libqca22.1.0.3-4
ii  libqt4-dbus4:4.8.7+dfsg-3
ii  libqt4-network 4:4.8.7+dfsg-3
ii  libqt4-qt3support  4:4.8.7+dfsg-3
ii  libqt4-svg 4:4.8.7+dfsg-3
ii  libqt4-xml 4:4.8.7+dfsg-3
ii  libqtcore4 4:4.8.7+dfsg-3
ii  libqtgui4  4:4.8.7+dfsg-3
ii  libsolid4  4:4.14.10-3
ii  libsoprano42.9.4+dfsg-3
ii  libstdc++6 5.2.1-15
ii  phonon 4:4.8.3-1

konversation recommends no packages.

konversation suggests no packages.

-- no debconf information

Bug#786049: pynn: diff for NMU version 0.7.5-1.1

[Luca Falavigna]

Dear maintainer,

I've prepared an NMU for pynn (versioned as 0.7.5-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru pynn-0.7.5/debian/changelog pynn-0.7.5/debian/changelog
--- pynn-0.7.5/debian/changelog 2013-02-06 15:52:46.0 +0100
+++ pynn-0.7.5/debian/changelog 2015-08-24 08:19:23.0 +0200
@@ -1,3 +1,10 @@
+pynn (0.7.5-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to dh_python2 (Closes: #786049).
+
+ -- Luca Falavigna   Mon, 24 Aug 2015 08:18:43 +0200
+
 pynn (0.7.5-1) experimental; urgency=low
 
   * New upstream bugfix release
diff -Nru pynn-0.7.5/debian/control pynn-0.7.5/debian/control
--- pynn-0.7.5/debian/control   2013-02-06 15:52:46.0 +0100
+++ pynn-0.7.5/debian/control   2015-08-24 08:18:10.0 +0200
@@ -5,7 +5,7 @@
 Uploaders: Yaroslav Halchenko ,
Michael Hanke 
 Build-Depends: debhelper (>= 7.0.50~),
-   python, python-support,
+   python, dh-python,
python-numpy,
python-nose, python-mock,
python-cheetah, python-jinja2
diff -Nru pynn-0.7.5/debian/pyversions pynn-0.7.5/debian/pyversions
--- pynn-0.7.5/debian/pyversions2013-02-06 15:52:46.0 +0100
+++ pynn-0.7.5/debian/pyversions1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-2.5-
diff -Nru pynn-0.7.5/debian/rules pynn-0.7.5/debian/rules
--- pynn-0.7.5/debian/rules 2013-02-06 15:52:46.0 +0100
+++ pynn-0.7.5/debian/rules 2015-08-24 08:18:28.0 +0200
@@ -2,7 +2,7 @@
 # -*- makefile -*-
 
 %:
-   dh $@
+   dh $@ --with python2
 
 override_dh_auto_test:
for PYVER in `pyversions -d -r -v`; do \

Bug#644912: ipv6 link-local doesn't work as lookup doesn't set scope id

[Jens B. Jorgensen]

Incidentally even /with/ my patch ping6 doesn't work. This is because
due to the innards of how libnss works only when _nss_X_gethostbyname4_r
is called is it possible to return the scope id--the outputs of the
_nss_X_gethostbyname2_r and _nss_X_gethostbyname_r do not include this
data--_nss_X_gethostbyname2 returns data through a struct hostent as
does _nss_X_gethostbyname_r and unfortunately libnss doesn't call
_nss_X_gethostbyname4_r unless address family is UNSPEC. Now... despite
this you can see from my previous email that I was able to get different
behavior, ie. I could pass AF_INET6 and still get back scopeid. I
believe this is because the previous result was cached, though I didn't
step through the code to verify this. If you're curious you should take
a look at http://osxr.org/glibc/source/sysdeps/posix/getaddrinfo.c.
You'll see there:

0838   /* gethostbyname4_r sends out parallel A and  queries and
0839  is thus only suitable for PF_UNSPEC.  */
0840   if (req->ai_family == PF_UNSPEC)
0841 fct4 = __nss_lookup_function (nip, "gethostbyname4_r");
0842
0843   if (fct4 != NULL)
0844 {
0845   int herrno;
0846
0847   while (1)
0848 {
0849   rc = 0;
0850   status = DL_CALL_FCT (fct4, (name, pat, tmpbuf,
0851tmpbuflen, &rc, &herrno,

Seems to me it should try to use gethostbyname4 if address is family is
UNSPEC or INET6. I presume there was a reason but I certainly don't know
what it is. The code falls back on gethostbyname2 in any case if the
gethostbyname4 isn't available. This is all a bit messy because if at
the top level you call getaddrinfo you should get the resolution
functions that can return the data you asked for but... that's not the
way it is. glibc needs a fix but the code is pretty complex so I didn't
want to try to tackle that (getaddrinfo.c itself is 2664 lines)--plus
it's a bit more nasty to test ;-).

On Mon, 10 Oct 2011 19:04:41 +0200 =?UTF-8?B?U3RlZmFuIELDvGhsZXI=?=
 wrote:
> Package: libnss-mdns
> Tags: ipv6
> Version: 0.10-3.2
>
> Hi,
>
> libnss-mdns doesn't set the scope-id for link-local addresses, so
> something like
>
> $ ping6 example.local
> gives
> connect: Invalid argument
>
> while
> $ getent host example.local
> returns a valid link-local IPv6 address (fe80::...) and
> $ ping6 fe80::...%eth0
> works fine.
>
>
> I sent this nearly 2 years ago upstream per mail, but never got a
> response, and i couldn't find an upstream bug tracker.
>
>
>

--
Jens B. Jorgensen /jorgen...@kcg.com /


This e-mail and its attachments are intended only for the individual or entity 
to whom it is addressed and may contain information that is confidential, 
privileged, inside information, or subject to other restrictions on use or 
disclosure. Any unauthorized use, dissemination or copying of this transmission 
or the information in it is prohibited and may be unlawful. If you have 
received this transmission in error, please notify the sender immediately by 
return e-mail, and permanently delete or destroy this e-mail, any attachments, 
and all copies (digital or paper). Unless expressly stated in this e-mail, 
nothing in this message should be construed as a digital or electronic 
signature. For additional important disclaimers and disclosures regarding KCG’s 
products and services, please click on the following link:

http://www.kcg.com/legal/global-disclosures

Bug#796090: Garbled resolver view in aptitude: Should be fixed in aptitude 0.7.1~exp1-1~apt1.1~exp9 from Debian Experimental, please test

[Harald Dunkel]

The garbage chars went away. Problem resolved.

But I had to disable apt.sources.list.d/*.list to make it
work. "apt-get update" complained

# apt-get update
E: Type 'debhttp://afaics.de/debian/' is not known on line 2 in source list 
/etc/apt/sources.list.d/afaics.de.list
E: The list of sources could not be read.

Same for aptitude.


Regards
Harri

Bug#796763: slurmd cannot be started under systemd

[Andre Florath]

Package: slurmd
Version: 14.03.9-5
Justification: renders package unusable
Severity: grave

Dear Maintainer,

it is not possible to start slurmd under systemd:

root@slurmclient1:~# systemctl stop slurmd
root@slurmclient1:~# time systemctl start slurmd
Job for slurmd.service failed. See 'systemctl status slurmd.service' and 
'journalctl -xn' for details.

real1m30.034s
user0m0.000s
sys 0m0.000s

journal:
Aug 12 17:53:45 slurmclient1 slurmd[1266]: CPU frequency setting not configured 
for this node
Aug 12 17:53:45 slurmclient1 slurmd[1268]: slurmd version 14.03.9 started
Aug 12 17:53:45 slurmclient1 slurmd[1268]: slurmd started on Wed, 12 Aug 2015 
17:53:45 +0200
Aug 12 17:53:45 slurmclient1 slurmd[1268]: CPUs=4 Boards=1 Sockets=4 Cores=1 
Threads=1 Memory=1000 TmpDisk=7321 Uptime=1320
Aug 12 17:55:15 slurmclient1 systemd[1]: slurmd.service start operation timed 
out. Terminating.
Aug 12 17:55:15 slurmclient1 slurmd[1268]: Slurmd shutdown completing
Aug 12 17:55:15 slurmclient1 systemd[1]: Failed to start Slurm node daemon.
Aug 12 17:55:15 slurmclient1 systemd[1]: Unit slurmd.service entered failed 
state.

Nevertheless, when I start the slurmd manually either with
$ slurmd -Dv
or
$ /usr/sbin/slurmd
everything works fine: process is started, connects to the control machine
and it is possible to execute commands on the node.

Workaround:
The process starts when the config (in /etc/default/slurmd) is set to:
SLURMD_OPTIONS="-D"
and in /lib/systemd/system/slurmd.service the type is changed to 'simple'.
(Nevertheless there is no log output any more, but as long as it works )

Kind regards

Andre

P.S.: Please note that this is also true for the slurmctld package.
  I'm not sure if this is the same root cause.  If you want,
  I can file the same bug also for slurmctld.


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

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

Versions of packages slurmd depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.22
ii  libc62.19-18
ii  libhwloc51.10.0-3
ii  libpam0g 1.1.8-3.1
ii  lsb-base 4.1+Debian13+nmu1
ii  munge0.5.11-1.1+b1
ii  openssl  1.0.1k-3+deb8u1
ii  openssl-blacklist0.5-3
ii  slurm-wlm-basic-plugins  14.03.9-5

slurmd recommends no packages.

slurmd suggests no packages.

-- no debconf information

Bug#785949: NMU cancelled

[Luca Falavigna]

Control: tags -1 - pending
Control: tags -1 + patch

Apparently the NMU was cancelled, reflecting this in the bug tags.

-- 
Cheers,
Luca

Bug#795704: Fwd: Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

[Gianfranco Costamagna]

Hi Alex,



>I contacted Ernst (upstream dev) and he agreed to integrate the build
>system into his dev branch.


Wonderful! Good news are good :)
>I think the above should solve the version string problem as well. Or
>if it doesn't we can use the old method based on date string. I think
>it should work find beacuse the date is monotonic increasing. For
>example, the current release is 12.11.2014. Let's assume the next
>release is 09.01.2015. We can use some regex replacement to tranform
>them into 20141211 and 20150901 respectively and this should works.


I still don't follow that, you need to change the watch file to see a new
release or not?

I mean, it might be ok to change it to download the new release,
but uscan is used to *detect* new tarballs on the remote, and in that
way... I'm not sure it works...

Maybe some other DDs can help us in achieving something similar
(I guess some uversionmangle syntax might help there)


>So do I :P I always think I used too much "I think" and "the"...
>The original conversation is forwarded for your reference.


thanks!!!

Gianfranco

Bug#796562: lintian: Please identify lack of sanitation compiler/linker flags

[intrigeri]

Hi,

Jakub Wilk wrote (22 Aug 2015 17:32:52 GMT) :
> Could you clarify what exactly you want Lintian to check for?

The scope of my request was: possibly all checks that
`DEB_BUILD_MAINT_OPTIONS = sanitize=+all' enables. Possibly only some.
That's up for discussion. I personally lack the expertise to evaluate
the different options we have here (hence keeping Jacob Cc'd).

> I you meant to say that you think that all packages should be built
> with -fsanitize=address, and Lintian should complain about binaries that 
> weren't
> compiled that way, then I disagree. On the contrary, I think we shouldn't ship
> binaries built with with ASAN enabled, except maybe in special cases, for a 
> variety
> of reasons: [...]

Thanks for sharing! A couple of these shortcomings were unknown to me
(I'm not a low-level / C person myself). Most of them seem to be
definitely worth it for specific programs, e.g. those whose security
track record is bad, and that are known of being regularly used as
attack vectors in the wild. I guess these were maybe part of the
"special cases" you are referring to.

With all this info in mind, I'm not arguing in favour of treating the
lack of sanitation options as an error than one must "fix" in every
package.

However, I believe that Lintian could have an educational role here:
I suspect that lots of maintainers of security-sensitive packages are
not aware that dpkg-dev (>= 1.17.14) now provides this easy way to
build their package with these options, and thus have perhaps never
tried it; if, additionally, upstream has never done that either, then
we may have situations in which only potential attackers have
discovered a bunch of security issues... thanks to tools that we ship
in Debian, but don't use ourselves.

So, the current state of my thoughts is:  Lintian could encourage
package maintainers to try these sanitation options out *locally*
first, report bugs upstream if needed, and to actively and consciously
decide if their package is worth compiling+linking this way in the
archive, with all the drawbacks you mentioned in mind. And if they
decide that these options are no good for their package, then they can
man this explicit by adding a Lintian override. This would make me
feel more comfortable wrt. "lacking" these compilation/linking options
in packages: I could trust their maintainers to having made the best
decision they could, rather than being in the position I'm currently
in, that is: wondering if they ever have considered this option
at all.

In the end, it feels like that finding an agreement could mostly be
a matter of phrasing, and of carefully picking the best Lintian
severity for these checks. What do you think?

Now, perhaps this is out of the scope of Lintian's mission, as
perceived by its maintainers. If that would be the case, then let me
know, and I'm happy to think about other ways to handle this in
Debian, in coordination with other people who are already working on
this topic.

Cheers,
-- 
intrigeri

Bug#796305: python-oauthlib: FTBFS: plugin distutils failed with: exit code=1:

[Daniele Tricoli]

Hello Chris,
many thanks for this report and sorry for my late reply but I was not notified 
(althouth I subscribed to python-oauthlib bugs time ago).

On Friday 21 August 2015 10:08:51 Chris Lamb wrote:
> python-oauthlib fails to build from source on unstable/amd64:

Yes, it's due some docstrings that can't be tested as, for example, this:

https://github.com/idan/oauthlib/blob/16cd3b255b2c86ec7da412357cad899c72d8dbf7/oauthlib/oauth1/rfc5849/endpoints/authorization.py#L77

But it was fixed in python-oauthlib 1.0.3-1. My usual sponsor tagged it on SVN 
(6 days ago[¹]) so I'm sure he uploaded it but since it's not in the archive 
something did not work. I'm sending him an email to sort this out. Sorry for 
the inconvenience.

Kind regards,

[¹] 
https://anonscm.debian.org/viewvc/python-modules/packages/python-oauthlib/trunk/debian/changelog?revision=33818&view=markup

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org

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

Bug#796129: Build of tellico is missing support for cddb

[Frédéric BURLET]

Hi Regis,

Thanks for your feedback.

I'll wait until things become more stable than ;-)

Regards,

Fred.

On 23.08.2015 21:18, Regis Boudin wrote:

Hi Frederic,

Thanks for the report. Looking at the buildd logs, it looks like 
that's

something related to the gcc5 transition going on in unstable, where
libkcddb is not actually usable.

Tellico is actually quite far in the dependency chain, and depends on
many different C++ libraries, so I'm afraid it's going to have some
features broken in unstable for a bit...

Regis

On 19/08/15 18:54, Frédéric BURLET wrote:

Package: tellico
Version: 2.3.9+dfsg.1-1+b1

Dear maintainer,

The item menu "File > Import > Import Audio CD Data..." is greyed 
out,

audio CD Data cannot be imported.

I guess this is because tellico hasn't been compiled with cddb 
support.

Here are the result of my investigations:

apt-cache show tellico shows that tellico depends on libkcddb4 (>=
4:4.3.4).

dpkg -l libkcddb4 shows that the lib is actually installed but 
version

4:15.04.1-2.

ldd $(which tellico) | grep cddb doesn't output anything.

dpkg -l \*tellico\* shows:
ii  tellico  2.3.9+dfsg.1-1+b1 amd64
Collection manager for books, videos, music, etc
ii  tellico-data 2.3.9+dfsg.1-1all
Collection manager for books, videos, music, etc [data]
ii  tellico-doc  2.3.9+dfsg.1-1all
Collection manager for books, videos, music, etc [doc]
ii  tellico-scripts  2.3.9+dfsg.1-1all
Collection manager for books, videos, music, etc [scripts]

I guess tellico needs to be built with cddb support to get the
aforementioned menu item enabled.

Environment information:
- Debian unstable
- System: amd64
- kernel version: 4.1.0-1-amd64 #1 SMP Debian 4.1.3-1 (2015-08-03)
x86_64 GNU/Linux
- libc6: 2.19-19

Regards,

Frédéric BURLET.

Bug#796601: encfs: password gets modified in keystore after umount

[Eduard Bloch]

Control: tag 796601 +notreproducible
Control: severity 796601 important

> When using encfs to scramble a backup to an alternate media, the password gets
> modified somehow during umount.Any further attempts to mount the media fail,
> even if the password is correct.

Cannot reproduce. Please show a sample .encfs6.xml and matching password
or we cannot do much for you.

> I copy the password from keepass to a text file, then copy the password to the

There is no keepass package in Debian. Do you mean keepassx or keepass2?

> terminal.You cannot directly copy from keepass to the terminal due to its
> "secure storage and wiping"  feature with the clipboard. The password has not
> been changed by me since initial creation of the encfs storage.

After using a terminal... seriously? Terminals hide a lot of "invisible"
but effective characters.

Regards,
Eduard.

Bug#793937: [LCFC2] templates://libdvd-pkg/{templates}

[Dmitry Smirnov]

Hi Justin,

On Sunday 23 August 2015 22:51:53 Justin B Rye wrote:
> Dmitry Smirnov wrote:
> > The only thing which makes me feel uncomfortable about this version is
> > "doing downloads" in
> > 
> >  This package automates the process of doing downloads of the source
> 
> Hmm, "do" can often be a bit weak, if that's what you mean...

I mean "process of (doing|launching|performing) downloads" feels heavy and 
unnecessary... Why not just "process of downloading"?


> That has an excess "of (the)", and it loses the plural instances of
> downloads (plural runs automatically produce plural output packages,
> so you can recycle this text for other downloaders regardless of how
> many packages they produce per run).  Oh, and you've lost a Harvard
> comma again and put the "deb" back in after I thought we'd agreed to
> take it out!

Sorry about those unintentional changes. I simply missed all that on manual 
merge...


> Would you be any happier with a version that just replaces "doing"
> with something less weak, like "performing" or "launching"?

I reckon "performing" might be the best for this context but still I'm not 
convinced if it is necessary...

What do you think of

>This package automates the process of downloading source
>files for ${PKGG} from videolan.org, compiling them, and installing the
>binary packages (${PKGG_ALL}).

-- 
Best wishes,
 Dmitry Smirnov

---

However beautiful the strategy, you should occasionally look at the
results.
-- Winston Churchill


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

Bug#796762: pcre3: another heap overflow in compile_regexp()

[Salvatore Bonaccorso]

Source: pcre3
Version: 2:8.35-7
Severity: important
Tags: security upstream fixed-upstream
Control: forwarded -1 https://bugs.exim.org/show_bug.cgi?id=1672

Hi

Wen Guanxing reported another heap overflow vulnerability in
compile_regexp(), CVE requested at
http://www.openwall.com/lists/oss-security/2015/08/24/1 .

Upstream bugreport: https://bugs.exim.org/show_bug.cgi?id=1672

Fix: http://vcs.pcre.org/pcre?view=revision&revision=1594

Regards,
Salvatore

Bug#795222: Can confirm the bug

[ZeroBeat]

Hi.

There are much more issues with this driver (take a look at #793488).
I think it takes a long, long time until we get an update (for example
14.12 -> 15.7 seven month).
By the way: 14.12 was unusable for me, because it computes wrong OpenCl
results!!!
But for OpenCL, AMD is the best choice, so we have to live with this
issues...




Regards,
Mike



0x5DB88630.asc
Description: application/pgp-keys

Bug#796708: libqt5sql5: segfault error 4 in libQt5Sql.so.5.4.2 with kactivitymanagerd

[Diederik de Haas]

On Sunday 23 August 2015 09:45:09 Harrison Metzger wrote:
> [UPGRADE] libkdecorations2-5:amd64 4:5.3.2-1 -> 4:5.3.2-2
> [UPGRADE] libkdecorations2private5:amd64 4:5.3.2-1 -> 4:5.3.2-2

Those are likely the component versions that are given you troubles. 
Downgrading those to version 4:5.3.2-1 will likely fix your problem.


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

Bug#796761: golang-golang-x-tools: please upload a new snapshot

[Michael Hudson-Doyle]

Package: golang-golang-x-tools
Version: 1:0.0~git20150716.0.87156cb+dfsg1-3
Severity: important

Dear Maintainer,

Currently golang-golang-x-tools has tests that fail with Go 1.5. These have
been fixed in tip.

There are other tests that I think will fail on some builder unless -short is
passed to go test. But we'll see I guess.

Cheers,
mwh

-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), 
(100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#793761: chromium: freezes at startup in xfce4

[Michael Gilbert]

On Tue, Aug 18, 2015 at 1:44 PM, Arturo Borrero Gonzalez wrote:
> Please, could you please give me a few pointers about how to debug the
> issue or workaround it?

There are many ways to do it, but you could create a new user to start
with a fresh ~/.config/chromium.

Best wishes,
Mike

Bug#796754: FTBFS: test_filtering_uses_distinct raises AttributeError

[Brian May]

On Mon, 24 Aug 2015 at 09:27 Luke Faraone  wrote:

> Package: django-filter
> Version: 0.9.2-1
> Severity: serious
> Justification: fails to build from source
> User: python-dja...@packages.debian.org
> Usertags: django18
>

Looks like this is a problem for Django 1.7 too.

The latest upstream version 0.11.0 still has this problem.

I have opened a bug report upstream:
https://github.com/alex/django-filter/issues/283

Bug#795222: Can confirm the bug

[eimaiosatanas]

Hi,

Just updated to kernel 4.1 and can confirm the issue. Did not try out the patch 
yet.

Hope for a quick resolution to the issue.

Regards,

Bug#796760: ghex: %P is not a valid offset format

[Kyanos]

Package: ghex
Version: 3.10.1-1
Severity: minor
Tags: upstream

Dear Maintainer,

In the preferences menu (Edit > Preferences), the option to specify
the offset format rejects format specifiers such as "%s", stating:

> The offset format string contains invalid format specifier.
> Only 'x', 'X', 'p', 'P', 'd' and 'o' are allowed.

Entering "%P" doesn't trigger the error message (as it's supposedly
valid), but it causes the status bar to show a literal "%P" instead of
the offset.

I can't seem to find any reference to a "%P" format specifier. POSIX
does not mention it, and GCC (4.9.3-3) gives a warning about an
"unknown conversion type character."

Thank you for your consideration.

Kyanos

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

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

Versions of packages ghex depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  libatk1.0-0  2.16.0-2
ii  libc62.19-19
ii  libcairo-gobject21.14.2-2
ii  libcairo21.14.2-2
ii  libgail-3-0  3.16.6-1
ii  libgdk-pixbuf2.0-0   2.31.5-1
ii  libglib2.0-0 2.44.1-1.1
ii  libgtk-3-0   3.16.6-1
ii  libgtkhex-3-03.10.1-1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3

ghex recommends no packages.

ghex suggests no packages.

-- no debconf information

Bug#796759: reportbug: HTTPError 500 Internal Server Error

[Pierre Rudloff]

Package: reportbug
Version: 6.6.3
Severity: normal

Hello,

When I try to do reportbug wnpp, I get this error when he tries to query the
tracker, after I entered the package description:
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2211, in 
main()
  File "/usr/bin/reportbug", line 1081, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1703, in user_interface
latest_first=self.options.latest_first)
  File "/usr/lib/python2.7/dist-packages/reportbug/ui/gtk2_ui.py", line 1505,
in func
args, kwargs = op.sync_pre_operation (*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/reportbug/ui/gtk2_ui.py", line 886, in
sync_pre_operation
http_proxy=http_proxy, archived=archived, source=source)
  File "/usr/lib/python2.7/dist-packages/reportbug/debbugs.py", line 1275, in
get_reports
stats = debianbts.get_status(bugs)
  File "/usr/lib/pymodules/python2.7/debianbts.py", line 179, in get_status
reply = server.get_status(*nr)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 545, in
__call__
return self.__r_call(*args, **kw)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 567, in
__r_call
self.__hd, self.__ma)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 430, in __call
timeout = self.timeout)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 318, in call
raise HTTPError(code, msg)
SOAPpy.Errors.HTTPError: 

Regards,



-- Package-specific info:
** Environment settings:
DEBEMAIL="cont...@rudloff.pro"
INTERFACE="gtk2"

** /home/pierre/.reportbugrc:
reportbug_version "6.6.3"
mode advanced
ui gtk2
email "cont...@rudloff.pro"
smtphost "smtp.gmail.com:587"
smtpuser "tael67"
smtptls

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

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

Versions of packages reportbug depends on:
ii  apt   1.0.9.8
ii  python2.7.9-1
ii  python-reportbug  6.6.3
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail   
pn  debconf-utils
pn  debsums  
pn  dlocate  
pn  emacs23-bin-common | emacs24-bin-common  
ii  file 1:5.22+15-2
ii  gnupg1.4.18-7
ii  postfix [mail-transport-agent]   2.11.3-1
ii  python-gtk2  2.24.0-4
ii  python-gtkspell  2.25.3-13
pn  python-urwid 
ii  python-vte   1:0.28.2-5
ii  xdg-utils1.1.0~rc1+git20111210-7.4

Versions of packages python-reportbug depends on:
ii  apt   1.0.9.8
ii  python-debian 0.1.27
ii  python-debianbts  1.12
pn  python:any

python-reportbug suggests no packages.

-- no debconf information

Bug#796758: [pkg-wine-party] Bug#796758: Update dependency on wine-gecko to 2.40.

[Michael Gilbert]

On Sun, Aug 23, 2015 at 9:22 PM, Jens Reyer wrote:
> wine 1.7.50 needs a new wine-gecko version (2.40).
> See http://wiki.winehq.org/Gecko.

Please feel ok to commit to git :)

Best wishes,
Mike

Bug#796758: Update dependency on wine-gecko to 2.40.

[Jens Reyer]

Source: wine-development
Version: 1.7.50-1
Severity: normal

Hi

wine 1.7.50 needs a new wine-gecko version (2.40).
See http://wiki.winehq.org/Gecko.

btw, this line from ANOUNCE is missing in d/changelog:
  - New version of the Gecko engine based on Firefox 40.

Greets
jre


diff --git a/debian/control.in b/debian/control.in
index 271f88f..862bc0b 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -89,7 +89,7 @@ Depends:
 Recommends:
  wineVERSION,
  libgl1-mesa-dri,
- libwine-gecko-2.36 [!armhf !arm64],
+ libwine-gecko-2.40 [!armhf !arm64],
  libasound2-plugins,
 Suggests:
  wine32VERSION-preloader,
-- 
2.5.0

Bug#796757: FTBFS: test failures with Django 1.7

[Luke Faraone]

Source: djangorestframework-nested-resource
Version: 1.2.0-1
Severity: serious
Justification: fails to build from source
User: python-dja...@packages.debian.org
Usertags: django18

Hello,

During a test rebuild of packages dependent on python-django for the upcoming 
Django 1.8 transition, your package failed to build from source.

This rebuild was done against unstable on an amd64 system, under python-django 
1.7.9-1.

The log from the build is attached.

 -- Luke Faraone
sbuild (Debian sbuild) 0.65.2 (24 Mar 2015) on aqua.sfba.luke.wf

╔══╗
║ djangorestframework-nested-resource 1.2.0-1 (amd64)23 Aug 2015 22:35 ║
╚══╝

Package: djangorestframework-nested-resource
Version: 1.2.0-1
Source Version: 1.2.0-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64

I: NOTICE: Log filtering will replace 
'build/djangorestframework-nested-resource-SpneJ8/djangorestframework-nested-resource-1.2.0'
 with '«PKGBUILDDIR»'
I: NOTICE: Log filtering will replace 
'build/djangorestframework-nested-resource-SpneJ8' with '«BUILDDIR»'
I: NOTICE: Log filtering will replace 
'var/lib/schroot/mount/sid-amd64-92439f3c-101e-486b-8cda-87124c7ee486' with 
'«CHROOT»'

┌──┐
│ Update chroot│
└──┘

Get:1 file: unstable InRelease [215 kB]
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following package was automatically installed and is no longer required:
  libapt-inst1.5
Use 'apt-get autoremove' to remove it.
The following packages will be REMOVED:
  libasprintf0c2
The following NEW packages will be installed:
  cpp-5 g++-5 gcc-5 libapparmor1 libapt-inst1.7 libapt-pkg4.16 libasan2
  libasprintf0v5 libcc1-0 libgcc-5-dev libmpx0 libprocps4 libseccomp2
  libstdc++-5-dev
The following packages will be upgraded:
  apt apt-utils build-essential cpp g++ gcc gettext-base libapt-pkg-perl
  libparse-debianchangelog-perl libsystemd0 libudev1 procps systemd udev
Preconfiguring packages ...
14 upgraded, 14 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B/92.1 MB of archives.
After this operation, 428 MB of additional disk space will be used.
Selecting previously unselected package libapt-pkg4.16:amd64.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 14293 files and directories currently installed.)
Preparing to unpack .../libapt-pkg4.16_1.0.10.2_amd64.deb ...
Unpacking libapt-pkg4.16:amd64 (1.0.10.2) ...
Setting up libapt-pkg4.16:amd64 (1.0.10.2) ...
Processing triggers for libc-bin (2.19-19) ...
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 14342 files and directories currently installed.)
Preparing to unpack .../a/apt/apt_1.0.10.2_amd64.deb ...
Unpacking apt (1.0.10.2) over (1.0.9.10) ...
Processing triggers for man-db (2.7.2-1) ...
Not building database; man-db/auto-update is not 'true'.
Setting up apt (1.0.10.2) ...
Processing triggers for libc-bin (2.19-19) ...
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 14343 files and directories currently installed.)
Preparing to unpack .../gettext-base_0.19.5.1-1_amd64.deb ...
Unpackin

Bug#644912: works for getaddrinfo but not if AF_INET6 specified

[Jens B. Jorgensen]

This e-mail and its attachments are intended only for the individual or entity 
to whom it is addressed and may contain information that is confidential, 
privileged, inside information, or subject to other restrictions on use or 
disclosure. Any unauthorized use, dissemination or copying of this transmission 
or the information in it is prohibited and may be unlawful. If you have 
received this transmission in error, please notify the sender immediately by 
return e-mail, and permanently delete or destroy this e-mail, any attachments, 
and all copies (digital or paper). Unless expressly stated in this e-mail, 
nothing in this message should be construed as a digital or electronic 
signature. For additional important disclaimers and disclosures regarding KCG’s 
products and services, please click on the following link:

http://www.kcg.com/legal/global-disclosures
--- Begin Message ---
I just built this with my previously-submitted patch and I did get
scope_id in when address family was unspecified as well as when I
specified it as AF_INET6. Not sure why my results are different. It'd
still be great to get this patch applied...

-- 
Jens B. Jorgensen /jorgen...@kcg.com /



signature.asc
Description: OpenPGP digital signature
--- End Message ---

Bug#791286: smokegen: library transition may be needed when GCC 5 is the default

[Scott Kitterman]

On Sun, 16 Aug 2015 19:21:38 -0400 Scott Kitterman  
wrote:
...
> Working on it.
> 
smokegen transition is all done, just waiting for gcc5.

Scott K

Bug#792685: fixup BTS metadata

[peter green]

reopen 792685
tags 792685 +jessie
thanks


You closed the bug in a nonexistant version. Furthermore the bug isn't 
"fixed" per-se it's just not applicable to stretch/sid (because we don't 
support direct upgrades from wheezy to stretch/sid). The correct way to 
indicate that a bug is not applicable for particular releases is to use 
release tags.


Hopefully with this metadata fixup the package should be able to migrate 
to stretch.

Bug#796755: RFP: mpxj-java -- library to manipulate project information in various file formats

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org 
pkg-java-maintain...@lists.alioth.debian.org debian-qt-...@lists.debian.org
Control: affects -1 calligra

   Package name: mpxj-java
Version: 5.1.8
Upstream Author: Jon Iles 
License: LGPL-2.1+
URL: http://mpxj.sourceforge.net/

MPXJ provides a set of facilities to allow project information to be
manipulated in Java and .Net. MPXJ supports a range of data formats:
Microsoft Project Exchange (MPX),
Microsoft Project (MPP,MPT),
Microsoft Project Data Interchange (MSPDI XML),
Microsoft Project Database (MPD),
Planner (XML),
Primavera (PM XML, XER, and database),
Asta Powerproject (PP, MDB),
and the Standard Data Exchange Format (SDEF).

Calligra Plan can use MPXJ to import project data from foreign file formats.

-- 
Cheers,
 Dmitry Smirnov.

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

Bug#796753: FTBFS: tries to download from PyPI

[Luke Faraone]

Package: python-django-pyscss
Version: 2.0.2-1
Severity: serious
Justification: fails to build from source
User: python-dja...@packages.debian.org
Usertags: django18

Hello,

During a test rebuild of packages dependent on python-django for the upcoming 
Django 1.8 transition, your package failed to build from source. 

This rebuild was done against unstable on an amd64 system, under python-django 
1.7.9-1.

The log from the build is attached. Relevant portions enclosed below.

 -- Luke Faraone

===> Testing with python2.7
running test
Searching for mock
Reading https://pypi.python.org/simple/mock/
Download error on https://pypi.python.org/simple/mock/: [SSL: 
CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590) -- Some 
packages may not be found!
Couldn't find index page for 'mock' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading https://pypi.python.org/simple/
Download error on https://pypi.python.org/simple/: [SSL: 
CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590) -- Some 
packages may not be found!
No local packages or download links found for mock
error: Could not find suitable distribution for Requirement.parse('mock')
make[1]: *** [override_dh_auto_test] Error 1
debian/rules:29: recipe for target 'override_dh_auto_test' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [build] Error 2
debian/rules:10: recipe for target 'build' failed
dpkg-buildpackage: error: debian/rules build gave error exit status 2


python-django-pyscss_2.0.2-1_amd64.build
Description: inode/symlink

Bug#794721: Acknowledgement (udev_queue_get_udev_is_active API is broken starting in 221-1)

[Jon DeVree]

On Sun, Aug 23, 2015 at 18:57:14 +0200, Michael Biebl wrote:
> Hi Jon,
> 
> That approach is sysvinit specific, though. Can you actually reproduce
> the problem with systemd being your PID 1?
> 

I don't appear to be able to. Presumably because udev isn't terminated
until later in the shutdown sequence.

-- 
Jon
Doge Wrangler
X(7): A program for managing terminal windows. See also screen(1) and tmux(1).

Bug#796754: FTBFS: test_filtering_uses_distinct raises AttributeError

[Luke Faraone]

Package: django-filter
Version: 0.9.2-1
Severity: serious
Justification: fails to build from source
User: python-dja...@packages.debian.org
Usertags: django18

Hello,

During a test rebuild of packages dependent on python-django for the upcoming 
Django 1.8 transition, your package failed to build from source.

This rebuild was done against unstable on an amd64 system, under python-django 
1.7.9-1.

The log from the build is attached. Relevant portions enclosed below.

 -- Luke Faraone

==
ERROR: test_filtering_uses_distinct (tests.test_filters.FilterTests)
--
Traceback (most recent call last):
  File "/«PKGBUILDDIR»/tests/test_filters.py", line 179, in 
test_filtering_uses_distinct
result = qs.distinct.assert_called_once()
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 721, in __getattr__
raise AttributeError(name)
AttributeError: assert_called_once

--
Ran 205 tests in 0.722s

FAILED (errors=1, skipped=13, expected failures=7, unexpected successes=1)


django-filter_0.9.2-1_amd64.build
Description: inode/symlink

Bug#796490: [texlive-latex-base] pdflatex does not create reproducible pdfs with multiple images

[Norbert Preining]

Hi Sandro

On Sun, 23 Aug 2015, Sandro Knauß wrote:
> I can still reproduce the bug with the changing stream (images) with pdflatex
> 2014.20141024-2 on my system.

Not surprising. Nothing will change on jessie.

Can you please try it on sid with the packages that I uploaded
yesterday. There I see only differences in /CreationDate, /ModDate
and /Id.

> Hopefully with that you can reproduce it.

On jessie, maybe, but I am honestly too lazy to install a jessie
for that, as I don't see any gain in doing it.

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#273015: Problem with backlit keyboard on aluminium powerbook

[Michael Schmitz]

Mathieu,

the attached udev rules file will load the i2c-dev module at boot time.

I've copied it into /etc/udev on my system, and linked it as
../050_pbbuttonsd.rules
inside /etc/udev/rules.d as it's done for mouseemu.

Maybe Dan could test this solution - I can't get a stable X desktop
session on my PowerBook5,5 model with Jessie.

Cheers,

  Michael



On Sat, Aug 15, 2015 at 3:33 AM, Mathieu Malaterre  wrote:
> Control: tags -1 - moreinfo
> Control: tags -1 confirmed
>
>
> Michael,
>
> On Thu, Aug 13, 2015 at 4:32 AM, Dan DeVoto  wrote:
>>
>> Hi,
>>
>> On Jessie with version 0.7.9-5 I still have to manually add i2c-dev to
>> /etc/modules to get the keyboard backlight working.
>
> You mentionned earlier working on a patch. Can you prepare something for
> udev ?
>
> Thanks.
>


pbbuttonsd.rules
Description: Binary data

Bug#795814: FTBFS: boost/math/tools/test.hpp: No such file or directory

[Simon McVittie]

On Mon, 17 Aug 2015 at 09:57:16 +0100, Manuel A. Fernandez Montecelo wrote:
> Today it cannot even start to compile because of conflics of deps to install:
> 
> The following packages have unmet dependencies:
>  libopenexr6v5 : Conflicts: libopenexr6 but 1.6.1-8 is to be installed.
>  libilmbase6v5 : Conflicts: libilmbase6 but 1.0.1-6.1 is to be installed.
>  libcairomm-1.0-1v5 : Conflicts: libcairomm-1.0-1 but 1.10.0-1.1+b1 is
> to be installed.

I think this was caused by a mis-build of imagemagick on amd64[1] which
has now been fixed by a binNMU. Please try again; I can reproduce the
original build failure in sbuild today.

I think this might be the last sourceful upload needed by the imagemagick
sub-transition within the larger libstdc++ mess.

S

[1] The mirror used by my sbuild chroot hadn't seen libopenexr6v5 yet,
causing it to be built against libopenexr6 on amd64 only.
I for one welcome our new "throw away maintainer-built binaries"
overlords.

Bug#796752: libsres: could not bind to random port above [port]

[Justin Coffman]

Package: irssi
Version: 0.8.17-1
Severity: normal
Tags: ipv6

Dear Maintainer,

Starting irssi causes approximately ten lines of

20150823::16:55:28 libsres: could not bind to random port above 44300

to be displayed per server on initial connection. Port number is randomized for 
each message. 

Connection to servers do succeed, after which no further issue has been noted.

Seems to only occur on systems with a global IPv6 address.

The following do not affect/resolve the issue:

* Enabling/disabling IPv6 nameservers in /etc/resolv.conf
* Enabling/disabling irssi's "resolve_prefer_ipv6" setting.
* Enabling/disabling local firewall (iptables)

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=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 irssi depends on:
ii  libc6   2.19-18
ii  libglib2.0-02.42.1-1
ii  libncurses5 5.9+20140913-1+b1
ii  libperl5.20 5.20.2-3+deb8u1
ii  libssl1.0.0 1.0.1k-3+deb8u1
ii  libtinfo5   5.9+20140913-1+b1
ii  libval142.0-1.1
ii  perl5.20.2-3+deb8u1
ii  perl-base [perlapi-5.20.1]  5.20.2-3+deb8u1

irssi recommends no packages.

Versions of packages irssi suggests:
pn  irssi-scripts  

-- no debconf information

Bug#796751: ldc: FTBFS on armhf: gen/asm-x86.h:225:5: error: narrowing conversion of '-1' from 'int' to 'char' inside { }

[Simon McVittie]

Source: ldc
Version: 1:0.14.0.dfsg-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

ldc was binNMU'd for the libstdc++ transition (specifically, "Rebuild
with libconfig++9v5".

The log:


You'll see there are lots of instances of:

In file included from /«PKGBUILDDIR»/gen/asmstmt.cpp:142:0:
/«PKGBUILDDIR»/gen/asm-x86.h:225:5: error: narrowing conversion of '-1' from 
'int' to 'char' inside { } [-Wnarrowing]

I'm a little confused as to why a file named asm-x86.h would be included
on the only non-x86 architecture supported by ldc, so perhaps that's the
bug here; or perhaps there's some good reason for it, and something
else is broken.

S

Bug#796557: ITP: openomf -- Open Source remake of "One Must Fall 2097"

[Alexandre Detiste]

Le samedi 22 août 2015, 17:24:16 Andreas Gnau a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Andreas Gnau 
> 
> * Package name: openomf
>   Version : 0.6.5
>   Upstream Author : Tuomas Virtanen  and others
> * URL : https://github.com/omf2097/openomf
> * License : MIT
>   Programming Lang: C++
>   Description : Open Source remake of "One Must Fall 2097"

Hey, I loved this game and it's music !

I had already contacted upstream begin of this year.
he replied back then that the game was quite not done;
well there have been some commits since,
maybe it'll be good enough for Stretch goal with a bit of luck,
an half-broken engine would be kind of deceptive for users.

As this engine would need a mix off the original + new assets;
please store data in /usr/share/games/openomf .

One more pedantic way would have been to store the original data in
/usr/share/games/one-must-fall (engine-agnostic name)
and new data + a linkfarm in 
/usr/share/games/openomf 
for the theorical case that an other OMF-compatbile engine someday appears.

But that has little chance to happen & it's not an absolute "rule/policy":
for already packaged engines (eg: dxx-rebirth for Descent 1&2);
G-D-P sticks to already defined namespace. (usr/share/games/d1x-rebirth)


>De :   Tuomas Virtanen 
>À :Alexandre Detiste 
>Date : 13/02/2015 15:54
>Hey,
>
>OpenOMF is not done, and therefore we're not currently really
>comfortable in pushing it into any official repository. Our own packages
>work well enough for now.
>
>The paths we are using are not really final either. Even so, note that
>/usr/share/openomf doesn't contain only the old gamefiles; it will/does
>also contain OpenOMF plugins and new game resources.

Bug#796750: djvuextract: exit status 0 when chunk was missing

[Jakub Wilk]

Package: djvulibre-bin
Version: 3.5.27.1-3

djvuextract exits with status 0, even when it failed extract a chunk 
because it was missing:


$ djvuextract djvu3spec.djvu -page=1 MOOO=/dev/null
 MOOO=/dev/null --> not found!


I'd expect the exit status to be non-zero in this case.


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

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

Versions of packages djvulibre-bin depends on:
ii  curl7.44.0-1
ii  libc6   2.19-19
ii  libdjvulibre21  3.5.27.1-3
ii  libgcc1 1:5.2.1-12
ii  libstdc++6  5.2.1-12
ii  libtiff54.0.3-13

--
Jakub Wilk

Bug#796749: djvulibre-bin: option for quietening djvuextract

[Jakub Wilk]

Package: djvulibre-bin
Version: 3.5.27.1-3
Severity: wishlist

djvuextract prints stuff on stderr even when no error happened:

$ djvuextract djvu3spec.djvu -page=1 Sjbz=/dev/null >/dev/null
 Sjbz=/dev/null --> "/dev/null" (4226 bytes)


Please add an option to djvuextract for quietening it.


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

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

Versions of packages djvulibre-bin depends on:
ii  curl7.44.0-1
ii  libc6   2.19-19
ii  libdjvulibre21  3.5.27.1-3
ii  libgcc1 1:5.2.1-12
ii  libstdc++6  5.2.1-12
ii  libtiff54.0.3-13

--
Jakub Wilk

Bug#796748: RM: gstreamermm/experimental -- RoQA; obsoleted by gstreamermm-1.0, last upload 2011, never left experimental

[Simon McVittie]

Package: ftp.debian.org
Severity: normal

While trying to process libstdc++ transition stuff I ran into
src:gstreamermm, which:

* has only ever been uploaded to experimental
* has not been uploaded since 2011
* has no rdeps according to "dak rm -R -n -s experimental gstreamermm"
* is an older version of src:gstreamermm-1.0
* is a C++ binding for an obsolete C library (GStreamer 0.10) which
  will itself hopefully be removed from unstable reasonably soon

I suggest dropping this package rather than applying the libstdc++
transition.

S

Bug#796641: cdimage.debian.org: jigdo scanning from local media is slower than dirt

[Mateusz Poszwa]

Je 2015-08-23 00:13:00
Richard Jasmin  skribis:

> when using local media to scan for packages needed, it is horrendously slow.
> 
> This could be sped up by using a local package database or csv file or the 
> like
> on each install medium.Then it would be a breeze to scan that file and compare
> it to the jigdo template. The entire medium, in my case BDROM, would not need
> to be scanned.
> 
> Since the entire jigdo process is all about knowing what packages are where,
> this should be an easy fix.

Hello.

This is a very nice idea. It’s not a cdimage.d.o problem though.

If I remember correctly, JigDo keeps a cache with md5sums of files
it has already scanned in ~/.jigdo-file-cache.db.
It should be possible to extend it with appropriate entries,
given the template (which contains, among other information,
md5sums and paths) and the mountpoint.

For now I have some workarounds for you.
As I said, JigDo maintains a cache of scanned files,
so you can pre-scan your media (or a loopmounted image)
in spare time as soon as you get them,
so you don’t have to do it when you create a new image.
Of course you will still need them for the packages,
but at least JigDo will already know where to find them.

Second workaround requires a lot of spare disk space.
Long ago (oh dear; it was 5 years ago) I’ve written many
JigDo-related tools. Among them was a script for finding
and copying files needed by a given JigDo file.
It’s faster than JigDo, because it makes use of filenames,
and checks only required files (unless it doesn’t find all of them
(which happens because images usually don’t share the same kernels),
in which case it falls back to scanning everything, but you can
interrupt the script at this point and just make JigDo download
the remaining files). You can use it to extract needed files
to a temporary folder, and then point JigDo to scan that folder.
Even though you essentially scan the needed files twice,
I think it’s still worthwhile if you make ,e.g., a DVD out of a BD.
If you make a BD out of BD, you don’t need all this in the first place.

You can find the script at http://f8l.netne.net (jigdo-files.sh).

If you want even faster method, I could modify another script of mine
which extracts packages from images based on information found in
templates. It extracts all files now, but I can make it read
another template to extract only files found in both templates.
Let me know if you want that. This script is much shorter and clearer,
so if you don’t trust 5-years-ago-me, this is a better way.

I have more JigDo tricks up my sleeve (like jigdo.php).
One day I could port what I described here into JigDo itself.
No additional files are needed, as the information is already there.

I’m always happy to help.
Best regards.

-- 
Mateusz Poszwa

Bug#795823: blender: Uninstallable in sid

[Christoph Anton Mitterer]

Control: reopen -1

Hey.

I doubt this won't be fixed by itself; as said in the bug mentioned by
the original reporter, boost 1.55 won't build with GCC5, so you'll have
to change the package to use a newer version (e.g. 1.58)... and I don't
think this would happen automatically by the transitions.


And even if, the issue would be still there so closing the bug isn't
justified =)


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#793937: [LCFC2] templates://libdvd-pkg/{templates}

[Justin B Rye]

Dmitry Smirnov wrote:
> The only thing which makes me feel uncomfortable about this version is
> "doing downloads" in
> 
>  This package automates the process of doing downloads of the source
>  files for ${PKGG} from videolan.org, compiling them, and installing the
>  binary packages (${PKGG_ALL}).

Hmm, "do" can often be a bit weak, if that's what you mean...
 
> I suggest re-writing as
> 
>  This package automates the process of downloading of the source files for
>  ${PKGG} from videolan.org, compiling them and installing the
>  binary deb packages (${PKGG_ALL}).

That has an excess "of (the)", and it loses the plural instances of
downloads (plural runs automatically produce plural output packages,
so you can recycle this text for other downloaders regardless of how
many packages they produce per run).  Oh, and you've lost a Harvard
comma again and put the "deb" back in after I thought we'd agreed to
take it out!

Would you be any happier with a version that just replaces "doing"
with something less weak, like "performing" or "launching"?

   This package automates the process of launching downloads of the source
   files for ${PKGG} from videolan.org, compiling them, and installing the
   binary packages (${PKGG_ALL}).

(Revised patch attached)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff -ru libdvd-pkg-1.3.99-1.pristine/debian/control 
libdvd-pkg-1.3.99-1/debian/control
--- libdvd-pkg-1.3.99-1.pristine/debian/control 2015-04-14 02:47:06.0 
+0100
+++ libdvd-pkg-1.3.99-1/debian/control  2015-08-23 22:25:32.002037000 +0100
@@ -16,7 +16,8 @@
 ,${guest:Build-Depends}
 Recommends: ${guest:Recommends} ,libcap2-bin
 Suggests: ${guest:Suggests}
-Description: download and install software necessary to play video DVDs
- This package fetches, compiles from source code and installs library
- packages that are necessary to play all video DVDs with media
- player of your choice (like VLC, SMplayer, Totem, etc.).
+Description: DVD-Video playing library - installer
+ This package provides libraries that are needed for playing video DVDs
+ with a media player (such as VLC, SMplayer, Totem, etc.). It automates
+ the process of downloading source files, compiling them, and installing
+ the binary packages.
diff -ru libdvd-pkg-1.3.99-1.pristine/debian/templates 
libdvd-pkg-1.3.99-1/debian/templates
--- libdvd-pkg-1.3.99-1.pristine/debian/templates   2014-12-17 
03:00:49.0 +
+++ libdvd-pkg-1.3.99-1/debian/templates2015-08-23 22:29:10.904209938 
+0100
@@ -1,60 +1,66 @@
 Template: libdvd-pkg/first-install
 Type: note
 _Description:
- This package downloads the ${PKGG} source files from videolan.org,
- compile them and install the binary deb package(s)
- [${PKGG_ALL}].
+ This package automates the process of launching downloads of the source
+ files for ${PKGG} from videolan.org, compiling them, and installing the
+ binary packages (${PKGG_ALL}).
  .
- Please remember to run "sudo dpkg-reconfigure ${PKGI}"
- to build and install guest package(s) for the first time.
+ Please run "sudo dpkg-reconfigure ${PKGI}" to launch this process for
+ the first time.
 
 Template: libdvd-pkg/title_b-i
 Type: title
-_Description: Build and install ${PKGG}${VER}
+_Description: Download, build and install ${PKGG}${VER}
 
 Template: libdvd-pkg/build
 Type: boolean
 Default: true
-_Description: Proceed with downloading and compiling ${PKGG}${VER}?
- The installation process is therefore about to download the source files
- from videolan.org, compile them, and install the binary deb package(s)
- [${PKGG_ALL}].
+_Description: Download, build, and install ${PKGG}${VER}?
+ This package automates the process of launching downloads of the source
+ files for ${PKGG} from videolan.org, compiling them, and installing the
+ binary packages (${PKGG_ALL}).
  .
  Please confirm whether you wish this to happen.
 
 Template: libdvd-pkg/title_u
 Type: title
-_Description: Upgrades available for guest package(s)
+_Description: Upgrade available for ${PKGG}
 
 Template: libdvd-pkg/upgrade
 Type: note
 _Description:
- An update to guest package(s) [${PKGG_ALL}] version ${VER} is available
- but automatic upgrade is disabled.
+ This package automates the process of launching downloads of the source
+ files for ${PKGG} from videolan.org, compiling them, and installing the
+ binary packages (${PKGG_ALL}).
  .
- Please remember to run "sudo dpkg-reconfigure ${PKGI}" to build and
- install guest package(s) or consider installing the APT post-invoke hook.
+ An update to version ${VER} is available, but automatic upgrades are
+ disabled.
+ .
+ Please run "sudo dpkg-reconfigure ${PKGI}" to launch this process
+ manually and/or activate automatic upgrades in future.
 
 Template: libdvd-pkg/post-invoke_hook-install
 Type: boolean
 Default: true
-_Description: Install APT post-invoke hook?
+_Description: Enable automatic upgrades for ${

Bug#796747: installing kernel optional

[Geert Stappers]

Package: base-installer
Version: 1.157
Severity: Wishlist

Hello D-I team,

The udeb base-installer does always install a kernel.

For several virtualisation platform it doesn't make sense to install a kernel.
It would be handy to make the kernel install optional.

An aproach might installing kernel in a seperate udeb.

Another aproach would be a debconf variable like  "di/doinstallkernel",
a boolean with default value 'true'.

Making variable "di/doinstallkernel" _not local_ to base-installer
allows it to reuse at bootloader  install time.


Cheers
Geert Stappers
-- 
Leven en laten leven

Bug#796742: general: system takes a hit when encryption used

[Josselin Mouette]

Le dimanche 23 août 2015 à 15:16 -0500, Richard Jasmin a écrit : 
> modern day systems have 6GB/sec connections and GBs of RAM and Ghz of speed.
> There is simply no reason that ANY cipher algorithm should slow a system to a
> crawl.
> 
> Cached data or not.
> 
> Yet this is clearly the case.I tried both EncFS and GostCrypt(whole volume
> encryption) and am getting the same results here on SATA 6GB/sec connection
> with drives that support such speeds.

For the record (the bug has already been closed):
- GostCrypt is not part of Debian
- EncFS doesn’t support AES-NI so this is expected (and I’m not sure
about how secure it is, either)
You need to use dm-crypt or ecryptfs, that make use of the kernel’s
encryption library, if you want both acceptable security and
performance.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-

Bug#796730: pstreams: calls std::char_traits::move(s, NULL, 0)

[Jonathan Wakely]

Fixed in the pstreams git repo, I'm going to make a 1.0.0 release soon.

I'll fix char_traits in libstdc++ soon too.

Bug#779631: please make gemspec output reproducible

[Chris Lamb]

Chris Lamb wrote:

> I will therefore assume that this will "fix itself" once 2.2 becomes the 
> default.

Out of interest, is there an approximate timeline for 2.2 becoming the
default?

I can see https://wiki.debian.org/Teams/Ruby/Ruby2.2 and
https://wiki.debian.org/Teams/Ruby/InterpreterTransitions but it's
unclear where we currently.


Regards,

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

Bug#796745: possibly build additional hdf4-tools-alt (without netcdf support)

[Johan Van de Wauw]

On Sun, Aug 23, 2015 at 10:30 PM, Andreas Hilboll  wrote:
> Package: hdf4-tools
> Version: 4.2r10-0ubuntu1
>
> hdf4-tools depends on libhdf4-0.  However, libhdf4-0 conflicts with
> libhdf4-0-alt, which in turn is a dependency of libgdal0 and others.
>
> Would it be possible to provide a hdf4-tools-alt package depending on
> libhdf4-0-alt, without the HDF4-netcdf support?
Actually my plan is to try to have only one HDF4 library without
embedded netcdf: packages needing netcdf can link to the netcdf
library. This is the same way hdf4 is packaged in Fedora.

I'd like to test this approach locally after the netcdf transition. In
the meantime I will already upload the hdf4 4.2.11 package currently
in git.

Bug#795984: [Pkg-postgresql-public] Bug#795984: postgresql-plproxy: please make the build reproducible

[Jérémy Bobbio]

Hi Peter,

Peter Eisentraut:
> On 8/18/15 9:15 AM, Dhole wrote:
> > The attached patch sets the timezone to UTC before calling asciidoc to
> > avoid timezone differences in the generated docs. Once applied,
> > postgresql-plproxy can be built reproducibly in our current experimental
> > framework.
>
> Stupid question: Couldn't dpkg-buildpackage set the time zone?

This is a legitimate question. :)

`dpkg-buildpackage` is not mandatory to build Debian package. It would
be confusing to developers if `fakeroot debian/rules binary` would
create different packages than `dpkg-buildpackage.`

The other thing is that it might break some packages or test suites in
subtle ways. Overriding the timezone in a local manner avoids any
surprises.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#783210: glibc: please make the package build reproducibly

[Jérémy Bobbio]

Aurelien Jarno:
> I have just applied the part concerning point 1. For the 2 other points,
> from what I have understood there are now patches for gcc to define
> __DATE__ and __TIME__. So the question is should we still want to get
> this changes in the glibc? In that case I would try to get these patches
> upstream.

It's still unclear if GCC upstream will accept support for setting
predefined values to __DATE__ and __TIME__. As we are currently lacking
feedback on the patch that was submitted, waiting would make sense.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#792669: dovecot-sieve: sieve-test segfaults with editheader

[Jaldhar H. Vyas]

On Sun, 23 Aug 2015, Graham Cobb wrote:


Package: dovecot-sieve
Version: 1:2.2.18-1
Followup-For: Bug #792669

Please consider increasing the severity of this bug and releasing the package 
with the upgraded
pigeonhole asap (probably without additional changes).


I am actually working on this at this very minute.  I thought that since 
it has been some time since the last upload I would work on some other 
issues in the package but I think I will postpone all that for now and get 
an upload out today.


--
Jaldhar H. Vyas 

Bug#794809: What's you version of breeze?

[Jan Losinski]

On Thu, 06 Aug 2015 22:05:50 +0200 Diederik de Haas  
wrote:
> If you have breeze version 4:5.3.2-4 then that's likely your problem.
> Downgrading to the version in testing should fix that.

The current testing version 4:5.3.2-3 only works with kwin-style-breeze from 
sid (4:5.3.2-4). With the testing version it behaves like described above.

-- Jan

Bug#796746: RM: wine-gecko-2.24 -- ROM; obsolete

[Stephen Kitt]

Package: ftp.debian.org
Severity: normal

Dear FTP masters,

wine-gecko-2.24 is no longer used by anything in the archive in
unstable; please remove it.

Thanks,

Stephen

Bug#796550: RFP: sonic-pi -- live coding synth designed for ease of use

[Serge Schneider]

On 8/23/2015 9:41 PM, Petter Reinholdtsen wrote:

Ouch.  So if there is a problem with the binary package and Sam is
unavailable, you have no way to fix it?
We work fairly closely with Sam, he tests his releases thoroughly and I 
am sure we could build a release from source as well. It just hasn't 
come up yet.



Well, you can always backport the package from sid or unstable to stable
and stick it in your own repository, if you want to.
Well, I am a Debian developer, and do not believe it will be hard to get
the package uploaded, once there is a source package available that
build the deb with pbuilder based on unstable/sid.

Ah, that all sounds pretty good then.


I would prefer to use a git-repository buildable using git-buildpackage,
but am open to other approaches if you want a different work flow.

Perfect, that's what I try to do for all new packages, for example:
https://github.com/RPi-Distro/pgzero/tree/debian/debian

If I get some time over the next weekend, I'll take a look.

Bug#793937: [LCFC2] templates://libdvd-pkg/{templates}

[Dmitry Smirnov]

On Sunday 23 August 2015 11:26:17 Christian PERRIER wrote:
> This is the last call for comments for the review of debconf
> templates for libdvd-pkg.
> 
> The reviewed templates will be sent on Tuesday, August 25, 2015 to this bug
> report and a mail will be sent to this list with "[BTS]" as a subject tag.

The only thing which makes me feel uncomfortable about this version is
"doing downloads" in

 This package automates the process of doing downloads of the source
 files for ${PKGG} from videolan.org, compiling them, and installing the
 binary packages (${PKGG_ALL}).

I suggest re-writing as

 This package automates the process of downloading of the source files for
 ${PKGG} from videolan.org, compiling them and installing the
 binary deb packages (${PKGG_ALL}).

-- 
All the best,
 Dmitry Smirnov.


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

Bug#792669: dovecot-sieve: sieve-test segfaults with editheader

[Graham Cobb]

Package: dovecot-sieve
Version: 1:2.2.18-1
Followup-For: Bug #792669

Please consider increasing the severity of this bug and releasing the package 
with the upgraded
pigeonhole asap (probably without additional changes).

I upgraded my main personal mail server last week (after a few weeks of no 
upgrades) and subsequently
permanently lost more than two-thirds of my received emails for 2 days, before 
I noticed the problem.
Most of my emails invoke sieve header manipulation, and the dovecot-lda crash 
was being reported
back to the sender as a permanent mail delivery error.  Not only were the 
messages lost, but
several mailing lists suspended delivery due to the permanent error.

This is a very serious problem for operators of mail servers which make heavy 
use of sieve.
I have temporarily replaced delivery using dovecot-lda with postfix default 
delivery
(hence not using sieve).  But I would like to re-enable my sieve mail handling 
as soon as
possible and, more importantly, prevent others from losing emails.

Maybe a future release could consider some way of protecting dovecot-lda from 
crashes in the
sieve code so that sieve bugs just cause normal delivery instead of permanent 
delivery
failures and lost emails.

-- Package-specific info:

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

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

Versions of packages dovecot-sieve depends on:
ii  dovecot-core  1:2.2.18-1
ii  libc6 2.19-19
ii  ucf   3.0030

dovecot-sieve recommends no packages.

dovecot-sieve suggests no packages.

Versions of packages dovecot-sieve is related to:
ii  dovecot-core [dovecot-common]  1:2.2.18-1
pn  dovecot-dbg
pn  dovecot-dev
pn  dovecot-gssapi 
ii  dovecot-imapd  1:2.2.18-1
pn  dovecot-ldap   
pn  dovecot-lmtpd  
pn  dovecot-managesieved   
pn  dovecot-mysql  
pn  dovecot-pgsql  
ii  dovecot-pop3d  1:2.2.18-1
ii  dovecot-sieve  1:2.2.18-1
pn  dovecot-sqlite 

-- no debconf information

Bug#796642: debian-policy: hardening is an afterthought and should never be

[Florian Weimer]

* Steve Langasek:

>> Harden flags set AND ENFORCED on build environment(harden package)
>
> There is no way to "enforce" the use of hardening flags.

There is a way, involving multiple steps:

1. Put -grecord-gcc-switches into the hardening flags.

2. Make debuginfo packages mandatory.

3. Make full debuginfo coverage for ELF objects mandatory.  This needs
   tooling which does not exist yet.

4. Check that all record GCC switches (see step 1) contain hardening
   flags.

5. Add the the checks to Lintian.

Steps 2 and 3 are the difficult ones.  There is independent work on
automatic debuginfo package generation, so step 2 might eventually
become a possibility.  Step 3 should be relatively straightforward to
write for someone who is familiar with elfutils and DWARF.  In fact,
eu-checksec is on my long-term TODO list, and steps 3 and 4 could be
part of that.

Bug#796550: RFP: sonic-pi -- live coding synth designed for ease of use

[Petter Reinholdtsen]

[Serge Schneider]
> We get a compiled release from Sam, then build the .deb using the
> previous verion's packaging files as a template:
> http://archive.raspberrypi.org/debian/pool/main/s/sonic-pi/sonic-pi_2.6.0-3.debian.tar.gz

Ouch.  So if there is a problem with the binary package and Sam is
unavailable, you have no way to fix it?

> If reworking the package means it could go straight to Debian and 
> automatically pulled in by Raspbian, it would save time in the long run. 
> However, Sonic Pi releases are fairly frequent and, for us, the latest 
> version needs to be in 'stable', which is not going to happen under 
> standard Debian.

Well, you can always backport the package from sid or unstable to stable
and stick it in your own repository, if you want to.

> Some input from a Debian maintaner would be useful here. I have doubts
> that we would be able to find a sponsor to get this into untested or
> sid, even if a proper source package existed.

Well, I am a Debian developer, and do not believe it will be hard to get
the package uploaded, once there is a source package available that
build the deb with pbuilder based on unstable/sid.

I would prefer to use a git-repository buildable using git-buildpackage,
but am open to other approaches if you want a different work flow.

-- 
Happy hacking
Petter Reinholdtsen

Bug#796740: linux-image-4.0.0-2-amd64: kernel gets drugged to sleep when idle

[Ben Hutchings]

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

On Sun, 2015-08-23 at 14:52 -0500, Richard Jasmin wrote:
> Package: src:linux
> Version: 4.0.8-2
> Severity: grave
> Tags: upstream
> Justification: renders package unusable
> 
> Mommy Mommy he wont wake up
> seems to summarize this one nicely.
> 
> 
> System goes to sleep when idle for any length of time. Problem is once asleep,
> it wont wake. Not using sw suspend or anything like that either. Did not 
> notice
> this with debian in the past, even with the 990FX board, buggy as it may be.
> 
> No, I cant use anything newer, kmod causes video driver and virtualbox
> breakage(yet again).Stuck with #4002 until reformat or kmod issue gets fixed.
> Making backup set is taking sweet time.

Please report back when the out-of-tree modules are fixed and you can
test with 4.1.

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?



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

Bug#796745: possibly build additional hdf4-tools-alt (without netcdf support)

[Andreas Hilboll]

Package: hdf4-tools
Version: 4.2r10-0ubuntu1

hdf4-tools depends on libhdf4-0.  However, libhdf4-0 conflicts with 
libhdf4-0-alt, which in turn is a dependency of libgdal0 and others.


Would it be possible to provide a hdf4-tools-alt package depending on 
libhdf4-0-alt, without the HDF4-netcdf support?

Bug#795771: RFS: dblatex/0.3.7-1

[Andreas Hoenen]

control: retitle RFS: dblatex/0.3.7-2

Gianfranco Costamagna  wrote:

Hi Gianfranco,

thanks again for your review.  I have uploaded dblatex-0.3.7-2 to
mentors:

http://mentors.debian.net/package/dblatex

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

  dget -x http://mentors.debian.net/debian/pool/main/d/dblatex/dblatex_0.3.=
7-1.dsc

Regarding your findings:

> let's review:
> 1) please use a machine-readable copyright file

Sorry to disagree with your first suggestion (terrible start, I know):

Using a machine-readable copyright file is optional according to section
12.5.1 of the Debian Policy Manual.  In contrast to this idea I prefer
to keep as close to the upstream copyright file as possible, thus simply
diffing the upstream with the Debian file is enough to keep the latter
synchronized with the former.

> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> 2) d/compat: please bump to 9

Happy to comply, done.

> 3) d/control: you might want to run wrap-and-sort to clean the formatting=
 up,
> to bump debhelper to >=3D9 and to remove some already satisfied in oldsta=
ble version constraints.

Thanks for pointing me to wrap-and-sort, it's a nice tool.  Done.

> 4) d/rules: please prepend comments in overrides with a "tab" instead of =
spaces
> (vim is really showing them in a bad way)

That means sending the comments to the shell for evaluation, which is
superfluous (although it does no harm).  When doing so, the lines look
bad in emacs, as they are marked in warning style (that is pink
background with my color scheme).  The reason for the warning as found
in make-mode.el.gz:

;; Highlight shell comments that Make treats as commands,
;; since these can fool people.

Anyway, I'm happy to comply and have changed according to your
suggestion.

> 5) d/rules:
> I do not see the reason for get-orig-source target. if uscan works,
> what is the pourpose of it?

I have moved the retrieval of the examples tarball to the watch file and
eliminated the get-orig-source target and all related stuff.  Indeed
this simplifies the rules file remarkably.

> 6) d/rules: examples should belong to dh_installexamples not to dh_instal=
ldocs (unless
> I'm missing something)

You're right, done.

> 7) d/rules: I would add something like "--buildsystem=3Dpybuild" to the d=
efault dh call.

Done.

> 8) if the examples are the reason for the get-orig-source target, and if =
upstream ships them
> in a different source tarball, please then consider a package split

Here I disagree again: dblatex-examples.tar.bz2 has been uploaded one
time (in 2009) to SourceForge and hasn't changed since then, the archive
is not versioned at all.  Thus IMHO it's overkill to use a separate
package for this small, static add-on.

> 9) d/rules: mv debian/dblatex/usr/share/doc/dblatex/xhtml debian/dblatex/=
usr/share/doc/dblatex/html
>
> it is nice to current don't break existing installations, but I would ins=
tead create a symlink,
> rather than breaking the new installations (assuming some users might hav=
e compiled the documentation
> on their own.
>
> man dh_link might be useful there

Good idea, done.

> would you  mind fixing the above?

As you see, I've been happy to implement many of your findings, however
I disagree with your vote on the machine-readable copyright file and on
the package split.  I hope that you will nevertheless consider to
sponsor this upload, although I would also understand if you forbear
From=20sponsoring as you don't agree with my packaging decisions.

However you decide, thank you honestly for your review time and for your
valuable feedback, I have enjoyed improving dblatex's packaging.

Regards, Andreas
-- 
Andreas Hoenen 
GPG: 1024D/B888D2CE
 A4A6 E8B5 593A E89B 496B
 82F0 728D 8B7E B888 D2CE


signature.asc
Description: PGP signature

Bug#796744: jessie-pu: package owncloud-client/1.7.0~beta1+really1.6.4+dfsg-1

[Sandro Knauß]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hey,

the version 1.6.4+dfsg-1 of owncloud client can't interact with owncloud
server > 8.1 [#791721]. This versionnumber 1.7.0~beta1+really1.6.4+dfsg-1
is created by acident. It is simply the upstream version 1.6.4. The
prefix is only needed, becuase one time 1.7.0~beta1 was push to unstable
instead of experimental.

The problem is so far that upstream server checks the version of the client
and disallows the connection with an older client (< 1.7). Upstream says,
that they do it, because the older client is very unstable und not
reliable. It is so far possible to disable this feature on the server.

As far as I see different solutions to improve:
* Either we say, okay client+server from stable works together and do
  nothing.

* Mention the needed change in the stable package.
* Ship a new version via stable
* Ship a version in backports, you only need the client when a new
  server is used.

I think the best UX would be shipping the new client to stable, but I
want to hear yout opition about this issue.

So far as I looked at the code it is very hard to extract a subset to
cherrypick, there were overall improvments were made.

I didn't prepare anything for the request so far, because I want to
wait, till I know what possibilities you see. For sure we have to rebuild
owncloud-client another time with qt4 for stable. Because qt5 shipped in
stable is not current enough.

As diff of the upstream:

git clone git://anonscm.debian.org/pkg-owncloud/owncloud-client.git
cd owncloud-client
git diff upstream/1.6.4+dfsg..upstream/1.7.1+dfsg --stat csync src
 188 files changed, 8362 insertions(+), 5347 deletions(-)

Please feel to ask anything, if you missing informations.

Regards,

sandro

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

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

Bug#796743: depend on libhdf4-0-alt?

[Andreas Hilboll]

Package: libhdfeos0
Version: 2.17v1.00.dfsg.1-5

Currently libhdfeos0 depends on libhdf4-0.  However, libhdf4-0 conflicts 
with libhdf4-0-alt, which in turn is a dependency of libgdal0.


Does libhdfeos0 need the HDF4 library have netcdf support?  If not, 
would it be possible to make libhdfeos0 depend on one of either 
libhdf4-0 or libhdf4-0-alt?

Bug#791046: getfem++ and GCC 5 transition

[Anton Gladky]

I would then propose only to upload the so-name
change with the current version to fix the transition
issue. The newer 5.0 version can go to experimental
to properly check all rdepends.

Anton


2015-08-23 22:14 GMT+02:00 Scott Howard :
> On Sun, Aug 23, 2015 at 3:58 PM, Anton Gladky  wrote:
>> Hi Scott,
>>
>> thanks for the pushing it.
>> I think there is no need to upload it into experimental, let`s
>> upload it directly into unstable. The only problem is that
>> there is already a newer version of getfem than in our git, 5.0.
>> So I do not think there is a need to push the previous
>> svn-version.
>
>
> Hi Anton, I was just writing you about this, thanks for catching it earlier
> The push to experimental was to get the new package name through the
> NEW queue, trigger an auto-transition tracker, and give time for you
> to review changes without changing the library interface. I haven't
> tested reverse-depends against libgetfem5++ so I'm not comfortable
> enough with this library to bump the soversion. But you're right, it
> would be ideal to do push the version released last month if possible.
> Cheers,
> Scott

Bug#796742: general: system takes a hit when encryption used

[Richard Jasmin]

Package: general
Severity: important
Tags: lfs

modern day systems have 6GB/sec connections and GBs of RAM and Ghz of speed.
There is simply no reason that ANY cipher algorithm should slow a system to a
crawl.

Cached data or not.

Yet this is clearly the case.I tried both EncFS and GostCrypt(whole volume
encryption) and am getting the same results here on SATA 6GB/sec connection
with drives that support such speeds.

I am lucky to get ~100MB/sec throughput rates, and they are limited further
when using encryption by a factor of 4-5X.

This simply should NOT BE. The data can be encrypted in RAM or through a disk
buffer in such a case as a disk-to-disk copy.There is no need for excessive
disk writes during the encryption process, especially when using ext3+ as a
base filesystem. Ext3+ systems are known for error and power loss/reset
resiliency. Am I missing something here or did I find a major bug?

AES and SHA can be enhanced even further by use of OpenCL and SSE special
operations that newer CPUs have.And surely the TPM chip has some input here as
well.Or at least it SHOULD.



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

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

Bug#796550: RFP: sonic-pi -- live coding synth designed for ease of use

[Serge Schneider]

We get a compiled release from Sam, then build the .deb using the 
previous verion's packaging files as a template:

http://archive.raspberrypi.org/debian/pool/main/s/sonic-pi/sonic-pi_2.6.0-3.debian.tar.gz

It comes down to time constraints. It's quick, it works and is good 
enough for our purposes while there are other areas which need to be 
addressed more urgently.


If reworking the package means it could go straight to Debian and 
automatically pulled in by Raspbian, it would save time in the long run. 
However, Sonic Pi releases are fairly frequent and, for us, the latest 
version needs to be in 'stable', which is not going to happen under 
standard Debian.


Some input from a Debian maintaner would be useful here. I have doubts 
that we would be able to find a sponsor to get this into untested or 
sid, even if a proper source package existed.


On 8/23/2015 8:52 PM, Petter Reinholdtsen wrote:

[Serge Schneider]

Currently, there is no proper source package. There would need to be
a fair bit of work done to get something together that would meet
Debian's standards, so I don't think the Raspbian package is a valid
starting point. If there is interest and the Debian folk are open to
including the package, I am certainly willing to help in whatever
way I can.

Oh.  Why is there no proper source package?  I would be willing to help,
and a good starting point would be to get the source building using
pbuilder.  Is there a good version control repository to use for the
build rules?  Are you using one already?

Bug#791046: getfem++ and GCC 5 transition

[Scott Howard]

On Sun, Aug 23, 2015 at 3:58 PM, Anton Gladky  wrote:
> Hi Scott,
>
> thanks for the pushing it.
> I think there is no need to upload it into experimental, let`s
> upload it directly into unstable. The only problem is that
> there is already a newer version of getfem than in our git, 5.0.
> So I do not think there is a need to push the previous
> svn-version.


Hi Anton, I was just writing you about this, thanks for catching it earlier
The push to experimental was to get the new package name through the
NEW queue, trigger an auto-transition tracker, and give time for you
to review changes without changing the library interface. I haven't
tested reverse-depends against libgetfem5++ so I'm not comfortable
enough with this library to bump the soversion. But you're right, it
would be ideal to do push the version released last month if possible.
Cheers,
Scott

Bug#791046: getfem++ and GCC 5 transition

[Anton Gladky]

Hi Scott,

thanks for the pushing it.
I think there is no need to upload it into experimental, let`s
upload it directly into unstable. The only problem is that
there is already a newer version of getfem than in our git, 5.0.
So I do not think there is a need to push the previous
svn-version.

Regards

Anton


2015-08-23 21:44 GMT+02:00 Scott Howard :
> user release.debian@packages.debian.org
> usertag 791046 + transition
> block 791046 by 790756
> reassign 791046 release.debian.org
> thanks
>
> I have prepared a team upload to experimental using the previously posted 
> patch.
> http://anonscm.debian.org/cgit/debian-science/packages/getfem.git
> This is part of a bug-fix update of the upstream source from
> 4.2.1~beta1~svn4635~dfsg
> to
> 4.3+dfsg
>
> However, it's blocked by:
>  libstdc++6 : Breaks: python-scipy (<= 0.14.1-1) but 0.14.1-1 is to be
> installed.
>
> That's there because it was built from cpython and required c++ support:
> https://lists.debian.org/debian-gcc/2015/08/msg00046.html
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793227
>
> I'll submit a separate binNMU request for python-scipy that blocks this
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#796741: rdesktop: Does not connect

[ben]

Package: rdesktop
Version: 1.8.3-1
Severity: important

Dear Maintainer,

rdesktop fails to commect to windows 10 pro host running on local network:

$rdesktop 192.168.122.86
ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized 
?
Failed to connect, CredSSP required by server

Firewall on the Win 10 machine is completely down, and remote settings are set
to be as permissive as possible.  xfreerdp /v:192.168.122.86
works without a hitch.  

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

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

Versions of packages rdesktop depends on:
ii  libasound21.0.29-1
ii  libc6 2.19-19
ii  libgssglue1   0.4-2
ii  libpcsclite1  1.8.14-1
ii  libssl1.0.0   1.0.2d-1
ii  libx11-6  2:1.6.3-1
ii  libxrandr22:1.5.0-1

rdesktop recommends no packages.

Versions of packages rdesktop suggests:
pn  pcscd  

-- no debconf information

Bug#791209: Patched muparser for gcc 5 transitio

[Scott Howard]

On Sun, Aug 23, 2015 at 3:50 PM, Scott Howard  wrote:
> I'm going through and requesting NMUs as needed on depending packages.
> There are a couple other libraries that also need to finish their
> transitions in order to build of muparser's reverse depends (e.g.,
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791046)

No, I'm not filiing binNMUs
Julien Cristau: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794989#10
"Please don't go around filing binNMU bugs for the libstdc++ transition.
Stuff will be rebuilt as we get to it."

Bug#796740: linux-image-4.0.0-2-amd64: kernel gets drugged to sleep when idle

[Richard Jasmin]

Package: src:linux
Version: 4.0.8-2
Severity: grave
Tags: upstream
Justification: renders package unusable

Mommy Mommy he wont wake up
seems to summarize this one nicely.


System goes to sleep when idle for any length of time. Problem is once asleep,
it wont wake. Not using sw suspend or anything like that either. Did not notice
this with debian in the past, even with the 990FX board, buggy as it may be.

No, I cant use anything newer, kmod causes video driver and virtualbox
breakage(yet again).Stuck with #4002 until reformat or kmod issue gets fixed.
Making backup set is taking sweet time.




-- Package-specific info:
** Version:
Linux version 4.0.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.3 
(Debian 4.9.3-2) ) #1 SMP Debian 4.0.8-2 (2015-07-22)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.0.0-2-amd64 
root=UUID=e26b0d1e-661c-4ee3-8e0b-e1bf691fe8df ro rootflags=data=writeback 
selinux=1 security=selinux nomodeset quiet

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[  579.060877] blk_update_request: I/O error, dev loop0, sector 54571264
[  582.156555] blk_update_request: I/O error, dev loop0, sector 54575360
[  583.244735] [UFW BLOCK] IN=wlp12s0 OUT= 
MAC=1c:87:2c:c8:8e:5c:c0:56:27:60:d6:cd:08:00 SRC=188.165.138.141 
DST=192.168.2.116 LEN=595 TOS=0x00 PREC=0x00 TTL=45 ID=47168 DF PROTO=TCP 
SPT=443 DPT=59490 WINDOW=661 RES=0x00 ACK PSH URGP=0 
[  585.107399] blk_update_request: I/O error, dev loop0, sector 54579456
[  588.062510] blk_update_request: I/O error, dev loop0, sector 54583552
[  591.012143] blk_update_request: I/O error, dev loop0, sector 54587648
[  594.126897] blk_update_request: I/O error, dev loop0, sector 58720512
[  597.372589] blk_update_request: I/O error, dev loop0, sector 58724608
[  600.337556] blk_update_request: I/O error, dev loop0, sector 58728704
[  603.73] blk_update_request: I/O error, dev loop0, sector 58732800
[  606.281569] blk_update_request: I/O error, dev loop0, sector 58736896
[  609.164969] blk_update_request: I/O error, dev loop0, sector 58740992
[  612.232890] blk_update_request: I/O error, dev loop0, sector 58745088
[  615.210854] blk_update_request: I/O error, dev loop0, sector 58749184
[  617.913699] blk_update_request: I/O error, dev loop0, sector 58753280
[  620.589018] blk_update_request: I/O error, dev loop0, sector 58757376
[  623.345640] blk_update_request: I/O error, dev loop0, sector 58761472
[  624.756396] blk_update_request: I/O error, dev loop0, sector 58765568
[  627.856808] blk_update_request: I/O error, dev loop0, sector 58769664
[  630.320201] blk_update_request: I/O error, dev loop0, sector 58773760
[  633.368311] blk_update_request: I/O error, dev loop0, sector 58777856
[  636.273778] blk_update_request: I/O error, dev loop0, sector 58781952
[  639.265523] blk_update_request: I/O error, dev loop0, sector 62914816
[  642.175820] blk_update_request: I/O error, dev loop0, sector 62918912
[  645.342890] blk_update_request: I/O error, dev loop0, sector 62923008
[  648.636447] blk_update_request: I/O error, dev loop0, sector 62927104
[  651.671986] blk_update_request: I/O error, dev loop0, sector 62931200
[  654.584310] blk_update_request: I/O error, dev loop0, sector 62935296
[  657.511437] blk_update_request: I/O error, dev loop0, sector 62939392
[  660.430684] blk_update_request: I/O error, dev loop0, sector 62943488
[  663.678931] blk_update_request: I/O error, dev loop0, sector 62947584
[  666.783078] blk_update_request: I/O error, dev loop0, sector 62951680
[  669.875692] blk_update_request: I/O error, dev loop0, sector 62955776
[  670.379664] [UFW BLOCK] IN=wlp12s0 OUT= 
MAC=1c:87:2c:c8:8e:5c:c0:56:27:60:d6:cd:08:00 SRC=92.222.4.102 
DST=192.168.2.116 LEN=595 TOS=0x00 PREC=0x00 TTL=45 ID=45072 DF PROTO=TCP 
SPT=9001 DPT=18988 WINDOW=501 RES=0x00 ACK PSH URGP=0 
[  673.068359] blk_update_request: I/O error, dev loop0, sector 62959872
[  675.895932] blk_update_request: I/O error, dev loop0, sector 62963968
[  678.575734] blk_update_request: I/O error, dev loop0, sector 62968064
[  681.285705] blk_update_request: I/O error, dev loop0, sector 62972160
[  683.681641] [UFW BLOCK] IN=wlp12s0 OUT= 
MAC=1c:87:2c:c8:8e:5c:c0:56:27:60:d6:cd:08:00 SRC=89.238.161.245 
DST=192.168.2.116 LEN=595 TOS=0x00 PREC=0x00 TTL=46 ID=1586 DF PROTO=TCP 
SPT=49001 DPT=50577 WINDOW=450 RES=0x00 ACK PSH URGP=0 
[  684.039210] blk_update_request: I/O error, dev loop0, sector 62976256
[  686.682965] blk_update_request: I/O error, dev loop0, sector 67109120
[  689.299573] blk_update_request: I/O error, dev loop0, sector 67113216
[  691.935909] blk_update_request: I/O error, dev loop0, sector 67117312
[  694.623868] blk_update_request: I/O error, dev loop0, sector 67121408
[  697.274082] blk_update_request: I/O error, dev loop0, sector 67125504
[  699.972679] blk_update_request: I/O error, dev loop0, sector 67129600
[  702.675092] blk_update_request: I/O error, dev loop0, sector

Bug#794736: libvigraimpex: library transition is needed when GCC 5 is the default

[Simon McVittie]

On Thu, 13 Aug 2015 at 13:47:04 +0200, Daniel Stender wrote:
> We have some other serious issues open for Vigra (with the Lenna image set 
> [2] and test suite
> problems in Mips), so I suggest we do it that way: I'm going to prepare a 
> "v5" 1.9.0+dfsg-11
> for unstable in the next days and check the reverse deps.

Did this ever happen? I believe the current policy is that maintainers
(and NMUers) should upload transitioning packages to unstable as soon as
each library build-dependency that needs a transition has started it.
If necessary, add versioned build-dependencies, to make sure that your
package will go into Dep-Wait state on the buildds until their
build-dependencies are at the transitioned version on the relevant
architecture.

The bug about the Lena sample/test images does not need to block this:
while it is a bug that should be fixed, it isn't a regression (the version
currently in testing is no better than the one in unstable in this respect),
and unlike the libstdc++ transition it can't block work elsewhere in Debian.
If the offending files are also present in stable/testing (which I suspect
they are), please mark the bug as "found" in those versions so that the BTS
knows what's going on.

1.10.0 in experimental seems to have built successfully on mips, hopefully
that's a good sign for that bit.

You shouldn't need to go through the NEW queue for a second time when
1.9.0+dfsg-11 is uploaded, because the new binary package name has
already been approved.

S

Bug#796550: RFP: sonic-pi -- live coding synth designed for ease of use

[Petter Reinholdtsen]

[Serge Schneider]
> Currently, there is no proper source package. There would need to be
> a fair bit of work done to get something together that would meet
> Debian's standards, so I don't think the Raspbian package is a valid
> starting point. If there is interest and the Debian folk are open to
> including the package, I am certainly willing to help in whatever
> way I can.

Oh.  Why is there no proper source package?  I would be willing to help,
and a good starting point would be to get the source building using
pbuilder.  Is there a good version control repository to use for the
build rules?  Are you using one already?

-- 
Happy hacking
Petter Reinholdtsen

Bug#796739: flashplugin-nonfree: please disable screensaver on fullscreen mode

[ZenWalker]

Package: flashplugin-nonfree
Version: 1:3.6.1+b1
Severity: wishlist

Dear Maintainer,

While movie players (such as smplayer) prevent the MATE screensaver from
activating during movie playback, playing Flash videos does not affect the
screensaver, which means having to move the mouse occasionally, or turning off
the screensaver while watching YouTube videos and the like.

Please add option or disable by default the screensaver during movie playback.



-- Package-specific info:
Debian version: stretch/sid
Architecture: amd64
Package version: 1:3.6.1+b1
Adobe Flash Player version: LNX 11,2,202,508
MD5 checksums:
160a01dd00527304e5291e65eb0c65e2  
/var/cache/flashplugin-nonfree/get-upstream-version.pl
96691df0084037eaeebac9b0838bd9a2  
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz
6548c5b12b04c6637de392c09616885e  
/usr/lib/flashplugin-nonfree/libflashplayer.so
Alternatives:
flash-mozilla.so - auto mode
  link currently points to 
/usr/lib/flashplugin-nonfree/libflashplayer.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
Current 'best' version is 
'/usr/lib/flashplugin-nonfree/libflashplayer.so'.
lrwxrwxrwx 1 root root 34 Aug 23 16:55 
/usr/lib/mozilla/plugins/flash-mozilla.so -> /etc/alternatives/flash-mozilla.so
/usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to 
/etc/alternatives/flash-mozilla.so

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

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

Versions of packages flashplugin-nonfree depends on:
ii  binutils   2.25.1-1
ii  ca-certificates20150426
ii  debconf [debconf-2.0]  1.5.57
ii  gnupg  1.4.19-3
ii  libatk1.0-02.16.0-2
ii  libcairo2  1.14.2-2
ii  libcurl3-gnutls7.44.0-1
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.5.2-4
ii  libgcc11:5.1.1-14
ii  libglib2.0-0   2.44.1-1.1
ii  libgtk2.0-02.24.28-1
ii  libnspr4   2:4.10.8-2
ii  libnss32:3.19.2-1
ii  libpango1.0-0  1.36.8-3
ii  libstdc++6 5.1.1-14
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.4-1+b1
ii  wget   1.16.3-3

flashplugin-nonfree recommends no packages.

Versions of packages flashplugin-nonfree suggests:
ii  fonts-dejavu   2.35-1
pn  hal
ii  iceweasel  38.2.0esr-1~stretch
pn  konqueror-nsplugins
pn  ttf-mscorefonts-installer  
pn  ttf-xfree86-nonfree

-- no debconf information

Bug#791209: Patched muparser for gcc 5 transitio

[Scott Howard]

On Sun, Aug 23, 2015 at 1:36 PM, Simon McVittie  wrote:
> On Fri, 21 Aug 2015 at 17:21:33 -0400, Scott Kitterman wrote:
>> Since this has no C++ build-deps is can go ahead to unstable without RT ack.
>
> This is now fixed in unstable too.

I'm going through and requesting NMUs as needed on depending packages.
There are a couple other libraries that also need to finish their
transitions in order to build of muparser's reverse depends (e.g.,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791046)

Bug#791046: getfem++ and GCC 5 transition

[Scott Howard]

user release.debian@packages.debian.org
usertag 791046 + transition
block 791046 by 790756
reassign 791046 release.debian.org
thanks

I have prepared a team upload to experimental using the previously posted patch.
http://anonscm.debian.org/cgit/debian-science/packages/getfem.git
This is part of a bug-fix update of the upstream source from
4.2.1~beta1~svn4635~dfsg
to
4.3+dfsg

However, it's blocked by:
 libstdc++6 : Breaks: python-scipy (<= 0.14.1-1) but 0.14.1-1 is to be
installed.

That's there because it was built from cpython and required c++ support:
https://lists.debian.org/debian-gcc/2015/08/msg00046.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793227

I'll submit a separate binNMU request for python-scipy that blocks this

Bug#683328: Bug#796710: "moving a key signature to the correct place" loop

[Clint Adams]

Cc:ing #683328 since I still think sks should be a little more responsible here.

You can see the key brokenness if you scroll to the end of

http://pool.sks-keyservers.net:11371/pks/lookup?op=vindex&search=0x9C31503C6D866396

This is orthogonal to what gpg should and should not be doing.

Bug#796738: ruby-httpclient: FTBFS: Address already in use - bind(2) for 127.0.0.1:50000

[Chris Lamb]

Source: ruby-httpclient
Version: 2.3.3-3.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

Dear Maintainer,

ruby-httpclient fails to build from source in unstable/amd64. Port 5
is not "really" in use; I suspect that the ruby2.2 tests fail because
the server has not been cleaned up correctly from the ruby2.1 tests that
run just before it.

  [..]

  /usr/lib/ruby/2.2.0/socket.rb:459:in `tcp_server_sockets'
  /usr/lib/ruby/2.2.0/webrick/utils.rb:70:in `create_listeners'
  /usr/lib/ruby/2.2.0/webrick/ssl.rb:152:in `listen'
  /usr/lib/ruby/2.2.0/webrick/server.rb:114:in `initialize'
  /usr/lib/ruby/2.2.0/webrick/httpserver.rb:45:in `initialize'
  /tmp/buildd/ruby-httpclient-2.3.3/test/test_httpclient.rb:1599:in
  `new'
  /tmp/buildd/ruby-httpclient-2.3.3/test/test_httpclient.rb:1599:in
  `setup_server'
  /tmp/buildd/ruby-httpclient-2.3.3/test/test_httpclient.rb:11:in
  `setup'
  
===
  ..E
  
===
  Error: test_set_default_paths(TestSSL): Errno::EADDRINUSE: Address
  already in use - bind(2) for 127.0.0.1:5
  /usr/lib/ruby/2.2.0/socket.rb:206:in `bind'
  /usr/lib/ruby/2.2.0/socket.rb:206:in `listen'
  /usr/lib/ruby/2.2.0/socket.rb:461:in `block in tcp_server_sockets'
  /usr/lib/ruby/2.2.0/socket.rb:232:in `each'
  /usr/lib/ruby/2.2.0/socket.rb:232:in `foreach'
  /usr/lib/ruby/2.2.0/socket.rb:459:in `tcp_server_sockets'
  /usr/lib/ruby/2.2.0/webrick/utils.rb:70:in `create_listeners'
  /usr/lib/ruby/2.2.0/webrick/ssl.rb:152:in `listen'
  /usr/lib/ruby/2.2.0/webrick/server.rb:114:in `initialize'
  /usr/lib/ruby/2.2.0/webrick/httpserver.rb:45:in `initialize'
  /tmp/buildd/ruby-httpclient-2.3.3/test/test_ssl.rb:189:in `new'
  /tmp/buildd/ruby-httpclient-2.3.3/test/test_ssl.rb:189:in
  `setup_server'
  /tmp/buildd/ruby-httpclient-2.3.3/test/test_ssl.rb:14:in `setup'
  
===
  ..
  
  Finished in 18.601867468 seconds.
  --
  184 tests, 586 assertions, 1 failures, 42 errors, 0 pendings, 0
  omissions, 0 notifications
  76.6304% passed
  --
  9.89 tests/s, 31.50 assertions/s
  ERROR: Test "ruby2.2" failed. Exiting.
  dh_auto_install: dh_ruby --install
  /tmp/buildd/ruby-httpclient-2.3.3/debian/ruby-httpclient returned exit
  code 1
  debian/rules:15: recipe for target 'binary' failed
  make: *** [binary] Error 1
  dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
  status 2

  [..]

The full build log is attached or can be viewed here:


https://reproducible.debian.net/logs/unstable/amd64/ruby-httpclient_2.3.3-3.1.build1.log.gz


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Fri Aug 21 23:35:09 GMT+12 2015
I: pbuilder-time-stamp: 1440243309
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/unstable-reproducible-base.tgz]
I: creating local configuration
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /dev/shm
I: Mounting /sys
I: policy-rc.d already exists
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 7.0.50~), gem2deb (>= 0.2.7~)
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 20247 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on gem2deb (>= 0.2.7~); however:
  Package gem2deb is not installed.

Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
Building tag database...
The following NEW packages will be installed:
  ca-certificates{a} devscripts{a} dh-python{a} gem2deb{a} 
  gem2deb-test-runner{a} libexpat1{a} libgmp-

Bug#796737: ITP: modelio -- UML, BPMN2 and SysML modelling environment

[Ross Gammon]

Package: wnpp
Severity: wishlist
Owner: Ross Gammon 

* Package name: modelio
  Version : 3.3.1
  Upstream Author : Modeliosoft (https://www.modeliosoft.com/)
* URL : https://www.modelio.org/
* License : GPL-3
  Programming Lang: C++
  Description : UML, BPMN2 and SysML modelling environment

Modelio is an open source modeling environment (UML2, BPMN2, XMI, MDA, SysML,
TOGAF, SoaML, UML Testing Profile.). Modelio provides a standards-based
modelling environment for software developers, analysts, designers, business
architects and system architects.

This may be a good fit with the Debian Science Team - Engineering, and I intend
to offer to maintain it within that team.

Bug#796736: mirror listing update for mirrors.mit.edu

[MIT SIPB Mirrors Maintainers]

Package: mirrors
Severity: minor

Submission-Type: update
Site: mirrors.mit.edu
Type: leaf
Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc s390x sparc 
Archive-ftp: /debian/
Archive-http: /debian/
Archive-rsync: debian/
Backports-ftp: /debian-backports/
Backports-http: /debian-backports/
Backports-rsync: debian-backports/
IPv6: no
Archive-upstream: debian.gtisc.gatech.edu
Backports-upstream: debian.gtisc.gatech.edu
Updates: four
Maintainer: MIT SIPB Mirrors Maintainers 
Country: US United States
Location: Cambridge, MA, USA
Sponsor: MIT Student Information Processing Board http://sipb.mit.edu/
Comment: 1 Gbps uplink

Bug#796550: RFP: sonic-pi -- live coding synth designed for ease of use

[Serge Schneider]

Currently, there is no proper source package. There would need to be a 
fair bit of work done to get something together that would meet Debian's 
standards, so I don't think the Raspbian package is a valid starting 
point. If there is interest and the Debian folk are open to including 
the package, I am certainly willing to help in whatever way I can.

Bug#796129: Build of tellico is missing support for cddb

[Regis Boudin]

Hi Frederic,

Thanks for the report. Looking at the buildd logs, it looks like that's
something related to the gcc5 transition going on in unstable, where
libkcddb is not actually usable.

Tellico is actually quite far in the dependency chain, and depends on
many different C++ libraries, so I'm afraid it's going to have some
features broken in unstable for a bit...

Regis

On 19/08/15 18:54, Frédéric BURLET wrote:
> Package: tellico
> Version: 2.3.9+dfsg.1-1+b1
> 
> Dear maintainer,
> 
> The item menu "File > Import > Import Audio CD Data..." is greyed out,
> audio CD Data cannot be imported.
> 
> I guess this is because tellico hasn't been compiled with cddb support.
> Here are the result of my investigations:
> 
> apt-cache show tellico shows that tellico depends on libkcddb4 (>=
> 4:4.3.4).
> 
> dpkg -l libkcddb4 shows that the lib is actually installed but version
> 4:15.04.1-2.
> 
> ldd $(which tellico) | grep cddb doesn't output anything.
> 
> dpkg -l \*tellico\* shows:
> ii  tellico  2.3.9+dfsg.1-1+b1 amd64   
> Collection manager for books, videos, music, etc
> ii  tellico-data 2.3.9+dfsg.1-1all 
> Collection manager for books, videos, music, etc [data]
> ii  tellico-doc  2.3.9+dfsg.1-1all 
> Collection manager for books, videos, music, etc [doc]
> ii  tellico-scripts  2.3.9+dfsg.1-1all 
> Collection manager for books, videos, music, etc [scripts]
> 
> I guess tellico needs to be built with cddb support to get the
> aforementioned menu item enabled.
> 
> Environment information:
> - Debian unstable
> - System: amd64
> - kernel version: 4.1.0-1-amd64 #1 SMP Debian 4.1.3-1 (2015-08-03)
> x86_64 GNU/Linux
> - libc6: 2.19-19
> 
> Regards,
> 
> Frédéric BURLET.

Bug#592834: Still here

[Jayson Willson]

I confirm, these warning are still here.

Bug#781918:

[J.S.Júnior]

Sorry,…


I'd like to keep this package in Debian.
If you agree send an ok.



[]’s

Júnior Santos
ITIL® Foundation Certificate in IT Service Management
Registration number 4365854.1019776
E-mail: j.s.jun...@live.com



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#432986: Still here

[Jayson Willson]

It seems like LVM still does not supress such warnings by default - I can see 
them when running grub-install (see   
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592834). Or is it grub's bug?

Bug#780628: parcimonie: support gpg2

[Ximin Luo]

On 17/03/15 01:14, intrigeri wrote:
>> One workaround in the meantime is to edit
>> /usr/bin/parcimonie-torsocks-gpg, but of course this changes things
>> for the entire system.
> 
>> I also tried putting an override in ~/bin/ and adding this to PATH,
>> but it didn't work.
> 
> I find this surprising, given I use a very similar solution. Are you
> sure parcimonie knew about ~/bin/ being in the $PATH, in the
> environment where it was launched?
> 

For some reason I can't get the perl GnuPG::Interface to respect $PATH. I tried 
adding my own parcimonie-torified-gpg in /usr/local/bin but it didn't work, and 
various other things didn't work.

But I have a different solution to this that bypasses the perl, simply by 
having parcimonie-torified-gpg itself read $GNUPGBIN - patch supplied. I chose 
GNUPGBIN because that's what caff also uses.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
From 0db81be7613e51a1968641a21c015239ac9aa12d Mon Sep 17 00:00:00 2001
From: Ximin Luo 
Date: Sun, 23 Aug 2015 21:05:54 +0200
Subject: [PATCH] have GNUPGBIN envvar override the path to the gpg binary

---
 bin/parcimonie-torified-gpg | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bin/parcimonie-torified-gpg b/bin/parcimonie-torified-gpg
index 49c3bc0..6e06d13 100755
--- a/bin/parcimonie-torified-gpg
+++ b/bin/parcimonie-torified-gpg
@@ -1,3 +1,3 @@
 #!/bin/sh
-
-exec torsocks gpg $@
+GNUPGBIN="${GNUPGBIN:-gpg}"
+exec torsocks $GNUPGBIN $@
-- 
2.5.0



signature.asc
Description: OpenPGP digital signature

Bug#737058: CEGUI 0.8.4

[Yohann Ferreira]

Hey there Muammar,

I do hope you're going fine.  :)

I've noticed a few hours ago that now Debian is in the middle of the
gcc-5.2 transition, many package needs recompiling using that gcc version.

And CEGUI isn't spared from that part. Could you recompile the package
using gcc-5.2 and reupload it?

Best regards,

Yohann

Bug#781918: ITP

[J.S.Júnior]

I likede package in Debian for this program.



[]’s

Júnior Santos
ITIL® Foundation Certificate in IT Service Management
Registration number 4365854.1019776
E-mail: j.s.jun...@live.com



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#796730: pstreams: calls std::char_traits::move(s, NULL, 0)

[Jonathan Wakely]

On 23 August 2015 at 19:06, Jakub Wilk wrote:
> Apparently Pstreams calls std::char_traits::move() with destination buffer
> set to NULL, which is undefined behavior even when length is 0.

No it isn't, the C++ standard places no requirements on the arguments
to char_traits::move.

The fact that char_traits::move() calls memmov with null
pointers is a GCC bug, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65049

However, I'm not sure how or when I will fix the GCC bug so I might
add a workaround in pstreams instead.

Bug#785988: pysycache: diff for NMU version 3.1-3.1

[Andrey Rahmatullin]

Control: tags 785988 + patch
Control: tags 785988 + pending

Dear maintainer,

I've prepared an NMU for pysycache (versioned as 3.1-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
WBR, wRAR
diff -Nru pysycache-3.1/debian/changelog pysycache-3.1/debian/changelog
--- pysycache-3.1/debian/changelog	2010-04-05 15:37:48.0 +0600
+++ pysycache-3.1/debian/changelog	2015-08-23 23:50:21.0 +0500
@@ -1,3 +1,10 @@
+pysycache (3.1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Port from python-support to dh-python (Closes: #785988)
+
+ -- Andrey Rahmatullin   Sun, 23 Aug 2015 23:50:19 +0500
+
 pysycache (3.1-3) unstable; urgency=low
 
   * Switch to dpkg-source 3.0 (quilt) format  
diff -Nru pysycache-3.1/debian/control pysycache-3.1/debian/control
--- pysycache-3.1/debian/control	2010-04-05 15:53:46.0 +0600
+++ pysycache-3.1/debian/control	2015-08-23 23:46:24.0 +0500
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: José L. Redrejo Rodríguez 
 Homepage: http://www.pysycache.org
-Build-Depends: debhelper (>= 5), python, python-support (>= 0.4), quilt
+Build-Depends: debhelper (>= 5), python, dh-python, quilt
 Standards-Version: 3.8.4
 
 Package: pysycache
diff -Nru pysycache-3.1/debian/rules pysycache-3.1/debian/rules
--- pysycache-3.1/debian/rules	2010-04-05 15:40:54.0 +0600
+++ pysycache-3.1/debian/rules	2015-08-23 23:46:45.0 +0500
@@ -40,7 +40,7 @@
 	dh_installexamples
 	dh_install
 	dh_installmenu
-	dh_pysupport
+	dh_python2
 	dh_installman linux/man/pysycache.1
 	dh_link
 	dh_strip


signature.asc
Description: Digital signature

Bug#796735: ruby-omniauth-kerberos: Missing Build-Depends on ruby-rack-test

[Chris Lamb]

Source: ruby-omniauth-kerberos
Version: 0.3.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

Dear Maintainer,

ruby-omniauth-kerberos fails to build from source in unstable/amd64 due
to missing Build-Depends on ruby-rack-test:

  [..]
  
┌──┐
  │ Run tests for ruby2.1 from debian/ruby-tests.rake   
  │
  
└──┘
  
  
RUBYLIB=/tmp/buildd/ruby-omniauth-kerberos-0.3.0/debian/ruby-omniauth-kerberos/usr/lib/ruby/vendor_ruby:.
  rake2.1 -f debian/ruby-tests.rake
  /usr/bin/ruby2.1 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb
  /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in
  `require': cannot load such file -- rack/test (LoadError)
from
/usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in
`require'
from

/tmp/buildd/ruby-omniauth-kerberos-0.3.0/spec/omniauth/strategy/kerberos_spec.rb:2:in
`'
from
/usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1327:in
`load'
from
/usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1327:in
`block in load_spec_files'
from
/usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1325:in
`each'
from
/usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1325:in
`load_spec_files'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:103:in
`setup'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:89:in `run'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:74:in `run'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:42:in
`invoke'
from /usr/bin/rspec:4:in `'
  /usr/bin/ruby2.1 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb
  failed
  ERROR: Test "ruby2.1" failed. Exiting.
  dh_auto_install: dh_ruby --install
  /tmp/buildd/ruby-omniauth-kerberos-0.3.0/debian/ruby-omniauth-kerberos
  returned exit code 1
  debian/rules:18: recipe for target 'binary' failed
  make: *** [binary] Error 1
  dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
  status 2

  [..]

The full build log is attached or can be viewed here:


https://reproducible.debian.net/logs/unstable/amd64/ruby-omniauth-kerberos_0.3.0-1.build1.log.gz


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Sat Aug 22 03:39:35 GMT+12 2015
I: pbuilder-time-stamp: 1440257975
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/unstable-reproducible-base.tgz]
I: creating local configuration
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /dev/shm
I: Mounting /sys
I: policy-rc.d already exists
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 7.0.50~), gem2deb, rake, ruby-omniauth-multipassword, 
ruby-rspec, ruby-timfel-krb5-auth (>= 0.8)
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 20247 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on gem2deb; however:
  Package gem2deb is not installed.
 pbuilder-satisfydepends-dummy depends on rake; however:
  Package rake is not installed.
 pbuilder-satisfydepends-dummy depends on ruby-omniauth-multipassword; however:
  Package ruby-omniauth-multipassword is not installed.
 pbuilder-satisfydepends-dummy depends on ruby-rspec; however:
  Package ruby-rspec is not installed.
 pbuilder-satisfydepends-dummy depends on ruby-timfel-krb5-auth (>= 0.8); 
however:
  Package ruby-timfel-krb5-auth is not installed.

Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...

Bug#796734: monotone: FTBFS in sid (test suite failure)

[Julien Cristau]

Source: monotone
Version: 1.1-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: sid stretch

Hi,

your package no longer builds on the buildds, see the logs at
https://buildd.debian.org/status/package.php?p=monotone

> test/unit/tests/merge_3way.cc:20:12: error: 'std::cerr' has not been declared
>  using std::cerr;
> ^
> test/unit/tests/merge_3way.cc:21:12: error: 'std::cout' has not been declared
>  using std::cout;
> ^
> test/unit/tests/merge_3way.cc: In function 'void dump_incorrect_merge(const 
> std::vector >&, const 
> std::vector >&, const string&)':
> test/unit/tests/merge_3way.cc:37:7: error: 'cerr' was not declared in this 
> scope
>cerr << "bad merge: " << i << " [" << prefix << "]\t";
>^
> make[5]: *** [test/unit/tests/merge_3way.o] Error 1

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#786011: papercut: diff for NMU version 0.9.13-7.1

[Andrey Rahmatullin]

Control: tags 786011 + patch
Control: tags 786011 + pending

Dear maintainer,

I've prepared an NMU for papercut (versioned as 0.9.13-7.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
WBR, wRAR
diff -u papercut-0.9.13/debian/rules papercut-0.9.13/debian/rules
--- papercut-0.9.13/debian/rules
+++ papercut-0.9.13/debian/rules
@@ -56,7 +56,7 @@
 binary-indep: build install papercut.1
 	dh_testdir
 	dh_testroot
-	dh_pysupport /usr/share/papercut /usr/share/papercut/auth \
+	dh_python2 /usr/share/papercut /usr/share/papercut/auth \
 		/usr/share/papercut/storage
 	dh_installchangelogs
 	dh_installdocs
reverted:
--- papercut-0.9.13/debian/pycompat
+++ papercut-0.9.13.orig/debian/pycompat
@@ -1 +0,0 @@
-2
diff -u papercut-0.9.13/debian/changelog papercut-0.9.13/debian/changelog
--- papercut-0.9.13/debian/changelog
+++ papercut-0.9.13/debian/changelog
@@ -1,3 +1,11 @@
+papercut (0.9.13-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Port from python-support to dh-python (Closes: #786011).
+  * Drop unnecessary XB-Python-Versions.
+
+ -- Andrey Rahmatullin   Sun, 23 Aug 2015 23:18:20 +0500
+
 papercut (0.9.13-7) unstable; urgency=low
 
   * Fixed mysql and postgresql init dependencies (Closes: #486857)
diff -u papercut-0.9.13/debian/control papercut-0.9.13/debian/control
--- papercut-0.9.13/debian/control
+++ papercut-0.9.13/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: César Gómez Martín 
 Build-Depends: debhelper (>= 6), dpatch
-Build-Depends-Indep: python, python-support (>= 0.3), xsltproc, docbook-xsl
+Build-Depends-Indep: python, dh-python, xsltproc, docbook-xsl
 Standards-Version: 3.7.3
 HomePage: http://pessoal.org/papercut/
 XS-Python-Version: current
@@ -11,7 +11,6 @@
 Package: papercut
 Architecture: all
 Depends: ${python:Depends}, adduser
-XB-Python-Version: ${python:Versions}
 Recommends: python-mysqldb, python-pgsql
 Suggests: phpbb2, mysql-server
 Description: simple and extensible NNTP server


signature.asc
Description: Digital signature

Bug#786292: nicotine: diff for NMU version 1.2.16+dfsg-1.1

[Andrey Rahmatullin]

On Sun, Aug 23, 2015 at 08:17:11PM +0200, Josselin Mouette wrote:
> > I've prepared an NMU for nicotine (versioned as 1.2.16+dfsg-1.1) and
> > uploaded it to DELAYED/5. Please feel free to tell me if I
> > should delay it longer.
> 
> Thanks for the NMU. Are you sure you’re not forgetting a
> XB-Python-Version: (>= 2.5) ?

https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions
"The use of XB-Python-Version in the binary package paragraphs of
debian/control file has been deprecated and should be removed in the
normal course of package updates. "

Also, we don't have <2.5 for quite some time.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Bug#796733: ITP: runabc -- graphical user interface for processing abc files

[Ross Gammon]

Package: wnpp
Severity: wishlist
Owner: Ross Gammon 

* Package name: runabc
  Version : 1,952
  Upstream Author : Seymour Shlien 
* URL : http://ifdo.pugmarks.com/~seymour/runabc/top.html
* License : GPL-3
  Programming Lang: Tcl/Tk
  Description : graphical user interface for processing abc files

Runabc is a graphical user interface to several command line driven programs
for processing abc files. It is written in Tcl/Tk script.
.
The script now provides graphical user interfaces to abc2abc, abc2midi, abc2ps,
abcm2ps and yaps. You also need a midi player and a postscript viewer.

I currently maintain abcmidi and this is the graphical interface it. I intend
to maintain runabc within the Debian Multimedia Team.

Bug#782709: icedove: No special characters in Passwords allowed

[Michael Weghorn]

Hi,

I have searched in Mozilla's bug tracker.
There is an upstream Thunderbird bug report which looks to me like it
was dealing with the same issue:

https://bugzilla.mozilla.org/show_bug.cgi?id=312593

Best regards,
Michael