Bug#844658: stretch GIT broken

[Nikos Mavrogiannopoulos]

I think few months ago a similar issue was reported.  The culprit was librtmp 
or some other lib linking to a version of nettle with unversioned symbols. That 
resulted to a symbol clash which caused that issue. The solution was to update 
that lib.

On 18 November 2016 02:50:14 CET, Daniel Kahn Gillmor  
wrote:
>On Fri 2016-11-18 06:03:59 +0900, martin carmichael wrote:
>> Package: gnutls-bin (3.5.5-6)
>>
>>
>> message: fatal: unable to access 'https://github.com :
>gnutls_handshake() failed: Public key signature verification has
>failed.
>>
>>
>>  git --version
>> git version 2.10.2
>>
>> uname -a
>> Linux debian 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64
>GNU/Linux
>>
>> git push
>> fatal: unable to access 'https://github.com...  : gnutls_handshake()
>failed: Public key signature verification has failed.
>
>I'm not seeing this at all:
>
>0 dkg@alice:/tmp/cdtemp.B2ws82$ git clone https://github.com/dkg/s6
>Cloning into 's6'...
>remote: Counting objects: 1899, done.
>remote: Total 1899 (delta 0), reused 0 (delta 0), pack-reused 1899
>  Receiving objects: 100% (1899/1899), 503.91 KiB | 283.00 KiB/s, done.
>Resolving deltas: 100% (1169/1169), done.
>0 dkg@alice:/tmp/cdtemp.B2ws82$
>
>Regards,
>
>--dkg

-- 
Sent fron my mobile. Please excuse my brevity.

Bug#842638: gbp buildpackage: support basic version mangling for --git-upstream-tag

[Guido Günther]

Hi Jonas,
On Fri, Nov 04, 2016 at 03:24:56PM +0100, Guido Günther wrote:
> Hi Jonas,
> On Mon, Oct 31, 2016 at 03:21:46PM +0100, Jonas Meurer wrote:
> > Hi Guido,
> > 
> > Am 31.10.2016 um 11:21 schrieb Guido Günther:
> > >> See attached patch which implements basic version mangling for
> > >> '--git-upstream-tag' in a simple substitute fashion: if the provided
> > >> format contains the syntax '%(version%OLD%NEW)s', then the version used
> > >> for '%(version)s' has 'OLD' replaced by 'NEW'.
> > >>
> > >> This allows us to let gbp create the upstream tarball from upstream Git
> > >> release tag for new releases:
> > >>
> > >> $ gbp buildpackage --git-upstream-tag="v%(version%.%_)s"
> > >>
> > >>
> > >> In case that you like the approach and agree to add this feature to gbp,
> > >> I could write a few corresponding words for the related paragraphs of
> > >> gbp documentation.
> > >>
> > >> If you're not happy with the way it's implmented, just let me know why
> > >> and we can search for a better solution :)
> > > 
> > > The general approach is fine. Thanks for the patch. See my comments below:
> > 
> > Great :) I  tried to address your comments, see below.
> > 
> > >> commit f6a7e8f83935d74dc0cd67a5afa26b243357d04f
> > >> Author: Jonas Meurer 
> > >> Date:   Sun Oct 30 23:44:34 2016 +0100
> > >>
> > >> gbp/deb/git.py: add basic version mangling to version_to_tag()
> > >>
> > >> diff --git a/gbp/deb/git.py b/gbp/deb/git.py
> > >> index 64cd321..3070d93 100644
> > >> --- a/gbp/deb/git.py
> > >> +++ b/gbp/deb/git.py
> > >> @@ -142,12 +142,18 @@ class DebianGitRepository(GitRepository):
> > >>  hversion is useful for upstreams with tagging policies that 
> > >> prohibit .
> > >>  characters.
> > >>  
> > >> +%(version%A%B)s provides %(version)s with 'A' replaced by 'B'.
> > >> +
> > > 
> > > Please add tests using docstrings as below (including one that show how
> > > to use '%' as a replacement (e.g. 0-1.2.3 -> 0%1.2.3.4 and as replaced
> > > pattern 0%1%2%3 -> 0.1.2.3).
> > 
> > Done.
> > 
> > >>  >>> DebianGitRepository.version_to_tag("debian/%(version)s", 
> > >> "0:0~0")
> > >>  'debian/0%0_0'
> > >>  >>> DebianGitRepository.version_to_tag("libfoo-%(hversion)s", 
> > >> "1.8.1")
> > >>  'libfoo-1-8-1'
> > >>  
> > >>  """
> > >> +r = re.search(r"\%\(version\%([^%s]+)\%([^\%]+)\)s", format)
> > >> +if r:
> > >> +format = re.sub(r"\%\(version\%[^%s]+\%[^\%]+\)s", 
> > >> "%(version)s", format)
> > >> +version = version.replace(r.group(1), r.group(2))
> > >>  return format_str(format, 
> > >> dict(version=DebianGitRepository._sanitize_version(version),
> > >> 
> > >> hversion=DebianGitRepository._sanitize_version(version).replace('.', 
> > >> '-')))
> > >>  
> > > 
> > > Please document the behaviour. The current place that has the most
> > > information on how to modify the upstream version is in
> > > 
> > >  docs/chapters/import.sgml
> > 
> > Done.
> > 
> > See the attached updated patch.

While looking into this in some more details I noticed that we're
missing the reverse operation. In 'gbp buildpackage' we need to map from
the Debian version to the upstream tag while in 'gbp dch' we need to
map from the upstream tag to the debian version. This is not reversible
since '_' will be mapped back to '~'. Therefore I added a warning to the
docs. I've also made some simplifications to allow for easier future
expansion like only allowing for single character replacements for now.

If you have some time it owuld be great if you could have a look
at these commits:

 0b317eeb649090ab8bdd8507c189477670a91cd1 docs: Use version mangling with care
 7ed5e2b5ffbaf8dec310f98162e653fc95cd45f9 DebianGitRepository: Unmangle version
 25a5d679daf6ca90e03fe3bede787396fc630687 DebianGitRepository: split out 
version mangling
 d360a6d92d744762f9f13555ed03726b6d4ba937 DebianGitRepository: simplify version 
mangling

Cheers,
 -- Guido

Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script

[Christian Perrier]

Le 17/11/2016 à 15:32, Jonas Smedegaard a écrit :

Quoting Harshula (2016-11-17 14:58:33)

On 19/09/16 02:07, Christian PERRIER wrote:

I'd be happy to do this, however the fonts-noto-hinted-udeb package
is 5 megabytes in size while the former fonts-lklug-sinhala-udeb
package is only 67kilobytes.

Size is somehow constrained in Debian Installer, so I'd prefer
getting more input and advice before replacing
fonts-lklug-sinhala-udeb byt fonts-notohinted-udeb in D-I


Perhaps the Noto maintainers might consider splitting Noto into script
based debs. IIRC, that's what was done in Fedora.


I'd be happy to improve the usefulnes of the Noto package(s), but will
need more guidance.

I suspect easiest approach would be for debian-installer to use Noto
generally - i.e. replace not only the font for Sinhala but (I guess) a
larger range of region-specific fonts.

If debian-installer installs locale-specific fonts only when needed, or
there are reasons to not shift generally to Noto, then indeed there is a
benefit in creating udeb packages for smaller regions.

I can create a udeb specifically for Sinhala.  Or I can create a udeb
for each single font part of the Noto deb.  What do the debian-installer
team consider useful?

 - Jonas



Chagning the D-I font to Noto for all languages hasn't been 
validated...and the current font is well tested and accepted.


So, as a consequence, I'd prefer a udeb that would be suited for Sinhala.

Bug#844339: [PATCH v2 2/4] libvirt-daemon-system.{config,templates,postinst}: warn if allocated uid/gid cannot be used

[Guido Günther]

Hi Mauricio,

On Thu, Nov 17, 2016 at 07:53:55PM -0200, Mauricio Faria de Oliveira wrote:
> On 11/17/2016 05:37 PM, Guido Günther wrote:
> > I'm basically fine with all of this (but did not du any actual testing)
> 
> Cool.
> 
> > but we should not warn if the user/group already exists (even with the
> > wrong uid). Otherwise we'd warn over and over again, we don't want to
> > force users to change existing installations.
> 
> Actually the warning is not repeated; the answer is saved by debconf.

Debconf is not a registry that is you must not rely on the debconf
database saving values for you:

https://lintian.debian.org/tags/debconf-is-not-a-registry.html

> If you just install/upgrade after having answered the question once,
> it doesn't show up.

And it means all users of existing installation see it although they
can't do much about it - you really don't want to change uid/gid of the
user on an installed system since this requires cleanup of disk images,
etc. - leaving the user with a broken installation.

> You only get it again in intentional cases:
> 1) dpkg-reconfigure
> 2) apt-get purge && re-install
> 3) remove its 'Flags: seen' line from /var/cache/debconf/config.dat
> 
> > If we want to notify users of existing installations we have a
> > Debian.NEWS for this that can explain that switching to uid/git 64055 is
> > recommended.
> 
> Good point. I can write a snippet for that too if you want, but not
> sure it's enough depending on your decision about how/when to notify
> users (paragraph below).

I think it's sufficient for existing installations. People will see it
and can plan for the change to happen (they obviosly didn't run into the
problem for the last 10 years).

> 
> > IMHO the only important case to warn about is the case where user or
> > group does not yet exist _and_ the uid/gid is already taken by another
> > user or group. What do you think?
> 
> Well, I still think it's also important to warn when the user/group
> already exists (with a different uid/gid).
> 
> The main reason is to help users not to hit a known problem, and help
> maintainers not to get unnecessary bug reports, or having to debug it
> again (it was hard to debug/trace this, the root cause is very subtle,
> and the stack components pile up -- I ended up strace'ing qemu, found
> EACCES in read/write syscalls, and had to understand how NFS had come
> up with this type of error -- not that I'm proud, I imagine it's easy
> for people more experienced w/ the virtualization stack; just a story).
> 
> If existing installations are never told about this, they didn't
> even have a chance to try to fix their environment not to hit it,
> and I guess it's a valid expectation from the packages to set up
> things up correctly so not to hit problems (of course this case
> is not easy/automatic to resolve..)

And that's exactly what NEWS.Debian is for. We use your code for the
error case. That is we want to do the right thing but can't since the
uid/gid is already taken.

> (some systems will never hit it because users were just created
> in the same order on source/destination hosts; but that's luck)
> 
> On the other hand, I'm not sure how disruptive such a warning is
> for automated deployments/upgrades, specially because the default
> is to abort the install (perhaps we should change it).

Exactly. That's why NEWS.Debian is nicer iff the user libvirt-qemu
exists but with "wrong" (legacy) uid/gid on existing installations and
Debconf is better for new installations where the uid/gid is already
taken.

> Anyway, just trying to provide some pondering and other thoughts/
> views on the matter, with the intention it may help :- )  Let me
> know what/how you'd like it in the patches and I'll spin v3 ;- )

Please spin a v3 ;)
Cheers,
 -- Guido

Bug#844700: pbuilder: please support build profiles

[Samuel Thibault]

Package: pbuilder
Version: 0.226.1
Severity: wishlist

Hello,

When bootstrapping a package which depends on itself (directly or
through a loop), one uses e.g.

dpkg-buildpackage -Pstage1

which disables the self-dependency in Build-Depends.

However, using

pdebuild --debbuildopts -Pstage1

tries to install the self-dependency, I have to explicitly remove the
dependency from debian/control.

It would be nice if pdebuild had a way to specify a build profile, so
that it only tries to install what is needed for the bootstrap.

Samuel

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

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

Versions of packages pbuilder depends on:
ii  cdebconf [debconf-2.0]  0.218
ii  debconf [debconf-2.0]   1.5.59
ii  debootstrap 1.0.86
ii  dpkg-dev1.18.10
ii  wget1.18-4

Versions of packages pbuilder recommends:
ii  devscripts  2.16.8
ii  eatmydata   105-5
ii  fakeroot1.21-2
ii  iproute24.8.0-1
ii  net-tools   1.60+git20150829.73cef8a-2
ii  sudo1.8.17p1-2

Versions of packages pbuilder suggests:
pn  cowdancer   
ii  gdebi-core  0.9.5.7

-- debconf information excluded

-- 
Samuel
 le y est un animal discret se logeant facilement dans un terminal
*** c has changed the topic on channel #ens-mim to ne pas jeter de cacahuetes 
aux ys, svp
 -+- #ens-mim - n'oubliez pas le guide -+-

Bug#844696: And the patches...

[Mathieu Parent]

See attached patches.

Regards

-- 
Mathieu Parent
From f12fe5c931a8c47bd606671bf2c9cd3ba940f984 Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Sat, 5 Nov 2016 21:36:54 +0100
Subject: [PATCH 1/2] Add luasandbox-lpeg (Closes: #844696)

---
 debian/control| 2 +-
 debian/luasandbox.dh-lua.conf | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 12 debian/luasandbox.dh-lua.conf

diff --git a/debian/control b/debian/control
index 2cbb602..cc90429 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: lua-lpeg
 Section: interpreters
 Priority: optional
 Maintainer: Enrico Tassi 
-Build-Depends: dh-lua, debhelper (>= 8.0.0)
+Build-Depends: dh-lua (>= 24~), debhelper (>= 8.0.0)
 Standards-Version: 3.9.6
 Homepage: http://www.inf.puc-rio.br/~roberto/lpeg.html
 Vcs-Git: git://git.debian.org/git/pkg-lua/lua-lpeg.git
diff --git a/debian/luasandbox.dh-lua.conf b/debian/luasandbox.dh-lua.conf
new file mode 12
index 000..ba875b6
--- /dev/null
+++ b/debian/luasandbox.dh-lua.conf
@@ -0,0 +1 @@
+lua5.1.dh-lua.conf
\ No newline at end of file
-- 
2.10.2

From 6b805e8f1e8c0275666229ef494f7c4f4bb96ae5 Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Fri, 18 Nov 2016 06:28:58 +0100
Subject: [PATCH 2/2] Release 0.12.2-2

---
 debian/changelog | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index e1c34de..e5a5ee2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+lua-lpeg (0.12.2-2) unstable; urgency=medium
+
+  * Team upload
+  * Add luasandbox-lpeg (Closes: #844696)
+
+ -- Mathieu Parent   Fri, 18 Nov 2016 08:57:36 +0100
+
 lua-lpeg (0.12.2-1) unstable; urgency=medium
 
   * New upstream release
-- 
2.10.2

Bug#843520: [debian-mysql] Bug#843520: Bug#843520: Bug#843520: mysql-server-5.5 cannot be automatically upgraded

[Lars Tangvald]

On 11/18/2016 08:00 AM, Lars Tangvald wrote:

Hi,

On 11/17/2016 06:02 PM, Jean Louis wrote:

I am sorry, that I filed bug in the wrong package, it was
unintentional mistake. It should be in mysql-server. And I know all
about specifics.

In my case, there is nothing that I have changed in my Mysql
configuration from the plain install. That is why I filed the
bug. Otherwise I would look first on my side.

And I was surprised it did not work, as I was used to the stability
and certainty when upgrading.

I could not find the solution

I was reading other bugs and I found:

[mysqld]
secure_file_priv = /var/lib/mysql

So I have put it in /etc/mysql/conf.d and now I got it working. Even I
don't even know what is it about, as being so lazy to read the
documentation. Sorry.

Still I think it should not be like that, the upgrade should go
smooth, especially for databases. Nothing angers me, thank you for
putting attention. I am supporter of free software and use Debian on
remote servers.

Jean Louis

Hi,

In this case, the server defaults to 
secure_file_priv=/var/lib/mysql-files, and will require this directory 
to be created.
This is a big change to make in a stable release, but the old behavior 
was a potential security risk, so we felt it was justified. The 
upgrade _should_ have created this directory automatically, so if it 
failed for you then there's probably something with your environment 
we didn't account for. If you have any console logs or mysql error 
logs from the update it would be good if you can attach them to the bug.


One important note, however:
The solution you note, setting secure_file_priv=/var/lib/mysql (the 
data directory) is not a good one. You should either set it to NULL or 
to a separate, empty directory owned by the mysql user.


The secure_file_priv setting determines where the server is allowed to 
read and write files using import/export operations. Setting it to the 
same location as the database will mean that any user of your database 
can get full access.



Correction here: You need the FILE privilege to use these operations.

--
Lars

Bug#811634: meshlab: FTBFS with GCC 6: cannot convert x to y

[Graham Inggs]

On 17 November 2016 at 18:27, Graham Inggs  wrote:
> Copying to debian-science-maintainers list in case someone is
> interested in rescuing this package.

Meshlab is already maintained in the debian-science's git repository [1].
All of Teemu Ikonen's other packages have Debian Science Maintainers
in the Maintainer field.

I will update the Maintainer field and prepare a team upload.


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

Bug#268658: Achtung: Überprüfen Sie Ihr Outlook-Konto.

[Mira Pavlicic]

Achtung: Lieber Outlook User,



Dies ist für alle Outlook-Benutzer informieren, dass wir derzeit aktualisieren 
unsere Outlook-Konto heute und Sie haben 24 Stunden, dies zu tun.
Bitte versäumt, Ihr Outlook-Konto, Ihr Microsoft Outlook-Konto zu aktualisieren 
/ zu bestätigen, das wir aussetzen und aus unserer Datenbank löschen.

Bitte aktualisieren / überprüfen Sie Ihr Outlook-Konto Klicken Sie auf die 
Outlook Web Apps, um Ihr Outlook-Konto zu 
aktualisieren.



Danke für dein Verständnis.



ADMIN-TEAM

Bug#844694: firefox: high-lighting issues with the new release (maybe gtk3 issue ? )

[Mike Hommey]

On Fri, Nov 18, 2016 at 12:21:25PM +0530, shirish शिरीष wrote:
> Package: firefox
> Version: 50.0-1
> Severity: normal
> 
> Dear Maintainer,
> In Debian mate, previous versions of Mozilla Firefox used the
> high-lighting color (from the theme selected/used) while in the new
> version the highlighting while going through the different drop-down
> menus is unavailable. Can this be fixed ?
> 
> https://jumpshare.com/v/CMeKzSwl83vyRrEvzSEe also has the same video
> which I have attached, it shows the problem in case I have been unable
> to explain well.
> 
> Notice that the new version doesn't tell you which option you are
> choosing while in tor the green band always tells you visually which
> option you are taking.
> 
> The video has been bought to you by simplescreenrecorder.

Run gtk3-demo from the gtk-3-examples package. In the list it brings,
select "Menus" then click the "Run" button. Does the same happen there?

Mike

Bug#844697: maxima-emacs: imaxima does not load in maxima

[Emmanuel Charpentier]

Package: maxima-emacs
Version: 5.38.1-5
Severity: important

Dear Maintainer,

This is almost a duplicate of bug#842164 : maxima *cannot*
load /usr/share/emacs24/site-lisp/maxima/imaxima.lisp, which is
a symlink to /usr/share/emacs/site-lisp/maxima/imaxima.lisp, and
*can* be used :

Cut'n paste from emacs :

Maxima 5.38.1 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) block(load(("/usr/share/emacs24/site-lisp/maxima/imaxima.lisp")),
linenum:0)$

file_search1: /usr/share/emacs24/site-lisp/maxima/imaxima.lisp not found in
   file_search_maxima,file_search_lisp.
 -- an error. To debug this try: debugmode(true);

/* Manually done : */

(%i2) block(load(("/usr/share/emacs/site-lisp/maxima/imaxima.lisp")),
linenum:0)

After this load, imaxima works as expected...

The only maxima-related snippet in my .emacs is :

;; Pour (i)maxima
(setq imaxima-use-maxima-mode-flag t)

For completeness :
charpent@asus16-ec:~$ ls -l  /usr/share/emacs24/site-lisp/maxima/imaxima.lisp
lrwxrwxrwx 1 root root 46 nov.   4 09:00 /usr/share/emacs24/site-
lisp/maxima/imaxima.lisp -> /usr/share/emacs/site-lisp/maxima/imaxima.lisp
charpent@asus16-ec:~$ ls -l /usr/share/emacs/site-lisp/maxima/imaxima.lisp
-rw-r--r-- 1 root root 22299 nov.   1 14:00 /usr/share/emacs/site-
lisp/maxima/imaxima.lisp

HTH,

--
Emmanuel Charpentier



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

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

Versions of packages maxima-emacs depends on:
ii  emacs24 [emacsen]24.5+1-7
ii  emacsen-common   2.0.8
ii  maxima   5.38.1-5
ii  maxima-doc   5.38.1-5
ii  tex-common   6.05
ii  texlive-binaries [texlive-base-bin]  2016.20160513.41080-6
ii  texlive-latex-recommended2016.20161103-1

Versions of packages maxima-emacs recommends:
ii  evince [postscript-viewer]   3.22.1-2
ii  ghostscript [postscript-viewer]  9.19~dfsg-3.1
ii  mime-support 3.60
ii  xpdf [pdf-viewer]3.04-1+b1

maxima-emacs suggests no packages.

-- no debconf information

Bug#844699: ITP: tdiary-style-gfm -- GFM Style for tDiary

[Youhei SASAKI]

Package: wnpp
Owner: Youhei SASAKI 
Severity: wishlist

* Package name: tdiary-style-gfm
  Version : 0.4.0-1
  Upstream Author :  2003 TADA Tadashi 
 2004 MoonWolf 
 2012 kdmsnr 
 2013 hsbt 
* URL or Web page : https://github.com/tdiary/tdiary-style-gfm
* License : GPL-3+
  Description : GFM Style for tDiary

GFM Style for tDiary (>= 2.x) format.
.
The tDiary is a weblog system, which makes your weblog
communication-friendly for the writer (you) and readers. It consists of
Ruby scripts for CGI (Common Gateway Interface).
.
This package provides GFM(Github Flavored Markdown) style.
   

Bug#844655: plasma-desktop-5: problem with autostart

[chatrapati]

Excuse me.
"firefox-esr trying to go in IP-adress "%u" "
URI-adress insted of IP-adress.

Bug#844598: [haskell-stack] relocations errors on compiling

[frederic wagner]

hi,

ghc is working for me ; only stack is causing troubles.

i tried the latest upstream stack version with the same problem.

luckily someone pointed me to this thread : 
https://github.com/commercialhaskell/stack/issues/2712


using this hint made everything work :

"""

It builds in my case
Just adapt the ghc version which has the error (ghc-8.0.01 above or 
ghc-7.10 in my case:

~/.stack/programs/x86_64-linux/ghc-7.10.3/lib/ghc-7.10.3/settings )

cp settings settings.bak

And change the options as @senorhesles  
mentionned previously:

("C compiler flags", "-fno-PIE -fno-stack-protector"),
("C compiler link flags", "-no-pie"),
("ld flags", "-no-pie"),

It builds, yes, but I wonder the effects of adding such options 
(-no-pie) in long term use.
Ok for the hack but how long should we maintain it (mv settings.bak 
settings) ?


"""

i'm not too sure about upgrading to unstable.

thanks for the suggestion though

Fred

Le 17/11/2016 à 16:36, Ilias Tsitsimpis a écrit :

Hi Frederic,

On Thu, Nov 17, 2016 at 01:35PM, frederic wagner wrote:

I cannot build anything using stack.

to reproduce :

  stack new test simple
  cd test
  stack build

-> gives following output :
[1 of 1] Compiling Main ( /tmp/stack28309/Setup.hs,
/tmp/stack28309/Setup.o )
Linking 
/home/wagnerf/.stack/setup-exe-cache/x86_64-linux/tmp-setup-Simple-Cabal-1.24.0.0-ghc-8.0.1
...
/usr/bin/ld: /tmp/stack28309/Setup.o: relocation R_X86_64_32S against symbol
`stg_bh_upd_frame_info' can not be used when making a shared object;
recompile with -fPIC
/usr/bin/ld: 
/home/wagnerf/.stack/programs/x86_64-linux/ghc-8.0.1/lib/ghc-8.0.1/Cabal-1.24.0.0/libHSCabal-1.24.0.0.a(Simple__87.o):
relocation R_X86_64_32S against `.text' can not be used when making a shared
object; recompile with -fPIC

Thanks for reporting this.

The above works for me with haskell-stack and ghc both from unstable.
The current version of ghc in testing is known to be broken (see #712228):

   https://bugs.debian.org/712228

Could you give it a try?

Best,

Bug#844698: Uses hard-coded /run/media/ paths which don't work in Debian

[Michael Biebl]

Package: zulumount-cli
Version: 4.9.0-2
Severity: important

I tried to use zulumount-gui and cli together with cryfs.
Unfortunately this fails, the error message I get is that zulumount was
unable to create the mountpoint.

I suspect this is due to the use of /run/media/private/$USER

That directory does not exist here and /run is not writable for an
unprivileged user. As I run zulumount as user and not root, it is unable
to create that directory.



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

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

Versions of packages zulumount-cli depends on:
ii  libblkid1   2.29-1
ii  libc6   2.24-5
ii  libgcrypt20 1.7.3-2
ii  libzulucrypt-exe1.2.0   4.9.0-2
ii  libzulucrypt1.2.0   4.9.0-2
ii  libzulucryptpluginmanager1.0.0  4.9.0-2

zulumount-cli recommends no packages.

zulumount-cli suggests no packages.

-- no debconf information

Bug#834369: ITP: python-libusb1 -- Python wrapper for libusb1

[Arnaud Fontaine]

Hello,

> Any news on the ITP ?
> If I can help getting this packaged in any way, please tell me.

Sorry for the lag. I have prepared a package:
https://people.debian.org/~arnau/packages/python-libusb1_1.5.3-1_all.deb

And the git repository of the package:
https://anonscm.debian.org/cgit/python-modules/packages/python-libusb1.git/

Please try it out.

Cheers,
-- 
Arnaud Fontaine


signature.asc
Description: PGP signature

Bug#842555: QA upload

[Tobias Frost]

Hi Dimitry, 

On Sun, 06 Nov 2016 07:58:14 +0300 Dmitry Bogatov 
wrote:
> 
> [2016-11-03 09:37] "gustavo panizzo (gfa)" 
> >
> > I intend to do a QA upload for this package soon, if anybody wants
to be
> > the real maintainer, ping me I can handover my improvements to you
> 
> Hello! I am interested in tsocks maintainership and your
improvements.
> 

Gustavo did now thie QA upload, you're very welcome to adopt this
package now, if you're still interested.
Pease indicate this by retitling this bug to
"ITA: tsocks -- transparent network access through a SOCKS 4 or 5
proxy", so that everyone knows about your intentions.

Many thanks for contributing to Debian!

--
tobi

Bug#844433: libdr-tarantool-perl: Non-determistically FTBFS due to unreliable tests

[Chris Lamb]

Hi,

> I think Your build system (container?) is overloaded so these tests
> are not passed from time to time.
[..]
> So I'll reduce severity for the ticket. If the problem is appeared on
> debian buildd I'll do something.

Not entirely comfortable with that conclusion. If our users or QA tools
cannot reliably build your package, then that is surely a problem.


Regards,

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

Bug#844706: libssl1.1 needs Breaks on salt-common

[Adrian Bunk]

Package: libssl1.1
Version: 1.1.0c-1
Severity: serious
Control: block 827061 by -1
Control: block -1 by 843871

libssl1.1 needs a Breaks on salt-common versions without the fix
for #843871 to avoid breakages for users upgrading from jessie.

Bug#834228: more info

[Russell Coker]

~/systemd-tmpfiles --create /usr/lib/tmpfiles.d/systemd.conf

I copied /bin/systemd-tmpfiles to /root (so I can give it a different 
context).  When I run the above command after logging in as root:sysadm_r it 
sets the correct context.  But when I delete /run/utmp and run it again it 
doesn't recreate the file.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#844707: plasma-workspace: plasmadesktop - excessive cpu usage, slow desktop operation

[Tim Small]

Package: plasma-workspace
Version: 4:5.8.2-1
Severity: important

plasmashell consumes excessive CPU, increases over time.

Possibly I'm hitting a couple of bugs here, but I'm not sure...

plasmashell starts by stat()ing about 4 files per second, and
consuming 50% of one CPU core.  CPU then climbs to around 110% of one
core, and the stat() rate (under strace) falls to about 3 per second.

This is 10 seconds of strace output from a freshly started plasmashell:

http://buttersideup.com/plasmashell-debug/plasmashell-highcpu-strace-fresh

and a summary output taken afterwards:

http://buttersideup.com/plasmashell-debug/plasmashell-highcpu-strace-fresh-summary

These two are for processes that have been running longer, and have
climbed to >100% usage:

http://buttersideup.com/plasmashell-debug/plasmashell-highcpu-strace

http://buttersideup.com/plasmashell-debug/plasmashell-highcpu-strace-summary

Tim.


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

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

Versions of packages plasma-workspace depends on:
ii  dbus-x11 1.10.12-1
ii  frameworkintegration 5.27.0-1
iu  gdb  7.11.1-2+b1
ii  iso-codes3.70-1
ii  kactivitymanagerd5.8.2-1
ii  kde-cli-tools4:5.8.2-1
ii  kded55.27.0-1
ii  kinit5.27.0-1
ii  kio  5.27.0-2
ii  kpackagetool55.27.0-1
ii  libc62.24-5
ii  libcln6  1.3.4-2
ii  libdbusmenu-qt5-20.9.3+16.04.20160218-1
ii  libgcc1  1:6.2.0-13
ii  libgps22 3.16-4
ii  libice6  2:1.0.9-1+b1
ii  libkf5activities55.27.0-1
ii  libkf5auth5  5.27.0-1
ii  libkf5baloo5 5.27.0-1
ii  libkf5bookmarks5 5.27.0-1
ii  libkf5calendarevents55.27.0-1+b1
ii  libkf5completion55.27.0-1
ii  libkf5configcore55.27.0-1
ii  libkf5configgui5 5.27.0-1
ii  libkf5configwidgets5 5.27.0-1
ii  libkf5coreaddons55.27.0-1
ii  libkf5crash5 5.27.0-1
ii  libkf5dbusaddons55.27.0-1
ii  libkf5declarative5   5.27.0-1+b1
ii  libkf5globalaccel-bin5.27.0-1
ii  libkf5globalaccel5   5.27.0-1
ii  libkf5guiaddons5 5.27.0-1
ii  libkf5holidays5  16.04.2-1
ii  libkf5i18n5  5.27.0-2
ii  libkf5iconthemes55.27.0-1
ii  libkf5idletime5  5.27.0-1
ii  libkf5itemviews5 5.27.0-1
ii  libkf5jobwidgets55.27.0-1
ii  libkf5js55.27.0-1
ii  libkf5jsembed5   5.27.0-1
ii  libkf5kdelibs4support5   5.27.0-1
ii  libkf5kiocore5   5.27.0-2
ii  libkf5kiofilewidgets55.27.0-2
ii  libkf5kiowidgets55.27.0-2
ii  libkf5networkmanagerqt6  5.27.0-1
ii  libkf5newstuff5  5.27.0-1
ii  libkf5notifications5 5.27.0-1
ii  libkf5notifyconfig5  5.27.0-1
ii  libkf5package5   5.27.0-1
ii  libkf5plasma55.27.0-1
ii  libkf5plasmaquick5   5.27.0-1
ii  libkf5quickaddons5   5.27.0-1+b1
ii  libkf5runner55.27.0-1
ii  libkf5service-bin5.27.0-1
ii  libkf5service5   5.27.0-1
ii  libkf5solid5 5.27.0-1
ii  libkf5texteditor55.27.0-1
ii  libkf5textwidgets5   5.27.0-1
ii  libkf5wallet-bin 5.27.0-1
ii  libkf5wallet55.27.0-1
ii  libkf5waylandclient5 4:5.27.0-1
ii  libkf5widgetsaddons5 5.27.0-1
ii  libkf5windowsystem5  5.27.0-1
ii  libkf5xmlgui55.27.0-1
ii  libkf5xmlrpcclient5  5.27.0-1
ii  libkscreenlocker55.8.2-1
ii  libksgrd7

Bug#844220: maybe not /usr-merged but 0700 for / could be the culprit here

[Holger Levsen]

reassign 844220 usrmerge,debootstrap

Hi,

someone mailed me privately and pointed me to this forum post
https://bbs.archlinux.org/viewtopic.php?id=186056=2 which made me
realize that debootstrap had another change: TARGET is now created with
0700 permissions and not 0755 anymore, though I couldnt find this in
debootstrap's changelog, so maybe I'm confused.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844629: transcriber: sound stops after less than a second

[Giulio Paci]

Hi,
  thank you for your bug report. Unfortunately using transcriber with 
pulseaudio has always lead to issues.
As far as I know, the issues are shared among all the software that use snack 
library.

Can you check if you have similar experience with wavesurfer?

Best,
Giulio


On 17/11/2016 18:28, Frank Doepper wrote:
> Package: transcriber
> Version: 1.5.1.1-10
> Severity: important
> 
> Dear Maintainer,
> 
> trying to use transcriber in stretch I experience that the sound output
> stops after less than a second, although the cursor moves on. Stopping
> (with tab) and restarting starts playing again, which stops then again
> in the same way. Pulseaudio is installed, the transcriber sound source
> does not dissapear.
> 
> I would expect to hear the sound without interruption. I remember it
> worked some time ago (wheezy?), before Pulseaudio.
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages transcriber depends on:
> ii  libc6  2.24-5
> ii  libx11-6   2:1.6.3-1
> ii  sox14.4.1-5+b1
> ii  tcl-snack  2.2.10.20090623-dfsg-6
> ii  tcl-tclex  1.2a1-16
> ii  tcl8.5 8.5.19-2
> ii  tk 8.6.0+9
> ii  tk8.5  8.5.19-1
> 
> transcriber recommends no packages.
> 
> transcriber suggests no packages.
> 
> -- no debconf information
> 

Bug#844708: maildir-utils: `--clearlinks' option seems broken

[Gian Piero Carrubba]

Package: maildir-utils
Version: 0.9.17-1
Severity: important

Dear Maintainer,

thank you for your work on maildir-utils.

Version 0.9.17-1 seems to have broken the `--clearlinks' functionality,
at least on my system.

(ins) ~ $ mu find --muhome "${HOME}/.cache/mu" --format=links 
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/cur: No such file or 
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links 
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/cur: No such file or 
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links 
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/cur8: No such file or 
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links 
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/curK: No such file or 
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links 
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/cur: No such file or 
directory (73)
(cmd) ~ 73! mu find --muhome "${HOME}/.cache/mu" --format=links 
--linksdir="${HOME}/.cache/mu/results" --clearlinks email
mu: failed to open /home/gpiero/.cache/mu/results/curf: No such file or 
directory (73)


Please note the seemingly random chars added at the end of the directory
path it cannot found. Maybe when not shown it's a non-printable char?

Anyway:

$ ls -ld /home/gpiero/.cache/mu/results/cur
drwx-- 2 gpiero gpiero 4096 Nov 18 11:23 /home/gpiero/.cache/mu/results/cur

Path exists w/ right permissions.

Without the use of the `--clearlinks' option it works (but links
have to be manually removed). Downgrading to 0.9.16-1+b1 re-enables the
right behaviour for `--clearlinks'.

Thank you,
Gian Piero.


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

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

Versions of packages maildir-utils depends on:
ii  dpkg1.18.15
ii  guile-2.0-libs  2.0.13+1-2
ii  install-info6.3.0.dfsg.1-1+b1
ii  libc6   2.24-5
ii  libgc1c21:7.4.2-8
ii  libgcc1 1:6.2.0-13
ii  libglib2.0-02.50.2-1
ii  libgmime-2.6-0  2.6.20-8
ii  libstdc++6  6.2.0-13
ii  libxapian30 1.4.1-1

maildir-utils recommends no packages.

maildir-utils suggests no packages.

-- no debconf information

Bug#844709: certmonger: Certmonger runs its programs from nonexistent path

[Michal Kašpar]

Package: certmonger
Version: 0.78.6-4
Severity: important

Dear Maintainer,
I've noticed the certmonger processes ends as defunct in process list.
When looking into it via running certmonger in foreground debug mode
(certmonger -f -d 5), I've found out the certmonger tries to run its
components from /usr/lib/x86_64-linux-gnu/certmonger/ while they are
installed in /usr/lib/certmonger. The symlink 
/usr/lib/x86_64-linux-gnu/certmonger -> /usr/lib/certmonger fixes this, however 
the correct fix is probably either to install those binaries to arch dependent 
path or let them run from path where they are really installed.

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

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

Versions of packages certmonger depends on:
ii  dbus 1.10.12-1
ii  init-system-helpers  1.46
ii  libc62.24-5
ii  libcomerr2   1.43.3-1
ii  libcurl3-nss 7.51.0-1
ii  libdbus-1-3  1.10.12-1
ii  libidn11 1.33-1
ii  libk5crypto3 1.15~beta1-1
ii  libkrb5-31.15~beta1-1
ii  libldap-2.4-22.4.42+dfsg-2+b3
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1
ii  libpopt0 1.16-10
ii  libssl1.0.2  1.0.2j-4
ii  libtalloc2   2.1.8-1
ii  libtevent0   0.9.31-1
ii  libuuid1 2.29-1
ii  libxml2  2.9.4+dfsg1-2.1
ii  libxmlrpc-core-c31.33.14-3

certmonger recommends no packages.

certmonger suggests no packages.

-- no debconf information

Bug#844710: autocorrection suggested rm for typing mr without typing "y"

[Martin Steigerwald]

Package: zsh
Version: 5.2-5+b1
Severity: normal
Tags: upstream

Dear maintainer,

# Actual result

Both zsh 5.0.7-5 on Jessie…

ms@intraws:~/Backup/Mail/Linux#1> mr test
zsh: correct 'mr' to 'rm' [nyae]? n
zsh: command not found: mr

as well as 5.2-5+b1

ms@merkaba:~#127> mr test
zsh: correct 'mr' to 'rm' [nyae]? n
zsh: command not found: mr

suggest "rm" for "mr" but on simply typing return they choose "n", which is
a sane default.

Yet, I had this:

ms@intraws:~/Backup/Mail/Linux> mr kernel-ml_archive.gz 
kernel-ml_archive_2014-1b.gz
zsh: correct 'mr' to 'rm' [nyae]?
rm: das Entfernen von „kernel-ml_archive_2014-1b.gz“ ist nicht möglich: Datei 
oder Verzeichnis nicht gefunden

I didn´t type yes, as when I type "y", it is shown on command line:

ms@intraws:~/Backup/Mail/Linux#1> LANG=C mr test
zsh: correct 'mr' to 'rm' [nyae]? y
rm: cannot remove 'test': No such file or directory

And I really didn´t type "y" there, I am pretty sure of that, but I may
have hit another key by accident. And lost a (not so important) file, as
it was completed after last snapshot was being taken.

Unfortunately so far I have no idea on how to reproduce this.


# Expected results

1. Never autocorrect until I say "y"!

Ideally also:

2. Do not autocorrect to dangerous commands.


I think this is an upstream issue and would also report it there, if it shelps.

Thanks,
Martin


-- Package-specific info:
Packages which depend, recommend, suggest or enhance a zsh package and hence 
may provide code meant to be sourced in .zshrc:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture  
  Description
+++-=-===-===-===
ii  fizsh 1.0.7-1 all   
  Friendly Interactive ZSHell
ii  zsh-syntax-highlighting   0.5.0-1 all   
  Fish shell like syntax highlighting for zsh
debsums: missing file /etc/fizsh/modify-etc-shells.zsh (from fizsh package)

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture  
  Description
+++-=-===-===-===
ii  curl  7.51.0-1amd64 
  command line tool for transferring data with URL syntax
ii  git-buildpackage  0.8.6   all   
  Suite to help with Debian packages in Git repositories
ii  mpv   0.21.0-2amd64 
  video player based on MPlayer/mplayer2
ii  pass  1.6.5-3 all   
  lightweight directory-based password manager
ii  pdfgrep   1.4.1-2 amd64 
  search in pdf files for strings matching a regular expression
ii  pulseaudio9.0-5   amd64 
  PulseAudio sound server
ii  sysdig0.9.0-1 amd64 
  system-level exploration and troubleshooting tool
ii  systemd   232-3   amd64 
  system and service manager
ii  systemd-container 232-3   amd64 
  systemd container/nspawn tools
ii  udev  232-3   amd64 
  /dev/ and hotplug management daemon
ii  vlc-bin   2.2.4-8 amd64 
  binaries from VLC

The following files were modified:

/etc/systemd/resolved.conf
/etc/pulse/daemon.conf

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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

Versions of packages zsh depends on:
ii  dpkg1.18.15
ii  libc6   2.24-5
ii  libcap2 1:2.25-1
ii  libtinfo5   6.0+20160917-1
ii  zsh-common  5.2-5

Versions of packages zsh recommends:
ii  libc6  

Bug#844711: libxkbcommon: Documentation incomplete, needs B-D graphviz

[Jakob Haufe]

Source: libxkbcommon
Version: 0.6.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

libxkbcommon uses doxygen which in turn needs dot from graphviz.

See [1] line 1121+ and e.g. [2].

Should be fixed by adding graphviz as build dependency.

Cheers,
sur5r

[1] 
https://buildd.debian.org/status/fetch.php?pkg=libxkbcommon=i386=0.6.1-1=1471852715
[2] /usr/share/doc/libxkbcommon-dev/graph_legend.html

- -- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libxkbcommon-dev depends on:
ii  libxkbcommon0  0.6.1-1

libxkbcommon-dev recommends no packages.

libxkbcommon-dev suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYLtwJAAoJEEzyshj1Ta49V/UP/0odVEA+7UEY04ufdUR2sFIJ
JTue/3OC83UM1dqZjsgNvtoxD4gYwQfXw0pcNG20Y8H/v0lbnA3glftAP/nV5FdL
4iBJDOMbKdTsAqUI/Ked7DtNzDbueO4TTD9DQrzZBinJx79n0G5khY16/Ko2WBVn
JtP0NyYWYFzvWaKgAUfMQwNy09kqQExGkXr53lVJNu4htwkHmlw24cWWczmvJHm8
If9J7PftOWrOgnr1h0zt+0iHcrtLyuz3gVR0XL5RytXIlf3wCJYI56vFn3p9/V0X
aTpCOzqdTLV+8Y+XLCjOB0bp26qlmkzgOJ625V3qs8h/c0f6izRhwNGtNx0EQQx8
Y0lvQabTWbbzVcc7gnwobKqnG4F8xxCYs3THG+j/YO3xcUivnBmoOsdCjuG7osdx
GlUC6zv/9p4hfxctx1yArqP6nGzLt/IORQKdvdInsjcE/8Mqwsmhs5j00Fy/3rRU
MvVumRUhxwUBaGiBaFLmaYs8HyAk7UsG2tPICaichGnDqodK/BIULtXWa3lN0ko4
e/l/915zg7jcfnwlwqViYQK+FHSYhMCmXn1WMbYK4p5tgmYxBLtznJW3fQkcX3yl
ZgDOOdUufONObCwq9ldYRy9Z+RUgILzP/luAGtPHMUn/dcWvJp3vFU1wGGSu45CL
Wa4HMoT38zLs7kLuklKC
=ZEcS
-END PGP SIGNATURE-

Bug#844433: libdr-tarantool-perl: Non-determistically FTBFS due to unreliable tests

[Dmitry E. Oboukhov]

severity 844433 important
thanks

the package contains some tests that relay to the other program
(tarantool_box) does something while fixed interval exceeded.

I think Your build system (container?) is overloaded so these tests
are not passed from time to time.

Debian's buildd built the package successfully.

So I'll reduce severity for the ticket. If the problem is appeared on
debian buildd I'll do something.
Now the package is (de-facto) LTS, so I don't want to change it. I
also don't want to disable tests.


> Source: libdr-tarantool-perl
> Version: 0.45-2
> 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,

> libdr-tarantool-perl's testsuite appears to non-deterministically fail, 
> causing
> itself to FTBFS.

> Using wall-clock time is inherently unreliable.

> […]

> #   Failed test 'total time less than 1 second'
> #   at t/090-parallel-requests.t line 153.
> # '8.6400101184845'
> # <=
> # '1'
> # Looks like you failed 1 test of 48.
> t/090-parallel-requests.t ...
> 1..48
> ok 1 - use DR::Tarantool::LLClient;
> ok 2 - use DR::Tarantool;
> ok 3 - use File::Spec::Functions;
> ok 4 - use File::Basename;
> ok 5 - use AnyEvent;
> ok 6 - use DR::Tarantool::AsyncClient;
> ok 7 - directory with test data
> ok 8 - t/test-data/llc-easy2.cfg
> ok 9 - -d t/test-data
> ok 10 - -r t/test-data/init.lua
> ok 11 - An object of class 'DR::Tarantool::AsyncClient' isa 
> 'DR::Tarantool::AsyncClient'
> ok 12 - first call test_parallel: status
> ok 13 - return value
> ok 14 - id: 6
> ok 15 - delay minimum
> ok 16 - delay maximum
> ok 17 - id: 1
> ok 18 - delay minimum
> ok 19 - delay maximum
> ok 20 - id: 4
> ok 21 - delay minimum
> ok 22 - delay maximum
> ok 23 - id: 7
> ok 24 - delay minimum
> ok 25 - delay maximum
> ok 26 - id: 3
> ok 27 - delay minimum
> ok 28 - delay maximum
> ok 29 - id: 10
> ok 30 - delay minimum
> ok 31 - delay maximum
> ok 32 - id: 2
> ok 33 - delay minimum
> ok 34 - delay maximum
> ok 35 - id: 5
> ok 36 - delay minimum
> ok 37 - delay maximum
> ok 38 - id: 9
> ok 39 - delay minimum
> ok 40 - delay maximum
> ok 41 - id: 8
> ok 42 - delay minimum
> ok 43 - delay maximum
> ok 44 - id: 0
> ok 45 - delay minimum
> ok 46 - delay maximum
> ok 47 - total time
> not ok 48 - total time less than 1 second
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/48 subtests

> […]

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

> https://tests.reproducible-builds.org/debian/logs/unstable/amd64/libdr-tarantool-perl_0.45-2.build2.log.gz

> Regards,

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

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Bug#844703: [l10n] Updated Czech translation of apt-listbugs

[Miroslav Kure]

Package: apt-listbugs
Severity: wishlist
Tags: l10n, patch

Hi,

in attachement there is updated Czech (cs.po) translation of 
apt-listbugs. Please include it with the package.

Thank you
-- 
Miroslav Kure
# Czech translation of apt-listbugs.
# Copyright (C) 2002-2014 Masato Taruishi et al.
# This file is distributed under the same license as the apt-listbugs package.
# Miroslav Kure , 2005, 2009, 2012, 2014, 2016.
#
msgid ""
msgstr ""
"Project-Id-Version: apt-listbugs 0.1.16\n"
"Report-Msgid-Bugs-To: invernom...@paranoici.org\n"
"POT-Creation-Date: 2016-09-25 17:59+0200\n"
"PO-Revision-Date: 2016-11-18 10:06+0100\n"
"Last-Translator: Miroslav Kure \n"
"Language-Team: Czech \n"
"Language: cs\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2;\n"

#. TRANSLATORS: "E: " is a label for error messages; you may translate it with 
a suitable abbreviation of the word "error"
#: ../bin/apt-listbugs:416 ../bin/apt-listbugs:449 ../bin/apt-listbugs:454
#: ../bin/apt-listbugs:460 ../bin/apt-listbugs:474 ../bin/apt-listbugs:504
#: ../bin/apt-listbugs:535 ../bin/apt-listbugs:584 ../bin/apt-listbugs:597
#: ../lib/aptlistbugs/aptcleanup:52 ../lib/aptlistbugs/aptcleanup:55
#: ../lib/aptlistbugs/logic.rb:285 ../lib/aptlistbugs/logic.rb:295
#: ../lib/aptlistbugs/logic.rb:931 ../lib/aptlistbugs/logic.rb:943
#: ../lib/aptlistbugs/logic.rb:956 ../lib/aptlistbugs/migratepins:52
#: ../lib/aptlistbugs/migratepins:55
msgid "E: "
msgstr "E: "

#: ../bin/apt-listbugs:417
msgid "This may be caused by a package lacking support for the ruby interpreter 
in use. Try to fix the situation with the following commands:"
msgstr "To může být způsobeno balíkem bez podpory použitého interpretru ruby. 
Zkuste vzniklou situaci vyřešit těmito příkazy:"

#: ../bin/apt-listbugs:449
msgid "APT_HOOK_INFO_FD is undefined.\n"
msgstr "APT_HOOK_INFO_FD není definovaná.\n"

#: ../bin/apt-listbugs:454
msgid "APT_HOOK_INFO_FD is not correctly defined.\n"
msgstr "APT_HOOK_INFO_FD není definovaná správně.\n"

#: ../bin/apt-listbugs:460
msgid "Cannot read from file descriptor %d"
msgstr "Nelze číst z deskriptoru souboru %d"

#: ../bin/apt-listbugs:474
msgid "APT Pre-Install-Pkgs is not giving me expected 'VERSION 3' string.\n"
msgstr "APT Pre-Install-Pkgs nevrací očekávaný řetězec „VERSION 3“.\n"

#: ../bin/apt-listbugs:504
msgid "APT Pre-Install-Pkgs is giving me fewer fields than expected.\n"
msgstr "APT Pre-Install-Pkgs vrací méně polí, než je očekáváno.\n"

#: ../bin/apt-listbugs:535
msgid "APT Pre-Install-Pkgs is giving me an invalid direction of version 
change.\n"
msgstr "APT Pre-Install-Pkgs vrací neplatný směr změny verze.\n"

#: ../bin/apt-listbugs:614
msgid "** Exiting with an error in order to stop the installation. **"
msgstr "** Ukončeno s chybou s cílem ukončit instalaci. **"

#: ../lib/aptlistbugs/aptcleanup:52 ../lib/aptlistbugs/logic.rb:355
#: ../lib/aptlistbugs/migratepins:52
msgid "Cannot read from %s"
msgstr "Nelze číst z %s"

#: ../lib/aptlistbugs/aptcleanup:123
msgid "Fixed packages : "
msgstr "Opravené balíky: "

#: ../lib/aptlistbugs/logic.rb:47
msgid "Usage: "
msgstr "Použití: "

#: ../lib/aptlistbugs/logic.rb:48
msgid " [options]  [arguments]"
msgstr " [volby]  [argumenty]"

#: ../lib/aptlistbugs/logic.rb:50
msgid "Options:\n"
msgstr "Volby:\n"

#. TRANSLATORS: the colons (:) in the following strings are vertically aligned, 
please keep their alignment consistent
#. TRANSLATORS: the \"all\" between quotes should not be translated
#: ../lib/aptlistbugs/logic.rb:53
msgid ""
" -s   : Filter bugs by severities you want to see\n"
"(or \"all\" for all)\n"
"[%s].\n"
msgstr ""
" -s   : Zobrazí jen chyby daných závažností\n"
"(nebo „all“ pro všechny)\n"
"[%s].\n"

#: ../lib/aptlistbugs/logic.rb:54
msgid " -T : Filter bugs by tags you want to see.\n"
msgstr " -T <štítky>  : Zobrazí jen chyby s danými štítky.\n"

#: ../lib/aptlistbugs/logic.rb:55
msgid ""
" -S   : Filter bugs by pending-state categories you want to see\n"
"[%s].\n"
msgstr ""
" -S: Zobrazí jen chyby daných stavů\n"
"[%s].\n"

#: ../lib/aptlistbugs/logic.rb:56
msgid " -B : Filter bugs by number, showing only the specified 
bugs.\n"
msgstr " -B   : Zobrazí pouze chyby daných čísel.\n"

#: ../lib/aptlistbugs/logic.rb:57
msgid " -D   : Show downgraded packages, too.\n"
msgstr " -D   : Vypíše také chyby v degradovaných balících.\n"

#: ../lib/aptlistbugs/logic.rb:58
msgid " -H : Hostname of Debian Bug Tracking System [%s].\n"
msgstr " -H  : Jméno počítače na němž běží debianí BTS [%s].\n"

#: ../lib/aptlistbugs/logic.rb:59
msgid " -p : 

Bug#844655: plasma-desktop-5: problem with autostart

[chatrapati]

I think, my message is difficult to understand. Excuse me for my English.

I put file "firefox-esr.desktop" in ~/.config/autostart/ and when I 
reboot system firefox-esr trying to go in URI-adress http://www.%u.com/ 
. So I have an error "server is not found".There is a string 
"Exec=firefox-esr %u" in firefox-esr.desktop


I do similarly with "inkscape.desktop". I have similar problem: inkscape 
starting trying to open file with name "%F", but there is no file with 
this name! There is a string "Exec=inkscape %F" in file inkscape.desktop".


So I should to delete these "%u" and "%F" in files *.desktop if I use 
them (*.desktop) in .config/autostart/

Bug#844598: [haskell-stack] relocations errors on compiling

[frederic wagner]

just a small mail to confirm it works correctly in unstable

Fred

Thanks for reporting this.

The above works for me with haskell-stack and ghc both from unstable.
The current version of ghc in testing is known to be broken (see #712228):

   https://bugs.debian.org/712228

Could you give it a try?

Best,

Bug#844705: libedit-dev: Missing build dependency - ncurses

[Mark Gillott]

Package: libedit-dev
Version: 3.1-20160903-1
Severity: normal

Dear Maintainer,

An application makes use of the libedit-dev library. In a recent updated
from Debian8 to Debian9 the (previously working) build failed. The
reason for the failure was a missing library - ncurses:

[   68s] cc -g -fdebug-prefix-map=/usr/src/packages/BUILD=.
-fstack-protector-strong -Wformat -Werror=format-security -O3 -g -Wall
-Wextra -Werror -I/usr/include/json-c -I/usr/include/editline
-Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I ../ctrldb -Wl,-z,relro
-o vplsh \
[   68s]   vplsh.o ../ctrldb/ctrldb.o -lczmq -lzmq -ljson-c -ledit
-lncurses -lbsd
[   68s] /usr/bin/ld: cannot find -lncurses
[   68s] collect2: error: ld returned 1 exit status
[   68s] Makefile:21: recipe for target 'vplsh' failed
[   68s] make[2]: *** [vplsh] Error 1

The line in the makefile is simply:

   VPLSH_LIBS  = $(LIBS) $(shell pkg-config --libs libedit)

The fix was to modify the application control file so as to add
libncurses5-dev as an explicit dependency.

Ultimately the libedit-dev package file should have called out the
dependency and pulled in the necessary support library. Either that or
eliminate ncurses if its not actually required.

Thanks,

Mark

Bug#844700: pbuilder: please support build profiles

[James Clarke]

Control: retitle -1 pbuilder: Add --profiles flag

Hi,
> On 18 Nov 2016, at 08:22, Samuel Thibault  wrote:
> 
> Package: pbuilder
> Version: 0.226.1
> Severity: wishlist
> 
> Hello,
> 
> When bootstrapping a package which depends on itself (directly or
> through a loop), one uses e.g.
> 
> dpkg-buildpackage -Pstage1
> 
> which disables the self-dependency in Build-Depends.
> 
> However, using
> 
> pdebuild --debbuildopts -Pstage1
> 
> tries to install the self-dependency, I have to explicitly remove the
> dependency from debian/control.
> 
> It would be nice if pdebuild had a way to specify a build profile, so
> that it only tries to install what is needed for the bootstrap.

There's no flag that I know of (we should probably add one), but
setting DEB_BUILD_PROFILES should work and be honoured by
all the resolvers (except gdebi). --debbuildopts doesn't look
inside its argument, hence why the resolvers don't know to use
certain build profiles.

Regards,
James

Bug#844709: [Pkg-freeipa-devel] Bug#844709: Bug#844709: certmonger: Certmonger runs its programs from nonexistent path

[Michal Kašpar]

No. After start/stop (without editing the cas/* files) the problem
remains.

-- 
Michal Kašpar

Bug#843402: reprepro cannot handle .changes files that reference .buildinfo files

[Guillem Jover]

Hi!

On Sun, 2016-11-06 at 14:16:14 +0100, Helmut Grohne wrote:
> Package: reprepro
> Version: 4.17.1-1
> Severity: important
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> Since dpkg 1.18.11, a .buildinfo file is generated as part of package
> builds and referenced by .changes files. Supplying such a .changes file
> to "reprepro include" results in an error:
> 
> | Unknown file type: '2d3e9992648837b6a4a8a5b819e6da8e 4791 devel optional 
> binutils_2.27.51.20161105-1_20161106T104833z-2d3e9992.buildinfo', assuming 
> source format...
> | .changes put in a
> | distribution not listed within it!
> | Ignoring as --ignore=wrongdistribution given.
> | 'binutils_2.27.51.20161105-1_20161106T104833z-2d3e9992.buildinfo' looks 
> like part of an source package, but no dsc file listed in the .changes file!
> | There have been errors! 
>   
>   
> 
> So any workflow based on importing .changes files from unstable (soon
> stretch) is now broken.

I've just prepared a patch supposedly fixing this, but I've never used
reprepro and don't even know how it works, so it's just built-tested.
We are now performing some tests, and will update the report once this
is confirmed to work.

(The preliminary and perhaps non-working patch can be found for now at
https://www.hadrons.org/~guillem/tmp/0001-Add-preliminary-.buildinfo-support.patch)

Thanks,
Guillem

Bug#844716: speedtest-cli: please consider packaging 1.0.0

[Félix Sipma]

Package: speedtest-cli
Version: 0.3.4-1
Severity: wishlist

Upstream recently released 1.0.0. Could you please consider packaging it?


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

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

Versions of packages speedtest-cli depends on:
ii  python2.7.11-2
ii  python-pkg-resources  28.7.1-1

speedtest-cli recommends no packages.

speedtest-cli suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles

[Dimitri John Ledkov]

On 18 November 2016 at 11:56, Steve McIntyre  wrote:
> On Fri, Nov 18, 2016 at 11:44:25AM +, Dimitri John Ledkov wrote:
>>Package: wnpp
>>Owner: Dimitri John Ledkov 
>>Severity: wishlist
>>
>>* Package name: partman-swapfile
>>  Version : 1
>>  Upstream Author : d-i team
>>* URL or Web page : d-i
>>* License : GPL
>>  Description : add support for creating swapfiles
>>
>>I am working on minimising number of partitions used in the default
>>instalations in Ubuntu.
>
> Might I ask why?

Multiple reasons. Mostly surrounding supportability, and flexibility
for migrations / future changes.

There are a lot of people with dedicated /boot partitions, which are
full, preventing security kernel upgrades to succeed. At the same
time, people who are vulnerable to this, have no idea what a /boot
partition is, or how to run $ sudo apt autoremove to remove old
kernels. Booting off LVM, makes /boot part of the rootfs and hopefully
reduces chances of running out of all the disk space, because even
less sophisticated users tend to notice that.

As a side-effect this makes /boot an ext4 filesystem in more cases.
I'm thinking to move /boot to be ext4 by default in Ubuntu. Such that
it is the same regardless of the autopartitioning method.

Similarly with swap. One can dynamically resize/remove swapfile to add
swap or reclaim disk-space. And I am seeing a lot of systems that have
missized swaps. Having a 512GB swap, on a 1TB NVMe hard drive is
obscene when one has 256GB RAM. Other distributions (e.g. RHEL) have
started to limit swap well below the total amount of RAM. Note, in
Ubuntu, hibernation is disabled by default, therefore swap is only
used for the purpose of extreme memory pressure when things balloon
(e.g. during large process start-up before parts of it can be swapped
out).

Backup & restore / migration is simplified if a single partition
represents all of Ubuntu. This has been the case for a long time, on
e.g. cloud images. (UEFI & PReP partitions notwithstanding Har Har
Har)

Hence, it's just a general simplification, to make sure that default
installations are as sensible and as future proof as possible, and are
easier to modify if one realizes that one has miss-sized things.

Given that grub2 can unlock luks partitions, I wish it had some way to
pass the encryption secret to the kernel, such that /boot can be on
encrypted LVM as well, without needing to type the full disk
encryption passphrase twice on boot.

Note, that Debian supports a lot more architectures and a wider range
of machine configurations. I only have insight in a subset of these,
thus I am aware that above goals are potentially unachievable on the
more exotic machine types & bootloaders.

-- 
Regards,

Dimitri.

Bug#844339: [PATCH v2 2/4] libvirt-daemon-system.{config,templates,postinst}: warn if allocated uid/gid cannot be used

[Mauricio Faria de Oliveira]

On 11/18/2016 06:24 AM, Guido Günther wrote:

Exactly. That's why NEWS.Debian is nicer iff the user libvirt-qemu
exists but with "wrong" (legacy) uid/gid on existing installations and
Debconf is better for new installations where the uid/gid is already
taken.


Thanks for the debconf/NEWS.Debian clarifications; finally got it!
Totally agree w/ your point now. I'll spin the v3 w/ those changes.

cheers,

--
Mauricio Faria de Oliveira
IBM Linux Technology Center

Bug#844700: pbuilder: please support build profiles

[Samuel Thibault]

Hello,

James Clarke, on Fri 18 Nov 2016 10:56:28 +, wrote:
> but setting DEB_BUILD_PROFILES should work and be honoured by all the
> resolvers (except gdebi).

Oh, right, that can work already, indeed.

> --debbuildopts doesn't look inside its argument, hence why the
> resolvers don't know to use certain build profiles.

Sure :)

Samuel

Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles

[Steve McIntyre]

On Fri, Nov 18, 2016 at 11:44:25AM +, Dimitri John Ledkov wrote:
>Package: wnpp
>Owner: Dimitri John Ledkov 
>Severity: wishlist
>
>* Package name: partman-swapfile
>  Version : 1
>  Upstream Author : d-i team
>* URL or Web page : d-i
>* License : GPL
>  Description : add support for creating swapfiles
>
>I am working on minimising number of partitions used in the default
>instalations in Ubuntu.

Might I ask why?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Bug#844715: openssl: segfault in shlibloadtest (observed on x32) due to dlopen/dlclose/OPENSSL_atexit/OPENSSL_cleanup ordering

[Thorsten Glaser]

Source: openssl
Version: 1.1.0c-1
Severity: important

[…]
ok 1 - running secmemtest
ok
../util/shlib_wrap.sh ./shlibloadtest -crypto_first libcrypto.so libssl.so => 
139

#   Failed test 'running shlibloadtest -crypto_first'
#   at ../test/recipes/90-test_shlibload.t line 30.
../util/shlib_wrap.sh ./shlibloadtest -ssl_first libcrypto.so libssl.so => 0
../util/shlib_wrap.sh ./shlibloadtest -just_crypto libcrypto.so libssl.so => 0
# Looks like you failed 1 test of 3.
../test/recipes/90-test_shlibload.t 
1..3
not ok 1 - running shlibloadtest -crypto_first
Success
ok 2 - running shlibloadtest -ssl_first
Success
ok 3 - running shlibloadtest -just_crypto
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/3 subtests 
[…]

The cause here seems to be:

(pbuild24392)root@tglase:/tmp/buildd/openssl-1.1.0c # export SHELL=/bin/sh 
LD_LIBRARY_PATH=/tmp/buildd/openssl-1.1.0c:/usr/lib/libeatmydata:/usr/lib/libeatmydata
(pbuild24392)root@tglase:/tmp/buildd/openssl-1.1.0c # gdb --args 
test/shlibloadtest -crypto_first libcrypto.so libssl.so
GNU gdb (Debian 7.10-1.1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnux32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test/shlibloadtest...done.
(gdb) r
Starting program: /tmp/buildd/openssl-1.1.0c/test/shlibloadtest -crypto_first 
libcrypto.so libssl.so
warning: linux_ptrace_test_ret_to_nx: Cannot PTRACE_PEEKUSER: Input/output error
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnux32/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0xf6745c50 in ?? ()
(gdb) bt
#0  0xf6745c50 in ?? ()
#1  0xf6ac51c5 in OPENSSL_cleanup () at crypto/init.c:395
#2  0xf724fece in __cxa_finalize () from /lib/x86_64-linux-gnux32/libc.so.6
#3  0xf69d80d1 in __do_global_dtors_aux () from 
/tmp/buildd/openssl-1.1.0c/libcrypto.so
#4  0xce90 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) frame 1
#1  0xf6ac51c5 in OPENSSL_cleanup () at crypto/init.c:395
395 currhandler->handler();
(gdb) list
390  */
391 ossl_init_thread_stop(ossl_init_get_thread_local(0));
392
393 currhandler = stop_handlers;
394 while (currhandler != NULL) {
395 currhandler->handler();
396 lasthandler = currhandler;
397 currhandler = currhandler->next;
398 OPENSSL_free(lasthandler);
399 }
(gdb) print *currhandler
$1 = {handler = 0xf6745c50, next = 0x0}
(gdb) x/i currhandler->handler
   0xf6745c50:  Cannot access memory at address 0xf6745c50

So, when does that value get written?

(gdb) x/4xc currhandler
0x5675b170: 80 'P'  92 '\\' 116 't' -10 '\366'

This looks only vaguely ASCII-ish, so that’s not like it.

The memory map of the process is:

tglase@tglase:~ $ sudo cat /proc/13583/maps
56555000-56556000 r-xp  fd:00 4511408
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/test/shlibloadtest
56755000-56756000 r--p  fd:00 4511408
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/test/shlibloadtest
56756000-56757000 rw-p 1000 fd:00 4511408
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/test/shlibloadtest
56757000-56779000 rw-p  00:00 0  [heap]
f6982000-f6bbf000 r-xp  fd:00 4511417
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/libcrypto.so.1.1
f6bbf000-f6dbf000 ---p 0023d000 fd:00 4511417
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/libcrypto.so.1.1
f6dbf000-f6dd1000 r--p 0023d000 fd:00 4511417
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/libcrypto.so.1.1
f6dd1000-f6dda000 rw-p 0024f000 fd:00 4511417
/var/cache/pbuilder/build/cow.24367/tmp/buildd/openssl-1.1.0c/libcrypto.so.1.1
f6dda000-f6dde000 rw-p  00:00 0 
f6dde000-f6dfe000 r-xp  fd:00 2304977
/var/cache/pbuilder/build/cow.24367/lib/x86_64-linux-gnux32/libtinfo.so.5.9
f6dfe000-f6ffe000 ---p 0002 fd:00 2304977
/var/cache/pbuilder/build/cow.24367/lib/x86_64-linux-gnux32/libtinfo.so.5.9
f6ffe000-f700 r--p 0002 fd:00 

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Lluís Vilanova]

Petter Reinholdtsen writes:

> [Lluís Vilanova]
>> The package currently fails to run its tests during build due to
>> insufficient permissions to access Linux's perf interface.

> Is there some way to figure out if such permissions are missing or not?

> On my machine, where the build work, the value of 
> /proc/sys/kernel/perf_event_paranoid is '1', so '0' is not required.

> I notice the autobuilders work, the ci.debian.org builders work, but the
> reproducable build builders do not.  No idea what the difference is.

I've rechecked, and things seem to be a bit different...

For some reason my kernel (4.7.0-1-amd64) ignores changes through the file
system. It's more reliable to use:

  /sbin/sysctl kernel.perf_event_paranoid
  sudo /sbin/sysctl kernel.perf_event_paranoid=

Now, I've tried on a nother machine, and (strangely) the kernel starts with a
perf paranoid level of 3, which is not even documented as a valid value on
Linux's source code.

Getting it down to 2 is sufficient to run the check successfully.

A possible check could be:

  if [ `/sbin/sysctl kernel.perf_event_paranoid` -gt 2 ]; then
  echo "ERROR: perf is too paranoid for us"
  exit 1
  fi

This would build-depend on procps (which installs sysctl).

Cheers,
  Lluis

Bug#844710: [Pkg-zsh-devel] Bug#844710: autocorrection suggested rm for typing mr without typing "y"

[Axel Beckert]

Control: tag -1 + confirmed
Control: found -1 5.0.7-5
Control: found -1 4.3.17-1

Hi Martin,

Martin Steigerwald wrote:
> ms@intraws:~/Backup/Mail/Linux> mr kernel-ml_archive.gz 
> kernel-ml_archive_2014-1b.gz
> zsh: correct 'mr' to 'rm' [nyae]?
> rm: das Entfernen von „kernel-ml_archive_2014-1b.gz“ ist nicht möglich: Datei 
> oder Verzeichnis nicht gefunden
> 
> I didn´t type yes, as when I type "y", it is shown on command line:
> 
> ms@intraws:~/Backup/Mail/Linux#1> LANG=C mr test
> zsh: correct 'mr' to 'rm' [nyae]? y
> rm: cannot remove 'test': No such file or directory
> 
> And I really didn´t type "y" there, I am pretty sure of that, but I may
> have hit another key by accident.

Indeed scary.

>From the output it look to as if "Enter" had been pressed on a
first glance. But if I press "Enter" (on Sid at least) it shows an "n"
instead afterwards. (Since I have mr installed, I tested it with "rmm"
which is only available if nmh or mailutils-mh is installed.)

After some experimenting I noticed that while pressing Enter is
equivalent to pressing "n" and also prints an "n", pressing the space
bar is equivalent to "y" _without_ printing a "y".

So you very likely hit the space bar accidentially.

I was able to reproduce this behaviour on Debian 7 Wheezy, Debian 8
Jessie and Debian Sid.

> 2. Do not autocorrect to dangerous commands.

You might want to have a look at CORRECT_IGNORE in zshall(1).

CORRECT_IGNORE=rm did the trick for me.

> I think this is an upstream issue and would also report it there, if
> it helps.

Thanks for the offer, appreciated. And yes, I also think that is very
likely an upstream issue, so please do. Write an e-mail to
zsh-work...@zsh.org for that.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#841247: [Calendarserver-maintainers] Bug#841247: calypso: UnicodeDecodeError when importing an .ics

[Mathias Behrle]

* Guido Günther: " Re: [Calendarserver-maintainers] Bug#841247: calypso:
  UnicodeDecodeError when importing an .ics" (Thu, 17 Nov 2016 20:22:46 +0100):

> On Thu, Nov 17, 2016 at 01:20:59PM +0100, Mathias Behrle wrote:
> > * Guido Günther: " Re: [Calendarserver-maintainers] Bug#841247: calypso:
> >   UnicodeDecodeError when importing an .ics" (Wed, 2 Nov 2016 21:30:21
> > +0100):
> > 
> > Hi Guido,
> >   
> > > Hi Mathias,
> > > 
> > > On Wed, Nov 02, 2016 at 01:14:02PM +0100, Mathias Behrle wrote:  
> > > > control: affects -1 + tryton-modules-calendar
> > > > tryton-modules-calendar-classification
> > > > tryton-modules-calendar-scheduling tryton-modules-calendar-todo
> > > > tryton-modules-party-vcarddav tryton-meta   
> > > > > From: Guido Günther 
> > > > > To: Jens Reyer , 841...@bugs.debian.org
> > > > > Subject: Re: Bug#841247: calypso: UnicodeDecodeError when importing
> > > > > an .ics Date: Sun, 23 Oct 2016 12:28:37 +0200
> > > >  
> > > > 
> > > > Hi Guido,
> > > > 
> > > > > The unicode handling for python 2.7 got broken in upstream commit
> > > > > 
> > > > > 
> > > > > https://github.com/eventable/vobject/commit/b3f9bbcf4cf222f0dda3ac29f96364c5d7ab5f16
> > > > > 
> > > > > Let's see if upstream cares at all. If not we should rather drop the
> > > > > python2.7 version for stretch.
> > > > 
> > > > There are currently 6 Tryton modules affected as rdepends of
> > > > python-vobject. There are still some bits in the Tryton framework
> > > > lacking Python3 support, so it is currently not possible to switch the
> > > > whole Tryton stuff to Python3 (and I suppose this won't be the case for
> > > > stretch). Dropping the Python2 version of python-vobject would
> > > > seriously hurt those Tryton modules. So please let's find a way to keep
> > > > the Python2 version in the archive (for stretch).
> > > 
> > > It breaks calyso as well which I'd rather see in the archive than
> > > removed.
> > > 
> > > The bug is fixable. Someone needs to sit down and cook a patch. I have
> > > it on the TODO list but work is piling up at the moment - but I hope to
> > > get it done til the end of the year.  
> > 
> > While I am currently not able to assist in making a patch I had a quite
> > intensive test with a complete Tryton calendar setup using vobject 0.9.3
> > under Python2. It is working like a charm. So it seems the Tryton modules
> > are not *directly* affected by this bug.
> > 
> > I would want to elaborate the different measures to take now (time is
> > running away and the autoremoval is scheduled in 27 days).
> > 
> > For me the severity of this bug is definitely important, not grave. I think
> > we should downgrade the severity immediately. Would you agree with this?

You didn't answer this question. Severity grave was set explicitely by you, not
by the original bug reporter, hence I am asking you to re-consider the
situation with the new information (see above). According to my tests this
severity is wrong, but severity important is just correct:

A bug which has a major effect on the usability of a package, without rendering
it completely unusable to everyone.

What's your opinion on this one?

> > As another measure to avoid the autoremoval of basically unaffected
> > Tryton modules it could be argued, that calypso is not ready for current
> > vobject and reassign the bug to calypso.  
> 
> This is not related to calypso. The ABI has changed significantly.

There was a jump from 0.8 to 0.9 in python-vobject, which in many softwares
means, that ABI breakage must be expected. 
 
> We're miles away from an autoremoval so keep calm ;)

It is not my way to keep calm, if problems can be solved. And you said,
that you only have time for a fix by the end of the year, which is way
after the autoremoval date.

Sorry if stepping on your toes, it is for sure not my intention to create more
work load for you. But this issue can be solved right now with respect to the
tryton-modules, why I am asking you again to agree on a correct bug severity.

Cheers,

Mathias


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles

[Philipp Kern]

On 18.11.2016 12:44, Dimitri John Ledkov wrote:
> Another thing I am investigating is moving away from swap partitions to
> swap files, on non-lvm installations. This will involve tweaking the
> default partman-auto recipes & the no-swap warning.

Note that you should then also check that the memory available to the
installer is sufficient to proceed without swap. (Especially for locales
generation and such.)

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#844717: pydb suggests outdated emacs

[Martin Pitt]

Package: pydb
Version: 1.26-2
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch zesty

Hello,

In https://launchpad.net/bugs/1537938 it was reported that pydb
suggests an outdated emacs version (22). Jeff submitted a patch for
this (attached).

Thanks for considering,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
diff -Naur pydb-1.26/debian/changelog pydb-next/debian/changelog
--- pydb-1.26/debian/changelog	2015-12-11 17:09:31.0 -0500
+++ pydb-next/debian/changelog	2016-10-18 20:56:24.223941838 -0400
@@ -1,3 +1,10 @@
+pydb (1.26-2ubuntu1) yakkety; urgency=low
+
+  * changed emacs to actually available emacs
+  * nmu update
+
+ -- Jeff Cliff   Tue, 17 Oct 2016 12:00:00 +0600
+
 pydb (1.26-2) unstable; urgency=low
 
   * Team Upload
diff -Naur pydb-1.26/debian/control pydb-next/debian/control
--- pydb-1.26/debian/control	2015-12-11 17:04:05.0 -0500
+++ pydb-next/debian/control	2016-10-18 20:54:53.073612427 -0400
@@ -13,7 +13,7 @@
 Package: pydb
 Architecture: all
 Depends: ${python:Depends}
-Suggests: ddd, emacs22
+Suggests: ddd, emacs25
 Description: An enhanced Python command-line debugger
  Pydb is a command-line debugger for Python. It is based on the standard
  Python debugger pdb, but has a number of added features. Particularly, it is
diff -Naur pydb-1.26/debian/pydb.emacsen-remove pydb-next/debian/pydb.emacsen-remove
--- pydb-1.26/debian/pydb.emacsen-remove	2015-12-11 16:40:06.0 -0500
+++ pydb-next/debian/pydb.emacsen-remove	2016-10-18 20:54:40.865300218 -0400
@@ -3,8 +3,23 @@
 
 FLAVOR=$1
 PACKAGE=pydb
+EMACS=no
+
+if [ ${FLAVOR} = emacs22 ] ; then
+	EMACS="yes"
+fi
+if [ ${FLAVOR} = emacs23 ] ; then
+	EMACS="yes"
+fi
+if [ ${FLAVOR} = emacs24 ] ; then
+	EMACS="yes"
+fi
+if [ ${FLAVOR} = emacs25 ] ; then
+	EMACS="yes"
+fi
+
+if [ ${EMACS} = "yes" ] ; then
 
-if [ ${FLAVOR} = emacs22 ]; then
 if test -x /usr/sbin/install-info-altdir; then
 echo remove/${PACKAGE}: removing Info links for ${FLAVOR}
 install-info-altdir --quiet --remove --dirname=${FLAVOR} /usr/share/info/${PACKAGE}.info.gz
@@ -12,4 +27,5 @@
 
 echo remove/${PACKAGE}: purging byte-compiled files for ${FLAVOR}
 rm -rf /usr/share/${FLAVOR}/site-lisp/${PACKAGE}
+
 fi

Bug#844719: Out of bounds read when using a malformated pcap file

[Lucian Cojocar]

Package: tcptrace
Version: 6.6.7-4.1
Severity: normal
File: /usr/bin/tcptrace

Dear Maintainer,

   * What led up to the situation?
While developing a new fuzzer we discovered this bug.

   * What outcome did you expect instead?
We expected the program not to crash. I'm attaching an input file that
triggers this bug. The bug can be triggered on x86_64 as well.

Here's a stack trace:
"""
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov  4, 2004

TCP packet 10: reserved bits are not all zero.
Further warnings disabled, use '-w' for more info

Program received signal SIGSEGV, Segmentation fault.
0x08058ecc in MemCpy (vp1=0x80caab0, vp2=0x80baab6, n=4294699681) at
tcptrace.c:2620
2620*p1++=*p2++;
(gdb) bt
#0  0x08058ecc in MemCpy (vp1=0x80caab0, vp2=0x80baab6, n=4294699681) at
tcptrace.c:2620
#1  0x080558c4 in callback (user=0x0, phdr=0xb1bc, buf=0x80baaa8 "")
at tcpdump.c:166
#2  0xb7f4ba18 in pcap_offline_read (p=0x80ba8a0, cnt=1,
callback=0x8055850 ,
user=0x0) at ./savefile.c:404
#3  0xb7f3c8f6 in pcap_dispatch (p=0x80ba8a0, cnt=1, callback=0x8055850
,
user=0x0) at ./pcap.c:829
#4  0x080556d8 in pread_tcpdump (ptime=0x80a75c8 ,
plen=0xb29c,
ptlen=0xb2a0, pphys=0xb298, pphystype=0xb294,
ppip=0xb28c,
pplast=0xb2a4) at tcpdump.c:247
#5  0x08058098 in ProcessFile (filename=0x80caab0 "E`") at tcptrace.c:966
#6  0x08049fba in main (argc=1, argv=0xb4f4) at tcptrace.c:785
"""


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

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

Versions of packages tcptrace depends on:
ii  libc6   2.19-18+deb8u4
ii  libpcap0.8  1.6.2-2

Versions of packages tcptrace recommends:
ii  tcpdump  4.6.2-5+deb8u1
ii  xplot-xplot.org  0.90.7.1-2

tcptrace suggests no packages.

-- debconf-show failed


tcptrace-2016-05-18T02-38-38.155527.pcap
Description: tcptrace-2016-05-18T02-38-38.155527.pcap


signature.asc
Description: OpenPGP digital signature

Bug#844618: ITP: bornagain -- Simulating and fitting X-ray and neutron small-angle scattering at grazing incidence

[Mika Pflüger]

Hi Frederic,

I was just accepted in the debian-science team on alioth, my login is 
mikapfl-guest.
Thanks for creating the git repository on alioth, I'll commit what I've 
done so far (mostly some metadata like watchfile and copyright) using 
git-buildpackage soon.
bornagain is a pretty complex program, with a C++ shared library, a qt 
GUI and bindings for python as well as python3. I'll first try to build 
one monolithic package with GUI, library and python bindings, and then 
see how to split it and build the python3 bindings as well.
Another problem might be the bundled libraries, the upstream tarball is 
bundling patched versions of gtest, some fitting routines from other 
packages like ROOT and some themes and widgets from qt.


Cheers

Mika

Am 2016-11-18 08:07, schrieb PICCA Frederic-Emmanuel:

Hello Mika,

VEry glade to hear that you decided to integrate bornagain into Debian.

I created a git repository for it under

ssh://git.debian.org/git/debian-science/packages/bornagain.git

do you have an alioth account, and are you already member of the
debian-science team ?


Cheers


Frederic

Bug#844718: kmail: Kmail cannot be synchronized between 2 computers anymore

[Joerg Hau]

Package: kmail
Version: 4:4.14.1-1
Severity: important

Dear Maintainer,

I am using kmail on different computers (in particular: 1 desktop and 1 laptop) 
and I need to keep all mail synchronized between these computers. That is all 
:-)

In all previous kmail versions including those in Debian 7, it was possible to 
transfer/synchronize the complete mail settings and folders between different 
computers. I simply used to quit kmail, used 'unison' to sync the relevant 
files and directories from pc-1 to pc-2, continued to work on pc-2 (think 
travel) and then sync back from pc-2 to pc-1. This took only seconds.

With the introduction of a different kmail/akonadi/... architecture in Debian 
8, this is no longer possible. The relevant data seem now now be spread across 
a multitude of databases that are all "live" as soon as I am logged in, i.e. I 
cannot sync them - some software (akonadi? baloo?) starts as soon as I log in 
and keeps these files open.

=> How can I get back to a state where all mail on my notebook computer could 
be kept identical with that on my desktop? 

Notes:

o the key problem is the non-sync of the "local" folders since I transfer lots 
of mails from IMAP to "local" folders, and these must stay in sync. (hey, 
syncing IMAP is not a problem ;-)

o I have tried 'pimsettingexporter' but this was a major mess - (a) it takes a 
very long time to create the archive, and (2) on unpacking, both the mail 
folders and account settings/names are lost/garbled. This is not a valid option 
:-/

   * What led up to the situation?

 The switch to a different kmail/akonadi/... architecture in Debian 8. 


-- System Information:
Debian Release: 8.6
  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_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 kmail depends on:
ii  kde-runtime   4:4.14.2-2
ii  kdepim-runtime4:4.14.2-3
ii  kdepimlibs-kio-plugins4:4.14.2-2+deb8u2
ii  libakonadi-calendar4  4:4.14.2-2+deb8u2
ii  libakonadi-contact4   4:4.14.2-2+deb8u2
ii  libakonadi-kde4   4:4.14.2-2+deb8u2
ii  libakonadi-kmime4 4:4.14.2-2+deb8u2
ii  libakonadiprotocolinternals1  1.13.0-2+deb8u2
ii  libc6 2.19-18+deb8u6
ii  libcalendarsupport4   4:4.14.1-1
ii  libfollowupreminder4  4:4.14.1-1
ii  libgcc1   1:4.9.2-10
ii  libgpgme++2   4:4.14.2-2+deb8u2
ii  libgrantlee-core0 0.4.0-2
ii  libincidenceeditorsng44:4.14.1-1
ii  libkabc4  4:4.14.2-2+deb8u2
ii  libkalarmcal2 4:4.14.2-2+deb8u2
ii  libkcalcore4  4:4.14.2-2+deb8u2
ii  libkcalutils4 4:4.14.2-2+deb8u2
ii  libkcmutils4  4:4.14.2-5+deb8u1
ii  libkdecore5   4:4.14.2-5+deb8u1
ii  libkdepim44:4.14.1-1
ii  libkdeui5 4:4.14.2-5+deb8u1
ii  libkio5   4:4.14.2-5+deb8u1
ii  libkleo4  4:4.14.1-1
ii  libkmanagesieve4  4:4.14.1-1
ii  libkmime4 4:4.14.2-2+deb8u2
ii  libknewstuff3-4   4:4.14.2-5+deb8u1
ii  libknotifyconfig4 4:4.14.2-5+deb8u1
ii  libkontactinterface4a 4:4.14.2-2+deb8u2
ii  libkparts44:4.14.2-5+deb8u1
ii  libkpgp4  4:4.14.1-1
ii  libkpimidentities44:4.14.2-2+deb8u2
ii  libkpimtextedit4  4:4.14.2-2+deb8u2
ii  libkpimutils4 4:4.14.2-2+deb8u2
ii  libkprintutils4   4:4.14.2-5+deb8u1
ii  libksieveui4  4:4.14.1-1
ii  libktnef4 4:4.14.2-2+deb8u2
ii  libmailcommon44:4.14.1-1
ii  libmailimporter4  4:4.14.1-1
ii  libmailtransport4 4:4.14.2-2+deb8u2
ii  libmessagecomposer4   4:4.14.1-1
ii  libmessagecore4   4:4.14.1-1
ii  libmessagelist4   4:4.14.1-1
ii  libmessageviewer4 4:4.14.1-1
ii  libpimcommon4 4:4.14.1-1
ii  libqt4-dbus   4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-network4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-xml4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtwebkit4  2.3.4.dfsg-3
ii  libsendlater4 4:4.14.1-1
ii  libsolid4 4:4.14.2-5+deb8u1
ii  libstdc++64.9.2-10
ii  libtemplateparser44:4.14.1-1
ii  perl  5.20.2-3+deb8u6

Versions of packages kmail recommends:
ii  

Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles

[Dimitri John Ledkov]

On 18 November 2016 at 12:02, Philipp Kern  wrote:
> On 18.11.2016 12:44, Dimitri John Ledkov wrote:
>> Another thing I am investigating is moving away from swap partitions to
>> swap files, on non-lvm installations. This will involve tweaking the
>> default partman-auto recipes & the no-swap warning.
>
> Note that you should then also check that the memory available to the
> installer is sufficient to proceed without swap. (Especially for locales
> generation and such.)
>

Right so the no-swap warning comes after partitioning scheme is
finalised, but before swapfile is created and activated.

I still want to default to having some swap. But have that provided
via swap partition, or a swapfile. So far my scripts are a bit hackish
as the swapfile does not form part of the parted aware things /
something one cas specify in partman-auto recipes. It really is tucked
on the side, in finish.d, at the moment.

I have no solution yet for e.g. partman-auto automic recipe which uses
swapfile, if the rootfs filesystem is ext4; but creates a swap
partition if the rootfs filesystem is btrfs. And i'm not quite sure
how to express that in the recipe, or decode it.

-- 
Regards,

Dimitri.

Bug#844720: Enable QR-Code support

[Martin Pitt]

Package: xfce4-clipman-plugin
Version: 2:1.4.0-1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch zesty

Hello,

In https://launchpad.net/bugs/1641802 it was reported that Out of the
box xfce4-clipman-plugin doesn't include QR-Code support. Attached
patch from Ben adds that by building against libqrencode-dev.

Thanks for considering,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
diff -Nru xfce4-clipman-plugin-1.4.0/debian/changelog 
xfce4-clipman-plugin-1.4.0/debian/changelog
--- xfce4-clipman-plugin-1.4.0/debian/changelog 2016-09-15 16:19:53.0 
-0400
+++ xfce4-clipman-plugin-1.4.0/debian/changelog 2016-11-17 20:48:55.0 
-0500
@@ -1,3 +1,9 @@
+xfce4-clipman-plugin (2:1.4.0-2) UNRELEASED; urgency=medium
+
+  * Enable QR-Code support
+
+ -- Ben Swartzlander   Thu, 17 Nov 2016 20:48:34 -0500
+
 xfce4-clipman-plugin (2:1.4.0-1) unstable; urgency=medium
 
   [ Mateusz Łukasik ]
diff -Nru xfce4-clipman-plugin-1.4.0/debian/control 
xfce4-clipman-plugin-1.4.0/debian/control
--- xfce4-clipman-plugin-1.4.0/debian/control   2016-09-15 16:03:36.0 
-0400
+++ xfce4-clipman-plugin-1.4.0/debian/control   2016-11-17 14:50:29.0 
-0500
@@ -9,7 +9,7 @@
  libxfce4panel-2.0-dev, libxml2-dev, libxml-parser-perl, intltool,
  libx11-dev, pkg-config, libgtk-3-dev, libexo-1-dev, libxfce4util-dev,
  libxfconf-0-dev, libglade2-dev, libunique-dev, libxfce4ui-2-dev,
- libxtst-dev
+ libxtst-dev, libqrencode-dev
 Standards-Version: 3.9.8
 Homepage: http://goodies.xfce.org/
 Vcs-Svn: svn://anonscm.debian.org/pkg-xfce/goodies/trunk/xfce4-clipman-plugin/

Bug#844720: Acknowledgement (Enable QR-Code support)

[Martin Pitt]

Hello again,

FTR, Ben's email address in the patch that I sent is wrong. The
current CC: should work better.

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

Bug#841592: [debian-mysql] Bug#841592: Bug#841592: Bug#841592: mysql-5.7: FTBFS: Tests failures

[Lucas Nussbaum]

Hi,

On 18/11/16 at 09:52 +0100, Lars Tangvald wrote:
> Could you try setting /proc/sys/fs/aio-max-nr in your build environment
> (64-core machine) to a high number like 40 (I'm guessing it's set to the
> default 65536), then building with my patch and see if that clears up
> everything?

Sorry, I don't have time to try this. Maybe you could post your build
log and diff it with mine to see if something comes up?

I'm suprised that you can't reproduce it.
(or maybe someone else reading that bug log can try? for me it fails
after 324 seconds, so it's easy to try)

Lucas

Bug#844721: libgtest-dev isn't replacing dir with symlink on upgrade

[David Kalnischkies]

Package: libgtest-dev
Version: 1.8.0-1
Severity: serious

Hi,

libgtest-dev contains in 1.8.0-1 a symlink to the new on-disk location.
That works for new installs, but doesn't on upgrades – a user ends up
with an empty /usr/src/gtest in that case.  You need to work with
maintainerscripts here, see "man dpkg-maintscript-helper" and especially
the section about dir_to_symlink for details on how and why.

The justification for 'serious' is a bit of a stretch (pun intended) as
the policy isn't explicitly saying that upgrades must produce a working
package… but I hope you and/or the release team implicitly agree. :)


In all likelyhood its the same with mock, but I am not using it…

You should also update your README.Debian and the descriptions with the
new paths and the transitional package as I guess you want to retire the
old package/path some day and the longer the grace period the better…

btw: Upstream seems to have retired their remark on compiling googletest
on your own as I can't find it any longer on their website and e.g. in
the RPM/BSD worlds you get a binary only.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#844722: qtwebkit: Please add platform support for m68k

[John Paul Adrian Glaubitz]

Source: qtwebkit
Version: 2.3.4.dfsg-9
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

qtwebkit used to build fine in the past but due to changes in the
upstream WebKit code no longer does. I have therefore created a
small patch which re-adds m68k support to qtwebkit.

This patch is based on the m68k support patch for qtwebkit-
opensource-src [1] and I have verified it to make qtwebkit
build fine on m68k with the patch applied.

It would be great to have both qtwebkit-opensource-src and
qtwebkit patched for m68k support as both packages still have
a lot of reverse dependencies and therefore prevent several
packages from being built on m68k.

I'm aware that qtwebkit* is going away in the future, but until
this has happened, it would be great to just have m68k support
in the package to help Debian's m68k port move forward.

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780430

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

--- qtwebkit-2.3.4.dfsg.orig/Source/WTF/wtf/Platform.h
+++ qtwebkit-2.3.4.dfsg/Source/WTF/wtf/Platform.h
@@ -345,6 +345,12 @@
 #endif
 #endif
 
+/* CPU(M68K) - m68k */
+#if defined(__mc68000__)
+#define WTF_CPU_M68K 1
+#define WTF_CPU_BIG_ENDIAN 1
+#endif
+
 #if CPU(ARM) || CPU(MIPS) || CPU(SH4) || CPU(SPARC) || CPU(MIPS64)
 #define WTF_CPU_NEEDS_ALIGNED_ACCESS 1
 #endif
--- qtwebkit-2.3.4.dfsg.orig/Source/WTF/wtf/dtoa/utils.h
+++ qtwebkit-2.3.4.dfsg/Source/WTF/wtf/dtoa/utils.h
@@ -58,6 +58,8 @@ defined(_MIPS_ARCH_MIPS32R2)
 #else
 #undef DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS
 #endif  // _WIN32
+#elif defined(__mc68000__)
+#undef DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS
 #else
 #error Target architecture was not detected as supported by Double-Conversion.
 #endif
--- qtwebkit-2.3.4.dfsg.orig/Source/WebCore/css/CSSProperty.cpp
+++ qtwebkit-2.3.4.dfsg/Source/WebCore/css/CSSProperty.cpp
@@ -39,7 +39,7 @@ struct SameSizeAsCSSProperty {
 void* value;
 };
 
-COMPILE_ASSERT(sizeof(CSSProperty) == sizeof(SameSizeAsCSSProperty), CSSProperty_should_stay_small);
+COMPILE_ASSERT(sizeof(CSSProperty) <= sizeof(SameSizeAsCSSProperty), CSSProperty_should_stay_small);
 
 void CSSProperty::wrapValueInCommaSeparatedList()
 {
--- qtwebkit-2.3.4.dfsg.orig/Source/WebCore/dom/ShadowRoot.cpp
+++ qtwebkit-2.3.4.dfsg/Source/WebCore/dom/ShadowRoot.cpp
@@ -60,7 +60,7 @@ struct SameSizeAsShadowRoot : public Doc
 unsigned countersAndFlags[1];
 };
 
-COMPILE_ASSERT(sizeof(ShadowRoot) == sizeof(SameSizeAsShadowRoot), shadowroot_should_stay_small);
+COMPILE_ASSERT(sizeof(ShadowRoot) <= sizeof(SameSizeAsShadowRoot), shadowroot_should_stay_small);
 
 ShadowRoot::ShadowRoot(Document* document)
 : DocumentFragment(document, CreateShadowRoot)
--- qtwebkit-2.3.4.dfsg.orig/Source/WebCore/rendering/style/RenderStyle.cpp
+++ qtwebkit-2.3.4.dfsg/Source/WebCore/rendering/style/RenderStyle.cpp
@@ -58,7 +58,7 @@ struct SameSizeAsBorderValue {
 unsigned m_width;
 };
 
-COMPILE_ASSERT(sizeof(BorderValue) == sizeof(SameSizeAsBorderValue), BorderValue_should_not_grow);
+COMPILE_ASSERT(sizeof(BorderValue) <= sizeof(SameSizeAsBorderValue), BorderValue_should_not_grow);
 
 struct SameSizeAsRenderStyle : public RefCounted {
 void* dataRefs[7];
@@ -75,7 +75,7 @@ struct SameSizeAsRenderStyle : public Re
 } noninherited_flags;
 };
 
-COMPILE_ASSERT(sizeof(RenderStyle) == sizeof(SameSizeAsRenderStyle), RenderStyle_should_stay_small);
+COMPILE_ASSERT(sizeof(RenderStyle) <= sizeof(SameSizeAsRenderStyle), RenderStyle_should_stay_small);
 
 inline RenderStyle* defaultStyle()
 {
--- qtwebkit-2.3.4.dfsg.orig/Source/WebCore/rendering/style/StyleBoxData.cpp
+++ qtwebkit-2.3.4.dfsg/Source/WebCore/rendering/style/StyleBoxData.cpp
@@ -33,7 +33,7 @@ struct SameSizeAsStyleBoxData : public R
 uint32_t bitfields;
 };
 
-COMPILE_ASSERT(sizeof(StyleBoxData) == sizeof(SameSizeAsStyleBoxData), StyleBoxData_should_not_grow);
+COMPILE_ASSERT(sizeof(StyleBoxData) <= sizeof(SameSizeAsStyleBoxData), StyleBoxData_should_not_grow);
 
 StyleBoxData::StyleBoxData()
 : m_minWidth(RenderStyle::initialMinSize())
--- qtwebkit-2.3.4.dfsg.orig/Source/WebCore/rendering/style/StyleRareInheritedData.cpp
+++ qtwebkit-2.3.4.dfsg/Source/WebCore/rendering/style/StyleRareInheritedData.cpp
@@ -61,7 +61,7 @@ struct SameSizeAsStyleRareInheritedData
 #endif
 };
 
-COMPILE_ASSERT(sizeof(StyleRareInheritedData) == sizeof(SameSizeAsStyleRareInheritedData), StyleRareInheritedData_should_bit_pack);
+COMPILE_ASSERT(sizeof(StyleRareInheritedData) <= sizeof(SameSizeAsStyleRareInheritedData), StyleRareInheritedData_should_bit_pack);
 
 StyleRareInheritedData::StyleRareInheritedData()
 : listStyleImage(RenderStyle::initialListStyleImage())

Bug#828352: ipmitool: FTBFS with openssl 1.1.0

[Jörg Frings-Fürst]

severity 828352 important
thanks

We switched our build dependnecy on libssl-dev to libssl1.0-dev so I'm 
downgrading this bug.

Of course I'm keeping this open because we need to switch to 1.1 as
soons as 
upstream allows us.

CU 
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Petter Reinholdtsen]

[Lluís Vilanova]
> A possible check could be:
>
>   if [ `/sbin/sysctl kernel.perf_event_paranoid` -gt 2 ]; then
>   echo "ERROR: perf is too paranoid for us"
>   exit 1
>   fi
>
> This would build-depend on procps (which installs sysctl).

This seem like a good approach.  Perhaps explain in the message how to
get the build working too?

I found
http://unix.stackexchange.com/questions/14227/do-i-need-root-admin-permissions-to-run-userspace-perf-tool-perf-events-ar
 >
explaining the values 2 to -1 for perf_event_paraniod.

I'm using kernel 3.16 myself, and here the default value seem to be 1.

I guess coz should be patched too, to explain why it isn't working
instead of returning the fairly incomprehensive message it give today
when the perf call fail

-- 
Happy hacking
Petter Reinholdtsen

Bug#826862: ipmitool fails with Segmentation fault

[Jörg Frings-Fürst]

Hello,

no answer since 11 weeks. So I close this bug.

If the bug still occurs please reopen[1] this bug or file a new one.

CU
Jörg

[1] https://www.debian.org/Bugs/server-control#reopen

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#844723: ITP: ruby-unicode-display-width -- Unicode character width library

[Michael Moll]

Package: wnpp
Severity: wishlist

I'm packaging this in pkg-ruby-extras

Bug#844724: apt: Does not seem to support new GnuPG keybox keyring format

[Guillem Jover]

Package: apt
Version: 1.3.1
Severity: important

[ Setting as important as this is GnuPG default, but if you think this
  is a new feature or similar please just change it to wishlist. ]

Hi!

It seems like apt (and its gpgv method) do not support the new GnuPG
keybox keyring format? Which is the one currently generated by default
with newer GnuPG versions. A simple session to demonstrate:

  ,--- (line-wrapped for easier readability) ---
  # cd /etc/apt/trusted.gpg.d
  # file debian-archive-jessie-automatic.gpg
  debian-archive-jessie-automatic.gpg: GPG key public ring,
  created Fri Nov 21 21:01:13 2014
  # mv debian-archive-jessie-automatic.gpg ~
  # gpg --no-default-keyring --no-options --no-auto-check-trustdb \
--keyring ./debian-archive-jessie-automatic.gpg --import \
<~/debian-archive-jessie-automatic.gpg
  gpg: keybox './debian-archive-jessie-automatic.gpg' created
  gpg: key 7638D0442B90D010: public key "Debian Archive Automatic Signing
   Key (8/jessie) " imported
  gpg: Total number processed: 1
  gpg:   imported: 1
  # file debian-archive-jessie-automatic.gpg
  debian-archive-jessie-automatic.gpg: GPG keybox database version 1,
  created-at Fri Nov 18 12:50:26 2016,
  last-maintained Fri Nov 18 12:50:26 2016
  # apt update
  Hit:1 https://cdn-aws.deb.debian.org/debian unstable InRelease
  Err:1 https://cdn-aws.deb.debian.org/debian unstable InRelease
The following signatures couldn't be verified because the public key is
not available: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  1 package can be upgraded. Run 'apt list --upgradable' to see it.
  W: An error occurred during the signature verification.
The repository is not updated and the previous index files will be used.
GPG error: https://cdn-aws.deb.debian.org/debian unstable InRelease:
The following signatures couldn't be verified because the public key
is not available: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010
  W: Failed to fetch https://deb.debian.org/debian/dists/unstable/InRelease
The following signatures couldn't be verified because the public key is
not available: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010
  W: Some index files failed to download. They have been ignored, or
old ones used instead.
  `---

Although I've trimmed it down here, it seems like one single keybox
formatted keyring makes the whole verification fail for all other
keyrings.

Thanks,
Guillem

Bug#844702: firewall-applet: Firewall-applet icon is missing in panel

[Simon Frei]

Package: firewall-applet
Version: 0.4.4.1-1
Severity: normal

Since my last update the panel icon is not shown anymore for firewall-applet. 
It is running, space is reserved on the panel and it works as expected, but no 
symbol. Starting firewall-applet from command line produces the following 
message:

QSystemTrayIcon::setVisible: No Icon set

I update from 0.4.3.3-1, where this problem was not present.

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

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

Versions of packages firewall-applet depends on:
ii  firewall-config  0.4.4.1-1
ii  firewalld0.4.4.1-1
ii  gir1.2-networkmanager-1.01.4.2-2
ii  gir1.2-notify-0.70.7.7-1
ii  python3-dbus 1.2.4-1
ii  python3-dbus.mainloop.pyqt5  5.7+dfsg-2+b1
ii  python3-gi   3.22.0-1
ii  python3-pyqt55.7+dfsg-2+b1
ii  python3-slip-dbus0.6.1-3
pn  python3:any  

firewall-applet recommends no packages.

firewall-applet suggests no packages.

-- no debconf information

Bug#844694: firefox: high-lighting issues with the new release (maybe gtk3 issue ? )

[shirish शिरीष]

update at bottom :-

On 18/11/2016, shirish शिरीष  wrote:
> at bottom :-
>
> On 18/11/2016, Mike Hommey  wrote:
>> On Fri, Nov 18, 2016 at 12:21:25PM +0530, shirish शिरीष wrote:
>>> Package: firefox
>>> Version: 50.0-1
>>> Severity: normal
>>>
>>> Dear Maintainer,
>>> In Debian mate, previous versions of Mozilla Firefox used the
>>> high-lighting color (from the theme selected/used) while in the new
>>> version the highlighting while going through the different drop-down
>>> menus is unavailable. Can this be fixed ?
>>>
>>> https://jumpshare.com/v/CMeKzSwl83vyRrEvzSEe also has the same video
>>> which I have attached, it shows the problem in case I have been unable
>>> to explain well.
>>>
>>> Notice that the new version doesn't tell you which option you are
>>> choosing while in tor the green band always tells you visually which
>>> option you are taking.
>>>
>>> The video has been bought to you by simplescreenrecorder.
>>
>> Run gtk3-demo from the gtk-3-examples package. In the list it brings,
>> select "Menus" then click the "Run" button. Does the same happen there?
>
> Dear Mike,
>
> Nope. It runs similar to what I shared as the behaviour of tor. No
> change from tor behaviour.
>
>> Mike
>>

I also ran firefox in safe-mode, the odd behaviour in firefox persists
here too :(

-- 
  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#844694: firefox: high-lighting issues with the new release (maybe gtk3 issue ? )

[shirish शिरीष]

at bottom :-

On 18/11/2016, Mike Hommey  wrote:
> On Fri, Nov 18, 2016 at 12:21:25PM +0530, shirish शिरीष wrote:
>> Package: firefox
>> Version: 50.0-1
>> Severity: normal
>>
>> Dear Maintainer,
>> In Debian mate, previous versions of Mozilla Firefox used the
>> high-lighting color (from the theme selected/used) while in the new
>> version the highlighting while going through the different drop-down
>> menus is unavailable. Can this be fixed ?
>>
>> https://jumpshare.com/v/CMeKzSwl83vyRrEvzSEe also has the same video
>> which I have attached, it shows the problem in case I have been unable
>> to explain well.
>>
>> Notice that the new version doesn't tell you which option you are
>> choosing while in tor the green band always tells you visually which
>> option you are taking.
>>
>> The video has been bought to you by simplescreenrecorder.
>
> Run gtk3-demo from the gtk-3-examples package. In the list it brings,
> select "Menus" then click the "Run" button. Does the same happen there?

Dear Mike,

Nope. It runs similar to what I shared as the behavior of tor. No
change from tor behavior.

> Mike
>

-- 
  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#843520: [debian-mysql] Bug#843520: Bug#843520: mysql-server-5.5 cannot be automatically upgraded

[Jean Louis]

I have no console logs, it was just hanging. That is the problem
encountered, the upgrade was hanging forever without giving error
messages.

Thank you.

On Fri, Nov 18, 2016 at 08:00:34AM +0100, Lars Tangvald wrote:
> Hi,
> 
> On 11/17/2016 06:02 PM, Jean Louis wrote:
> > I am sorry, that I filed bug in the wrong package, it was
> > unintentional mistake. It should be in mysql-server. And I know all
> > about specifics.
> > 
> > In my case, there is nothing that I have changed in my Mysql
> > configuration from the plain install. That is why I filed the
> > bug. Otherwise I would look first on my side.
> > 
> > And I was surprised it did not work, as I was used to the stability
> > and certainty when upgrading.
> > 
> > I could not find the solution
> > 
> > I was reading other bugs and I found:
> > 
> > [mysqld]
> > secure_file_priv = /var/lib/mysql
> > 
> > So I have put it in /etc/mysql/conf.d and now I got it working. Even I
> > don't even know what is it about, as being so lazy to read the
> > documentation. Sorry.
> > 
> > Still I think it should not be like that, the upgrade should go
> > smooth, especially for databases. Nothing angers me, thank you for
> > putting attention. I am supporter of free software and use Debian on
> > remote servers.
> > 
> > Jean Louis
> Hi,
> 
> In this case, the server defaults to secure_file_priv=/var/lib/mysql-files,
> and will require this directory to be created.
> This is a big change to make in a stable release, but the old behavior was a
> potential security risk, so we felt it was justified. The upgrade _should_
> have created this directory automatically, so if it failed for you then
> there's probably something with your environment we didn't account for. If
> you have any console logs or mysql error logs from the update it would be
> good if you can attach them to the bug.
> 
> One important note, however:
> The solution you note, setting secure_file_priv=/var/lib/mysql (the data
> directory) is not a good one. You should either set it to NULL or to a
> separate, empty directory owned by the mysql user.
> 
> The secure_file_priv setting determines where the server is allowed to read
> and write files using import/export operations. Setting it to the same
> location as the database will mean that any user of your database can get
> full access.
> 
> --
> Lars
> 
> 
> > 
> > On Tue, Nov 15, 2016 at 12:10:10PM +, Robie Basak wrote:
> > > Hi Jean,
> > > 
> > > On Tue, Nov 15, 2016 at 12:08:18PM +0100, Jean Louis wrote:
> > > > sudo apt-get update
> > > > sudo apt-get upgrad
> > > > 
> > > > * What exactly did you do (or not do) that was effective (or
> > > >   ineffective)?
> > > > 
> > > > Starting or configuring mysql-server-5.5 hangs forever. System is 
> > > > broken.
> > > > 
> > > > * What was the outcome of this action?
> > > > 
> > > > It hangs forever.
> > > Unfortunately I think this isn't enough for anyone to understand what
> > > happened in your case. This is a problem statement, not a bug report.
> > > 
> > > Clearly a simple upgrade on a fresh install of jessie works; otherwise
> > > we would have thousands of bug reports. Something must be different on
> > > your system, but we do not know what that is. Please provide full steps
> > > to reproduce your problem so that we may figure that out.
> > > 
> > > > I see that several bugs have been filed and marked as RESOLVED, how
> > > > they can be resolved when it is happening over and over again.
> > > Because they are different bugs with different root causes. This
> > > particular issue was determined to be something that needs to be fixed
> > > in akonadi packaging and is now being tracked in bug 843534. Presumably
> > > though you have a different issue as you did not mention akonadi in your
> > > bug report.
> > > 
> > > Please understand that your report cannot be addressed because you have
> > > not provided enough information. If this angers you, try reading
> > > http://www.chiark.greenend.org.uk/~sgtatham/bugs.html which is a great
> > > essay that explains this problem well.
> > > 
> > > Please file a new bug report with full steps on how to reproduce your
> > > bug. If it turns out to have a common root cause, we can always mark it
> > > as a duplicate later.
> > > 
> > > Robie
> > ___
> > pkg-mysql-maint mailing list
> > pkg-mysql-ma...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint
> 

Bug#834369: ITP: python-libusb1 -- Python wrapper for libusb1

[Vincent Pelletier]

Thanks for the update.

On Fri, 18 Nov 2016 17:05:49 +0900, Arnaud Fontaine 
wrote:
> Sorry for the lag. I have prepared a package:
> https://people.debian.org/~arnau/packages/python-libusb1_1.5.3-1_all.deb

  x2:~/git$ dpkg-deb -c python-libusb1_1.5.3-1_all.deb
  [...]
  -rw-r--r-- root/root 50327 2016-08-21 23:20 
./usr/lib/python2.7/dist-packages/libusb1.py
  -rwxr-xr-x root/root 11486 2016-11-18 07:00 
./usr/lib/python2.7/dist-packages/testUSB1.py

I did not intend this file to appear in the modules namespace. It's
nice to run it while building, of course.

Personally, I would not package it - or maybe
in /usr/share/doc/python-libusb1/examples/ ?

I confirm I could run my protocol analyser user-land driver with
installed package with python2.7 2.7.12-5 .

  $ pypy
  Python 2.7.12 (5.6.0+dfsg-2, Nov 12 2016, 10:14:18)
  [PyPy 5.6.0 with GCC 6.2.0 20161103] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
   import usb1
  Traceback (most recent call last):
File "", line 1, in 
  ImportError: No module named usb1

Maybe you intend to enable pypy (and python3, maybe needing some
packaging overhead to run 2to3) support after first tests ?

Regards,
-- 
Vincent Pelletier


pgpLM1I6cH20m.pgp
Description: Signature digitale OpenPGP

Bug#836124: trafficserver is built with --enable-linux-aio, which is unstable and will be removed in 7.0

[Jean Baptiste Favre]

Hello,
I'm one of the uploader for trafficserver package.

--enable-linux-aio build option has not been removed from 7.0.0.
Instead, it's been decided to rename it.

I use trafficserver with Linux AIO without any issues for 3 years now.
Enabling it actually improved performance a bit.

But, since the feature future isn't clear, I'll consider removing the
option in 7.0.0 package.

Regards,
Jean Baptiste Favre



signature.asc
Description: OpenPGP digital signature

Bug#844701: dpkg: buggy dpkg 1.8.11 and above ? Package: dpkg

[shirish शिरीष]

Package: dpkg
Version: 1.18.14
Severity: normal

Dear Maintainer,
It seems the bug is in dpkg 1.18.11 and above. I was suffering from
some sort of broken packages. I shared my issue at
http://unix.stackexchange.com/questions/323817/debian-strech-update-broken-seems-buggy-dpkg
. It took quite some time but it seems that dpkg at least 1.18.14 is
somewhat broken/buggy in its implementation. In dpkg 1.18.10 I am able
to fix the broken packages. These happened a few more times. I did run
a few checks 
http://unix.stackexchange.com/questions/324151/how-to-find-out-half-configured-broken-packages-in-debian
but found nothing untoward.

I would update to 1.18.15 as and when it comes to testing.

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8
ii  libc62.24-5
ii  liblzma5 5.2.2-1.2
ii  libselinux1  2.6-3
ii  tar  1.29b-1.1
ii  zlib1g   1:1.2.8.dfsg-2+b3

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.3.1

-- Configuration Files:
/etc/dpkg/dpkg.cfg changed:
debug=1
no-debsig
log /var/log/dpkg.log


-- no debconf information


-- 
  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#771183: Specific to gdm3

[Bryan Quigley]

Hi Maintainer,

The gdm3 dependency is a bit different than just including an application.
Could we move the gdm3 dependency to task-gnome-desktop? or to the
gnome metapackage?

Thank you

Bug#844704: gdc fails to build, user_defined_section_attribute removed on trunk

[Matthias Klose]

Package: gdc-7

after this change, D fails to build with the current trunk:

2016-11-16  Andrew Burgess  

* gcc/bb-reorder.c: Remove 'toplev.h' include.
(pass_partition_blocks::gate): No longer check
user_defined_section_attribute, instead check the function decl
for a section attribute.
* gcc/c-family/c-attribs.c (handle_section_attribute): No longer
set user_defined_section_attribute.
* gcc/final.c (rest_of_handle_final): Likewise.
* gcc/toplev.c: Remove definition of user_defined_section_attribute.
* gcc/toplev.h: Remove declaration of
user_defined_section_attribute.

../../src/gcc/d/d-attribs.c: In function 'tree_node*
d_handle_section_attribute(tree_node**, tree, tree, int, bool*)':
../../src/gcc/d/d-attribs.c:591:7: error: 'user_defined_section_attribute' was
not declared in this scope
   user_defined_section_attribute = true;
   ^~
Makefile:1100: recipe for target 'd/d-attribs.o' failed
make[4]: *** [d/d-attribs.o] Error 1

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc//stat utime,stime,etc. reported

[Christophe Aguettaz]

On Sun, 13 Nov 2016 04:23:54 + Ben Hutchings  wrote:
> Control: tag -1 moreinfo
>
> On Sun, 2016-11-06 at 00:02 -0700, Tom Lee wrote:
> [...]
> > Downgrading to linux-image-4.6.0-1-amd64 fixed all symptoms. Haven't yet
> > tried 4.8.0-1 from unstable, not sure if it's impacted.
> [...]
>
> Please do.
>
> Ben.
>
> --
> Ben Hutchings
> Nothing is ever a complete failure; it can always serve as a bad
> example.
>

Hi,

I stumbled on the same problem using sid's 4.8.0-1 kernel.
I had been using linux-image-4.7.0-1-amd64 for a while without
trouble, and noticed the issue after upgrading to 4.8.0-1.
I then reverted to using 4.7.0-1... and still the issue persisted!

A colleague of mine told me that he had noticed the problem as well a
while ago. He switched back to kernel version 4.6.0-1, which fixed it.
Later he started using 4.7.0-1 again, but the problem had gone away.
Nasty.

After much rebooting and hair-pulling, I noticed that we three had one
thing in common:

sys_vendor: Alienware
product_name: Aurora-R4
product_version: 00
chassis_vendor: Alienware
chassis_version: 00
bios_vendor: Alienware
bios_version: A11


So here's my theory: there's a bug at some point in the reboot process
that leaves the CPU in a weird state in which some counter are not
getting updated at all. This explains the utime/stime values being
always 0, and this would also probably wreak havoc on the scheduler if
it relied on these counters to account for time slices, explaining the
overall sluggishness.

Since it seems to only affect Aurora-R4 users, I'm guessing the
motherboard might be doing something funky to reset the CPU during
reboots. This behavior may have been revealed by changes in the
4.7.0-1 kernel. So, motherboard bug? Kernel regression? Both? I don't
know.

Long story short, I performed a cold reboot (even pulling the plug for
extra safety), and my system went back to running smoothly using sid's
linux 4.8.0-1.

Hope this helps,

Christophe Aguettaz