Bug#794383: apache2: Upgrade to apache2-2.2.22-13+deb7u5 breaks CA certificate chain

[Takatsugu Nokubi]

Sorry fo late reply.

I tried it with rebuilded deb because I use i386 arch.
So it seems to work fine.
I don't need to replace mod_ssl.so in my situation.

2015-08-08 6:18 GMT+09:00 Stefan Fritsch :
> Please try the version from https://people.debian.org/~sf/794383/
> and check if it either fixes the problem or at least gives some
> more information in the error log. You may either replace all
> packages with dpkg or only the /usr/lib/apache2/modules/mod_ssl.so
> file by hand.

Bug#795877: missing os import

[Dmitry Smirnov]

Hi Antoine,

On Tuesday 18 August 2015 11:47:11 Antoine Martin wrote:
> I normally keep quiet. But not this time. Enough is enough about
> claiming "frequent regressions" from upstream.
> I've heard it before, and I have provided statistics on those so called
> "frequent regressions" and where they actually come form vs the need to
> fix things.

Antoine, it will be hard for me to provide an accurate statistics of all 
uploads I had to withheld because I've noticed breakage somewhere...
It is true that situation improved lately but as you can see it is not 
perfect yet. You warned me yourself about regression in 0.14.27 and now we 
have another one in 0.14.28... It is just a few cases but I see no point in 
digging history for more evidence. We are both have better things to do. :)


> So let's get some facts straight.
> 
> First, some context: everyone can take a long hard look at the 0.14.10
> "stable" version found in Debian and decide if "stable" really means
> what they think it means:

Yes it really means stable. That includes protection from unexpected changes 
and regressions. 0.14.10 worked very well for me and if I weren't involved to 
packaging I could have been still using it...

Usually we do not upload new releases directly to "stable". For new releases 
we have backports [1] repository where you can find Xpra/0.14.26.

[1]: http://backports.debian.org/


> http://xpra.org/trac/wiki/Packaging

This page do not take into account that 0.14.26 is available for "Jessie" 
through official backports.


> There's a large number of serious issues in 0.14.10, people will hit
> them despite the fact that those issues are known and have an easy fix
> upstream.

I could upload isolated fixes for some of those issues but applying cherry-
picked fixes takes time that I do not have. Would you be interested to 
prepare bugfix for stable? Or would you recommend not to include Xpra to 
stable Debian releases and provide Xpra packages through backports and 
"testing" only? We do that for some packages that are considered to be 
unsuitable for release. Patching stable versions is more difficult as 
uploading new upstream releases is not allowed precisely to avoid regressions 
like this one.


> What percentage will bother filing a Debian ticket for those? Probably
> no more than a low single digit (and that's for the very obvious ones,
> not the odd crashes), but until they do things don't get fixed at all.

This is not true. There are plenty of issues get fixed if they are known to 
maintainer even if there is no corresponding bug report. However it is true 
that most bugs get fixed upstream but it is also true that most regression 
are also introduced upstream. Everyone can report a bug but as you previously 
argued, there is little sense to report upstream bugs in Debian if they can 
be reported directly upstream.


> This is a fundamentally flawed process and I just don't buy that "this
> is the Debian" way. I know for fact packages get fixed, not always just
> reactively.

I'm not sure what are you trying to say. How would you like this to be 
organised? Please let us know your ideas of a perfect workflow and maybe we 
can improve.


> Second, this fix has been committed exactly 2 weeks ago, because *we* do
> test things and find such issues very quickly:
> http://xpra.org/trac/changeset/10214

This bug is fixed only in Debian and in upstream repository. Does anyone 
still install from source? Anyway this bug is present in the latest release 
tarball of 0.14 branch.


> We even document what goes in each branch, and what will go in and when
> where you could have found this fix from day one in this branch's
> commit log:
> http://xpra.org/trac/wiki/Versions/PendingFixes

That's nice but I'm not sure how can I use this information for packaging.


> But if you want to make us look bad because you did not test and did not
> notice this in *your* package for 2 weeks, fine. At least we're clear on
> that.

On this instance, with regrets I admit that I did not do enough testing to 
notice this bug, which is entirely my fault. I let myself to believe that 
quality of your releases improved. Lesson learned and in the future I'll try 
to resist wishful thinking to avoid repeating the same mistake. This wouldn't 
have happen if I were testing 0.14.28 for two weeks.

However I've uploaded fix as soon as I've noticed this bug which was less 
than 48 hours since upload of package with regression.

FYI I work on packaging new releases when it fits to my schedule and not the 
minute when you publish a new release. On this instance I assumed that if 
release is available for two weeks it may be safer to upload because 
otherwise corrected 0.14.29 could have been already released (which is still 
not the case).


> Third, AFAIK this bug did not affect anyone using the packages we
> provide at xpra.org - only the packages provided by Debian.

So you offer binary packages that do not match release tarballs?
Do you do your ow

Bug#795934: evince: doesn't close network connections after opening documents from thunderbird/icedove

[Andrew King]

Package: evince
Version: 3.16.1-1
Severity: normal
Tags: upstream

Dear Maintainer,

After opening pdf attachments from my mail client (icedove), each evince 
process keeps an open network connection to the mail server (long after the 
document has completed loading). 

(I'm assuming that evince is retrieving the document, otherwise I am unsure why 
it needs a network connection in the first place). 

The problem is that after I have 10 documents open my mail client is unable to 
contact (or authenticate to) the mail server as it limits the number of active 
connections to 10 per IP.


Evince should close the connection once the document is loaded, or better yet, 
load the document from /tmp and not make/keep any network connections.

The immediate workaround is to save all attachments and then open them (which 
is somewhat inconvenient). 

Regards,
Andrew


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

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

Versions of packages evince depends on:
ii  evince-common  3.16.1-1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  libatk1.0-02.16.0-2
ii  libc6  2.19-18
ii  libcairo-gobject2  1.14.2-2
ii  libcairo2  1.14.2-2
ii  libevdocument3-4   3.16.1-1
ii  libevview3-3   3.16.1-1
ii  libgdk-pixbuf2.0-0 2.31.4-2
ii  libglib2.0-0   2.44.1-1.1
ii  libgtk-3-0 3.16.4-2
ii  libpango-1.0-0 1.36.8-3
ii  libsecret-1-0  0.18.2-1
ii  shared-mime-info   1.3-1

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

Versions of packages evince suggests:
ii  gvfs  1.24.1-2+b1
pn  nautilus  
ii  poppler-data  0.4.7-3
ii  unrar 1:5.2.7-0.1

-- no debconf information

Bug#795140: hunspell-br: FTBFS: invalid dates in changelog

[Norbert Preining]

clone 795140 -1 -2
reassign -1 lintian
reassing -2 dpkg
retitle -1 needs to warn on non-abbreviated month names
retitle -2 needs to check for non-abbreviated month names
thanks

> The package fails to build.  dpkg has recently[1] been made more
> sensitive to date formats in the changelog, although it does not give

Aehm, without providing error messages...

> The only error printed is, at some point during the build:
> Error parsing time at /usr/lib/x86_64-linux-gnu/perl/5.20/Time/Piece.pm line 
> 469, <$filehandle> line 5.

Not very helpful.

It seems that spelled out (i.e., non-abbreviated) month names are not
anymore accepted.

dpkg and lintian need to clean up their mess, too, and provide proper
warnings or return values.

Thanks

Norbert


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

Bug#760473: Further analysis and a patch

[Lennart Weller]

August 11 2015 7:54 PM, "David Kalnischkies"  wrote:
> apt does not link indirectly to libnettle nor to libcurl-gnutls. The
> optinal apt-transport-https does. That is a big difference for
> bootstrappers as it means they can ignore -https for the time being
> until the base system is up and running and can then be used to build
> "proper" packages.

I was indeed wrong about that assumption. wget on the other hand, which is
marked important and part of the base system, is linked against libnettle.
So the library will most likely exist on all but the most minimal systems
on which the base system is not defined by the debian policy.

> So, big thanks for the patch, but I have to pull the marker as we can't
> apply it as is. What could be done maybe is dlopen libnettle (and/or
> others if available) and use them and otherwise fallback to our own
> slower but always available code. We could then Recommends libnettle and
> make everyone happy, I guess… just, libnettle seems to be a bit too
> unstable in its ABI, which is another problem with this patch ATM as
> every ABI break in nettle means we are required to make one in
> libapt-pkg, too, entangling use in their transition…
> Caused by e.g. SHA256Summation having a struct sha256_ctx member, which
> could have a size change in a newer libnettle abi, so the size of
> SHA256Summation would change, too (that could be avoided through via the
> use of a d-pointer).

I get your point but the wget authors did consider it to be stable enough to
include it in their software. I might have a look at rewriting the patch
as a dynamically linked version. In which case I could also add openssl,
which is also part of the base system, as second fall-back.

> 
>> In the process of finding the culprit I also replaced the http method
>> with a new version using libcurl. Similiar to the https method. This
>> change does not provide any measurable speed boost as of yet, as the
>> whole process is still waiting for the hashing to complete. I attached
>> the patch nonetheless as it removes a lot of redudant code.
> 
> Same problem. http is in apt directly as 99% of all mirrors are
> http-only, so it is how you usually operate apt, -https is used by…
> very few people/mirrors.
> 
I'll probably won't have a second look at this patch as it brings almost no
benefit to the table at the current point in time. It just made the HTTP
implementation a lot more stable.

Regards,
Lennart

Bug#711460: Xfce4-mixer : muting disabled the sound

[Rpnpif]

Hello,

I confirm that purging pulseaudio is a workaround for this bug but so,
we lost the functions of pulseaudio.

This annoying bug is still here (Aug. 2015).

Regards.

Bug#683120: RFS: yadifa/2.0.5-1 [ITP]

[Markus Schade]

Hi Gianfranco

On 17.08.2015 at 16:41 Gianfranco Costamagna wrote:
> 1)
> 
> # upstream does not sign releases
> #yadifa source: debian-watch-may-check-gpg-signature

That is a commented out leftover. I have removed it anyway so other
won't think it is still used like you ;-)

> 2) sbin/yadifad/install-sh
> 
> not mentioned in copyright
> (and every install-sh on the source tree)

Ah, well spotted. I added the (hopefully correct) license paragraph to
debian/copyright.

> the other stuff looks good to me

Great. Thanks for the review. New version is on mentors.d.n


Best regards,
Markus

Bug#791230: [pkg-xtuple-maintainers] Bug#791230: nmu diff for openrpt 3.3.7-1.1

[Andrew Shadura]

Please do.

Bug#795890: ori: FTBFS on non-Linux: "UNSUPPORTED OS"

[Aaron M. Ucko]

Afif Elghraoui  writes:

> FreeBSD is even on that whitelist, strangely enough.

__FreeBSD__ is predefined only on systems that use FreeBSD's normal
userland; systems that swap most of it out instead predefine
__kFreeBSD__.  (For the record, you could detect the Hurd with __GNU__.)

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#795937: mairix: stack smash in make_nvp

[Daniel Silverstone]

Package: mairix
Version: 0.23+git20131125-0.3
Severity: important
Tags: patch

Dear Maintainer,

Mairix has, at its core, a name/value pair scheme which assumes names and
values cannot exceed 256 bytes in length.

There was a semi-active bug which ended up with a 4k limit instead of a 256
byte limit, but instead I have submitted a PR which sizes the buffers
dynamically with input at https://github.com/rc0/mairix/pull/17

It makes sense to apply this to the mairix package and then, ideally, to submit
for a backport to jessie as currently in jessie I am unable to index my mail
archive without the above patch.

D.

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

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

Versions of packages mairix depends on:
ii  libbz2-1.0  1.0.6-7+b3
ii  libc6   2.19-18
ii  zlib1g  1:1.2.8.dfsg-2+b1

mairix recommends no packages.

mairix suggests no packages.

-- no debconf information

Bug#795890: ori: FTBFS on non-Linux: "UNSUPPORTED OS"

[Aaron M. Ucko]

Afif Elghraoui  writes:

> FreeBSD is even on that whitelist, strangely enough.

__FreeBSD__ is predefined only on systems that use FreeBSD's normal
userland; systems that swap most of it out instead predefine
__kFreeBSD__.  (For the record, you could detect the Hurd with __GNU__.)

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#791118: nmu diff for libetonyek 0.1.3-1.1

[Rene Engelhard]

Hi,

On Tue, Aug 18, 2015 at 08:45:02AM +0200, Rene Engelhard wrote:
> Hi Julien,
> 
> On Mon, Aug 17, 2015 at 09:04:35PM +0200, Julien Cristau wrote:
> > I've prepared a NMU for libetonyek, to deal with the libstdc++ transition,
> > and will shortly upload it to the 1-day delayed queue.  Please find the
> > debdiff below.
> 
> This is one of the import libs I talked about yesterday where the LO
> import tests still pass with the not-rebuilt library. As also for libcdr,
> where Steve said it's not needed (see #791102).
> 
> Same for libabw, libmwaw. (libpagemaker afaics isn't in the unit tests
> yet although it has a data file)

I *believe* though that libpagemaker also is not needed. libodfgen also
might work given the tested LO-libraries (libwpft*so) use/link against it.

Regards,
 
Rene

Bug#795938: vcr.py: tests break in reproducible builds

[Daniel Stender]

Source: vcr.py
Version: 1.6.1-1
Severity: serious
Justification: fails to build from source

Tests break in reproducible builds test build [1].

I'm going to get into this, soon.

DS

[1] 
https://reproducible.debian.net/rbuild/unstable/amd64/vcr.py_1.6.1-1.rbuild.log

-- 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=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#794383: apache2: Upgrade to apache2-2.2.22-13+deb7u5 breaks CA certificate chain

[Stefan Fritsch]

On Tue, 18 Aug 2015, Takatsugu Nokubi wrote:

> Sorry fo late reply.
> 
> I tried it with rebuilded deb because I use i386 arch.
> So it seems to work fine.

Thanks for the testing

Stefan

Bug#674294: #674294 opennebula-node: Handle one node conf files and one manager conf files in different /etc/ dirs

[Dmitry Smirnov]

Hi Olivier,

Could you please confirm if this problem still exist in OpenNebula 4.12.3 ?

Thanks.

-- 
Best wishes,
 Dmitry Smirnov


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

Bug#789429: Stable update? Bug#787398 (evolution-data-server: SMTP connection lost while reading message data)

[Fabian Greffrath]

Hi there,

Am Montag, den 15.06.2015, 10:46 +0200 schrieb Josselin Mouette:
> I put 3.12.11 in unstable precisely so that it gets a little testing,
> and I’d indeed like to see it in 8.2 if the diff is acceptable.

unfortunately, I had no luck convincing the SRM to accept my proposed e
-d-s update in Jessie in #789429. I didn't even receive a singly reply
after ~2 months. Maybe one of you wants to try his luck with it?

Cheers,

Fabian



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

Bug#795939: RM: haskell-src-exts [mips mipsel] -- ROM; architecture does not cope

[Joachim Breitner]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

haskell-src-exts sometimes builds, often does not build on mips, and it
is an annoyance. The buidd admins now have added it to Not-for-us, so
that it will not be built there anymore. Therefore, the existing binaries and 
its reverse dependencies have to be removed from the archive. I found this dak 
line to work:

dak rm -R -n -a mips,mipsel haskell-src-exts agda ghc-mod haskell-derive 
haskell-hgettext haskell-hoogle haskell-hsx2hs haskell-jmacro haskell-src-meta 
haskell-test-framework-th hlint hothasktags lambdabot uuagc haskell-ed25519

Thanks,
Joachim



-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlXS5fwACgkQ9ijrk0dDIGyKAwCfemjAVf1iMS66x4kvL3qOzbqk
bIoAnRELLb48X6WCRA5BQwn5/ojSS7h6
=hkm1
-END PGP SIGNATURE-

Bug#795922: libgstreamermm-1.0-0: transition needed for g++-5 ABI

[Philip Rinn]

Hi Simon,

thanks for taking care of the transition to the g++-5 ABI!
Could you be a little more verbose? Should I do something to make the 
transition 
happen (and if, how and when)?

Best,
Philip


signature.asc
Description: Digital signature

Bug#795940: vcr.py: FTBFS: Build requires internet access ("gaierror: [Errno -2] Name or service not known")

[Chris Lamb]

Source: vcr.py
Version: 1.6.1-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,

vcr.py fails to build from source on unstable/amd64 as it tries to
connect to httpbin.org. Debian packages should not contact the internet
during build.

  [..]
  I: pybuild base:170: python2.7 -m pytest -v -x -rs
  = test session starts
  ==
  platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.7.2 --
  /usr/bin/python2.7
  rootdir: /tmp/buildd/vcr.py-1.6.1, inifile: 
  plugins: tornado, localserver
  collecting ... collected 278 items / 2 skipped
  
  tests/integration/test_basic.py::test_nonexistent_directory FAILED
  
  === FAILURES
  ===
  __ test_nonexistent_directory
  __
  
  tmpdir = local('/tmp/pytest-0/test_nonexistent_directory0')
  
  def test_nonexistent_directory(tmpdir):
  '''If we load a cassette in a nonexistent directory, it can
  save ok'''
  # Check to make sure directory doesnt exist
  assert not os.path.exists(str(tmpdir.join('nonexistent')))
  
  # Run VCR to create dir and cassette file
  with vcr.use_cassette(str(tmpdir.join('nonexistent',
  'cassette.yml'))):
  >   urlopen('http://httpbin.org/').read()
  
  tests/integration/test_basic.py:19: 
  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
  _ _ _ _ _ 
  /usr/lib/python2.7/urllib2.py:154: in urlopen
  return opener.open(url, data, timeout)
  /usr/lib/python2.7/urllib2.py:431: in open
  response = self._open(req, data)
  /usr/lib/python2.7/urllib2.py:449: in _open
  '_open', req)
  /usr/lib/python2.7/urllib2.py:409: in _call_chain
  result = func(*args)
  /usr/lib/python2.7/urllib2.py:1227: in http_open
  return self.do_open(httplib.HTTPConnection, req)
  /usr/lib/python2.7/urllib2.py:1200: in do_open
  r = h.getresponse(buffering=True)
  vcr/stubs/__init__.py:256: in getresponse
  headers=self._vcr_request.headers,
  /usr/lib/python2.7/httplib.py:1052: in request
  self._send_request(method, url, body, headers)
  /usr/lib/python2.7/httplib.py:1092: in _send_request
  self.endheaders(body)
  /usr/lib/python2.7/httplib.py:1048: in endheaders
  self._send_output(message_body)
  /usr/lib/python2.7/httplib.py:892: in _send_output
  self.send(msg)
  /usr/lib/python2.7/httplib.py:854: in send
  self.connect()
  /usr/lib/python2.7/httplib.py:831: in connect
  self.timeout, self.source_address)
  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
  _ _ _ _ _ 
  
  address = ('httpbin.org', 80), timeout = 
  source_address = None
  
  def create_connection(address, timeout=_GLOBAL_DEFAULT_TIMEOUT,
source_address=None):
  """Connect to *address* and return the socket object.
  
  Convenience function.  Connect to *address* (a 2-tuple
  ``(host,
  port)``) and return the socket object.  Passing the optional
  *timeout* parameter will set the timeout on the socket
  instance
  before attempting to connect.  If no *timeout* is supplied,
  the
  global default timeout setting returned by
  :func:`getdefaulttimeout`
  is used.  If *source_address* is set it must be a tuple of
  (host, port)
  for the socket to bind as a source address before making the
  connection.
  An host of '' or port 0 tells the OS to use the default.
  """
  
  host, port = address
  err = None
  >   for res in getaddrinfo(host, port, 0, SOCK_STREAM):
  E   gaierror: [Errno -2] Name or service not known
  
  /usr/lib/python2.7/socket.py:557: gaierror
  === short test summary info
  
  SKIP [1] /tmp/buildd/vcr.py-1.6.1/tests/integration/test_boto.py:2:
  could not import 'boto'
  SKIP [1] /tmp/buildd/vcr.py-1.6.1/tests/integration/test_urllib3.py:8:
  could not import 'certifi'
   Interrupted: stopping after 1 failures
  
  = 1 failed, 2 skipped in 2.82 seconds
  ==
  E: pybuild pybuild:262: test: plugin custom failed with: exit code=2:
  python2.7 -m pytest -v -x -rs
  dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7
  --dir . returned exit code 13
  debian/rules:13: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 25
  make[1]: Leaving directory '/tmp/buildd/vcr.py-1.6.1'
  debian/rules:10: recipe for target 'build' failed
  make: *** [build] Error 2
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

 

Bug#795934: evince: doesn't close network connections after opening documents from thunderbird/icedove

[Simon McVittie]

Control: reassign 795934 icedove
Control: retitle 795934 leaks file descriptors to attachment handlers
Control: found 795934 38.1.0-1

On 18/08/15 08:12, Andrew King wrote:
> After opening pdf attachments from my mail client (icedove), each
> evince process keeps an open network connection to the mail server (long
> after the document has completed loading).
> 
> (I'm assuming that evince is retrieving the document, otherwise I am
> unsure why it needs a network connection in the first place).

evince does not retrieve the document itself; icedove does give it a
filename in /tmp for the attachment.

The problem is that evince is executed as a subprocess of icedove, and
icedove does not either mark its open file descriptors as close-on-exec,
or close all file descriptors (except for stdin, stdout, stderr and any
other deliberately-inherited fds) in the child process after fork() but
before exec(). Any process that executes subprocesses should do at least
one of those two things, preferably both.

As a result, file descriptors that were open in icedove (including
sockets, pipes, the cache, and mailbox files) remain open in the child
process.

I can reproduce this with a different attachment handler, which
demonstrates that this is not unique to evince: if I open an attachment
with gvim, then "ls -l /proc/$(pgrep gvim)/fd", I can see that gvim has
incorrectly inherited various open file descriptors pointing to sockets,
pipes, ~/.icedove/*/Cache/*, and ~/.icedove/*/ImapMail/*/*.msf.

Quoting the rest of Andrew's report for the icedove maintainer.

> The problem is that after I have 10 documents open my mail client is
> unable to contact (or authenticate to) the mail server as it limits the
> number of active connections to 10 per IP.
> 
> Evince should close the connection once the document is loaded, or
> better yet, load the document from /tmp and not make/keep any network
> connections.
> 
> The immediate workaround is to save all attachments and then open
> them (which is somewhat inconvenient).

Regards,
S

Bug#760473: Further analysis and a patch

[Julian Andres Klode]

On Tue, Aug 18, 2015 at 07:17:56AM +, Lennart Weller wrote:
> August 11 2015 7:54 PM, "David Kalnischkies"  wrote:
> > apt does not link indirectly to libnettle nor to libcurl-gnutls. The
> > optinal apt-transport-https does. That is a big difference for
> > bootstrappers as it means they can ignore -https for the time being
> > until the base system is up and running and can then be used to build
> > "proper" packages.
> 
> I was indeed wrong about that assumption. wget on the other hand, which is
> marked important and part of the base system, is linked against libnettle.
> So the library will most likely exist on all but the most minimal systems
> on which the base system is not defined by the debian policy.

It's nice that wget does that, they're free to do whatever they want. And
we are free to decide what we want to link against.

> 
> > So, big thanks for the patch, but I have to pull the marker as we can't
> > apply it as is. What could be done maybe is dlopen libnettle (and/or
> > others if available) and use them and otherwise fallback to our own
> > slower but always available code. We could then Recommends libnettle and
> > make everyone happy, I guess… just, libnettle seems to be a bit too
> > unstable in its ABI, which is another problem with this patch ATM as
> > every ABI break in nettle means we are required to make one in
> > libapt-pkg, too, entangling use in their transition…
> > Caused by e.g. SHA256Summation having a struct sha256_ctx member, which
> > could have a size change in a newer libnettle abi, so the size of
> > SHA256Summation would change, too (that could be avoided through via the
> > use of a d-pointer).
> 
> I get your point but the wget authors did consider it to be stable enough to
> include it in their software. I might have a look at rewriting the patch
> as a dynamically linked version. In which case I could also add openssl,
> which is also part of the base system, as second fall-back.

You seem to be confused:

(1) wget is not a library, so ABI stability does not matter for it. We
would need a library transition every time nettle has one, and we
don't want that.

(2) APT cannot link to OpenSSL, as the OpenSSL license is incompatible
to the GPL.

Also, the existing code works and is reasonably fast, so replacing
it is IMHO not a good idea. If we can reach 30 or 23 MB/s does
not really matter, there is no reasonable gain here (1 GB takes
33 seconds at 30 MB/s, or 44 seconds at 23 MB/s, and updates
are usually *much* smaller).

So don't waste your time, we're not going to merge any patch adding
a dependency.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Be friendly, do not top-post, and follow RFC 1855 "Netiquette".
- If you don't I might ignore you.

Bug#795941: /usr/bin/licensecheck: [licensecheck] doesn not recognize this BSD copyright header

[picca]

Package: devscripts
Version: 2.15.8
Severity: wishlist
File: /usr/bin/licensecheck

Dear Maintainer,

I am working on the vispy packaging which is a python modules.
Most of the files contains these lines, but licensecheck doesn not recognize 
the license.

# -*- coding: utf-8 -*-
# -
# Copyright (c) 2015, Vispy Development Team. All Rights Reserved.
# Distributed under the (new) BSD License. See LICENSE.txt for more info.
# -

Would it be possible to indicate at least that the license is BSD instead of 
UNKNOWN

examples/benchmark/scene_test_1.py: UNKNOWN
examples/benchmark/scene_test_2.py: UNKNOWN
examples/benchmark/simple_vispy.py: UNKNOWN
examples/benchmark/simple_glut.py: UNKNOWN
...


thanks

Frederic

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

Kernel: Linux 4.1.0-1-586
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 devscripts depends on:
ii  dpkg-dev 1.18.2
ii  libc62.19-19
ii  perl 5.20.2-6
ii  python3  3.4.3-4
pn  python3:any  

Versions of packages devscripts recommends:
ii  at  3.1.16-1
ii  curl7.44.0-1
ii  dctrl-tools 2.24-1
ii  debian-keyring  2015.08.13
ii  dput0.9.6.4
ii  equivs  2.0.9
ii  fakeroot1.20.2-1
ii  file1:5.22+15-2
ii  gnupg   1.4.19-3
ii  libdistro-info-perl 0.14
ii  libencode-locale-perl   1.03-1
ii  libjson-perl2.90-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.11-1
ii  liburi-perl 1.69-1
ii  libwww-perl 6.13-1
ii  lintian 2.5.36.1
ii  man-db  2.7.2-1
ii  patch   2.7.5-1
ii  patchutils  0.3.4-1
ii  python3-debian  0.1.27
ii  python3-magic   1:5.22+15-2
ii  sensible-utils  0.0.9
ii  strace  4.10-3
ii  unzip   6.0-18
ii  wdiff   1.2.2-1
ii  wget1.16.3-3
ii  xz-utils5.1.1alpha+20120614-2.1

Versions of packages devscripts suggests:
ii  bsd-mailx [mailx]8.1.2-0.20150408cvs-1
ii  build-essential  12.1
pn  cvs-buildpackage 
pn  debbindiff   
pn  devscripts-el
pn  gnuplot  
ii  gpgv 1.4.19-3
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.12-1
ii  libnet-smtp-ssl-perl 1.01-3
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
ii  mutt 1.5.23-3.1
ii  openssh-client [ssh-client]  1:6.7p1-6
pn  svn-buildpackage 
pn  w3m  

-- no debconf information

Bug#778277: wget memory problem in mirror mode, possible memory leak

[Noël Köthe]

tags 778277 + moreinfo squeeeze
thanks

Hello,

Am Freitag, den 13.02.2015, 02:51 +0100 schrieb treaki:

...
> [269277.634832] Out of memory: Kill process 4049 (wget) score 780 or 
> sacrifice child
> [269277.634843] Killed process 4049 (wget) total-vm:5596716kB, anon
> -rss:4111532kB, file-rss:56kB
> 
> i have just a command lige this:
> 
> $ wget -a wgetlog -m http://domain.tld/path/
> 
> and let it run and this is the resould please fix that.

I didn't get any other bug report like yours and I cannot reproduce it.
Can you give me the exact commadnline?
Is it reproducible for you?
Can you reproduce it with Debian stable(jessie with wget 1.16?

thx.

Regards

Noël

-- 
Noël Köthe 
Debian GNU/Linux, www.debian.org

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

Bug#795065: dbus-c++: library transition needed for g++-5

[Simon McVittie]

Control: tags 795065 + patch

On Mon, 10 Aug 2015 at 08:41:54 +0100, Simon McVittie wrote:
> In the case of dbus-c++, it seems that std::string is part of the ABI.
>  says libffado
> failed to build from source

I have uploaded the necessary gtkmm2.4 version to unblock this, which is
now in the binary NEW queue. I intend to NMU dbus-c++ with the attached patch
after gtkmm2.4 reaches unstable, assuming I do not find any obvious
errors in test rebuilds of the reverse dependencies ffado and sflphone.

Regards,
S
diffstat for dbus-c++-0.9.0 dbus-c++-0.9.0

 changelog |8 
 control   |   12 +++-
 libdbus-c++-1-0.install   |1 -
 libdbus-c++-1-0v5.install |1 +
 4 files changed, 16 insertions(+), 6 deletions(-)

diff -Nru dbus-c++-0.9.0/debian/changelog dbus-c++-0.9.0/debian/changelog
--- dbus-c++-0.9.0/debian/changelog	2015-07-23 04:21:04.0 +0100
+++ dbus-c++-0.9.0/debian/changelog	2015-08-18 08:44:58.0 +0100
@@ -1,3 +1,11 @@
+dbus-c++ (0.9.0-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libdbus-c++-1-0 to libdbus-c++-1-0v5, based on Ubuntu patch
+by Matthias Klose. (Starts transition: #795065)
+
+ -- Simon McVittie   Tue, 18 Aug 2015 08:42:24 +0100
+
 dbus-c++ (0.9.0-7) unstable; urgency=medium
 
   * Add debian/patches/05_fix_glibmm_ftbfs.patch to fix FTBFS with
diff -Nru dbus-c++-0.9.0/debian/control dbus-c++-0.9.0/debian/control
--- dbus-c++-0.9.0/debian/control	2015-07-23 04:26:44.0 +0100
+++ dbus-c++-0.9.0/debian/control	2015-08-18 08:43:45.0 +0100
@@ -14,18 +14,20 @@
  libecore-dev,
  libexpat1-dev,
  libglib2.0-dev,
- libgtkmm-2.4-dev,
+ libgtkmm-2.4-dev (>= 1:2.24.4-2~),
  libtool
 Standards-Version: 3.9.6
 Homepage: http://sourceforge.net/projects/dbus-cplusplus/
 Vcs-Svn: svn://anonscm.debian.org/collab-maint/deb-maint/dbus-c++/trunk
 Vcs-Browser: http://anonscm.debian.org/viewvc/collab-maint/deb-maint/dbus-c++/trunk
 
-Package: libdbus-c++-1-0
+Package: libdbus-c++-1-0v5
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
+Breaks: libdbus-c++-1-0
+Replaces: libdbus-c++-1-0
 Description: C++ API for D-Bus (runtime package)
  Dbus-c++ attempts to provide a C++ API for D-Bus. The library has a glib/gtk
  and an Ecore mainloop integration. It also offers an optional own main loop.
@@ -37,7 +39,7 @@
 Priority: extra
 Architecture: any
 Multi-Arch: same
-Depends: libdbus-c++-1-0 (= ${binary:Version}),
+Depends: libdbus-c++-1-0v5 (= ${binary:Version}),
  libdbus-c++-bin (= ${binary:Version}),
  ${misc:Depends}
 Description: C++ API for D-Bus (development package)
@@ -50,7 +52,7 @@
 Architecture: any
 Section: utils
 Multi-Arch: foreign
-Depends: libdbus-c++-1-0 (= ${binary:Version}),
+Depends: libdbus-c++-1-0v5 (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Suggests: libdbus-c++-dev
@@ -78,7 +80,7 @@
 Priority: extra
 Architecture: any
 Multi-Arch: same
-Depends: libdbus-c++-1-0 (= ${binary:Version}), ${misc:Depends}
+Depends: libdbus-c++-1-0v5 (= ${binary:Version}), ${misc:Depends}
 Description: C++ API for D-Bus (debugging symbols)
  Dbus-c++ attempts to provide a C++ API for D-Bus. The library has a glib/gtk
  and an Ecore mainloop integration. It also offers an optional own main loop.
diff -Nru dbus-c++-0.9.0/debian/libdbus-c++-1-0.install dbus-c++-0.9.0/debian/libdbus-c++-1-0.install
--- dbus-c++-0.9.0/debian/libdbus-c++-1-0.install	2014-03-17 00:54:14.0 +
+++ dbus-c++-0.9.0/debian/libdbus-c++-1-0.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/*/*.so.*
diff -Nru dbus-c++-0.9.0/debian/libdbus-c++-1-0v5.install dbus-c++-0.9.0/debian/libdbus-c++-1-0v5.install
--- dbus-c++-0.9.0/debian/libdbus-c++-1-0v5.install	1970-01-01 01:00:00.0 +0100
+++ dbus-c++-0.9.0/debian/libdbus-c++-1-0v5.install	2014-03-17 00:54:14.0 +
@@ -0,0 +1 @@
+usr/lib/*/*.so.*

Bug#780002: ITP: node-core-util-is -- util.is* functions introduced in Node v0.12 for o lder versions

[rossgammon]

unarchive 780002
reopen 780002 !
owner 78002 !
thanks

It turns out that the latest version of node-cross-spawn depends on
node-core-util-is, so we need to resurrect this ITP and try and solve any
issues the ftp-masters may have.

Regards,

Ross

Bug#795159: hunspell-en-us dictionary is outdated

[Rene Engelhard]

retitle 795159 please update with version from http://wordlist.aspell.net/dicts/
thanks

Hi,

On Wed, Aug 12, 2015 at 09:32:27AM +0700, Ekanan Ketunuti wrote:
>Yes, there is.
>[3]http://wordlist.aspell.net/dicts/

Maybe, but this is not in the official hunspell sf project.

> The upstream version of hunspell is 2015.05.18.

That is wrong. The upstream version of hunspell is 1.3.3.

The dictionary is something else than the actual engine.

> So, the dic is outdated. please reopen this.

I see that Mike Hommey just did, though I still don't buy why we immediately
need to update something which works and just doesn't have some words. Or
is there some serious problem here I don't see?

Especially since as I said the version on sf.net/projects/hunspell _IS_ what
we have in the arhive. Yes, that might be old, but "outdated" is something
different.

Regards,

Rene

Bug#795940: vcr.py: FTBFS: Build requires internet access ("gaierror: [Errno -2] Name or service not known")

[Daniel Stender]

Thanks for taking care of this. The test are supposed to run offline on 
localhost
with pytest-localserver. I'll get into this, soon.

DS

-- 
http://www.danielstender.com/blog/
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8

Bug#795938: vcr.py: tests break in reproducible builds

[Chris Lamb]

merge 795938 795940
thanks

Merging these two. Opened BTS tab for before breakfast, and didn't check
one more time before submitting..


Regards,

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

Bug#795938: vcr.py: tests break in reproducible builds

[Daniel Stender]

On 18.08.2015 10:23, Chris Lamb wrote:
> merge 795938 795940
> thanks
> 
> Merging these two. Opened BTS tab for before breakfast, and didn't check
> one more time before submitting..
> 
> Regards,

Already closed in the meanwhile ..

Thanks for reporting this.

Dan

-- 
http://www.danielstender.com/blog/
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8

Bug#795589: libmath-planepath-perl: FTBFS: Failed 1/103 test programs. 1/34754 subtests failed.

[Kevin Ryde]

Niko Tyni  writes:
>
>   # round_up_pow(555906056624,3) i=33 post 
> 555906056623,16677181699666569 want 33,34

Thanks, that was a bug in the tests going past the floating point
mantissa.  Should be fixed in version 120 uploaded a couple of days ago.

(Dunno why it only showed up on some systems, some combination of NV and
UV sizes around 64-bits.)



-- 
Architectural biology jargon elucidated for the layman:
"Parthenogenesis" -- the method by which large Greek buildings are constructed.

Bug#791169: nmu diff for libsidplayfp 1.8.1-1.1

[Julien Cristau]

On Mon, Aug 17, 2015 at 23:28:55 +0200, László Böszörményi (GCS) wrote:

> Hi Julien,
> 
> On Mon, Aug 17, 2015 at 9:04 PM, Julien Cristau  wrote:
> > I've prepared a NMU for libsidplayfp, to deal with the libstdc++ transition,
> > and will shortly upload it to the 1-day delayed queue.  Please find the
> > debdiff below.
>  Please withdraw it, as the rename already happened. It was
> libsidplayfp3 before and was renamed with the new upstream release to
> libsidplayfp4 [1] for the GCC 5 transition (this also matches the new
> soname). With your upload it would be renamed twice, from
> libsidplayfp3 through libsidplayfp4 to libsidplayfp4v5 . Please
> describe why is this necessary if needed. Also as I know we don't
> close transition bugs from changelog, but reassign it to
> release.debian.org and tag it transition. What may I miss?
> 
If the rename already happened, why is #791169 then still open and
assigned to libsidplayfp?

Delayed upload canceled.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#795942: wheel: please use SOURCE_DATE_EPOCH over WHEEL_FORCE_TIMESTAMP

[Chris Lamb]

Source: wheel
Version: 0.24.0-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps toolchain
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Thanks for applying #776026. We now have a more generic /
package-agnostic solution for exposing a build timestamp, namely
SOURCE_DATE_EPOCH.

It works the same, just a different name. More importantly, because our
toolchain exports SOURCE_DATE_EPOCH, individual packages using wheel
will not require separate and somewhat tedious patching to use
WHEEL_FORCE_TIMESTAMP.

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/patches/reproducible-whls.diff 
b/debian/patches/reproducible-whls.diff
index 18c0372..04b8bf8 100644
--- a/debian/patches/reproducible-whls.diff
+++ b/debian/patches/reproducible-whls.diff
@@ -26,7 +26,7 @@ Author: Barry Warsaw 
 +# Some applications need reproducible .whl files, but they can't do this
 +# without forcing the timestamp of the individual ZipInfo objects.  See
 +# issue #143.
-+timestamp = os.environ.get('WHEEL_FORCE_TIMESTAMP')
++timestamp = os.environ.get('SOURCE_DATE_EPOCH')
 +if timestamp is None:
 +date_time = None
 +else:
@@ -164,7 +164,7 @@ Author: Barry Warsaw 
 +fp.write(filename + '\n')
 +zip_base_name = os.path.join(tempdir, 'dummy')
 +# The earliest date representable in TarInfos, 1980-01-01
-+with environ('WHEEL_FORCE_TIMESTAMP', '315576060'):
++with environ('SOURCE_DATE_EPOCH', '315576060'):
 +zip_filename = wheel.archive.make_wheelfile_inner(
 +zip_base_name, tempdir)
 +with readable_zipfile(zip_filename) as zf:
diff --git a/debian/tests/reproduce-2 b/debian/tests/reproduce-2
index ea481c7..01614f6 100644
--- a/debian/tests/reproduce-2
+++ b/debian/tests/reproduce-2
@@ -1,7 +1,7 @@
 #!/bin/bash
 
 # For reproducible .whl files.  See bug ##776026.
-export WHEEL_FORCE_TIMESTAMP=315576060
+export SOURCE_DATE_EPOCH=315576060
 
 # Change to the directory with the setup.py.
 cd debian/tests/dummy
diff --git a/debian/tests/reproduce-3 b/debian/tests/reproduce-3
index 0efad13..fd260d8 100644
--- a/debian/tests/reproduce-3
+++ b/debian/tests/reproduce-3
@@ -1,7 +1,7 @@
 #!/bin/bash
 
 # For reproducible .whl files.  See bug ##776026.
-export WHEEL_FORCE_TIMESTAMP=315576060
+export SOURCE_DATE_EPOCH=315576060
 
 # Change to the directory with the setup.py.
 cd debian/tests/dummy

Bug#795922: libgstreamermm-1.0-0: transition needed for g++-5 ABI

[Simon McVittie]

On 18/08/15 09:06, Philip Rinn wrote:
> thanks for taking care of the transition to the g++-5 ABI!
> Could you be a little more verbose? Should I do something to make the 
> transition 
> happen (and if, how and when)?

Sorry, I incorrectly assumed that gstreamermm-1.0 was a pkg-gnome
package, and so you would probably have seen enough of these bugs
already to be almost as tired of them as I am :-)

The context is that gstreamermm-1.0 has std::string in its ABI, and
g++-5 has switched its default ABI to C++11 mode, which changes the
representation of std::string; so building gstreamermm-1.0 with g++-5
changes its ABI, even though there were no source code changes.

As a result, someone needs to rename the binary package to add the "v5"
suffix, similar to what I did for gtkmm3.0
,
and fix any packaging that is broken by that change (for instance
symbols files, shlibs, or any mentions of the library package name in
debian/rules).

In principle you can upload that change to unstable as soon as all your
C++ build-dependencies have had their renames, or been confirmed to not
need a rename. In your case I think that just means waiting for
glibmm2.4, which has already happened.

However, to be able to test your change, ideally you should be able to
rebuild and test reverse-dependencies; or if you can't actually *test*
them because not enough packages have been binNMU'd for you to be able
to get a working system, the next best thing is to be able to *rebuild*
some reverse-dependencies successfully. I've been using a local instance
of sbuild, with a local apt repository containing transitioned and
locally-rebuilt packages.

To be able to rebuild subtitleeditor successfully, you'll probably need
to wait for atkmm, pangomm and gtkmm3.0 (each of which I just uploaded)
to get out of the NEW queue; so it's probably best to wait for those to
hit unstable before doing anything. However, you could prepare the
changes in your git repository if you want to be helpful. If you do
that, it would be great if you could send a patch to this bug, so that
it's obvious how to NMU if you aren't available to upload it at the
appropriate time.

It isn't currently clear whether you should close this bug in the upload
or not: the initial recommendation was to leave the bug open and
reassign it to release.debian.org as a transition tracker, but jcristau
seems to have switched to just closing the bug in the usual way in his
most recent round of NMUs, so I'm not sure what's going on there.

S

Bug#791169: nmu diff for libsidplayfp 1.8.1-1.1

[GCS]

On Tue, Aug 18, 2015 at 10:32 AM, Julien Cristau  wrote:
> On Mon, Aug 17, 2015 at 23:28:55 +0200, László Böszörményi (GCS) wrote:
>> On Mon, Aug 17, 2015 at 9:04 PM, Julien Cristau  wrote:
>> > I've prepared a NMU for libsidplayfp, to deal with the libstdc++ 
>> > transition,
>> > and will shortly upload it to the 1-day delayed queue.  Please find the
>> > debdiff below.
>>  Please withdraw it, as the rename already happened. It was
>> libsidplayfp3 before and was renamed with the new upstream release to
>> libsidplayfp4 for the GCC 5 transition (this also matches the new
>> soname).
> If the rename already happened, why is #791169 then still open and
> assigned to libsidplayfp?
 I was waiting for an answer from Frédéric[1] what did he mean by the
patch[2], if there's a source code fix or whatever to apply. As I
didn't get an answer, I think he is just confused with something; I
wanted to be extra safe. But just going to reassign the bug.

Regards,
Laszlo/GCS
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791169#24
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791169#19

Bug#790987: marked as done (botan1.10: library transition may be needed when GCC 5 is the default)

[Christian Hofstaedtler]

Control: reopen -1

Reopening to keep the bug until the transition is through.

>  botan1.10 (1.10.10-1) unstable; urgency=medium
>  .
>* Imported Upstream version 1.10.10
>* Add symbols file for libbotan-1.10-0v5 library
>* Rebuild with gcc-5 and libstdc++6 (Closes: #790987)
>* Add DPKG_GENSYMBOLS_CHECK_LEVEL=4 to d/rules
>* Upstream bumped SOVERSION to 1, so rename the shared library package
>  to libbotan-1.10-1

On non-amd64 archs, there's now this FTBFS:

- (c++)"vtable for Botan::IDEA_SSE2@Base" 1.10.8
+#MISSING: 1.10.10-2# (c++)"vtable for Botan::IDEA_SSE2@Base" 1.10.8

Thanks,
Christian

-- 
 ,''`.  Christian Hofstaedtler 


: :' :  Debian Developer


`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03  


  `-

Bug#778345: Snakeyaml upgrade to 1.15

[jevgeni...@gmail.com]

Hello,

What is the status of this one?
I'd need version 1.15 for testNg package upgrade.

Thanks,
Eugene

Bug#712155: [bug #45789] wget: -O does not work as described wrt timestamps

[NoëlKöthe]

URL:
  

 Summary: wget: -O does not work as described wrt timestamps
 Project: GNU Wget
Submitted by: nok
Submitted on: Di 18 Aug 2015 10:44:34 CEST
Category: Documentation
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
Operating System: None
 Reproducibility: None
   Fixed Release: None
 Planned Release: None
  Regression: None
   Work Required: None
  Patch Included: None

___

Details:

Hello,

a forwarded and with 1.16.3 reproducible bug report:

--8<--
wget's manpage says:

>   -O file
>   --output-document=file
> ...
>   Use of -O is not intended to mean simply "use the name file
instead of the one in the URL;" rather, it is
>   analogous to shell redirection: wget -O file http://foo is
intended to work like wget -O - http://foo >
>   file; file will be truncated immediately, and all downloaded
content will be written there.
>
>   For this reason, -N (for timestamp-checking) is not supported in
combination with -O: since file is always
>   newly created, it will always have a very new timestamp. A warning
will be issued if this combination is
>   used.

but:

> $ date
> Do 13. Jun 17:12:06 CEST 2013
> $ wget http://www.debian.org
> ...
> $ wget -O test1 http://www.debian.org
> ...
> $ wget -O - http://www.debian.org > test2
> ...
> $ ls -l index.html test1 test2
> -rw-r--r-- 1 user group 14649 Jun 11 21:58 index.html
> -rw-r--r-- 1 user group 14649 Jun 11 21:58 test1
> -rw-r--r-- 1 user group 14649 Jun 13 17:12 test2

So the documentation is completely wrong here: '-O file' has the same
timestamp of the last change of the web
page as the naked wget and behaves clearly different from '-O - > file' here.
--8<--

https://bugs.debian.org/712155

Additional there is a comment on this from former maintainer Micah in this
report but I want to be sure and verifiy if you think if is or is not
something which might be corrected.

thx




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/

Bug#724931: Re: Bug#724931: Please include the patch in git

[adrian15]

El 08/03/14 a las 18:11, Andreas Cadhalpun escribió:

I fixed a few things in my previous patch (see attachments):
 * Fix typo in finish-install.d/10apt-cdrom-setup: cdrom/$j -> cdrom$j
 * Always test for other CDs, except if it is a netinst CD.
   Otherwise one can't use CD-2 together with 
debian-testing-amd64-kde-CD-1.iso of type full_cd/single. (Maybe I 
didn't get how this is supposed to work?)
 * Mount further ISOs if at least four parts (seperated by -) of the 
name are the same. Example:

a) debian-testing-amd64-CD-1.iso
b) debian-testing-amd64-kde-CD-1.iso
c) debian-testing-amd64-CD-2.iso
d) debian-testing-amd64-CD-2-local-changes.iso
e) debian-testing-i386-CD-2.iso
  a) and b) would load c) or d), but not e).
 * Fix crash, if the filesystem is not know (e.g. unpartitioned).

Pease add the attached patches on top of current git, even if you 
don't want to apply the patch now and instead move it to another branch.


Best regards,
Andreas


Can you please explain why you are using: get_fstype () function which 
it's based on blkid instead of just using the old method of relying in 
auto function from the kernel itself?


This is used in both cdrom-detect.patch and mountmedia.patch.

Please, be aware, that I'm not telling you your approach is incorrect. 
It seems we are lacking the explanation or rationale on why you made 
that decision in order to evaluate that change in a fair manner.


Thank you very much!

adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona 
a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#795943: pbuilder-uml create crashes

[Benedikt Ahrens]

Package: pbuilder-uml
Version: 0.215+nmu3
Severity: grave

Dear Maintainer,

I launched the below command in order to create a pbuilder file, resulting in 
the crash reported below.
It seems that this renders the package unusable, hence I chose severity grave.
Maybe the bug should be filed against rootstrap instead, but since I 
encountered it using pbuilder-uml, and since
it renders pbuilder-uml unusable, I am reporting it as is.

$ pbuilder-user-mode-linux create  --distribution sid --buildplace 
/home/ahrens/var/cache --buildresult /home/ahrens/var/cache/result
Locating the bottom of the address space ... 0x1
Locating the top of the address space ... 0xc000
Core dump limits :
soft - 0
hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking environment variables for a tempdir...none found
Checking if /dev/shm is on tmpfs...OK
Checking PROT_EXEC mmap in /dev/shm...OK
Checking for the skas3 patch in the host:
  - /proc/mm...not found: No such file or directory
  - PTRACE_FAULTINFO...not found
  - PTRACE_LDT...not found
UML running in SKAS0 mode
Adding 24801280 bytes to physical memory to account for exec-shield gap
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys cpuacct
Linux version 3.16.7-ckt7 (root@binet) (gcc version 4.9.2 (Debian 4.9.2-10) ) 
#2 Mon Mar 2 20:21:47 UTC 2015
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 14135
Kernel command line: con0=fd:0,fd:1 con=pts root=/dev/root rootflags=/ 
rootfstype=hostfs ubd1=/home/ahrens/uml-image init=/usr/lib/rootstrap/builder 
devfs=nomount rsworkdir=/home/ahrens/.pbuilder-user-mode-linux
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Sorting __ex_table...
Memory: 25040K/56988K available (3641K kernel code, 1671K rwdata, 1128K rodata, 
110K init, 145K bss, 31948K reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:15
Calibrating delay loop... 5636.09 BogoMIPS (lpj=28180480)
pid_max: default: 32768 minimum: 301
Security Framework initialized
SELinux:  Initializing.
AppArmor: AppArmor disabled by boot time parameter
Yama: disabled by default; enable with sysctl kernel.yama.*
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys net_cls
Initializing cgroup subsys blkio
Checking for host processor cmov support...Yes
Checking that host ptys support output SIGIO...Yes
Checking that host ptys support SIGIO on close...No, enabling workaround
devtmpfs: initialized
Using 2.6 host AIO
xor: measuring software checksum speed
   8regs :  6673.600 MB/sec
   8regs_prefetch:  6617.200 MB/sec
   32regs:  5029.200 MB/sec
   32regs_prefetch:  4800.400 MB/sec
xor: using function: 8regs (6673.600 MB/sec)
NET: Registered protocol family 16
raid6: int32x1   1372 MB/s
raid6: int32x2   1529 MB/s
raid6: int32x4   1657 MB/s
raid6: int32x8   1478 MB/s
raid6: using algorithm int32x4 (1657 MB/s)
raid6: using intx1 recovery algorithm
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
Switched to clocksource itimer
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP: reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
console [stderr0] disabled
mconsole (version 2) initialized on /home/ahrens/.uml/AyFcbe/mconsole
Checking host MADV_REMOVE support...OK
Mapper v0.1
mmapper_init - find_iomem failed
UML Watchdog Timer
Host TLS support detected
Detected host type: i386 (GDT indexes 6 to 9)
futex hash table entries: 256 (order: -1, 3072 bytes)
audit: initializing netlink subsys (disabled)
audit: type=2000 audit(1439887044.943:1): initialized
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
squashfs: version 4.0 (2009/01/31) Phillip Lougher
JFS: nTxBlock = 195, nTxLock = 1565
SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no 
debug enabled
msgmni has been set to 48
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler cfq registered (default)
TCP: cubic registered
NET: Registered protocol family 17
Initialized stdio console driver
Console initialized on /dev/tty0
console [tty0] enabled
Initializing software serial port version 1
console [mc-1]

Bug#791169: libsidplayfp transition is in progress

[GCS]

Control: user release.debian@packages.debian.org
Control: usertag 791169 + transition
Control: block 791169 by 790756
Control: reassign 791169 release.debian.org
Control: severity 791169 normal

Hi,

The package rename already happened and as the transition tracker[1]
shows, sidplayfp already built with it. There was a confusion from one
of the users[2], but as I see, audacious-plugins is still need a
binNMU to be rebuilt with this libsidplayfp version.

Cheers,
Laszlo/GCS
[1] https://release.debian.org/transitions/html/auto-libsidplayfp.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791169#19

Bug#712155: #712155 wget: -O does not work as described wrt timestamps

[Noël Köthe]

forwarded 712155 https://savannah.gnu.org/bugs/?45789
tags 712155 + upstream
thanks

Hello,

your reported bug https://bugs.debian.org/712155 was commented by the
maintainer on the same day but to be sure I submitted it to the
upstream BTS.

Regards

Noël

-- 
Noël Köthe 
Debian GNU/Linux, www.debian.org

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

Bug#783545: #783545

[Sascha Girrulat]

Hi,

i tried to figure out whats the reason for the ever displayed tab and i
found out that asf do a nullify of some asf preferences like
'extensions.asf.version'. If you set the version manually the tab
disappear for (only) the next start. I didn't found the related code yet
but for the version on the wip branch it's fixed and workes fine for me.
The dialog from the documentation is missing all the time and also in
this version.

We have to take a more detailed look the version from the wip branch
because i found some other dialog bugs like missing labels for some
buttons like "Add, Up, Down, Delete" from the "Filter" dialog.

Regards
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#281201: [bug #45790] wget prints it's progress even when background

[NoëlKöthe]

URL:
  

 Summary: wget prints it's progress even when background
 Project: GNU Wget
Submitted by: nok
Submitted on: Di 18 Aug 2015 11:03:31 CEST
Category: User Interface
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
Operating System: None
 Reproducibility: None
   Fixed Release: None
 Planned Release: None
  Regression: None
   Work Required: None
  Patch Included: None

___

Details:

Hello,

an old forgotten bug report:

--8<--
When wget is suspended in command line and then
send into background (eg using bash bg command), it continues
to print it's progress messages. This leads to either stopping
wget or to garbling terminal with wget messages (depending
on the TOSTOP terminal setting).
--8<--
My suggestion is to stop printing verbose progress messages
when the job is resumed in background. It could be checked
by (successful) getpgrp() not equal to (successful) tcgetprp(1)
in SIGCONT signal handler.
 And something like this is used in some console applications,
for example, in lftp.
--8<--
https://bugs.debian.org/281201

As an example:

# wget
http://cdimage.debian.org/debian-cd/current/multi-arch/iso-cd/debian-8.1.0-amd64-i386-netinst.iso

[1]+  Stopped  wget
http://cdimage.debian.org/debian-cd/current/multi-arch/iso-cd/debian-8.1.0-amd64-i386-netinst.iso
nk@pro:/tmp/test$ bg


Regards

Noël




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/

Bug#783545: #783545

[Sascha Girrulat]

sry, the tested version of iceweasel is 38.2.0.

Regards
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#795944: installation-guide: should call a RAID a RAID

[Justin B Rye]

Source: installation-guide
Version: 20150528
Severity: minor
Tags: d-i patch

Following up #794936, here's my second bugreport for a big clear
individual issue before I start on a general proofreading sweep.

Section 6.3.3.4 (aka the file "using-d-i/modules/mdcfg.xml") describes
how to set up RAID arrays in D-I.  But instead of just calling them
that it insists on using jargon which users are unlikely to be
familiar with and which isn't even technically correct.

I'm including general proofreading fixes in this patch as well as the
headline problem, because it's all in one .xml file - if I tried to
separate things out into one patch fixing the grammar issues and one
standardising the punctuation and so on then they'd all just trample
on one another's toes.

Here's an annotated copy of the patch (and yes, this time I've
double-checked the attached version is the same file!):

> Index: mdcfg.xml
> ===
> --- mdcfg.xml (revision 70030)
> +++ mdcfg.xml (working copy)
> @@ -2,32 +2,32 @@
>  
>  
> 
> -   Configuring Multidisk Devices (Software RAID)
> +   Configuring Software RAID

Because absolutely nobody calls them Multidisk Devices, and MD has
never stood for that anyway.  (There are rumours it was once "Mirror
Disk", but it has officially always been "Multiple Device".)

I was going to add that if you Google "Multidisk Devices", it just
goes "did you mean...?" - but in fact if I insist, it will do that
search, and finds Frans Pop filing bug #387696 about this in 2006.
That was allegedly fixed, but here it still is.

If the mdcfg module supported RAID plus some other things then it
might be more pedantically accurate to talk here in terms of using
Multiple Device storage in general.  But it doesn't.  It's talking
about RAID, which was already widely known as RAID before Linux
existed.  So call it RAID!

>  
>  
> -If you have more than one harddrive
> +If you have more than one hard drive

I'm letting "mountpoints" and "filesystems" get away with being
written as one word, but "harddrive" is a step too far.

(Meanwhile, the day may be approaching when we'll need to say "hard
disk, flash drive, or similar main non-volatile storage system".  Or
maybe we'll be able to use plain "drive" as a cover-term...)
  
> -To be honest, you can construct an MD device even from partitions
> -residing on single physical drive, but that won't give any benefits.
> +To be strictly accurate, you can construct a RAID array even from partitions
> +residing on a single physical drive, but that won't give any benefits.

Leaving out this detail wouldn't have been dishonest.

Our default name for RAID arrays should be "RAID arrays".  Referring
to RAID in terms of the Linux kernel driver used for it makes even
less sense when you consider that this installer is also intended foe
use on systems where &arch-kernel; != Linux.

Missing indefinite article.

> - in your computer, you can use
> -mdcfg to set up your drives for increased
> -performance and/or better reliability of your data. The result is
> -called Multidisk Device (or after its most
> -famous variant software RAID).
> + in your computer, you can set up your drives for
> +improved performance and/or reliability by using software RAID.
> +The &d-i; module used for this is mdcfg, named
> +after the Linux md (Multiple Device)
> +driver.

Users of D-I are never told that they're using mdcfg, so it's fairly
pointless to act as if they'd recognise the name; instead, _introduce_
it here.  Tagging "mdcfg" as a  just spoils any plan we might
have for making the  tag pull its weight (they might for
instance link to manpages.debian.org - but D-I modules don't have man
pages).  I'm falling back on marking "mdcfg" as a basic  here
(which should result in the same markup as for a ), but it's
not clear it's entitled even to this much, since it isn't a word that
users ever need to be treat as a verbatim string...

"Reliability of your data" is subtly wrong.  If my data is the
collected prophetic ramblings of Nostradamus, RAID isn't going to make
it any more reliable!  Just say "improved [...] reliability".

Then the end of the second sentence is the main point of this bug
report.  The result of using mdcfg is _not_ called "Multidisk Device".
It isn't even called "MD".  It's called RAID.  Introduce it as RAID,
then note in case anybody cares that it's implemented in Linux under
the name "md".  (This might even go in a footnote, but we've just had
one of those.)
  
>  
>  
> -MD is basically a bunch of partitions located on different disks and
> -combined together to form a logical device. This
> -device can then be used like an ordinary partition (i.e. in
> -partman you can format it, assign a mountpoint,
> -etc.).
> +A RAID array is basically a bunch of partitions located on different
> +disks and combined together to form a logical
> +device. You can then proceed with the install using it just like an
> +ordinary partition —

Bug#281201: #281201 wget prints it's progress even when background

[Noël Köthe]

forwarded 281201 https://savannah.gnu.org/bugs/?45790
tags 281201 - moreinfo
found 281201 1.16.3-3
thanks

Hello,

the wishlist reqest is now forwarded to the upstream bugtracker.

Regards

Noël

-- 
Noël Köthe 
Debian GNU/Linux, www.debian.org

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

Bug#791230: [pkg-xtuple-maintainers] Bug#791230: Bug#791230: nmu diff for openrpt 3.3.7-1.1

[Daniel Pocock]

On 18/08/15 09:24, Andrew Shadura wrote:
>
> Please do.
>




Thanks Julien.  It would be good if you could commit and tag in our Git
repository too but if not, we can do that with your patch.

Upstream are now willing to keep some Debian artifacts in their
repositories, I'm currently looking at how to integrate our process more
closely with them, I'll take care of getting these patches in there too.

I think that this package needs to be updated to a newer version when
PostBooks v4.9.x or later is packaged, these patches will obviously need
to be part of that.

Regards,

Daniel

Bug#795159: hunspell-en-us dictionary is outdated

[Mike Hommey]

On Tue, Aug 18, 2015 at 10:21:07AM +0200, Rene Engelhard wrote:
> retitle 795159 please update with version from 
> http://wordlist.aspell.net/dicts/
> thanks
> 
> Hi,
> 
> On Wed, Aug 12, 2015 at 09:32:27AM +0700, Ekanan Ketunuti wrote:
> >Yes, there is.
> >[3]http://wordlist.aspell.net/dicts/
> 
> Maybe, but this is not in the official hunspell sf project.
> 
> > The upstream version of hunspell is 2015.05.18.
> 
> That is wrong. The upstream version of hunspell is 1.3.3.
> 
> The dictionary is something else than the actual engine.
> 
> > So, the dic is outdated. please reopen this.
> 
> I see that Mike Hommey just did, though I still don't buy why we immediately
> need to update something which works and just doesn't have some words. Or
> is there some serious problem here I don't see?
> 
> Especially since as I said the version on sf.net/projects/hunspell _IS_ what
> we have in the arhive. Yes, that might be old, but "outdated" is something
> different.

Come on, it's 7~8 years old and hasn't received updates, that can be
declared dead upstream.

Mike

Bug#795794: jessie-pu: package nss/3.17.2-1.1+deb8u1

[Christoph Egger]

"Adam D. Barratt"  writes:
> On Mon, 2015-08-17 at 16:19 +0100, Adam D. Barratt wrote:
>> Control: tags -1 + confirmed
>> 
>> On Sun, 2015-08-16 at 22:51 +0200, Christoph Egger wrote:
>> > This is a small patch from mozilla hg. It fixes #774195 and is
>> > confirmed to work. Would be cool if if can be included in the next
>> > stable release.
>> 
>> Please go ahead.
>
> This now needs rebasing on top of the 3.17.2-1.1+deb8u1 upload from DSA
> 3336, as 3.17.2-1.1+deb8u2.

Done and uploaded!

  Christoph


signature.asc
Description: PGP signature

Bug#795945: projectl: please make the build reproducible

[Reiner Herrmann]

Source: projectl
Version: 1.001.dfsg1-7
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that projectl could not be built reproducibly.
A file list is sorted with "sort", which behaves differently depending on the 
locale.

The attached patch fixes this by sorting with LC_ALL set to C.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds

diff --git a/debian/patches/makefile.patch b/debian/patches/makefile.patch
index 789a4c4..1d9cb0f 100644
--- a/debian/patches/makefile.patch
+++ b/debian/patches/makefile.patch
@@ -6,7 +6,7 @@
 +++ b/Makefile
 @@ -0,0 +1,11 @@
 +GDC=gdc
-+DSRC=$(shell find import src -name "*.d" -not -iname '*mpeg*' | sort)
++DSRC=$(shell find import src -name "*.d" -not -iname '*mpeg*' | LC_ALL=C sort)
 +EXE=projectl
 +
 +all: $(EXE)


signature.asc
Description: OpenPGP digital signature

Bug#795946: ITP: android-platform-frameworks-compile -- Android compiler frameworks

[殷啟聰]

Package: wnpp
Severity: wishlist
Owner: android-tools-de...@lists.alioth.debian.org

* Package Name: android-platform-frameworks-compile
  Version: 5.1.1+r8
  Upstream Author: Android Open Source Project
* URL: https://android.googlesource.com/platform/frameworks/compile/libbcc
* License: Apache 2.0
  Programming Lang: C++
  Description: Android compiler frameworks

This package is currently a combination of
platform/frameworks/compile/libbcc, platform/frameworks/compile/slang
and some portions of platform/frameworks/rs. This package produces
compiler frameworks for Android like libbcc, bcc_compat and llvm-rs-cc
which are part of Android SDK Build-tools.

Bug#795159: hunspell-en-us dictionary is outdated

[Ake K.]

AFAIK, The real SF's upstream hunspell en-US dictionary is
http://sourceforge.net/projects/wordlist/files/Hunspell/

CCing Kevin Atkinson,  Upstream Maintainer on en_US Hunspell dictionary for
confirm.


On Tue, Aug 18, 2015 at 4:05 PM, Mike Hommey  wrote:

> On Tue, Aug 18, 2015 at 10:21:07AM +0200, Rene Engelhard wrote:
> > retitle 795159 please update with version from
> http://wordlist.aspell.net/dicts/
> > thanks
> >
> > Hi,
> >
> > On Wed, Aug 12, 2015 at 09:32:27AM +0700, Ekanan Ketunuti wrote:
> > >Yes, there is.
> > >[3]http://wordlist.aspell.net/dicts/
> >
> > Maybe, but this is not in the official hunspell sf project.
> >
> > > The upstream version of hunspell is 2015.05.18.
> >
> > That is wrong. The upstream version of hunspell is 1.3.3.
> >
> > The dictionary is something else than the actual engine.
> >
> > > So, the dic is outdated. please reopen this.
> >
> > I see that Mike Hommey just did, though I still don't buy why we
> immediately
> > need to update something which works and just doesn't have some words. Or
> > is there some serious problem here I don't see?
> >
> > Especially since as I said the version on sf.net/projects/hunspell _IS_
> what
> > we have in the arhive. Yes, that might be old, but "outdated" is
> something
> > different.
>
> Come on, it's 7~8 years old and hasn't received updates, that can be
> declared dead upstream.
>
> Mike
>

Bug#795947: jessie-pu: package mesa/10.3.2-1+deb8u1

[Julien Cristau]

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

Hi,

we've had a patch for #775264 sitting in git since January.  This should
go in jessie.  Diff below, imagine its version is fixed and
s/UNRELEASED/jessie/.

Cheers,
Julien

diff --git a/debian/changelog b/debian/changelog
index 4828bbb..df3f044 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+mesa (10.3.2-2) UNRELEASED; urgency=medium
+
+  * radeonsi-disable-asynchronous-dma.diff: Disable asynchronous DMA
+on radeonsi which can cause lockups. (Closes: #775264)
+
+ -- Timo Aaltonen   Wed, 14 Jan 2015 16:40:19 +0200
+
 mesa (10.3.2-1) unstable; urgency=medium
 
   [ Sven Joachim ]
diff --git a/debian/patches/radeonsi-disable-asynchronous-dma.diff 
b/debian/patches/radeonsi-disable-asynchronous-dma.diff
new file mode 100644
index 000..1e94814
--- /dev/null
+++ b/debian/patches/radeonsi-disable-asynchronous-dma.diff
@@ -0,0 +1,45 @@
+commit ae4536b4f71cbe76230ea7edc7eb4d6041e651b4
+Author: Michel Dänzer 
+Date:   Tue Nov 11 16:10:20 2014 +0900
+
+radeonsi: Disable asynchronous DMA except for PIPE_BUFFER
+
+Using the asynchronous DMA engine for multi-dimensional operations seems
+to cause random GPU lockups for various people. While the root cause for
+this might need to be fixed in the kernel, let's disable it for now.
+
+Before re-enabling this, please make sure you can hit all newly enabled
+paths in your testing, preferably with both piglit and real world apps,
+and get in touch with people on the bug reports below for stability
+testing.
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85647
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83500
+Cc: "10.3 10.4" 
+Reviewed-by: Marek Olšák 
+Reviewed-by: Grigori Goronzy 
+
+--- a/src/gallium/drivers/radeonsi/si_dma.c
 b/src/gallium/drivers/radeonsi/si_dma.c
+@@ -270,6 +270,21 @@ void si_dma_copy(struct pipe_context *ct
+   return;
+   }
+ 
++  /* XXX: Using the asynchronous DMA engine for multi-dimensional
++   * operations seems to cause random GPU lockups for various people.
++   * While the root cause for this might need to be fixed in the kernel,
++   * let's disable it for now.
++   *
++   * Before re-enabling this, please make sure you can hit all newly
++   * enabled paths in your testing, preferably with both piglit and real
++   * world apps, and get in touch with people on the bug reports below
++   * for stability testing.
++   *
++   * https://bugs.freedesktop.org/show_bug.cgi?id=85647
++   * https://bugs.freedesktop.org/show_bug.cgi?id=83500
++   */
++  goto fallback;
++
+   if (src->format != dst->format || src_box->depth > 1 ||
+   rdst->dirty_level_mask != 0) {
+   goto fallback;
diff --git a/debian/patches/series b/debian/patches/series
index 9f0749f..d37557a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 07_gallium-fix-build-failure-on-powerpcspe.diff
+radeonsi-disable-asynchronous-dma.diff


signature.asc
Description: Digital signature

Bug#795948: minidlna: Minidlna is not able to create pid-file when run as user minidlna

[Jakobus Schürz]

Package: minidlna
Version: 1.1.4+dfsg-4~bpo8+1
Severity: normal

Dear Maintainer,

# systemctl status minidlna.service 
● minidlna.service - Mediaserver minidlna
   Loaded: loaded (/etc/systemd/system/minidlna.service; enabled)
  Active: active (running) since Mon 2015-08-17 21:36:43 CEST; 13h
  ago
   Main PID: 537 (minidlnad)
  CGroup: /system.slice/minidlna.service
 └─537 /usr/sbin/minidlnad -S -f /etc/minidlna.conf

 Aug 17 21:36:51 aldebaran minidlnad[537]:
 utils.c:277: warn: make_dir: cannot create
 directory '/run/minidlna'
 Aug 17 21:36:51 aldebaran minidlnad[537]:
 minidlna.c:434: error: Unable to create pidfile
 directory: /run/minidlna/minidlna.pid


My systemd-unit to start minidlna is:

# systemctl cat minidlna.service 
# /etc/systemd/system/minidlna.service
[Unit]
Description=Mediaserver minidlna 
After=network-online.target
ConditionPathExists=/etc/minidlna.conf

[Service]
User=minidlna
ExecStart=/usr/sbin/minidlnad -S -f /etc/minidlna.conf

[Install]
WantedBy=network-online.target



*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

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

Versions of packages minidlna depends on:
ii  adduser  3.113+nmu3
ii  initscripts  2.88dsf-59
ii  libavformat5610:2.6.4-dmo1
ii  libavutil54  10:2.6.4-dmo1
ii  libc62.19-18
ii  libexif120.6.21-2
ii  libflac8 1.3.0-3
ii  libid3tag0   0.15.1b-11
ii  libjpeg62-turbo  1:1.3.1-12
ii  libogg0  1.3.2-1
ii  libsqlite3-0 3.8.7.1-1+deb8u1
ii  libvorbis0a  1.3.4-2
ii  lsb-base 4.1+Debian13+nmu1

minidlna recommends no packages.

minidlna suggests no packages.

-- Configuration Files:
/etc/minidlna.conf changed:
media_dir=/home/Media
port=8200
serial=681019810597110
inotify=yes
album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg
album_art_names=AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg
album_art_names=Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg


-- no debconf information

Bug#791190: nmu diff for log4cplus 1.0.4-1.3

[Andrew Pollock]

On Mon, Aug 17, 2015 at 09:04:36PM +0200, Julien Cristau wrote:
> Dear maintainer,
> 
> I've prepared a NMU for log4cplus, to deal with the libstdc++ transition,
> and will shortly upload it to the 1-day delayed queue.  Please find the
> debdiff below.

So I've just uploaded 1.1.2 to experimental and plan on asking for a
transition slot. That would make this redundant, right?
 
> Cheers,
> Julien
> 
> From abe047c9096df4dcfcff888a5abdda8ffba994c5 Mon Sep 17 00:00:00 2001
> From: Julien Cristau 
> Date: Sun, 16 Aug 2015 17:45:42 +0200
> Subject: [PATCH] Rename library packages for g++5 ABI transition (closes:
>  791190).
> 
> ---
>  debian/changelog|  7 +++
>  debian/control  | 12 +++-
>  debian/liblog4cplus-1.0-4.install   |  1 -
>  debian/liblog4cplus-1.0-4v5.install |  1 +
>  4 files changed, 15 insertions(+), 6 deletions(-)
>  delete mode 100644 debian/liblog4cplus-1.0-4.install
>  create mode 100644 debian/liblog4cplus-1.0-4v5.install
> 
> diff --git a/debian/changelog b/debian/changelog
> index 586d070..46b1b89 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,10 @@
> +log4cplus (1.0.4-1.3) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename library packages for g++5 ABI transition (closes: 791190).
> +
> + -- Julien Cristau   Sun, 16 Aug 2015 17:45:42 +0200
> +
>  log4cplus (1.0.4-1.2) unstable; urgency=medium
>  
>* Non-maintainer upload.
> diff --git a/debian/control b/debian/control
> index b218fc4..b064b4f 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -12,9 +12,11 @@ Homepage: http://log4cplus.sourceforge.net
>  Vcs-Browser: http://git.debian.org/?p=collab-maint/log4cplus.git;a=summary
>  Vcs-Git: git://git.debian.org/collab-maint/log4cplus.git
>  
> -Package: liblog4cplus-1.0-4
> +Package: liblog4cplus-1.0-4v5
>  Architecture: any
>  Depends: ${shlibs:Depends}, ${misc:Depends}
> +Conflicts: liblog4cplus-1.0-4
> +Replaces: liblog4cplus-1.0-4
>  Description: C++ logging API modeled after the Java log4j API - shared 
> library
>   log4cplus is a simple to use C++ logging API providing thread-safe,
>   flexible, and arbitrarily granular control over log management and
> @@ -23,9 +25,9 @@ Description: C++ logging API modeled after the Java log4j 
> API - shared library
>  Package: liblog4cplus-dev
>  Architecture: any
>  Section: libdevel
> -Depends: liblog4cplus-1.0-4 (= ${binary:Version}), ${misc:Depends}
> -Breaks: liblog4cplus-1.0-4 (<< 1.0.4-1.1~)
> -Replaces: liblog4cplus-1.0-4 (<< 1.0.4-1.1~)
> +Depends: liblog4cplus-1.0-4v5 (= ${binary:Version}), ${misc:Depends}
> +Breaks: liblog4cplus-1.0-4v5 (<< 1.0.4-1.1~)
> +Replaces: liblog4cplus-1.0-4v5 (<< 1.0.4-1.1~)
>  Description: C++ logging API modeled after the Java log4j API - development 
> library
>   log4cplus is a simple to use C++ logging API providing thread-safe,
>   flexible, and arbitrarily granular control over log management and
> @@ -38,7 +40,7 @@ Package: liblog4cplus-dbg
>  Section: debug
>  Priority: extra
>  Architecture: any
> -Depends: ${misc:Depends}, liblog4cplus-1.0-4 (= ${binary:Version})
> +Depends: ${misc:Depends}, liblog4cplus-1.0-4v5 (= ${binary:Version})
>  Description: C++ logging API modeled after the Java log4j API - debug library
>   log4cplus is a simple to use C++ logging API providing thread-safe,
>   flexible, and arbitrarily granular control over log management and
> diff --git a/debian/liblog4cplus-1.0-4.install 
> b/debian/liblog4cplus-1.0-4.install
> deleted file mode 100644
> index fc08b1c..000
> --- a/debian/liblog4cplus-1.0-4.install
> +++ /dev/null
> @@ -1 +0,0 @@
> -usr/lib/liblog4cplus-1.0.so.*
> diff --git a/debian/liblog4cplus-1.0-4v5.install 
> b/debian/liblog4cplus-1.0-4v5.install
> new file mode 100644
> index 000..fc08b1c
> --- /dev/null
> +++ b/debian/liblog4cplus-1.0-4v5.install
> @@ -0,0 +1 @@
> +usr/lib/liblog4cplus-1.0.so.*
> -- 
> 2.5.0
> 


signature.asc
Description: Digital signature

Bug#795863: [Pkg-fglrx-devel] Bug#795863: fglrx-driver: fglrx ASIC lockup: HID devices unusable

[Patrick Matthäi]

severity #795863 normal
tag #795863 + upstream
thanks

Am 17.08.2015 um 16:26 schrieb Tom Noonan:

Package: fglrx-driver
Version: 1:14.9+ga14.201-2
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

Running the fglrx driver against a Advanced Micro Devices, Inc. [AMD/ATI] 
Bonaire [FirePro W5100] ASIC lockups have been seen on multiple occasions.
This is usually seen when the terminal is idle with the monitors in power save 
mode.
XScreenSaver is in use to lock the terminals however all screensavers are 
disabled (screen blanking only) to try and eliminate GL issues.


Both could be deactivated, so it is not a RC bug.

Anyway fglrx is closed source so we just can ask you: Is this issue 
fixed in 15.7-1 from stretch/sid?


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#795949: The sysconfig source package has a GnuPG digital signature which is not included in debian-keyring

[Stephen Powell]

Package: sysconfig
Version: 0.0.10+nmu1
Severity: minor

The sysconfig source package has a GnuPG digital signature which is not
included in the debian-keyring binary package  Unpacking the source
package with dpkg-source produces the following messages:

gpgv: Signature made Sat 29 Oct 2011 08:24:56 AM EDT using DSA key ID B2CFCDD8
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./sysconfig-0.0.10+nmu1.dsc

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Bug#795644: git-annex: configure eats all memory

[Joachim Breitner]

Hi,

Am Montag, den 17.08.2015, 14:42 -0400 schrieb Joey Hess:
> Joachim Breitner wrote:
> > If we can isolate the problem nicely, I’ll be happy to discuss this
> > with upstream.
> 
> deboostrap sid
> 
> in chroot:
> 
> mount -t proc proc /proc
> apt-get -y install ghc libghc-ifelse-dev libghc-missingh-dev libghc
> -unix-compat-dev libghc-data-default-dev libghc-exceptions-dev libghc
> -http-types-dev libghc-bloomfilter-dev libghc-old-locale-dev libghc
> -resourcet-dev libghc-monad-control-dev libghc-edit-distance-dev 
> libghc-sandi-dev libghc-json-dev libghc-utf8-string-dev libghc
> -hslogger-dev libghc-monad-logger-dev libghc-http-conduit-dev libghc
> -safesemaphore-dev libghc-uuid-dev libghc-quickcheck2-dev libghc
> -optparse-applicative-dev libghc-cabal-dev git cabal-install
> git clone git://git-annex.branchable.com/ git-annex
> cd git-annex
> ghc --make Setup
> cabal configure # succeeds
> ./Setup configure # OOM

thanks. I extracted a stand-alone test case for upstream:
https://github.com/haskell/cabal/issues/2777

Let’s see if it can make a difference.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Bug#795950: twig: Non-determistically FTBFS due to unreliable timing in tests

[Chris Lamb]

Source: twig
Version: 1.18.1-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,

twig's testsuite appears to use method timing/benchmarking in such
a way that it will non-deterministically FTBFS:

  [..]
  2) Twig_Tests_Profiler_Dumper_TextTest::testDump
  Failed asserting that format description matches text.
  --- Expected
  +++ Actual
  @@ @@
 └ index.twig::macro(foo)
  -  └ embedded.twig
  +  └ embedded.twig 6.90ms/46%
   └ included.twig
  
  /tmp/buildd/twig-1.18.1/test/Twig/Tests/Profiler/Dumper/TextTest.php:28
  
  FAILURES!
  Tests: 1115, Assertions: 2943, Failures: 2.
  debian/rules:45: recipe for target 'override_dh_auto_test-indep'
  failed
  make[1]: *** [override_dh_auto_test-indep] Error 1
  make[1]: Leaving directory '/tmp/buildd/twig-1.18.1'
  debian/rules:7: recipe for target 'build' failed
  make: *** [build] Error 2
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

  [..]

This is caused by conditionally emitting a different output if, for
example, a method appears to have run "slowly", which is
non-determinstic:

  lib/Twig/Profiler/Dumper/Text.php:

if ($profile->getDuration() * 1000 < 1) {
$str = $start."\n";
} else {
$str = sprintf("%s %s\n", $start,
$this->formatTime($profile, $percent));
}

  lib/Twig/Profiler/Dumper/Html.php:

return sprintf('%.2fms/%.0f%%',
$percent > 20 ? self::$colors['big'] : 'auto',
$profile->getDuration() * 1000, $percent);

(etc.)

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

  
https://reproducible.debian.net/logs/unstable/amd64/twig_1.18.1-1.build2.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: samedi 25 juillet 2015, 11:19:10 (UTC+1400)
I: pbuilder-time-stamp: 1437772750
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
I: user script 
/var/cache/pbuilder/build//45639/tmp/hooks/D01_modify_environment starting
I: Changing hostname to test build reproducibility
I: user script 
/var/cache/pbuilder/build//45639/tmp/hooks/D01_modify_environment finished
 -> 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 (>= 9), dh-php5, php5-dev, phpab, phpunit, pkg-php-tools (>= 
1.7~), python-sphinx, re2c
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 20236 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 dh-php5; however:
  Package dh-php5 is not installed.
 pbuilder-satisfydepends-dummy depends on php5-dev; however:
  Package php5-dev is not installed.
 pbuilder-satisfydepends-dummy depends on phpab; however:
  Package phpab is not installed.
 pbuilder-satisfydepends-dummy depends on phpunit; however:
  Package phpunit is not installed.
 pbuilder-satisfydepends-dummy depends on pkg-php-tools (>= 1.7~); however:
  Package pkg-php-tools is not installed.
 pbuilder-satisfydepends-dummy depends on python-sphinx; however:
  Package python-sphinx is not installed.
 pbuilder-satisfydepends-dummy depends on re2c; however:
  Package re2c 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:
  autoconf{a} automake{a} autotools-dev{a} dh-php5{a} docutils-common{a} 
  libbsd0{a} libedit2{a} libexpat1{a} libgssapi-krb5-2{a} 
  libjs-bootstrap{a} libjs-jquery{a} libjs-sphinxdoc{a} 
  libjs-twitter-bootstrap{a} libjs-underscore{a} libjson-c2{a} 
  libk5crypto3{a} libkeyutils1{

Bug#753669: seems there is no movement on the qemu side.

[shirish शिरीष]

Hi all,
There doesn't seem to be any movement on the qemu front.

@Martin Berends any updates ?

It perhaps would be better to move/fork the project to alioth and have
a git repo. and maintain it there in case if you really want to do it.
-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#792231: electrum

[Thomas Voegtlin]

Please note that the tlslite the dependency has been removed from
Electrum since version 2.4.1.

The only part of tlslite that was used in Electrum was the RSA
implementation; it is now added to the electrum lib.

Thomas

Bug#787649: xul-ext-exteditor

[W. Martin Borgert]

retitle 787649 ITP: xul-ext-exteditor -- edit Icedove messages in an external 
editor
thanks

Download from:
http://globs.org/file/exteditor_v100.xpi
(contains complete source)

Packaging at:
git.debian.org/collab-maint/xul-ext-exteditor.git

Bug#744170: wget: Read error in TLS connection with openssl s_server -www server

[Noël Köthe]

tags 744170 + moreinfo
thanks

Hello Vincent,

Am Freitag, den 11.04.2014, 03:35 +0200 schrieb Vincent Lefevre:
> Package: wget
> Version: 1.15-1
> Severity: normal
> 
> What I set up a test server with:
> 
>   openssl s_server -CAfile ... -key ... -cert ... -www
> 
> and try wget with it, I get errors:
> 
> --2014-04-11 03:30:47--  https://www.vinc17.net:4433/
> Resolving www.vinc17.net (www.vinc17.net)... 92.243.22.117, 
> 2001:4b98:dc0:45:216:3eff:fe9b:eb2f
> Connecting to www.vinc17.net (www.vinc17.net)|92.243.22.117|:4433... 
> connected.
> HTTP request sent, awaiting response... 200 ok
> Length: unspecified [text/html]
> Saving to: ‘index.html.2’
> 
> [ <=>   ] 5,494   --.-K/s  
>  in 0s  
> 
> 2014-04-11 03:30:47 (45.7 MB/s) - Read error at byte 5494 (The TLS 
> connection was non-properly terminated.).Retrying.
...

wget 1.16 fixed a lot of gnutls problems. Could you still reproduce
this problem with 1.16 in jessie or the later version in
testing/unstable?

thx.

Regards

Noël

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

Bug#795951: ITP: libpoe-filter-ssl-perl -- module to make SSL in POE easy and flexible

[Lucas Kanashiroo]

package: wnpp
Severity: wishlist
Owner: 'Lucas Kanashiro' 
X-Debbugs-CC: debian-p...@lists.debian.org

* Package Name : libpoe-filter-ssl-perl
  Version  : 0.27
  Upstream Author  : Markus Schräder 
* URL  : https://metacpan.org/release/POE-Filter-SSL
* License  : The Perl 5 License (Artistic 1 or GPL-1+)
  Programming Lang : Perl
  Description  : module to make SSL in POE easy and flexible

POE::Filter::SSL allows one to secure connections of POE::Wheel::ReadWrite with
OpenSSL by a POE::Filter object, and behaves (beside of SSLing) as
POE::Filter::Stream.

POE::Filter::SSL can be added, switched and removed during runtime, for example
if you want to initiate SSL (see the SSL on an established connection example
in SYNOPSIS) on an already established connection. You are able to combine
POE::Filter::SSL with other filters, for example have a HTTPS server together
with POE::Filter::HTTPD.

POE::Filter::SSL is based on Net::SSLeay, but got two XS functions which
Net::SSLeay is missing.

The package will be maintained under the umbrella of the Debian Perl Group.
-- 
Lucas Kanashiro
PGP-Key ID: RSA4096R/9883C97C
PGP fingerprint: 8ED6 C3F8 BAC9 DB7F C130  A870 F823 A272 9883 C97C


signature.asc
Description: Digital signature

Bug#791154: transition: libpcre++ (libpcre++0v5)

[Simon McVittie]

reassign 791154 release.debian.org
retitle 791154 transition: libpcre++ (libpcre++0v5)
severity 791154 normal
user release.debian@packages.debian.org
usertags 791154 + transition
thanks

On Mon, 10 Aug 2015 at 21:38:52 +0200, Julien Cristau wrote:
> libpcre++ exports a number of symbols involving std::string, so
> libpcre++0 needs to be renamed.

I have uploaded a NMU to DELAYED/2 with the attached diff.
Please let me know if I should reschedule or cancel it.

S
diffstat for libpcre++-0.9.5 libpcre++-0.9.5

 changelog|9 +
 control  |6 --
 libpcre++0.install   |1 -
 libpcre++0v5.install |1 +
 4 files changed, 14 insertions(+), 3 deletions(-)

diff -Nru libpcre++-0.9.5/debian/changelog libpcre++-0.9.5/debian/changelog
--- libpcre++-0.9.5/debian/changelog	2013-07-09 01:51:13.0 +0100
+++ libpcre++-0.9.5/debian/changelog	2015-08-18 10:02:57.0 +0100
@@ -1,3 +1,12 @@
+libpcre++ (0.9.5-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename library packages for g++5 ABI transition, based on
+changes made in Ubuntu by Steve Langasek.
+(Starts transition: #791154)
+
+ -- Simon McVittie   Tue, 18 Aug 2015 10:02:48 +0100
+
 libpcre++ (0.9.5-6) unstable; urgency=low
 
   * Incorporate NMU.
diff -Nru libpcre++-0.9.5/debian/control libpcre++-0.9.5/debian/control
--- libpcre++-0.9.5/debian/control	2013-07-09 01:20:15.0 +0100
+++ libpcre++-0.9.5/debian/control	2015-08-18 10:02:57.0 +0100
@@ -9,7 +9,7 @@
 Package: libpcre++-dev
 Section: libdevel
 Architecture: any
-Depends: ${misc:Depends}, libpcre++0 (= ${binary:Version}), libpcre3-dev
+Depends: ${misc:Depends}, libpcre++0v5 (= ${binary:Version}), libpcre3-dev
 Description: C++ wrapper class for pcre (development)
  PCRE++ is a C++ wrapper-class for the library PCRE (Perl Compatible
  Regular Expressions).
@@ -19,12 +19,14 @@
  into parts using expressions or to search and replace a part of a
  string with another part.
 
-Package: libpcre++0
+Package: libpcre++0v5
 Section: libs
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
+Conflicts: libpcre++0
+Replaces: libpcre++0
 Description: C++ wrapper class for pcre (runtime)
  PCRE++ is a C++ wrapper-class for the library PCRE (Perl Compatible
  Regular Expressions).
diff -Nru libpcre++-0.9.5/debian/libpcre++0.install libpcre++-0.9.5/debian/libpcre++0.install
--- libpcre++-0.9.5/debian/libpcre++0.install	2013-07-09 00:59:05.0 +0100
+++ libpcre++-0.9.5/debian/libpcre++0.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-/usr/lib/*/lib*.so.*
diff -Nru libpcre++-0.9.5/debian/libpcre++0v5.install libpcre++-0.9.5/debian/libpcre++0v5.install
--- libpcre++-0.9.5/debian/libpcre++0v5.install	1970-01-01 01:00:00.0 +0100
+++ libpcre++-0.9.5/debian/libpcre++0v5.install	2015-08-18 10:02:57.0 +0100
@@ -0,0 +1 @@
+/usr/lib/*/lib*.so.*

Bug#795952: base-files postinst error causes debootstrap to exit

[Steven Shiau]

Package: base-files
Version: 9.3
Severity: important

Dear Maintainer,

With the latest base-files, debootstrap won't be able to create a Sid
bootstrap system.
This is due to the postinst error, as shown in the bootstrap log:
Setting up base-files (9.3) ...
cp: cannot stat '/usr/share/base-files//usr/share/base-files/info.dir':
No such file or directory
dpkg: error processing package base-files (--install):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 base-files

The command I used to create a bootstrap system is:
debootstrap --verbose --arch=i386 sid sid-chroot
http://free.nchc.org.tw/debian
Attached please find the log when running debootstrap. If you need more
info, please let me know.
Thanks.

Steven.
-- 
Steven Shiau 
Public Key Server PGP Key ID: 4096R/47CF935C
Fingerprint: 0240 1FEB 695D 7112 62F0  8796 11C1 12DA 47CF 935C
steven@sid-amd64:~/tmp$ sudo debootstrap --verbose --arch=i386 sid sid-chroot 
http://free.nchc.org.tw/debian
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010)
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional required dependencies: adduser dmsetup insserv libapparmor1 
libaudit-common libaudit1 libbz2-1.0 libcap2 libcap2-bin libcryptsetup4 
libdb5.3 libdebconfclient0 libdevmapper1.02.1 libgcrypt20 libgpg-error0 
libkmod2 libncursesw5 libprocps4 libseccomp2 libsemanage-common libsemanage1 
libsystemd0 libudev1 libustr-1.0-1 procps systemd systemd-sysv udev
I: Found additional base dependencies: libdns-export100 libffi6 libgmp10 
libgnutls-deb0-28 libgnutls-openssl27 libhogweed4 libicu55 libidn11 
libirs-export91 libisc-export95 libisccfg-export90 libnettle6 libnfnetlink0 
libp11-kit0 libpsl0 libtasn1-6
I: Checking component main on http://free.nchc.org.tw/debian...
I: Retrieving libacl1 2.2.52-2
I: Validating libacl1 2.2.52-2
I: Retrieving adduser 3.113+nmu3
I: Validating adduser 3.113+nmu3
I: Retrieving libapparmor1 2.9.2-3
I: Validating libapparmor1 2.9.2-3
I: Retrieving apt 1.0.10.1
I: Validating apt 1.0.10.1
I: Retrieving apt-utils 1.0.10.1
I: Validating apt-utils 1.0.10.1
I: Retrieving libapt-inst1.5 1.0.9.10
I: Validating libapt-inst1.5 1.0.9.10
I: Retrieving libapt-inst1.7 1.0.10.1
I: Validating libapt-inst1.7 1.0.10.1
I: Retrieving libapt-pkg4.12 1.0.9.10
I: Validating libapt-pkg4.12 1.0.9.10
I: Retrieving libapt-pkg4.16 1.0.10.1
I: Validating libapt-pkg4.16 1.0.10.1
I: Retrieving libattr1 1:2.4.47-2
I: Validating libattr1 1:2.4.47-2
I: Retrieving libaudit-common 1:2.4.2-1
I: Validating libaudit-common 1:2.4.2-1
I: Retrieving libaudit1 1:2.4.2-1
I: Validating libaudit1 1:2.4.2-1
I: Retrieving base-files 9.3
I: Validating base-files 9.3
I: Retrieving base-passwd 3.5.38
I: Validating base-passwd 3.5.38
I: Retrieving bash 4.3-13
I: Validating bash 4.3-13
I: Retrieving libdns-export100 1:9.9.5.dfsg-11
I: Validating libdns-export100 1:9.9.5.dfsg-11
I: Retrieving libirs-export91 1:9.9.5.dfsg-11
I: Validating libirs-export91 1:9.9.5.dfsg-11
I: Retrieving libisc-export95 1:9.9.5.dfsg-11
I: Validating libisc-export95 1:9.9.5.dfsg-11
I: Retrieving libisccfg-export90 1:9.9.5.dfsg-11
I: Validating libisccfg-export90 1:9.9.5.dfsg-11
I: Retrieving libboost-iostreams1.54.0 1.54.0+dfsg-7
I: Validating libboost-iostreams1.54.0 1.54.0+dfsg-7
I: Retrieving libboost-iostreams1.55.0 1.55.0+dfsg-4
I: Validating libboost-iostreams1.55.0 1.55.0+dfsg-4
I: Retrieving libboost-iostreams1.58.0 1.58.0+dfsg-3
I: Validating libboost-iostreams1.58.0 1.58.0+dfsg-3
I: Retrieving bsdmainutils 9.0.6
I: Validating bsdmainutils 9.0.6
I: Retrieving libbz2-1.0 1.0.6-8
I: Validating libbz2-1.0 1.0.6-8
I: Retrieving libdebconfclient0 0.195
I: Validating libdebconfclient0 0.195
I: Retrieving coreutils 8.23-4
I: Validating coreutils 8.23-4
I: Retrieving cpio 2.11+dfsg-4.1
I: Validating cpio 2.11+dfsg-4.1
I: Retrieving cron 3.0pl1-128
I: Validating cron 3.0pl1-128
I: Retrieving libcryptsetup4 2:1.6.6-5
I: Validating libcryptsetup4 2:1.6.6-5
I: Retrieving dash 0.5.7-4+b1
I: Validating dash 0.5.7-4+b1
I: Retrieving libdb5.3 5.3.28-9+b1
I: Validating libdb5.3 5.3.28-9+b1
I: Retrieving debconf 1.5.57
I: Validating debconf 1.5.57
I: Retrieving debconf-i18n 1.5.57
I: Validating debconf-i18n 1.5.57
I: Retrieving debian-archive-keyring 2014.3
I: Validating debian-archive-keyring 2014.3
I: Retrieving debianutils 4.5.1
I: Validating debianutils 4.5.1
I: Retrieving diffutils 1:3.3-1+b1
I: Validating diffutils 1:3.3-1+b1
I: Retrieving dmidecode 2.12-4
I: Validating dmidecode 2.12-4
I: Retrieving dpkg 1.18.2
I: Validating dpkg 1.18.2
I: Retrieving e2fslibs 1.42.13-1
I: Validating e2fslibs 1.42.13-1
I: Retrieving e2fsprogs 1.42.13-1
I: Validating e2fsprogs 1.42.13-1
I: Retrieving libcomerr2 1.42.13-1
I: Validating libcomerr2 1.42.13-1
I: Retriev

Bug#795953: vim-syntastic: compile.py not found in /var/lib/addons/syntax_checkers/python

[Ben Reedy]

Package: vim-syntastic
Version: 3.5.0-1
Severity: normal

Hello,

* What led up to the situation?
- Editing any python script and checking with syntastic,
either manually with :SyntasticCheck or by saving the file.

* What outcome did you expect instead?
- Expected syntastic python checker to check python file as per normal

* What exactly did you do (or not do) that was effective (or
ineffective)?
- Symlinking /usr/share/vim/addons/syntax_checkers/python/compile.py to
/var/lib/vim/addons/syntax_checkers/python/compile.py resolved the
issue.

I'm not exactly sure how this is packaged, but would adding the line
'syntax_checkers/python/compile.py' to debian/vim-syntastic.yaml add
the necessary symlink?

Regards,
Ben Reedy


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

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

Versions of packages vim-syntastic depends on:
ii  vim2:7.4.488-7
ii  vim-addon-manager  0.5.3
ii  vim-gtk [vim]  2:7.4.488-7

vim-syntastic recommends no packages.

Versions of packages vim-syntastic suggests:
pn  checkstyle   
pn  chktex   
pn  closure-linter   
pn  cppcheck 
pn  foodcritic   
pn  hlint
pn  lacheck  
pn  libperl-critic-perl  
ii  libxml2-utils2.9.1+dfsg1-5
pn  pep8 
pn  puppet-lint  
ii  pyflakes 0.8.1-1
pn  pylint   
pn  python-flake8
pn  sparse   
pn  splint   
pn  tidy 

-- no debconf information

Bug#795159: hunspell-en-us dictionary is outdated

[Rene Engelhard]

On Tue, Aug 18, 2015 at 06:05:22PM +0900, Mike Hommey wrote:
> Come on, it's 7~8 years old and hasn't received updates, that can be
> declared dead upstream.

I didn't deny that. :)

Regards,

Rene

Bug#795159: hunspell-en-us dictionary is outdated

[Rene Engelhard]

retitle 795159 please update to uptodate SCOWL versions
thanks

Hi,

On Tue, Aug 18, 2015 at 04:21:34PM +0700, Ake K. wrote:
>AFAIK, The real SF's upstream hunspell en-US dictionary is
>[1]http://sourceforge.net/projects/wordlist/files/Hunspell/
> 
>CCing Kevin Atkinson,  Upstream Maintainer on en_US Hunspell dictionary
>for confirm.

If so, we should just remove the hunspell-en-* (source) packages then and
package the non-large(!) variants out of scowl itself by using the same script
used to create what you can download on that sf download page.

Cc'ing the scowl maintainer. If you agree I can send you a patch doing
this and/or do it myself as (prospective) co-maintainer...

Regards,

Rene

Bug#660932: [bug #45791] Double quote in (some) wget's international output for downloaded filename

[NoëlKöthe]

URL:
  

 Summary: Double quote in (some) wget's international output
for downloaded filename
 Project: GNU Wget
Submitted by: nok
Submitted on: Di 18 Aug 2015 12:00:06 CEST
Category: Localization
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
Operating System: None
 Reproducibility: None
   Fixed Release: None
 Planned Release: None
  Regression: None
   Work Required: None
  Patch Included: None

___

Details:

Hello,

some translators (de and ru known) add additional quotes which results in
double quotes like this:

...
2015-08-18 11:54:02 (459 KB/s) - »»index.html«« gespeichert [14710/14710]

This is known since some time and Tim already informed the translators but
without success.:(

https://bugs.debian.org/660932

thx.

Regards

Noël




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/

Bug#795404: cups-backend-bjnp: stops printing after some lines

[Brian Potkin]

On Mon 17 Aug 2015 at 22:51:08 +0200, Björn Siebke wrote:

> thank you once again for trying to get that printer working!

Thank you in anticipation of some more testing from from you, Björn.
> 
> > We can test if this behaviour is independent of CUPS and the filtering
> > system too,
> > 
> >   DEVICE_URI=bjnp://db-printer.fritz.box:8611 /usr/lib/cups/backend/bjnp 1 
> > 1 1 1 1 /etc/services
> 
> I tried this both with and without sudo:
> 
> $ sudo DEVICE_URI=bjnp://db-printer.fritz.box:8611
> /usr/lib/cups/backend/bjnp 1 1 1 1 1 /etc/services
> [sudo] password for bjoern:
> INFO: Attempting to connect to host db-printer.fritz.box on port 8611
> STATE: +connecting-to-device
> STATE: -connecting-to-device
> INFO: Connected to db-printer.fritz.box...
> DEBUG: Connected to [192.168.178.27]:8611 (IPv4)...

The printer is found; UDP broadcasts are used, I think. It doesn't look
like you have a network problem.

> PAGE: 1 1
> DEBUG: bjnp_backendRunLoop(print_fd=4, device_fd=5
> INFO: Sent print file, 0 bytes...
> INFO: Ready to print.
> 
> But the printer did nothing.

This looks like a problem with the backend. I am a bit surprised no data
are shown as being sent to the printer even though it didn't print.

Please enable debug logging in CUPS as described at

  
https://wiki.debian.org/Dissecting%20and%20Debugging%20the%20CUPS%20Printing%20System

Empty the error_log and do

  lp -d queue_name -o raw some_small_file

This does the same as the previous command  and uses only the backend
filter. Attach the error_log to your next mail.

It is rare for me to complile a program from source code but compiling
the bjnp backend is within my capabilities. So would you proceed as
follows:

1. Download the 2.0 version from
 
http://sourceforge.net/projects/cups-bjnp/

2. Unpack with

tar zvxf cups-bjnp-2.0.tar.gz

3. Download the gcc, libcups2-dev and make packages.

4. Do './configure' and 'make' in the unpacked directory. The commands
   should run without error and you should end up with a bjnp binary. It
   can be reduced in size with 'strip bjnp' but I don't think this is
   strictly necessary for it to work.

5. Replace the present backend with this new one, matching permissions
   and ownership with

chown root.root bjnp
chmod 755 bjnp 

6. Print and report.

I do not think I can devise anything else for you to do after this.

> >> What do you mean by that? Ping the router? Ping cups (which is on my
> >> laptop)?
> > 
> > Ping the printer is what I meant.
> 
> I then tried to ping.
> 
> $ ping db-printer.fritz.box:8611
> ping: unknown host db-printer.fritz.box:8611

ping doesn't need a port number. Leave off the ":8611".
 
> Then I looked up the IP adress and changed the router to give the
> printer a fixed IP adress.
> 
> $ ping 192.168.178.27
> PING 192.168.178.27 (192.168.178.27) 56(84) bytes of data.
> 64 bytes from 192.168.178.27: icmp_seq=1 ttl=64 time=5.73 ms
> 64 bytes from 192.168.178.27: icmp_seq=2 ttl=64 time=7.56 ms
> 64 bytes from 192.168.178.27: icmp_seq=3 ttl=64 time=5.09 ms
> 64 bytes from 192.168.178.27: icmp_seq=4 ttl=64 time=7.13 ms
> 64 bytes from 192.168.178.27: icmp_seq=5 ttl=64 time=5.68 ms
> 64 bytes from 192.168.178.27: icmp_seq=6 ttl=64 time=7.40 ms
> 64 bytes from 192.168.178.27: icmp_seq=7 ttl=64 time=5.09 ms
> 64 bytes from 192.168.178.27: icmp_seq=8 ttl=64 time=5.25 ms
> 64 bytes from 192.168.178.27: icmp_seq=9 ttl=64 time=4.98 ms
> 64 bytes from 192.168.178.27: icmp_seq=10 ttl=64 time=4.97 ms
> 64 bytes from 192.168.178.27: icmp_seq=11 ttl=64 time=6.70 ms
> 64 bytes from 192.168.178.27: icmp_seq=12 ttl=64 time=4.93 ms
> ^C
> - --- 192.168.178.27 ping statistics ---
> 12 packets transmitted, 12 received, 0% packet loss, time 11015ms
> rtt min/avg/max/mdev = 4.938/5.881/7.567/0.987 ms
> 
> This worked!
> So I did some tests by changing the URI in settings.
> 
> bjnp://db-printer.fritz.box:8611 -> problem as decribed initially
> ipp://db-printer.fritz.box:8611 -> printer not reachable
> bjnp://192.168.178.27 -> problem as decribed initially
> ipp://192.168.178.27 -> works!
> 
> Finally, I removed the package cups-backend-bjnp. Everything still works!

Perhaps another indication the bjnp backend is misbehaving.

Cheers,

Brian.

Bug#660932: #660932 Double quote in (some) wget's international output for downloaded filename

[Noël Köthe]

forwarded 660932 https://savannah.gnu.org/bugs/?45791
tags 660932 + upstream
found 660932 1.16.3-3
thanks

Hello,

even after info to the translators there are still double quotes I
reported it to the upstream bugtracker.

Regards

Noël

-- 
Noël Köthe 
Debian GNU/Linux, www.debian.org

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

Bug#795954: sysconfig-hardware contains various syntax errors in "case" commands

[Stephen Powell]

Package: sysconfig-hardware
Version: 0.0.10+nmu1
Severity: minor
Tags: patch
X-Debbugs-CC: debian-s...@lists.debian.org

The sysconfig-hardware package contains a number of syntax errors in "case"
commands.  The "case" command requires that after each pattern specification
there must be a command list, and this command list must be terminated by
a double semicolon.  This is violated in several places.  In some places,
the only thing between the end of the pattern specification and the double
semicolon is a comment.  A comment is not a list.  A null command (a colon)
will do, but there must be at least one command present to constitute a list.
In other places, there is no double semicolon to terminate the list.  This
also is a violation of the rules of valid syntax.

For some reason, the code has apparently been executing more or less correctly;
but a future release of bash (yes, bash, not dash) may tighten up standards
and the code will fail.  I have attached a patch file which corrects the
problems.

Note: the portion of the patch which changes chandev-convert affects only
the source package.  It is not included in the binary package.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-diff -uar a/etc/sysconfig/scripts/hardware/functions b/etc/sysconfig/scripts/hardware/functions
--- a/etc/sysconfig/scripts/hardware/functions	2010-10-30 10:50:49.0 -0400
+++ b/etc/sysconfig/scripts/hardware/functions	2015-08-18 05:36:06.411307488 -0400
@@ -27,6 +27,7 @@
   echo "$SCRIPTNAME: illegal option -- $OPTARG" >&2
   echo "Try: \`$SCRIPTNAME -h' for mor information." >&2
   exit $R_USAGE
+  ;;
 esac
   done
 
diff -uar a/etc/sysconfig/scripts/hardware/hwup b/etc/sysconfig/scripts/hardware/hwup
--- a/etc/sysconfig/scripts/hardware/hwup	2010-10-30 10:28:43.0 -0400
+++ b/etc/sysconfig/scripts/hardware/hwup	2015-08-18 05:38:22.536360188 -0400
@@ -17,6 +17,7 @@
 case "${STARTMODE:-auto}:$MODE" in
   auto:auto|*:auto-override)
   # Start auto devices in auto and override mode.
+  :
   ;;
   *:auto)
   # Don't display any message if device is not auto in auto mode.
@@ -24,6 +25,7 @@
   ;;
   auto:manual|manual:manual)
   # Start manual devices in manual mode.
+  :
   ;;
   off:manual)
   message "$SCRIPTNAME: used configuration has STARTMODE=$STARTMODE."
@@ -32,6 +34,7 @@
   *)
   message "$SCRIPTNAME: unknown STARTMODE=$STARTMODE."
   exit $R_ERROR
+  ;;
 esac
 
 source $SYSCONFIG/scripts/hardware/$COMMAND-$BUS $ID $DEVPATH
diff -uar a/usr/share/sysconfig/chandev-convert b/usr/share/sysconfig/chandev-convert
--- a/usr/share/sysconfig/chandev-convert	2009-03-24 06:10:51.0 -0400
+++ b/usr/share/sysconfig/chandev-convert	2015-08-18 05:40:58.760978505 -0400
@@ -26,6 +26,7 @@
 echo "$SCRIPTNAME: illegal option -- $OPTARG" >&2
 echo "Try: \`$SCRIPTNAME -h' for mor information." >&2
 exit $R_USAGE
+;;
   esac
 done
 

Bug#791187: nmu diff for libzeep 3.0.2-3.1

[Simon McVittie]

On Mon, 17 Aug 2015 at 21:04:36 +0200, Julien Cristau wrote:
> I've prepared a NMU for libzeep, to deal with the libstdc++ transition,
> and will shortly upload it to the 1-day delayed queue.  Please find the
> debdiff below.

Er, hasn't libzeep already been done?

> - libzeep3.0v5 (= ${binary:Version}),
> + libzeep3.0v5v5 (= ${binary:Version}),

This doesn't look right? Surely we only want one v5?

Please cancel this one, unless there's something important that I'm missing.

S

Bug#770925: wanna-build patches to support foreign-arch Build-Depends

[Aurelien Jarno]

Hi,

Here is a status update on this issue, as I a currently working on it.

On 2015-05-14 11:16, Dima Kogan wrote:
> Hi Andi. Thanks for the reply.
> 
> As you saw, there's some cleanup stuff mixed in with the actual
> foreign-arch build-dep stuff. I did a rebase so that these aren't
> interleaved anymore, and the cleanup can be evaluated somewhat
> independently. The build-dep stuff does depend on the cleanup, however.
> 
> The new tree lives in a branch:
> 
>  
> http://anonscm.debian.org/cgit/users/dkogan-guest/wanna-build.git/log/?h=770925_foreign_arch_bd
> 
> Same code as before, with a small, uninteresting bug fix:
> 
> --- b/bin/wanna-build
> +++ a/bin/wanna-build
> @@ -1920,1 +1920,1 @@
> -my @arch_foreign = grep { !/^(?:native|all|any|$arch_native)/ } keys 
> %qualified_arches;
> +my @arch_foreign = grep { !/^(?:native|all|any|$arch_native)$/ } 
> keys %qualified_arches;
> 
> 
> The tree now looks like this:
> 
> * 800aaee..: more correct handling of dose exit codes, as defined in the 
> latest dose3
This has been merged a few months ago.

> * 4428317..: dose-builddebcheck now has Packages for native and ALL foreign 
> arches
This doesn't work, as when passing Packages file from foreign
architectures, this also passes arch:all packages which might be at a
different version than on the native architecture. This would cause
some packages without cross-build-dependencies to be wrongly marked
as needs-build or bd-uninstallable.

I am currently working on an improve triggered code which passes the other
Packages file explicitely. That will also clean up a bit the arch:all
handling code.

> * 62fe41c..: I now pass --deb-foreign-archs to dose-builddebcheck as needed
This patch looks fine on principle, but the calls to dpkg triggers it to
determine its native architecture, which looks a bit scaring, given we
run it on an amd64 machine, not a buildd. This leads to this error messsages:
| sh: 1: gcc: not found
| wanna-build: warning: couldn't determine gcc system type, falling back to 
default (native compilation)

> * e041d64..: I now call dose-builddebcheck with IPC::Run

This has been merged a few months ago.
> * b857c74..: some small syntactic corrections

This has been merged a few months ago.


I am currently working on this, I really hope to get something working
by the end of the week.

Aurelien

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

Bug#795955: Complex regular subexpression recursion limit in cruft.pm

[Evgeni Golov]

Package: lintian
Version: 2.5.36.1
Severity: minor

Hi,

filling bug as requested in #debconf.

When running lintian on the source of some shady package [1]
(not in the archive), I get quite some warnings from perl:
Complex regular subexpression recursion limit (32766) exceeded at 
/usr/share/lintian/checks/cruft.pm line 939.

If you think this is a valid bug, feel free to fix it.
Otherwise, just close it :)

Greets
Evgeni

[1] 
http://pinky.die-welt.net/~evgeni/tmp/limesurvey_2.05plus-build140520%2bdfsg-1.dsc

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

Kernel: Linux 4.1.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)

Versions of packages lintian depends on:
ii  binutils   2.25.1-1
ii  bzip2  1.0.6-8
ii  diffstat   1.60-1
ii  file   1:5.22+15-2
ii  gettext0.19.5.1-1
ii  hardening-includes 2.7
ii  intltool-debian0.35.0+20060710.2
ii  libapt-pkg-perl0.1.29+b2
ii  libarchive-zip-perl1.49-1
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.38-1
ii  libdpkg-perl   1.18.2
ii  libemail-valid-perl1.196-1
ii  libfile-basedir-perl   0.07-1
ii  libipc-run-perl0.94-1
ii  liblist-moreutils-perl 0.413-1
ii  libparse-debianchangelog-perl  1.2.0-5
ii  libtext-levenshtein-perl   0.12-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.69-1
ii  man-db 2.7.2-1
ii  patchutils 0.3.4-1
ii  perl [libdigest-sha-perl]  5.20.2-6
ii  t1utils1.38-4
ii  xz-utils   5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg1.18.2
ii  libautodie-perl 2.29-1
ii  libperlio-gzip-perl 0.18-3+b1
ii  perl5.20.2-6
ii  perl-modules [libautodie-perl]  5.20.2-6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.2
ii  libhtml-parser-perl3.71-2
ii  libtext-template-perl  1.46-1
ii  libyaml-perl   1.13-1

-- no debconf information

Bug#744170: wget: Read error in TLS connection with openssl s_server -www server

[Vincent Lefevre]

Control: tags -1 - moreinfo
Control: found -1 1.16.3-3

On 2015-08-18 11:36:43 +0200, Noël Köthe wrote:
> wget 1.16 fixed a lot of gnutls problems. Could you still reproduce
> this problem with 1.16 in jessie or the later version in
> testing/unstable?

Still the same problem in unstable:

--2015-08-18 12:29:07--  https://www.vinc17.net:4433/
Resolving www.vinc17.net (www.vinc17.net)... 92.243.22.117, 
2001:4b98:dc0:45:216:3eff:fe9b:eb2f
Connecting to www.vinc17.net (www.vinc17.net)|92.243.22.117|:4433... connected.
HTTP request sent, awaiting response... 200 ok
Length: unspecified [text/html]
Saving to: ‘index.html’

index.html  [ <=>  ]   5.26K  --.-KB/s   in 0s 

2015-08-18 12:29:07 (204 MB/s) - Read error at byte 5386 (The TLS connection 
was non-properly terminated.).Retrying.

--2015-08-18 12:29:08--  (try: 2)  https://www.vinc17.net:4433/
Connecting to www.vinc17.net (www.vinc17.net)|92.243.22.117|:4433... connected.
HTTP request sent, awaiting response... 200 ok
Length: unspecified [text/html]
Saving to: ‘index.html’

index.html  [ <=>  ]   5.26K  --.-KB/s   in 0s 

2015-08-18 12:29:08 (1.21 GB/s) - Read error at byte 5386 (The TLS connection 
was non-properly terminated.).Retrying.

--2015-08-18 12:29:10--  (try: 3)  https://www.vinc17.net:4433/
Connecting to www.vinc17.net (www.vinc17.net)|92.243.22.117|:4433... connected.
HTTP request sent, awaiting response... 200 ok
Length: unspecified [text/html]
Saving to: ‘index.html’

index.html  [ <=>  ]   5.26K  --.-KB/s   in 0s 

2015-08-18 12:29:10 (742 MB/s) - Read error at byte 5386 (The TLS connection 
was non-properly terminated.).Retrying.

--2015-08-18 12:29:13--  (try: 4)  https://www.vinc17.net:4433/
Connecting to www.vinc17.net (www.vinc17.net)|92.243.22.117|:4433... connected.
HTTP request sent, awaiting response... 200 ok
Length: unspecified [text/html]
Saving to: ‘index.html’

index.html  [ <=>  ]   5.26K  --.-KB/s   in 0s 

2015-08-18 12:29:13 (710 MB/s) - Read error at byte 5386 (The TLS connection 
was non-properly terminated.).Retrying.
[...]

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

Bug#795956: digikam: Debian version is getting ancient, blocking sid upgrades

[Peter Gervai]

Package: digikam
Version: 4:4.4.0-1.1+b2
Severity: wishlist

Good day,

It is an ongoing problem that the Debian digikam version is getting rather
old: current release is 4.12.x.

Digikam also was removed from testing due to a build problem and a license
bug (which seem to be invalid by the last comment but still open).

Would it be possible to check / cooperate with Ubuntu maintainers who have a
working 4.12.0 in their repository? Or even back-migrate their changes?

Is there actually anyone maintaining digikam now here around?

Thank you,
Peter

Bug#795850: pdfgrep FTBFS / due to libstdc++ transition

[Christoph Egger]

Hi!

I've been told this will go away as soon as libpoppler gets its
rename+transition for the libstdc++ thing.

  Christoph
-- 

Bug#788328: [rt.cpan.org #96113] Fails with bleadperl since v5.21.0-74-g32f4893

[gregor herrmann]

On Mon, 17 Aug 2015 15:26:44 -0400, Peter John Acklam via RT wrote:

> https://rt.cpan.org/Ticket/Display.html?id=96113 >
> 
> I have just uploaded Math-BigInt-GMP-1.39.tar.gz to CPAN.
> 
> I am sorry this has taken so long. I am working on some release
> scripts to simplify the work of releasing Math-Big* distributions.

Thanks for the new release.

I can confirm that it now builds with 5.22, but it fails with 5.20.2:

#   Failed test at t/bigfltpm.inc line 182.
#  got: '2.25,1'
# expected: '2,1'

#   Failed test at t/bigfltpm.inc line 182.
#  got: '1.8,4'
# expected: '1,4'
# Looks like you failed 2 tests of 2343.
t/bigfltpm.t .. 
1..2343
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12
ok 13
ok 14
ok 15
ok 16
ok 17
ok 18
ok 19
ok 20
ok 21
ok 22
ok 23
ok 24
ok 25
ok 26
ok 27
ok 28
ok 29
ok 30
ok 31
ok 32
ok 33
ok 34
ok 35
ok 36
ok 37
ok 38
ok 39
ok 40
ok 41
ok 42
ok 43
ok 44
ok 45
ok 46
ok 47
ok 48
ok 49
ok 50
ok 51
ok 52
ok 53
ok 54
ok 55
ok 56
ok 57
ok 58
ok 59
ok 60
ok 61
ok 62
ok 63
ok 64
ok 65
ok 66
ok 67
ok 68
ok 69
ok 70
ok 71
ok 72
ok 73
ok 74
ok 75
ok 76
ok 77
ok 78
ok 79
ok 80
ok 81
ok 82
ok 83
ok 84
ok 85
ok 86
ok 87
ok 88
ok 89
ok 90
ok 91
ok 92
ok 93
ok 94
ok 95
ok 96
ok 97
ok 98
ok 99
ok 100
ok 101
ok 102
ok 103
ok 104
ok 105
ok 106
ok 107
ok 108
ok 109
ok 110
ok 111
ok 112
ok 113
ok 114
ok 115
ok 116
ok 117
ok 118
ok 119
ok 120
ok 121
ok 122
ok 123
ok 124
ok 125
ok 126
ok 127
ok 128
ok 129
ok 130
ok 131
ok 132
ok 133
ok 134
ok 135
ok 136
ok 137
ok 138
ok 139
ok 140
ok 141
ok 142
ok 143
ok 144
ok 145
ok 146
ok 147
ok 148
ok 149
ok 150
ok 151
ok 152
ok 153
ok 154
ok 155
ok 156
ok 157
ok 158
ok 159
ok 160
ok 161
ok 162
ok 163
ok 164
ok 165
ok 166
ok 167
ok 168
ok 169
ok 170
ok 171
ok 172
ok 173
ok 174
ok 175
ok 176
ok 177
ok 178
ok 179
ok 180
ok 181
ok 182
ok 183
ok 184
ok 185
ok 186
ok 187
ok 188
ok 189
ok 190
ok 191
ok 192
ok 193
ok 194
ok 195
ok 196
ok 197
ok 198
ok 199
ok 200
ok 201
ok 202
ok 203
ok 204
ok 205
ok 206
ok 207
ok 208
ok 209
ok 210
ok 211
ok 212
ok 213
ok 214
ok 215
ok 216
ok 217
ok 218
ok 219
ok 220
ok 221
ok 222
ok 223
ok 224
ok 225
ok 226
ok 227
ok 228
ok 229
ok 230
ok 231
ok 232
ok 233
ok 234
ok 235
ok 236
ok 237
ok 238
ok 239
ok 240
ok 241
ok 242
ok 243
ok 244
ok 245
ok 246
ok 247
ok 248
ok 249
ok 250
ok 251
ok 252
ok 253
ok 254
ok 255
ok 256
ok 257
ok 258
ok 259
ok 260
ok 261
ok 262
ok 263
ok 264
ok 265
ok 266
ok 267
ok 268
ok 269
ok 270
ok 271
ok 272
ok 273
ok 274
ok 275
ok 276
ok 277
ok 278
ok 279
ok 280
ok 281
ok 282
ok 283
ok 284
ok 285
ok 286
ok 287
ok 288
ok 289
ok 290
ok 291
ok 292
ok 293
ok 294
ok 295
ok 296
ok 297
ok 298
ok 299
ok 300
ok 301
ok 302
ok 303
ok 304
ok 305
ok 306
ok 307
ok 308
ok 309
ok 310
ok 311
ok 312
ok 313
ok 314
ok 315
ok 316
ok 317
ok 318
ok 319
ok 320
ok 321
ok 322
ok 323
ok 324
ok 325
ok 326
ok 327
ok 328
ok 329
ok 330
ok 331
ok 332
ok 333
ok 334
ok 335
ok 336
ok 337
ok 338
ok 339
ok 340
ok 341
ok 342
ok 343
ok 344
ok 345
ok 346
ok 347
ok 348
ok 349
ok 350
ok 351
ok 352
ok 353
ok 354
ok 355
ok 356
ok 357
ok 358
ok 359
ok 360
ok 361
ok 362
ok 363
ok 364
ok 365
ok 366
ok 367
ok 368
ok 369
ok 370
ok 371
ok 372
ok 373
ok 374
ok 375
ok 376
ok 377
ok 378
ok 379
ok 380
ok 381
ok 382
ok 383
ok 384
ok 385
ok 386
ok 387
ok 388
ok 389
ok 390
ok 391
ok 392
ok 393
ok 394
ok 395
ok 396
ok 397
ok 398
ok 399
ok 400
ok 401
ok 402
ok 403
ok 404
ok 405
ok 406
ok 407
ok 408
ok 409
ok 410
ok 411
ok 412
ok 413
ok 414
ok 415
ok 416
ok 417
ok 418
ok 419
ok 420
ok 421
ok 422
ok 423
ok 424
ok 425
ok 426
ok 427
ok 428
ok 429
ok 430
ok 431
ok 432
ok 433
ok 434
ok 435
ok 436
ok 437
ok 438
ok 439
ok 440
ok 441
ok 442
ok 443
ok 444
ok 445
ok 446
ok 447
ok 448
ok 449
ok 450
ok 451
ok 452
ok 453
ok 454
ok 455
ok 456
ok 457
ok 458
ok 459
ok 460
ok 461
ok 462
ok 463
ok 464
ok 465
ok 466
ok 467
ok 468
ok 469
ok 470
ok 471
ok 472
ok 473
ok 474
ok 475
ok 476
ok 477
ok 478
ok 479
ok 480
ok 481
ok 482
ok 483
ok 484
ok 485
ok 486
ok 487
ok 488
ok 489
ok 490
ok 491
ok 492
ok 493
ok 494
ok 495
ok 496
ok 497
ok 498
ok 499
ok 500
ok 501
ok 502
ok 503
ok 504
ok 505
ok 506
ok 507
ok 508
ok 509
ok 510
ok 511
ok 512
ok 513
ok 514
ok 515
ok 516
ok 517
ok 518
ok 519
ok 520
ok 521
ok 522
ok 523
ok 524
ok 525
ok 526
ok 527
ok 528
ok 529
ok 530
ok 531
ok 532
ok 533
ok 534
ok 535
ok 536
ok 537
ok 538
ok 539
ok 540
ok 541
ok 542
ok 543
ok 544
ok 545
ok 546
ok 547
ok 548
ok 549
ok 550
ok 551
ok 552
ok 553
ok 554
ok 555
ok 556
ok 557
ok 558
ok 559
ok 560
ok 561
ok 562
ok 563
ok 564
ok 565
ok 566
ok 567
ok 568
ok 569
ok 570
ok 571
ok 572
ok 573
ok 574
ok 575
ok 576
ok 577
ok 578
ok 579
ok 580
ok 581
ok 582
ok 583
ok 584
ok 585
ok 586
ok 587
ok 588
ok 589
ok 590
ok 591
ok 592
ok 593
ok 594
ok 595
ok 596
ok 597
ok 598
ok 599
ok 600
ok 601
ok 602
ok 603
ok 604
ok 605
ok 606
ok 607
ok 608
ok 609
ok 610
ok 611
ok 612
ok 613
ok 614
ok 615
ok 616
ok 617
ok 618
ok 619
ok 620
ok 621
ok 622
ok 623
ok 624
ok 625
ok 626
ok 627
ok 628
ok 629
ok 630
ok 631
ok 632
ok 633
ok 6

Bug#791228: nmu diff for openlayer 2.1-1.1

[Georges Khaznadar]

Thank you for your help, Julien, I most appreciate it.

Best regards,   Georges.

Julien Cristau a écrit :
> Dear maintainer,
> 
> I've prepared a NMU for openlayer, to deal with the libstdc++ transition,
> and will shortly upload it to the 1-day delayed queue.  Please find the
> debdiff below.
> 
> Cheers,
> Julien
> 
> >From af9554c3a2d12da40f78f567550da4c4779ae2da Mon Sep 17 00:00:00 2001
> From: Julien Cristau 
> Date: Sun, 16 Aug 2015 17:51:28 +0200
> Subject: [PATCH] Rename library packages for g++5 ABI transition (closes:
>  791228).
> 
> ---
>  debian/changelog   | 7 +++
>  debian/control | 6 --
>  debian/libopenlayer2.dirs  | 1 -
>  debian/libopenlayer2.install   | 1 -
>  debian/libopenlayer2v5.dirs| 1 +
>  debian/libopenlayer2v5.install | 1 +
>  6 files changed, 13 insertions(+), 4 deletions(-)
>  delete mode 100644 debian/libopenlayer2.dirs
>  delete mode 100644 debian/libopenlayer2.install
>  create mode 100644 debian/libopenlayer2v5.dirs
>  create mode 100644 debian/libopenlayer2v5.install
> 
> diff --git a/debian/changelog b/debian/changelog
> index f404683..6eda24b 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,10 @@
> +openlayer (2.1-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename library packages for g++5 ABI transition (closes: 791228).
> +
> + -- Julien Cristau   Sun, 16 Aug 2015 17:51:28 +0200
> +
>  openlayer (2.1-1) unstable; urgency=low
>  
>* Initial release (Closes: #735016)
> diff --git a/debian/control b/debian/control
> index 6f1eb5f..36dc57e 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -9,9 +9,11 @@ Build-Depends: debhelper (>= 8.0.0), cmake, 
> hardening-wrapper,
>  Standards-Version: 3.9.5
>  Homepage: http://openlayer.berlios.de/
>  
> -Package: libopenlayer2
> +Package: libopenlayer2v5
>  Architecture: any
>  Depends: ${shlibs:Depends}, ${misc:Depends}
> +Conflicts: libopenlayer2
> +Replaces: libopenlayer2
>  Description: hardware accelerated 2D Graphics library
>   OpenLayer is a hardware accelerated 2D Graphics library. It specifies
>   a new api to be used alongside of Allegro and takes control of how
> @@ -21,7 +23,7 @@ Description: hardware accelerated 2D Graphics library
>  Package: libopenlayer-dev
>  Section: libdevel
>  Architecture: any
> -Depends: ${shlibs:Depends}, ${misc:Depends}, libopenlayer2 (= 
> ${binary:Version})
> +Depends: ${shlibs:Depends}, ${misc:Depends}, libopenlayer2v5 (= 
> ${binary:Version})
>  Description: hardware accelerated 2D Graphics library : development files
>   OpenLayer is a hardware accelerated 2D Graphics library. It specifies
>   a new api to be used alongside of Allegro and takes control of how
> diff --git a/debian/libopenlayer2.dirs b/debian/libopenlayer2.dirs
> deleted file mode 100644
> index 6845771..000
> --- a/debian/libopenlayer2.dirs
> +++ /dev/null
> @@ -1 +0,0 @@
> -usr/lib
> diff --git a/debian/libopenlayer2.install b/debian/libopenlayer2.install
> deleted file mode 100644
> index 86eca04..000
> --- a/debian/libopenlayer2.install
> +++ /dev/null
> @@ -1 +0,0 @@
> -usr/lib/libopenlayer.so.*
> \ No newline at end of file
> diff --git a/debian/libopenlayer2v5.dirs b/debian/libopenlayer2v5.dirs
> new file mode 100644
> index 000..6845771
> --- /dev/null
> +++ b/debian/libopenlayer2v5.dirs
> @@ -0,0 +1 @@
> +usr/lib
> diff --git a/debian/libopenlayer2v5.install b/debian/libopenlayer2v5.install
> new file mode 100644
> index 000..86eca04
> --- /dev/null
> +++ b/debian/libopenlayer2v5.install
> @@ -0,0 +1 @@
> +usr/lib/libopenlayer.so.*
> \ No newline at end of file
> -- 
> 2.5.0
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#793681: apt-xapian-index: should depend on python-support

[Peter Gervai]

Package: apt-xapian-index
Version: 0.47
Followup-For: Bug #793681

The following NEW packages will be installed:
  python-support 
The following partially installed packages will be configured:
  apt-xapian-index 
0 packages upgraded, 1 newly installed, 0 to remove and 109 not upgraded.
Need to get 33.6 kB of archives. After unpacking 167 kB will be used.
Get: 1 http://cdn.debian.net/debian/ sid/main python-support all 1.0.15 [33.6 
kB]
Fetched 33.6 kB in 0s (65.4 kB/s)   
Selecting previously unselected package python-support.
(Reading database ... 16274 files and directories currently installed.)
Preparing to unpack .../python-support_1.0.15_all.deb ...
Unpacking python-support (1.0.15) ...
Processing triggers for man-db (2.5.7-8) ...
Setting up apt-xapian-index (0.47) ...
apt-xapian-index: Building new index in background...
Setting up python-support (1.0.15) ...


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

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

Versions of packages apt-xapian-index depends on:
ii  python 2.7.9-1
ii  python-apt 0.9.3.11
ii  python-debian  0.1.25
ii  python-xapian  1.2.19-1
pn  python:any 

apt-xapian-index recommends no packages.

Versions of packages apt-xapian-index suggests:
pn  app-install-data  
ii  python-xdg0.25-4

-- no debconf information

Bug#658312: keepassx: lock file was not deleted

[intrigeri]

Hi,

Felix Geyer wrote (11 Aug 2015 21:34:38 GMT) :
> What kind of desktop session is Tails running?

GNOME. But our "immediately shutdown" button doesn't properly close
the desktop session (instead it stops the GDM service, mainly for
speed and simplicity's sake).

> KeePassX doesn't setup any signal handlers so sending SIGINT or SIGTERM
> will just kill it.

Is there any reason why, or is it a simple matter of programming +
someone finding time to add these signal handlers?

> However it does react to requests from the X session manager.
> It ask whether to save changes, remove the lock file etc.
> Tested on KDE and Gnome 3.

Good to know. So I see 3 options:

a) KeePassX upstream adds a handler for SIGTERM, so that every
   standard way of closing the application work as reliably as the
   already supported ones.
b) We modify Tails to close the GNOME session with standard X session
   manager mechanisms.
c) We modify Tails to send the relevant X session manager request to
   KeePassX upon shutdown.

I suspect that (a) would be pretty simple to implement for anyone
who's at ease with C++, and would benefit more users than (b) and (c).
Now, nobody is interested in implementing (a), then we'll have to go
the (b) or (c) way, and this bug could be tagged wontfix or downgraded
to wishlist.

Cheers,
--
intrigeri

Bug#744170: [bug #45792] wget: Read error in TLS connection with openssl s_server -www server

[NoëlKöthe]

URL:
  

 Summary: wget: Read error in TLS connection with openssl
s_server -www server
 Project: GNU Wget
Submitted by: nok
Submitted on: Di 18 Aug 2015 13:19:01 CEST
Category: Protocol Issue
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.16.3
Operating System: None
 Reproducibility: None
   Fixed Release: None
 Planned Release: None
  Regression: None
   Work Required: None
  Patch Included: None

___

Details:

Hello,

--8<--
What I set up a test server with:

  openssl s_server -CAfile ... -key ... -cert ... -www

and try wget with it, I get errors:

--2015-08-18 12:29:07--  https://www.vinc17.net:4433/
Resolving www.vinc17.net (www.vinc17.net)... 92.243.22.117,
2001:4b98:dc0:45:216:3eff:fe9b:eb2f
Connecting to www.vinc17.net (www.vinc17.net)|92.243.22.117|:4433...
connected.
HTTP request sent, awaiting response... 200 ok
Length: unspecified [text/html]
Saving to: ‘index.html’

index.html  [ <=>  ]   5.26K  --.-KB/s   in 0s


2015-08-18 12:29:07 (204 MB/s) - Read error at byte 5386 (The TLS connection
was non-properly terminated.).Retrying.

--2015-08-18 12:29:08--  (try: 2)  https://www.vinc17.net:4433/
Connecting to www.vinc17.net (www.vinc17.net)|92.243.22.117|:4433...
connected.
HTTP request sent, awaiting response... 200 ok
Length: unspecified [text/html]
Saving to: ‘index.html’

index.html  [ <=>  ]   5.26K  --.-KB/s   in 0s


2015-08-18 12:29:08 (1.21 GB/s) - Read error at byte 5386 (The TLS connection
was non-properly terminated.).Retrying.
...
--8<--
https://bugs.debian.org/744170

thx®ards

Noël




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/

Bug#794783: aces3: ftbfs on mipsel

[Jurica Stanojkovic]

Hello,

We have successfully built package aces3 using sbuild for mipsel on multiple 
boards.
Package was built without any changes to source code.

We plan to ask for give-back.

Thank you!

Regards,
Jurica

Bug#744170: wget: Read error in TLS connection with openssl s_server -www server

[Noël Köthe]

Control: tags -1 +upstream
Control: forwarded -1 https://savannah.gnu.org/bugs/?45792

Hello Vincent

Am Dienstag, den 18.08.2015, 12:39 +0200 schrieb Vincent Lefevre:

> > wget 1.16 fixed a lot of gnutls problems. Could you still reproduce
> > this problem with 1.16 in jessie or the later version in
> > testing/unstable?
> 
> Still the same problem in unstable:
> 
> --2015-08-18 12:29:07--  https://www.vinc17.net:4433/
> Resolving www.vinc17.net (www.vinc17.net)... 
> 92.243.22.117,2001:4b98:dc0:45:216:3eff:fe9b:eb2f
...
> 
> 2015-08-18 12:29:07 (204 MB/s) - Read error at byte 5386 (The TLS 
> connection was non-properly terminated.).Retrying.

Thanks for your fast reply and the testserver. I submitted the problem
to the upstream bugtracker.

Regards

Noël

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

Bug#795957: iceweasel: popup menu appears on second screen in multiscreen setup

[none]

Package: iceweasel
Version: 38.2.0esr-1~deb8u1
Severity: important

Dear Maintainer,

after upgrading to Iceweasel version 38.2.0 (previous versions of Iceweasel 
were working fine!)
there is a bug with Multi-Monitor setup and Iceweasel.


Bug Description:
Opening a popup menu (like the File Menu or Bookmark Menu) leads to opening the 
Menu on the
second screen while the iceweasel window is displayed on the first (primary) 
screen.

Expected is that the popup menu is displayed near the mouse pointer and near
the iceweasel window not on a completely different screen.


How to trigger:
Tracking down the bug reveals that it has to do with configuration of
option: layout.css.devPixelsPerPx

Setting the value of layout.css.devPixelsPerPx in about:config to a value
below 1.0 triggers the problem always! Even with a virgin iceweasel profile
and _NO_ add-ons installed, I tested this explicitely!

Setting the value of layout.css.devPixelsPerPx in about:config to a value
-1.0 or bigger than 1.0 prevents the bug, but iceweasels representation
of websites and the UI is way to large.


Remark:
* Setup of Multi-Monitor is done by: 
xrandr --output eDP1 --primary --auto --output HDMI1 --auto --below eDP1
--dpi 85


Regards



-- Package-specific info:

-- Extensions information
Name: Bluhell Firewall
Location: ${PROFILE_EXTENSIONS}/{6BB5760D-F97E-421B-AF5B-8457A90C3CED}.xpi
Status: enabled

Name: Classic Theme Restorer (Customize UI)
Location: ${PROFILE_EXTENSIONS}/classicthemeresto...@arist2noia4dev.xpi
Status: enabled

Name: Compact Menu 2
Location: ${PROFILE_EXTENSIONS}/{57068FBE-1506-42ee-AB02-BD183E7999E4}.xpi
Status: enabled

Name: Default theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: user-disabled

Name: Firesizer
Location: ${PROFILE_EXTENSIONS}/{04426594-bce6-4705-b811-bcdba2fd9c7b}.xpi
Status: enabled

Name: Ghostery
Location: ${PROFILE_EXTENSIONS}/fire...@ghostery.com.xpi
Status: enabled

Name: LittleFox theme
Location: ${PROFILE_EXTENSIONS}/{29852C08-1E91-4889-A6BF-C77F91D6A8F3}.xpi
Status: enabled

Name: MicroFox theme
Location: ${PROFILE_EXTENSIONS}/{403304EE-066A-4a2a-8F41-F12028480A0A}.xpi
Status: user-disabled

Name: NoScript
Location: ${PROFILE_EXTENSIONS}/{73a6fe31-595d-460b-a920-fcc0f8843232}.xpi
Status: enabled

Name: ScrapBook
Location: ${PROFILE_EXTENSIONS}/{53A03D43-5363-4669-8190-99061B2DEBA5}.xpi
Status: enabled

Name: SQLite Manager
Location: ${PROFILE_EXTENSIONS}/sqlitemana...@mrinalkant.blogspot.com.xpi
Status: enabled

Name: Stylish
Location: ${PROFILE_EXTENSIONS}/{46551EC9-40F0-4e47-8E18-8E5CF550CFB8}.xpi
Status: user-disabled

Name: Tab Mix Plus
Location: ${PROFILE_EXTENSIONS}/{dc572301-7619-498c-a57d-39143191b318}.xpi
Status: enabled

-- Plugins information
Name: Shockwave Flash (11.2.202.508)
Location: /usr/lib/flashplugin-nonfree/libflashplayer.so
Status: enabled


-- Addons package information
ii  iceweasel  38.2.0esr-1~ i386 Web browser based on Firefox

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

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

Versions of packages iceweasel depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18
ii  libcairo2 1.14.0-2.1
ii  libdbus-1-3   1.8.18-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+b1
ii  libglib2.0-0  2.42.1-1
ii  libgtk2.0-0   2.24.25-3
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.36.8-3
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  procps2:3.3.9-9
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages iceweasel recommends:
ii  gstreamer1.0-libav 1:1.4.5-dmo1
ii  gstreamer1.0-plugins-good  1.4.4-2

Versions of packages iceweasel suggests:
ii  fonts-mathjax  2.4-2
pn  fonts-oflb-asana-math  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-2.1
pn  libgnomeui-0   
ii  libgssapi-krb5-2   1.12.1+dfsg

Bug#795958: lynx-cur: certificate revocation checking is buggy

[Vincent Lefevre]

Package: lynx-cur
Version: 2.8.9dev6-3
Severity: serious
Tags: security

If I run

  lynx https://www.vinc17.net:4434/

I get

  SSL error:The certificate is NOT trusted. The certificate chain is revoked.
  -Continue? (n) 

as expected. But If I set up a test server with the same certificate
with:

  openssl s_server -CAfile old.crt -key old.key -cert old.crt -www

(the default port being 4433) and run

  lynx https://www.vinc17.net:4433/

I don't get any error.

No such problem with Iceweasel, which says:

  Secure Connection Failed

  An error occurred during a connection to www.vinc17.net:4433. Peer's
  Certificate has been revoked. (Error code: sec_error_revoked_certificate)

With curl, I get:

$ curl --cert-status https://www.vinc17.net:4434/
curl: (91) Server certificate was revoked: unspecified reason
$ curl --cert-status https://www.vinc17.net:4433/
curl: (91) No OCSP response received

I wonder why curl doesn't get an OCSP response in the 4433 case,
but at least one gets an error.

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

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

Versions of packages lynx-cur depends on:
ii  libbsd00.7.0-2
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.19-19
ii  libgnutls-deb0-28  3.3.17-1
ii  libidn11   1.32-1
ii  libncursesw5   5.9+20150516-2
ii  libtinfo5  5.9+20150516-2
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages lynx-cur recommends:
ii  mime-support  3.59

lynx-cur suggests no packages.

-- no debconf information

Bug#795867: Acknowledgement (vgchange has at least one race condition)

[Matthew Vernon]

Hi,

I can reproduce a similar effect with out vgchange, just pvcreate 
followed by drbdadm secondary can produce the same error message.


lsof shows that it's systemd-udevd that's holding /dev/drbd7 open.

Matthew

Bug#795959: linux-image-4.1.0-2-amd64: intel Centrino Advanced-N 6205 frequently disconnects

[gustavo panizzo (gfa)]

Package: src:linux
Version: 4.1.5-1
Severity: normal

since kernel 4.1 (I didn't test 4.0) wireless frequently disconnects and
does not reconnect by itself, I think the hardware restart does not work
as good as before. using kernel 3.16 this didn't happened

for example here

[25854.446926] ieee80211 phy0: Hardware restart was requested
[32280.403878] iwlwifi :24:00.0: L1 Enabled - LTR Disabled

until some time later when I manually restarted the interface it didn't
reconnect

is not a big deal to me, as I can boot my laptop with 3.16


-- Package-specific info:
** Version:
Linux version 4.1.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.3 
(Debian 4.9.3-3) ) #1 SMP Debian 4.1.5-1 (2015-08-15)

** Command line:
BOOT_IMAGE=/vmlinuz-4.1.0-2-amd64 root=/dev/mapper/vg00-root ro 
root=/dev/mapper/vg00-root ro clocksource=hpet cgroup_enable=memory swapaccount 
quiet

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[25849.447645] iwlwifi :24:00.0: 0x0001001E | branchlink1
[25849.447648] iwlwifi :24:00.0: 0x00010090 | branchlink2
[25849.447680] iwlwifi :24:00.0: 0xD6BE | interruptlink1
[25849.447682] iwlwifi :24:00.0: 0xD6BE | interruptlink2
[25849.447685] iwlwifi :24:00.0: 0x0081 | data1
[25849.447688] iwlwifi :24:00.0: 0x0703 | data2
[25849.447690] iwlwifi :24:00.0: 0x00024B96 | line
[25849.447693] iwlwifi :24:00.0: 0x07C0E518 | beacon time
[25849.447695] iwlwifi :24:00.0: 0x00311AE8 | tsf low
[25849.447698] iwlwifi :24:00.0: 0x | tsf hi
[25849.447701] iwlwifi :24:00.0: 0x | time gp1
[25849.447704] iwlwifi :24:00.0: 0x048560E4 | time gp2
[25849.447706] iwlwifi :24:00.0: 0x | time gp3
[25849.447709] iwlwifi :24:00.0: 0x754312A8 | uCode version
[25849.447711] iwlwifi :24:00.0: 0x00B0 | hw version
[25849.447714] iwlwifi :24:00.0: 0x00488700 | board version
[25849.447717] iwlwifi :24:00.0: 0x001C | hcmd
[25849.447719] iwlwifi :24:00.0: 0xAF863000 | isr0
[25849.447722] iwlwifi :24:00.0: 0x1101E000 | isr1
[25849.447724] iwlwifi :24:00.0: 0x0E1F | isr2
[25849.447727] iwlwifi :24:00.0: 0x0147FC42 | isr3
[25849.447729] iwlwifi :24:00.0: 0x | isr4
[25849.447732] iwlwifi :24:00.0: 0x | isr_pref
[25849.447734] iwlwifi :24:00.0: 0x00024B96 | wait_event
[25849.447737] iwlwifi :24:00.0: 0x9894 | l2p_control
[25849.447740] iwlwifi :24:00.0: 0x2D0D | l2p_duration
[25849.447742] iwlwifi :24:00.0: 0x000F | l2p_mhvalid
[25849.447745] iwlwifi :24:00.0: 0x0200 | l2p_addr_match
[25849.447749] iwlwifi :24:00.0: 0x0005 | lmpm_pmg_sel
[25849.447752] iwlwifi :24:00.0: 0x06061222 | timestamp
[25849.447755] iwlwifi :24:00.0: 0x7888 | flow_handler
[25849.447760] iwlwifi :24:00.0: Radio type=0x1-0x2-0x0
[25849.447832] iwlwifi :24:00.0: Start IWL Event Log Dump: display last 1 
entries
[25849.447854] iwlwifi :24:00.0: EVT_LOGT:0075849952:0x010c:0123
[25849.447869] iwlwifi :24:00.0: Disabled INTA bits 0x0200 were pending
[25849.448447] iwlwifi :24:00.0: Hardware error detected.  Restarting.
[25849.448455] iwlwifi :24:00.0: CSR values:
[25849.448457] iwlwifi :24:00.0: (2nd byte of CSR_INT_COALESCING is 
CSR_INT_PERIODIC_REG)
[25849.448463] iwlwifi :24:00.0:CSR_HW_IF_CONFIG_REG: 0X00488700
[25849.448469] iwlwifi :24:00.0:  CSR_INT_COALESCING: 0X0040
[25849.448475] iwlwifi :24:00.0: CSR_INT: 0X2000
[25849.448483] iwlwifi :24:00.0:CSR_INT_MASK: 0X
[25849.448492] iwlwifi :24:00.0:   CSR_FH_INT_STATUS: 0X
[25849.448498] iwlwifi :24:00.0: CSR_GPIO_IN: 0X0030
[25849.448504] iwlwifi :24:00.0:   CSR_RESET: 0X0003
[25849.448509] iwlwifi :24:00.0:CSR_GP_CNTRL: 0X080403c5
[25849.448514] iwlwifi :24:00.0:  CSR_HW_REV: 0X00b0
[25849.448520] iwlwifi :24:00.0:  CSR_EEPROM_REG: 0X
[25849.448529] iwlwifi :24:00.0:   CSR_EEPROM_GP: 0X9001
[25849.448536] iwlwifi :24:00.0:  CSR_OTP_GP_REG: 0X00030001
[25849.448543] iwlwifi :24:00.0: CSR_GIO_REG: 0X00080046
[25849.448549] iwlwifi :24:00.0:CSR_GP_UCODE_REG: 0X
[25849.448555] iwlwifi :24:00.0:   CSR_GP_DRIVER_REG: 0X
[25849.448561] iwlwifi :24:00.0:   CSR_UCODE_DRV_GP1: 0X
[25849.448567] iwlwifi :24:00.0:   CSR_UCODE_DRV_GP2: 0X
[25849.448573] iwlwifi :24:00.0: CSR_LED_REG: 0X0018
[25849.448580] iwlwifi :24:00.0:CSR_DRAM_INT_TBL_REG: 0X
[25849.448587] iwlwifi :24:00.0:CSR_GIO_CHICKEN_BITS: 0X27800200
[25849.448593] iwlwifi :24:00.0: CSR_ANA_PLL_CFG: 0X
[25849.448600] iwlwifi :24:00.0:  CSR_MONITOR_STATUS_RE

Bug#780001: ITP: node-isarray -- JavaScript Array#isArray for older browsers

[rossgammon]

unarchive 780001
reopen 780001 !
owner 780001 !
thanks

It turns out that the latest version of node-cross-spawn depends on
node-isarray, so we need to resurrect this ITP and try and solve any
issues the ftp-masters may have.

Regards,

Ross

Bug#795960: mosh: Does not display characters outside Unicode BMP

[Jonathan McDowell]

Package: mosh
Version: 1.2.5-1
Severity: normal

mosh is unable to disable characters outside the Unicode BMP, for
example U+1F35C (🍜). Connecting to the host via regular SSH and trying
to type the character works fine.


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

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

Versions of packages mosh depends on:
ii  dpkg1.18.2
ii  libc6   2.19-19
ii  libgcc1 1:5.1.1-14
ii  libprotobuf92.6.1-1
ii  libssl1.0.0 1.0.2d-1
ii  libstdc++6  5.1.1-14
ii  libtinfo5   5.9+20150516-2
ii  libutempter01.1.6-1
ii  openssh-client  1:6.7p1-6
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages mosh recommends:
ii  libio-socket-ip-perl  0.37-1
ii  perl-base [libio-socket-ip-perl]  5.20.2-6

mosh suggests no packages.

-- no debconf information

Bug#795958: lynx-cur: certificate revocation checking is buggy

[Alessandro Ghedini]

On Tue, Aug 18, 2015 at 01:32:19pm +0200, Vincent Lefevre wrote:
> Package: lynx-cur
> Version: 2.8.9dev6-3
> Severity: serious
> Tags: security
> 
> If I run
> 
>   lynx https://www.vinc17.net:4434/
> 
> I get
> 
>   SSL error:The certificate is NOT trusted. The certificate chain is revoked.
>   -Continue? (n) 
> 
> as expected. But If I set up a test server with the same certificate
> with:
> 
>   openssl s_server -CAfile old.crt -key old.key -cert old.crt -www

Try adding the "-status" option here.

I think the problem is that both lynx and curl only support OCSP stapling,
while firefox also does full-blown OCSP. So, if you don't enable OCSP stapling
in s_server (with the -status option), lynx and curl won't receive any response,
while firefox will also try to contact the CA's OCSP server and receive a
response from that.

It's more like lack of a feature than an actual bug (hardly RC material though,
IMO).

Hope this helps.

Cheers


signature.asc
Description: Digital signature

Bug#228844: cron-apt: treats "--no-download --download-only" as error

[Julian Andres Klode]

On Wed, Jan 21, 2004 at 09:28:58AM +0100, Marc Haber wrote:
> Package: cron-apt
> Version: 0.0.18
> Severity: wishlist
> 
> hi,
> 
> on one of my hosts, I'd like cron-apt to send update e-mails, but not
> to download any packages automatically. To accomplish this, I have set
> "upgrade --no-download --download-only --show-upgraded --yes" in
> /etc/cron-apt/action.d/3-download.

Combining --no-download with --download-only does not make sense
anyway. You either want to download or not, you can't do both
at the same time.

You might want to use "--simulate" instead, or add "--fix-missing"
as the manual page for --no-download says.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Be friendly, do not top-post, and follow RFC 1855 "Netiquette".
- If you don't I might ignore you.

Bug#744170: wget: Read error in TLS connection with openssl s_server -www server

[Vincent Lefevre]

On 2015-08-18 13:22:34 +0200, Noël Köthe wrote:
> Thanks for your fast reply and the testserver.

The testserver is not permanent, but this can easily be reproduced
locally after creating a certificate, starting the test server
with a command like:

  openssl s_server -CAfile file.crt -key file.key -cert file.crt -www

and using

  wget --no-check-certificate https://localhost:4433/

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

Bug#789460: [Pkg-bluetooth-maintainers] Bug#789460: unable to receive files over bluetooth

[Nobuhiro Iwamatsu]

severity 789460 normal
tag 789460 moreinfo
thanks

Hi,

Thanks for your report.

I use the blueman and I have confirmed to send and receive files via
bluez-obexd.
Could you give me more infomation about this?

Best regards,
  Nobuhiro

2015-06-21 16:37 GMT+09:00 Pirate Praveen :
> package: bluez-obexd
> version: 5.23-2+b1
> severity: grave
> reason: file transfer is a major feature of bluetooth
>
> I can use internet connection of my android phone and send files to it,
> but receiving files don't work. I had tried with firefox os phone as
> well and result is same.
>
>
> ___
> Pkg-bluetooth-maintainers mailing list
> pkg-bluetooth-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-bluetooth-maintainers



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#335920: please provide 'apt-cache srcpolicy'

[Julian Andres Klode]

Control: block -1 by 590088

On Thu, Oct 27, 2005 at 02:22:48AM +0800, LI Daobing wrote:
> Package: apt
> Version: 0.6.42.1
> Severity: wishlist
> 
> Please provide 'apt-cache srcpolicy'.
> 
> I like the output of the apt-cache policy, but it does not work on
> source packges, how about provide one?
> 
> for example, I use a deb-src source from mentors.debian.net, there isn't
> a easy way to print the aviable source versions cleanly. 
> 
> Thanks.

There *is no* policy for source packages, so there's nothing we can
print. If might get some cache for source packages, we could have
that, but currently, it does not exist.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Be friendly, do not top-post, and follow RFC 1855 "Netiquette".
- If you don't I might ignore you.

Bug#786382: Bug resolved

[Cesare Leonardi]

Today i've upgraded my system and the problem looks resolved. For 
details, see the bug opened upstream:

https://bugs.freedesktop.org/show_bug.cgi?id=90617

To me this bug can be closed.

Cesare.

Bug#795711: Fwd: [snag] OpenSSH root privilege escalation

[Yves-Alexis Perez]

On mar., 2015-08-18 at 08:38 +0200, Salvatore Bonaccorso wrote:
> Hi Luca,
> 
> Thanks for forwarding. This seem to be relate to
> https://bugs.debian.org/795711 which we actually marked previously as
> no-dsa. But let's recheck if we missed something.

The OpenSSH 7.0 announcement is a bit confusing on that topic. But I
think it was marked no-dsa because the vulnerability needs another
vulnerability in order to be able to achieve arbitrary code execution
in the context of the sandboxed pre-authentication process. *IF* you
have that possibility, a vulnerability in the monitor process could be
exploited in order to bypass authentication.

So as far as I can tell it's defense in depth and hardening, not a
“root privilege escalation bug”.

Maybe OpenSSH maintainers can comment on this, though.
> 
> See you,
> Salvatore
> 
> (top-posting for context reference to the team)
> 
> On Mon, Aug 17, 2015 at 10:08:46PM +, Filipozzi, Luca wrote:
> > 
> > 
> > --
> > Luca Filipozzi
> > Sent from my mobile. Blame auto-correct fur any errors.
> > 
> > Begin forwarded message:
> > 
> > From: Derek Poon mailto:der...@ece.ubc.ca>>
> > Date: August 17, 2015 at 23:38:21 GMT+2
> > To: SNAG mailto:s...@snag.ubc.ca>>
> > Subject: [snag] OpenSSH root privilege escalation
> > Reply-To: Derek Poon mailto:der...@ece.ubc.ca>>
> > 
> > SNAG,
> > 
> > There is a root privilege escalation bug in OpenSSH, for versions 
> > from 5.9 to 6.9, and fixed in 7.0.  There is no CVE number issued, 
> > and no word from Red Hat and Debian yet.
> > 
> > 
> > Technical explanation:
> > https://cxsecurity.com/issue/WLB-2015080072
> > 
> > OpenSSH 7.0 release announcement:
> > http://lists.mindrot.org/pipermail/openssh-unix-announce/2015
> > -August/000122.html
> > 
> > Ubuntu USN-2710-1:
> > http://www.ubuntu.com/usn/usn-2710-1/
> > 
> > 
> > Derek Poon
> > Infrastructure Special Projects Team
-- 
Yves-Alexis


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

Bug#720872: perl: Perl 5.18 "randomly" loses active references under "use threads"

[Dominic Hargreaves]

On Thu, Aug 29, 2013 at 09:20:51PM +0200, Niels Thykier wrote:
> On 2013-08-29 19:41, Dominic Hargreaves wrote:
> > On Sun, Aug 25, 2013 at 10:13:39PM +0200, Niels Thykier wrote:
> >> Noticed this under the Lintian test suite:
> >>
> >> """
> >> [...]
> >> t/scripts/changelog-format.t .. ok
> >> ===( 314;1   0/22  0/?  1/?  0/?  0/?  0/?   5/21  0/? 
> >> )Thread 2 terminated abnormally: Can't call method 
> >> "minimum_explicit_version" on an undefined value at 
> >> /usr/share/perl5/Test/MinimumVersion.pm line 54.
> >> t/scripts/needs-info-exists.t . ok
> >> [...]
> >> """
> >>
> >> I doubt this is a bug in Test::MinimumVersion because:
> >>  * it happens randomly
> >>  * last time I saw this problem, it happened in a different script
> >>
> >> I believe (but this is a guess) this is related to threads because I
> >> have only seen it in scripts using threads so far (and only in
> >> sections where other threads are active).
> >>
> >> Based on my observations, I would guess we are looking at a
> >> race-condition in Perl itself somewhere.  That said, I have no idea
> >> where to look for it (or how to verify this assertion).
> > 
> > Does #718438 look like the same issue? Can you reproduce it using
> > 5.18 on current sid?
> > 
> > Cheers,
> > Dominic.
> 
> I doubt it is the same issue; I never experienced it with perl5.14.
> That said, I will try when the perl transition has progressed a bit further.

Hi Niels,

Are you able to say whether this is reproducible on perl 5.20? If not,
we should probably just close this bug.

Cheers,
Dominic.