Bug#682264: #682264,libapache2-mod-perl2: Crash at server startup when pre-loading Plack app

[Dominic Hargreaves]

On Fri, Sep 01, 2017 at 03:47:57PM +1000, Dmitry Smirnov wrote:
> I had the same problem until I've realised that Apache now uses event module
> by default. Solution is simple -- just switch to (traditional) MPM Prefork
> model as follows:
> 
> 
> a2dismod mpm_event
> a2enmod mpm_prefork
> 

Hi Dmitry,

Thanks for pointing this out. And to the original submitter, I'm sorry
that there was no reply on this bug before in many years!

As far as I know from a quick bit of digging it is indeed the case
that mod_perl will not work with the event mpm, so we should
arrange for it to either not be possible to load it it in that
configuration, or at least to print dire warnings if that happens
(which may be safer in any case).

I will try and have a look at this at some point but it might not be
soon, so help would be appreciated.

FTR, Red Hat does the same thing:
.

Kjetil, do you have any additional observations about this bug since
it was first filed in 2012? (For example did you find out that it
was in fact caused by use of the event mpm?)

.

Best,
Dominic. 

Bug#873812: e2fsprogs: Please move l10n package from Suggests to Recommends

[Guillem Jover]

Hi!

On Thu, 2017-08-31 at 11:35:13 -0400, Theodore Ts'o wrote:
> On Thu, Aug 31, 2017 at 02:03:58PM +0200, Guillem Jover wrote:
> > Package: e2fsprogs
> > Version: 1.43.6-1
> > 
> > The recently split translations ended up being added as a Suggests in
> > e2fsprogs, which means they will not be installed by default anymore.
> > This should probably be a Recommends, which would allow people to
> > remove them, but would be pulled in by default.
> 
> It hasn't been clear to me whether there is some kind of de factor
> standard about what the priority of translations should be.  They are
> not strictly speaking necessary for the proper operation of e2fsprogs,
> and people have started complaining that the translation files is
> getting very heavyweight.

Right, they are not necessary for the operation of the program by
itself, but might instead be necessary by the (non-English-speaking)
user to be able to operate the program. :)

> Some kind of guideline about how these packages should be named (e.g.,
> -l10n versus -locales) and what priority they would be might be a good
> thing to publish somewhere, if it doesn't already exist?  I'm not
> entirely certain it needs to be in Debian Policy as a mandatory thing,
> but I spent a bunch of time trying to figure out what was considered
> best practice, and it wasn't obvious to me.  Perhaps my Google-Fu failed me.  
> :-)

I think the common trend now is to use -l10n, which seems like the
correct thing to do, as even though it's a bit of a technical term
it's also pretty unambiguous.

I even filed a report against lintian to that effect some time ago:

  

And regarding the strength of the dependency. I still think Recommends
is the right bar, even though I (being a non-native English speaker)
do remove all l10n packages from my primary system as I tend to use
just LANG=C.UTF-8. :)

Thanks,
Guillem

Bug#873791: Bug#873915: python2.7: fpectl removal breaks cython

[Axel Beckert]

Ole Streicher wrote:
> On 01.09.2017 09:51, Matthias Klose wrote:
> > Control: severity -1 important
> 
> IMO it is RC, isn't it?

I'd even say "critical" instead of the previous "serious" since it
breaks unrelated packages like apt and aptitude. (But the "unrelated"
is discussable so I didn't raise the severity from serious.)

IMHO this issue (since there are breaks in the python packages) now
should be filed again against python-numpy and what else is affected.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://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#873923: installer not detecting/configuring existing LUKS/LVM setup

[Eduard Bloch]

Package: debian-installer
Severity: normal

this is a follow-up to #873862 , see there for most details.

So, the outcome is, when the installer fails with the problem mentioned
there, I can still reboot the system.

But then, the d-i is basically stuck at the same step. The LUKS
partition is not displayed as LUKS or crypto but "unused". There is no
way to tell it "this is crypto, unencrypt it only". The only
sensible option in the usage types is apparently "PV for encryption". But
then, nothing asks me for the password, instead it presents me a list of
cryptsetup parameters. Hard to tell for a normal user whether it did
detect LUKS or not.

When I go to the main partman menu, there is the option "configure
crypto volumes".  But it does NOT configure the existing one. It only
offers me the choice "create a new crypto volume" and "go back". This is
pretty ... useless if I want to keep existing data.

So apparently the d-i is inept to use the same device setup that it has
created before or there is maybe no LUKS detection whatsoever?

When I try to investigate later with Ubuntu Live, the file manager shows
the encrypted volume and lets me unencrypt it with a a double-click and
it even detects and scans the LVM and registers LVs there). It doesn't
redisplay the discovered PVs in the filemanager, though, but I can mkfs
and mount them manually.

Regards,
Eduard.

Bug#873791: [python-numpy] Undefined symbols on several architectures

[Adrian Bunk]

On Fri, Sep 01, 2017 at 11:18:00AM +0300, Adrian Bunk wrote:
> On Thu, Aug 31, 2017 at 12:48:53PM +0200, Matthias Klose wrote:
> > On 31.08.2017 12:35, Adrian Bunk wrote:
> > > Control: reassign -1 python2.7 2.7.14~rc1-1
> > > Control: retitle -1 python2.7: fpectl extension removal broke the ABI for 
> > > C extensions
> > > Control: affects -1 python-numpy
> > > 
> > > On Thu, Aug 31, 2017 at 11:34:55AM +0200, Michał Klichowicz wrote:
> > >> Got that error on amd64, too.
> > >>
> > >> This started today, after the upgrading python2.7 packages to 2.7.14~rc1
> > >> in sid. Downgrading back to buster's 2.7.13-2 solves the problem.
> > > 
> > > I got the same error with Cython:
> > > 
> > > ImportError: 
> > > /usr/lib/python2.7/dist-packages/Cython/Compiler/Code.x86_64-linux-gnu.so:
> > >  undefined symbol: PyFPE_jbuf.  You should look at http://www.cython.org; 
> > > 
> > > It seems the following change in 2.7.14~rc1-1 broke the ABI:
> > >   * Stop building the fpectl extension.
> > 
> > yes, that's intended. I'll add a break.  Are there other known packages 
> > besides
> > python-numpy?
> 
> As written above, Cython is the one where I ran into this issue.

And based on #873921, borgbackup.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#867724: Multiple security issues

[Fabian Greffrath]

Hi Markus,

Markus Koschany wrote:
> I uploaded a security update for faad2 to wheezy-security a few hours
> ago. I am attaching the debdiff to this bug report.

thank you very much for that!

> Do you intend to fix the issue in Stretch too? I could prepare the
> update for Jessie and ask the release team for a jessie-pu.

I don't have any plans to do that.

Cheers,

 - Fabian

Bug#873791: Bug#873915: python2.7: fpectl removal breaks cython

[Ole Streicher]

Hi Mathias,

On 01.09.2017 09:51, Matthias Klose wrote:
> Control: severity -1 important

IMO it is RC, isn't it?

> yes, please check the archive for uploads before you file issues.
Which one do you mean?

Currently (from the tracker): Python 2.7 is still 2.7.14~rc1-2, and
Python 3.6 is still 3.6.2-3, both from yesterday, and both don't break
Cython. Cython also did not get an binNMU yet.

To me, this looks as it is still unresolved on both Python 2 and 3. I
just didn't want to create another issue since you do probably both in
the same step anyway.

Best regards

Ole

Bug#873792: qjackctl will not start at all

[Ed Peguillan III]

My mail client replied to the wrong address, my apologies.

After performing
$ sudo mv 
/usr/lib/x86_64-linux-gnu/freetype-infinality/liblibfreetype.so.6 ~


qjackctl and virtualbox seem to start and work normally.

It's too bad that I can't use infinality fonts anymore, my screen is 
back to looking terrible.


Thank you for your help! This bug can be closed.

Ed

On Thu, 31 Aug 2017 23:46:16 +0200 Sebastian Ramacher 
 wrote:

> Re-adding the bug to CC.
>
> On 2017-08-31 16:02:13, Ed Peguillan III wrote:
> > Sure.
> >
> > |$ ldd -r /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5||
> > || linux-vdso.so.1 (0x7ffd883f3000)||
> > || libxcb-xinerama.so.0 => 
/usr/lib/x86_64-linux-gnu/libxcb-xinerama.so.0

> > (0x7f6ec82f9000)||
> > || libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
> > (0x7f6ec7fe4000)||
> > || libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
> > (0x7f6ec7da)||
> > || libfreetype.so.6 =>
> > /usr/lib/x86_64-linux-gnu/freetype-infinality/libfreetype.so.6
>
> And that's the issue. Please remove it and try again.
>
> Cheers
>
> > (0x7f6ec7aef000)||
> > || libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
> > (0x7f6ec7388000)||
> > || libQt5DBus.so.5 => /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
> > (0x7f6ec70fe000)||
> > || libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> > (0x7f6ec69b5000)||
> > || libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > (0x7f6ec6798000)||
> > || libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
> > (0x7f6ec6458000)||
> > || libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1
> > (0x7f6ec6256000)||
> > || libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6
> > (0x7f6ec6046000)||
> > || libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6
> > (0x7f6ec5e3e000)||
> > || libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6
> > (0x7f6ec5c21000)||
> > || libxcb-xkb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-xkb.so.1
> > (0x7f6ec5a05000)||
> > || libxcb-render-util.so.0 =>
> > /usr/lib/x86_64-linux-gnu/libxcb-render-util.so.0 
(0x7f6ec5801000)||

> > || libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0
> > (0x7f6ec55f3000)||
> > || libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1
> > (0x7f6ec53ec000)||
> > || libxcb-xfixes.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0
> > (0x7f6ec51e4000)||
> > || libxcb-randr.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-randr.so.0
> > (0x7f6ec4fd4000)||
> > || libxcb-image.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-image.so.0
> > (0x7f6ec4dcf000)||
> > || libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0
> > (0x7f6ec4bcb000)||
> > || libxcb-keysyms.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-keysyms.so.1
> > (0x7f6ec49c8000)||
> > || libxcb-icccm.so.4 => /usr/lib/x86_64-linux-gnu/libxcb-icccm.so.4
> > (0x7f6ec47c3000)||
> > || libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1

Bug#849622: lintian: unexpected description-starts-with-leading-spaces

[Chris Lamb]

tags 849622 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=d947c8318c0e8b0cd08cda1582358558d5befccb

Thanks!


Regards,

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

Bug#871765: please don't force a specific TLS version

[Evgeni Golov]

On Fri, Sep 01, 2017 at 09:01:29AM +0100, Julian Gilbey wrote:
> On Fri, Aug 11, 2017 at 08:20:38AM +0200, Evgeni Golov wrote:
> > isync/mbsync defaults to use TLSv1, which was recently disabled in Debian 
> > [1].
> > This results in funny errors when trying to use mbsync now:
> >  Socket error: secure connect to mail.die-welt.net (81.7.13.250:143): 
> > error:141640BF:SSL routines:tls_construct_client_hello:no protocols 
> > available
> > 
> > Please don't hardcode any TLS defaults, let OpenSSL use whatever it knows 
> > is best.
> > 
> > Tempted to add a "security" tag.
> 
> I wonder whether this should be a "serious" bug: it makes the package
> unusable whenever a mailbox has an SSL handshake.

Well, the workaround is kinda trivial, just add:
  SSLVersions TLSv1.2
to your config.

And there is no data leakage/corruption/loss.

What do the maintainers think?

Bug#873919: make dpkg-buildpackage default locale UTF-8

[Guillem Jover]

Control: forcemerge -1 843776

Hi!

On Fri, 2017-09-01 at 10:23:59 +0200, Hans-Christoph Steiner wrote:
> Package: dpkg-dev
> 
> More and more packages are adding unicode files as unicode support has
> become more reliable and available.  The package building process is not
> guaranteed to happen in a unicode locale since the Debian default locale
> is LC_ALL=C, which is ASCII not UTF-8.  Reading UTF-8 filenames when the
> system is using ASCII causes errors (Python makes them very visible, for
> example).
> 
> mbiebl, youpi, wRAR, bunk, and I had a discussion in #debian-devel.  It
> looks like setting the default locale to C.UTF-8 in dpkg-buildpackage is
> an easy way to improve this situation a lot.  Any package that needs an
> encoding besides UTF-8 could always set it by adding something like this
> to debian/rules:
> 
>   export LC_ALL = C

As long as the project considers debian/rules the main entry point to a
package build, I'm not planning on predefining new general purpose
environment variables from dpkg-buildpackage that would otherwise not
be set by the builder.

The distinction here would be something like LC_*, against something
like CC on a cross-compilation, which you need to set no matter what.

But please, see the rationale on the other bug. I think I'll be adding
an entry to the dpkg FAQ, because it seems this has become a recurring
request. :)

> Setting C.UTF-8 as the global default in Debian would be the best
> solution to this and many other issues, but that's a much much larger
> project:
> https://sourceware.org/glibc/wiki/Proposals/C.UTF-8

That _might_ help on buildds, but not on maintainer systems for example.

Thanks,
Guillem

Bug#857123: lintian: warning about missing classpath is confusing

[Chris Lamb]

tags 857123 + moreinfo
thanks

> Can someone give a concrete example?

(Tagging as moreinfo...)


Regards,

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

Bug#871956: lintian: false positive: binary-file-built-without-LFS-support on x32

[Chris Lamb]

Hi all,

> false positive: binary-file-built-without-LFS-support on x32

I think the next step here would be to identify which of these
archs should be skipped for this check:

  
https://anonscm.debian.org/git/lintian/lintian.git/tree/data/common/architectures


Regards,

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

Bug#870069: orig-tarball-missing-upstream-signature error breaks rebuilding existing packages and more

[Chris Lamb]

Hey Stefan and Paul,

> orig-tarball-missing-upstream-signature error breaks rebuilding
> existing packages

The next version of Lintian will ignore "repacked" tarballs - ones
that contain "dfsg" in their version.

Perhaps we could also ignore "UNRELEASED" in the distribution? Or
is there something else we could check for in the version...?


Regards,

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

Bug#873921: python3.5_3.5.4-3 breaks borgbackup: undefined symbol: PyFPE_jbuf

[Sven Hartge]

Package: borgbackup
Version: 1.0.11-3
Severity: grave

Hi!

I am reporting this bug against borgbackup, because I am not sure if the
bug is in python3.5 or borgbackup just needs to be binNMUd. Please
reassign as you see fit.

The upload of python3.5 (3.5.4-3) disables the fpectl extension and
breaks borgbackup:

$ borg
Traceback (most recent call last):
  File "/usr/bin/borg", line 11, in 
load_entry_point('borgbackup==1.0.11', 'console_scripts', 'borg')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 564, in 
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2662, 
in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2316, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2322, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 22, in 
from .helpers import Error, location_validator, archivename_validator, 
format_line, format_time, format_file_size, \
  File "/usr/lib/python3/dist-packages/borg/helpers.py", line 35, in 
from . import crypto
ImportError: 
/usr/lib/python3/dist-packages/borg/crypto.cpython-35m-i386-linux-gnu.so: 
undefined symbol: PyFPE_jbuf

Grüße,
Sven.

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

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

Versions of packages borgbackup depends on:
ii  fuse   2.9.7-1
ii  libacl12.2.52-3+b1
ii  libc6  2.24-17
ii  liblz4-1   0.0~r131-2+b1
pn  libssl1.1  
ii  python33.5.3-3
ii  python3-llfuse 1.2+dfsg-1+b1
ii  python3-msgpack0.4.8-1+b1
ii  python3-pkg-resources  36.2.7-2

borgbackup recommends no packages.

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- debconf-show failed

Bug#862051: Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Jérémy Lal]

2017-08-31 19:08 GMT+02:00 Sam Hartman :

> > "Dominique" == Dominique Dumont  writes:
>
> Dominique> On Thursday, 31 August 2017 13:58:23 CEST Thorsten Glaser
> wrote:
> >> > How about printing a "nice" warning explaining it would be a
> >> good idea to > move to /usr/bin/node ?
> >>
> >> That will break scripts that do:
> >>
> >> x=$(nodejs somescript)
>
> Dominique> This kind of script won't break if the deprecation
> Dominique> warning is sent to STDERR
>
>
> Sigh.
> I wish I had seen your message before your earlier reply.
> This breaks too in more complex situations involving ssh, things like
> expect scripts and the like.
> There are cases where people mix stderr and stdout.  There are cases
> where people treat any unexpected output on stderr as a failure in
> automated scripts.
>
> The next level you can look at is considering whether /dev/stdin in a
> tty and printing the warning to either stderr or /dev/tty only in that
> case.
> And that will reduce the breakage but not remove it.
> And yes, when you actually have something it's important to deprecate,
> accepting some level of breakage and adopting one of those strategies is
> the right thing.
>
> It's just not worth it in this case.
> People who use more than Debian are very quickly going to learn that
> /usr/bin/node is preferred to /usr/bin/nodejs.
> As several people have already pointed out we've far exceeded the amount
> of effort in considering whether to deprecate or remove the link that
> will be spent maintaining the link until the end of time.
> In one sense we've already lost:-)
>

So, a short NEWS entry explaining /usr/bin/node is now available by default,
and that /usr/bin/nodejs will stay available indefinitely ?
Or even nothing and just a changelog entry ?

Jérémy

Bug#873878: Acknowledgement (glusterfs-client: mount.glusterfs needs bash as /bin/sh)

[Michael Lundkvist]

Here is a quick and dirty patch. I manually applied the same change to 
/sbin/mount.glusterfs and got it working with dash again.


No real testing done...

/Micke
diff --git a/xlators/mount/fuse/utils/mount.glusterfs.in b/xlators/mount/fuse/utils/mount.glusterfs.in
index 216d03c41..51792c479 100755
--- a/xlators/mount/fuse/utils/mount.glusterfs.in
+++ b/xlators/mount/fuse/utils/mount.glusterfs.in
@@ -673,8 +673,9 @@ main ()
 [ -n "$volume_str" ] && {
 volume_id=$volume_str
 volume_str_temp=$volume_str
-[ ${volume_str:0:1} = '/' ] && {
-volume_str_temp=${volume_str:1}
+	first_char=$(echo "$volume_str" | cut -c 1)
+[ ${first_char} = '/' ] && {
+volume_str_temp=$(echo "$volume_str" | cut -c 2-)
 }
 [ $(echo $volume_str_temp | grep -c "/") -eq 1 ] && {
 volume_id=$(echo "$volume_str_temp" | cut -f1 -d '/');

Bug#873919: make dpkg-buildpackage default locale UTF-8

[Hans-Christoph Steiner]

Package: dpkg-dev

More and more packages are adding unicode files as unicode support has
become more reliable and available.  The package building process is not
guaranteed to happen in a unicode locale since the Debian default locale
is LC_ALL=C, which is ASCII not UTF-8.  Reading UTF-8 filenames when the
system is using ASCII causes errors (Python makes them very visible, for
example).

mbiebl, youpi, wRAR, bunk, and I had a discussion in #debian-devel.  It
looks like setting the default locale to C.UTF-8 in dpkg-buildpackage is
an easy way to improve this situation a lot.  Any package that needs an
encoding besides UTF-8 could always set it by adding something like this
to debian/rules:

  export LC_ALL = C

Setting C.UTF-8 as the global default in Debian would be the best
solution to this and many other issues, but that's a much much larger
project:
https://sourceware.org/glibc/wiki/Proposals/C.UTF-8

Bug#871813: isync: please allow the usage of TLS1.1+ by default

[Julian Gilbey]

On Sat, Aug 12, 2017 at 12:11:20PM +0200, Oswald Buddenhagen wrote:
> this should be considered a duplicate of Bug#871765.
> 
> the patch is rather incomplete in the compat wrapper part. but my own
> patch does not touch it at all, and i think i'll leave it at that
> (introducing new features to the compat wrapper seems anti-thetical).
> 
> also, don't mix in the ssl2/3 removal into the same patch. i'll remove
> sslv2 separately in master (to be 1.3 soon). i know that debian disables
> sslv3 in openssl, but it seems odd to prune it from mbsync at this point.

Hi Oswald,

Would you be able to share your patch here, or upload a patched
version of this package as an NMU (or both)?  I'd love to have a
working mbsync again

Many thanks,

   Julian

Bug#873920: libgssapi-krb5-2: adequate reports obsolete conffile in libgssapi-krb5-2

[shirish शिरीष]

Package: libgssapi-krb5-2
Version: 1.15.1-2
Severity: normal

Dear Maintainer,

Thank you for maintaining the library. libgssapi-krb5-2. While
upgrading today, saw adequate telling libgssapi-krb5-2 has an obsolete
conffile.

$ adequate libgssapi-krb5-2
   [100%]
libgssapi-krb5-2:amd64: obsolete-conffile /etc/gss/mech.d/README

If possible, please fix the same.

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

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

Versions of packages libgssapi-krb5-2 depends on:
ii  libc62.24-12
ii  libcomerr2   1.43.5-1
ii  libk5crypto3 1.15.1-2
ii  libkeyutils1 1.5.9-9
ii  libkrb5-31.15.1-2
ii  libkrb5support0  1.15.1-2

libgssapi-krb5-2 recommends no packages.

Versions of packages libgssapi-krb5-2 suggests:
pn  krb5-doc   
pn  krb5-user  

-- 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#873640: live-build: Hdd image fails due to hard links in binary directory

[Raphael Hertzog]

Hi Matthijs,

On Tue, 29 Aug 2017, Matthijs Kooijman wrote:
> To fix this I've attached a patch that, passes --count-links to du when
> the target is FAT, to make the space estimation correct.

Thanks for your multiple patches, I applied them all in git.

Would you like to become co-maintainer of live-build? I maintain
it because I use it in Kali but I use only a very limited set of
the features and it would be nice to have other people who can
look at bugs.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#871765: please don't force a specific TLS version

[Julian Gilbey]

On Fri, Aug 11, 2017 at 08:20:38AM +0200, Evgeni Golov wrote:
> Package: isync
> Version: 1.2.1-2
> Severity: important
> Tags: upstream
> 
> Ohai,
> 
> isync/mbsync defaults to use TLSv1, which was recently disabled in Debian [1].
> This results in funny errors when trying to use mbsync now:
>  Socket error: secure connect to mail.die-welt.net (81.7.13.250:143): 
> error:141640BF:SSL routines:tls_construct_client_hello:no protocols available
> 
> Please don't hardcode any TLS defaults, let OpenSSL use whatever it knows is 
> best.
> 
> Tempted to add a "security" tag.

I wonder whether this should be a "serious" bug: it makes the package
unusable whenever a mailbox has an SSL handshake.

   Julian

Bug#870599: Re; upload ansible version with Depends: python-jinja2 < 2.9

[Jack Henschel]

Thanks for fixing this, greatly appreciated!

Greetings
Jack



signature.asc
Description: OpenPGP digital signature

Bug#873791: [python-numpy] Undefined symbols on several architectures

[Adrian Bunk]

On Thu, Aug 31, 2017 at 12:48:53PM +0200, Matthias Klose wrote:
> On 31.08.2017 12:35, Adrian Bunk wrote:
> > Control: reassign -1 python2.7 2.7.14~rc1-1
> > Control: retitle -1 python2.7: fpectl extension removal broke the ABI for C 
> > extensions
> > Control: affects -1 python-numpy
> > 
> > On Thu, Aug 31, 2017 at 11:34:55AM +0200, Michał Klichowicz wrote:
> >> Got that error on amd64, too.
> >>
> >> This started today, after the upgrading python2.7 packages to 2.7.14~rc1
> >> in sid. Downgrading back to buster's 2.7.13-2 solves the problem.
> > 
> > I got the same error with Cython:
> > 
> > ImportError: 
> > /usr/lib/python2.7/dist-packages/Cython/Compiler/Code.x86_64-linux-gnu.so: 
> > undefined symbol: PyFPE_jbuf.  You should look at http://www.cython.org; 
> > 
> > It seems the following change in 2.7.14~rc1-1 broke the ABI:
> >   * Stop building the fpectl extension.
> 
> yes, that's intended. I'll add a break.  Are there other known packages 
> besides
> python-numpy?

As written above, Cython is the one where I ran into this issue.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#873918: charmtimetracker: Missing binary dependency on libqt5sql5-sqlite

[Chris Lamb]

Package: charmtimetracker
Version: 1.11.4-1
Severity: grave
Tags: patch
Justification: Renders package unusable

Hi,

charmtimetracker appears to be missing a binary dependency on
libqt5sql5-sqlite. Installing libqt5sql5-sqlite manually moves
past this.

  $ charmtimetracker
  QSqlDatabase: QSQLITE driver not loaded
  QSqlDatabase: available drivers: 

Screenshot of UI error:

  https://i.imgur.com/1RLOZ4L.jpg


Patch attached.



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

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

Versions of packages charmtimetracker depends on:
ii  libc62.24-17
ii  libgcc1  1:7.2.0-1
ii  libqt5core5a 5.9.1+dfsg-9
ii  libqt5dbus5  5.9.1+dfsg-9
ii  libqt5gui5   5.9.1+dfsg-9
ii  libqt5keychain1  0.7.0-3
ii  libqt5network5   5.9.1+dfsg-9
ii  libqt5printsupport5  5.9.1+dfsg-9
ii  libqt5script55.9.1+dfsg-2
ii  libqt5sql5   5.9.1+dfsg-9
ii  libqt5widgets5   5.9.1+dfsg-9
ii  libqt5xml5   5.9.1+dfsg-9
ii  libstdc++6   7.2.0-1
ii  libxcb-screensaver0  1.12-1
ii  libxcb1  1.12-1

charmtimetracker recommends no packages.

charmtimetracker suggests no packages.

-- no debconf information


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/control b/debian/control
index 32ff76f..ebdba87 100644
--- a/debian/control
+++ b/debian/control
@@ -20,7 +20,7 @@ Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-kde/kde-extras/charmtimetracker
 
 Package: charmtimetracker
 Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}, libqt5sql5-sqlite
 Description: Cross-Platform Time Tracker
  It is built around two major ideas - tasks and events.
  Tasks are the things time is spend on, repeatedly. Tasks

Bug#873903: libidn2-0: CVE-2017-14062: integer overflow in decode_digit

[Tim Rühsen]

On Fri, 01 Sep 2017 06:52:53 +0200 Salvatore Bonaccorso
 wrote:
> Source: libidn2-0
> Version: 0.10-2
> Severity: important
> Tags: upstream security patch
> 
> Hi,
> 
> the following vulnerability was published for libidn2-0.
> 
> CVE-2017-14062[0]:
> | Integer overflow in the decode_digit function in puny_decode.c in
> | Libidn2 before 2.0.4 allows remote attackers to cause a denial of
> | service or possibly have unspecified other impact.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2017-14062
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14062
> [1] 
> https://gitlab.com/libidn/libidn2/commit/3284eb342cd0ed1a18786e3fcdf0cdd7e76676bd

Just backported the fix from libidn2 into libidn upstream (commit
e9e81b8063b095b02cf104bb992fa9bf9515b9d8).

Regards, Tim




signature.asc
Description: OpenPGP digital signature

Bug#865586: live-build: binary_hdd failed with mkfs.vfat error

[Raphael Hertzog]

Hello,

On Tue, 29 Aug 2017, Matthijs Kooijman wrote:
> I also ran into this same error a while ago. It is caused by partition
> devices being created when parted creates partitions, which are not
> cleaned up when the loop devices are cleaned up. I'm attaching a patch
> that fixes this, by passing --partscan to losetup to clear out any
> lingering partition devices when the partition itself is mounted.

Thanks, applied in git.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Uwe Kleine-König]

On Fri, Sep 01, 2017 at 12:02:12AM -0700, Josh Triplett wrote:
> On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> > On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König  Yes
> > that works. So to address the Debian bug I can do:
> > >
> > >  - move sparse to /usr/lib
> > >  - teach cgcc about the move of sparse
> > >  - make /usr/bin/sparse call cgcc -no-compile "$@"
> > 
> > I don't like that. It means the user can't invoke sparse directly.
> > 
> > >
> > > or is it easier to teach sparse about the architecture stuff?
> > 
> > First of all. It is not very trivial to teach sparse about the architecture
> > stuff. To my mind, we need to move all the cgcc logic into sparse.
> 
> Related to that: while it would mean we couldn't necessarily just rely
> entirely on GCC's definitions for a target platform, I think in an ideal
> world we could have a sparse binary that understood *all* target
> platforms at once, such that you could ask Sparse on x86_64 to "compile"
> as though targeting any arbitrary architecture. That would also have the
> major advantage of making it easy to run the Sparse testsuite for
> *every* target architecture without needing compilers for every such
> architecture.

You'd need the target arch's system headers though. But still it would
be great. In a first attempt something like:

#ifdef __powerpc__
add_pre_buffer("#weak_define __powerpc__ " __powerpc__ "\n");
#ifdef _CALL_ELF
add_pre_buffer("#weak_define _CALL_ELF " _CALL_ELF "\n");
#endif
#endif

would be helpful already.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#873915: python2.7: fpectl removal breaks cython

[Matthias Klose]

Control: severity -1 important

On 01.09.2017 09:32, Ole Streicher wrote:
> Package: python2.7
> Version: 2.7.14~rc1-2
> Severity: serious
> Affects: cython
> 
> Like #873791, Cython is also affected. This causes an FTBFS for
> python-numpy:
> 
> https://buildd.debian.org/status/logs.php?pkg=python-numpy=1%3A1.12.1-3.1
> 
> The same problem probably happens with  python3.6 3.6.2-3.

yes, please check the archive for uploads before you file issues.

Bug#873917: charmtimetracker: Please drop "Cross-Platform" from package description

[Chris Lamb]

Package: charmtimetracker
Version: 1.11.4-1
Severity: wishlist

Hi,

The package description says "Cross-Platform" which means Windows,
Mac & Linux according to the homepage.

Given the context, it seems sensible to drop the "cross-platform"
bit given that, well, we are producing a GNU/Linux distribution. :)


Regards,

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

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Uwe Kleine-König]

Hello,

On Thu, Aug 31, 2017 at 11:43:53PM +0100, Ramsay Jones wrote:
> On 31/08/17 21:55, Uwe Kleine-König wrote:
> > On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote:
> >> That is very much like on x86_64 missing define "#weak_define __x86_64__ 1"
> >>
> >> Does cgcc work for you? In the future we do want to move the archetecture
> >> related define from cgcc into sparse by itself. For now you can set
> >> "sparse" as "cgcc -no-compile"
> > 
> > Yes that works. So to address the Debian bug I can do:
> > 
> >  - move sparse to /usr/lib
> >  - teach cgcc about the move of sparse
> >  - make /usr/bin/sparse call cgcc -no-compile "$@"
> 
> Hmm, I don't think that would be a good idea ...
> 
> > or is it easier to teach sparse about the architecture stuff?
> 
> I now understand (I think!) that you are building a sparse
> package (presumably a .deb) and you are concerned that sparse
> does not pass it's own testsuite on those platforms.

Nearly right. I'm responsible for the sparse Debian package and the
problem at hand is https://bugs.debian.org/873508. This bug report has
"Severity: serious" wihch might eventually result in the removal of
sparse from the Debian archive.

@anarcat: Given that cgcc seems to work, would you agree to apply the
following patch to horst:

diff --git a/Makefile b/Makefile
index 4f924fa..d563652 100644
--- a/Makefile
+++ b/Makefile
@@ -110,7 +110,7 @@ $(NAME): $(OBJS)
 $(OBJS): .buildflags
 
 check:
-   sparse $(CFLAGS) *.[ch]
+   cgcc -no-compile $(CFLAGS) *.[ch]
 
 clean:
-rm -f *.o radiotap/*.o *~

and downgrade the bug to "important"? That would be a compromise that
buys us a bit of time.
 
> As I said before, the additional failures you are seeing are
> in the 'llvm backend' code (which, as far as I know, only passes
> on x86_64 Linux), and in my opinion the llvm-backend programs should
> not be installed. (The Makefile will build them automatically if
> you have llvm installed, likewise for c2xml/libxml and test-inspect/gtk).

Currently the sparse package contains /usr/include/sparse/, c2xml, cgcc,
sparse, sparse-llvm, sparsec and a separate package sparse-test-inspect
includes test-inspect. (That's how I inherited the package some time
ago.)
 
> [I would like to see build variable(s) to allow the user to suppress
> the build (or installation) of the other 'non-primary' sparse programs.]
> 
> Anyway, if you were to un-install llvm, sparse-llvm etc., would not
> be built, and the tests would not be run ... ;-)
> 
> Christopher, as the project maintainer, has the joy of making these
> kinds of decisions! :-D

This only solves a part of the problem because the bug report is about
sparse itself, not it's llvm part.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#853568: [Debian-med-packaging] Bug#853568: No idea how to fix abs arguments in nanopolish

[Gert Wollny]

Am Donnerstag, den 31.08.2017, 21:00 -0700 schrieb Walter Landry:
> Andreas Tille  wrote:
> > Hi,
> > 
> > to fix bug #853568 I tried a patch (gcc-7.patch) to fix abs()
> > arguments
> > in nanopolish[1] but I have no idea how to deal with this:
> > 
> > ...
> > g++ -o src/hmm/nanopolish_pore_model_set.o -c -g -O2 -fdebug-
> > prefix-map=/build/nanopolish-0.5.0=. -fstack-protector-strong
> > -Wformat -Werror=format-security -g -O3 -std=c++11 -fopenmp -Wdate-
> > t
> > src/common/nanopolish_variant.cpp: In function
> > 'std::vector extract_variants(const string&, const
> > string&)':
> > src/common/nanopolish_variant.cpp:32:69: error: call of overloaded
> > 'abs(std::__cxx11::basic_string::size_type)' is ambiguous
> >  size_t difference = std::abs(reference.size() -
> > haplotype.size());
> 
> The result of subtracting two size_t's is still a size_t, which is
> unsigned.  So you need to cast it to a signed type.  The correct type
> is ptrdiff_t.
> 
>   http://en.cppreference.com/w/cpp/types/ptrdiff_t
> 
> The line then becomes
> 
>   size_t difference =
> std::abs(static_cast(reference.size() -
> haplotype.size()));

Casting the difference may result in undefined behavior. Consider the
case 

   reference.size() == 1
   haplotype.size() == 2 

then 

   reference.size() - haplotype.size() 

will be 0x (on 32 bit), and how this is casted to a signed type
is implementation dependent (i.e. it is not guaranteed that this simply
wraps to -1, it may also raise a trap because of integer overflow). 

It would be better to avoid the cast altogether by doing something like

   size_t difference = reference.size() > haplotype.size() ? 
   reference.size() - haplotype.size() : 
   haplotype.size() - reference.size(); 


or cast both values before doing the subtraction.

Best, 
Gert 

Bug#873916: RFP: shoogle -- use the Google API from the shell

[Chris Lamb]

Package: wnpp
Severity: wishlist

* Package name: shoogle
* URL : https://github.com/tokland/shoogle
  Upstream Author : Arnau Sanchez (@tokland)
* License : GPLv3

Command-line utility to use the Google API from the shell. An example
to get the long URL using the urlshortener service:


  $ echo '{"shortUrl": "http://goo.gl/Du5PSN"}' | \
  shoogle execute urlshortener:v1.url.get -
  {
"status": "OK",
"id": "http://goo.gl/Du5PSN;,
"longUrl": 
"http://1.bp.blogspot.com/-R0HSXDqlJI8/Tr67i-kr7hI/AAABMko/gaId6iYuhjA/s1600/12_%252520Cross%252520that%252520bridge%252520when%252520we%252520come%252520to%252520it.jpg;,
"kind": "urlshortener#url"
  }


Regards,

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

Bug#873831: [debhelper-devel] Bug#873831: debhelper: [meson] Default to a UTF8 locale?

[Jussi Pakkanen]

On Fri, Sep 1, 2017 at 12:37 AM, Steve Langasek  wrote:

> Because the transition is fraught.  C.UTF-8 is now built and always
> available as part of the libc package, but it's not built into the binary
> and making libc itself treat it as a built-in default is problematic; which
> means there's a need to configure C.UTF-8 on the system at install time as
> the default.

Seems reasonable. For this particular issue Python 3.7 will do the
ANSI -> UTF-8 coercion itself so this will only be an issue until that
lands. In the mean time the simplest solution would seem to be for
debhelper to add the necessary locale setting. This should match what
some of the packages are doing already.

Bug#873915: python2.7: fpectl removal breaks cython

[Ole Streicher]

Package: python2.7
Version: 2.7.14~rc1-2
Severity: serious
Affects: cython

Like #873791, Cython is also affected. This causes an FTBFS for
python-numpy:

https://buildd.debian.org/status/logs.php?pkg=python-numpy=1%3A1.12.1-3.1

The same problem probably happens with  python3.6 3.6.2-3.

Best

Ole

Bug#873914: doc: apt-get manpage mentions '--allow-releaseinfo-changes' instead of '--allow-releaseinfo-change'

[Christos Trochalakis]

Package: apt
Version: 1.5~rc1
Severity: normal
Tags: patch

There is a typo in apt-get manpage mentioning '--allow-releaseinfo-changes-*'
instead of '--allow-releaseinfo-changes-*', I am attaching a patch that
replaces all occurrences.



>From b2c62b51cd9f78fce156b97d0a1e859199842fc9 Mon Sep 17 00:00:00 2001
From: Christos Trochalakis 
Date: Fri, 1 Sep 2017 10:20:18 +0300
Subject: [PATCH] doc: correct '--allow-releaseinfo-change-*' typos

---
 doc/apt-get.8.xml  | 4 ++--
 doc/po/apt-doc.pot | 2 +-
 doc/po/de.po   | 2 +-
 doc/po/es.po   | 2 +-
 doc/po/fr.po   | 2 +-
 doc/po/it.po   | 2 +-
 doc/po/ja.po   | 2 +-
 doc/po/nl.po   | 2 +-
 doc/po/pl.po   | 2 +-
 doc/po/pt.po   | 2 +-
 doc/po/pt_BR.po| 2 +-
 11 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/doc/apt-get.8.xml b/doc/apt-get.8.xml
index c9c876dfd..cc4159fdf 100644
--- a/doc/apt-get.8.xml
+++ b/doc/apt-get.8.xml
@@ -579,7 +579,7 @@
  Configuration Item: Acquire::AllowInsecureRepositories.
  
 
- --allow-releaseinfo-changes
+ --allow-releaseinfo-change
  Allow the update command to continue downloading
  data from a repository which changed its information of the release
  contained in the repository indicating e.g a new major release.
@@ -588,7 +588,7 @@
  See also  for details on the concept and configuration.
  
  Specialist options
- (--allow-releaseinfo-changes-field)
+ (--allow-releaseinfo-change-field)
  exist to allow changes only for certain fields like origin,
  label, codename, suite,
  version and defaultpin. See also .
diff --git a/doc/po/apt-doc.pot b/doc/po/apt-doc.pot
index 88b3ee327..a1dfb814e 100644
--- a/doc/po/apt-doc.pot
+++ b/doc/po/apt-doc.pot
@@ -1427,7 +1427,7 @@ msgstr ""
 #: apt-get.8.xml:1
 msgid ""
 "Specialist options "
-"(--allow-releaseinfo-changes-field)  "
+"(--allow-releaseinfo-change-field)  "
 "exist to allow changes only for certain fields like "
 "origin, label, "
 "codename, suite, "
diff --git a/doc/po/de.po b/doc/po/de.po
index 7cfdd3386..d0033eb2c 100644
--- a/doc/po/de.po
+++ b/doc/po/de.po
@@ -2001,7 +2001,7 @@ msgstr ""
 #. type: Content of: 
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version

Bug#873913: firebird3.0-server-core: adequate reports broken symlinks for databases.conf and fbtrace.conf

[shirish शिरीष]

Package: firebird3.0-server-core
Version: 3.0.2.32703.ds4-9
Severity: normal

Dear Maintainer,

Thank you for maintaining firebird. While I was upgrading one of my
systems, noticed that adequate was sharing/telling about broken
symlinks as below -

$ adequate firebird3.0-server-core

firebird3.0-server-core:amd64: broken-symlink
/usr/lib/x86_64-linux-gnu/firebird/3.0/databases.conf ->
/etc/firebird/3.0/databases.conf
firebird3.0-server-core:amd64: broken-symlink
/usr/lib/x86_64-linux-gnu/firebird/3.0/fbtrace.conf ->
/etc/firebird/3.0/fbtrace.conf

Please fix the same.

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

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

Versions of packages firebird3.0-server-core depends on:
ii  firebird3.0-common  3.0.2.32703.ds4-9
ii  firebird3.0-common-doc  3.0.2.32703.ds4-9
ii  libc6   2.24-12
ii  libfbclient23.0.2.32703.ds4-9
ii  libgcc1 1:7.2.0-1
ii  libib-util  3.0.2.32703.ds4-9
ii  libicu5757.1-6
ii  libncurses5 6.0+20170715-2
ii  libstdc++6  7.2.0-1
ii  libtinfo5   6.0+20170715-2
ii  libtommath1 1.0-4

Versions of packages firebird3.0-server-core recommends:
ii  firebird3.0-utils  3.0.2.32703.ds4-9

Versions of packages firebird3.0-server-core suggests:
pn  firebird3.0-server  

-- 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#873508: sparse test failures on ppc32le (and other not so common archs)

[Josh Triplett]

On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König  Yes
> that works. So to address the Debian bug I can do:
> >
> >  - move sparse to /usr/lib
> >  - teach cgcc about the move of sparse
> >  - make /usr/bin/sparse call cgcc -no-compile "$@"
> 
> I don't like that. It means the user can't invoke sparse directly.
> 
> >
> > or is it easier to teach sparse about the architecture stuff?
> 
> First of all. It is not very trivial to teach sparse about the architecture
> stuff. To my mind, we need to move all the cgcc logic into sparse.

Related to that: while it would mean we couldn't necessarily just rely
entirely on GCC's definitions for a target platform, I think in an ideal
world we could have a sparse binary that understood *all* target
platforms at once, such that you could ask Sparse on x86_64 to "compile"
as though targeting any arbitrary architecture. That would also have the
major advantage of making it easy to run the Sparse testsuite for
*every* target architecture without needing compilers for every such
architecture.

Bug#873832:

[Arturo Borrero Gonzalez]

Control: tags -1 pending

Thanks, I did the change and is now pending:

https://anonscm.debian.org/cgit/pkg-suricata/pkg-suricata.git/commit/?id=93ee9030a53a45c800ad5879c4e7c754c1dc1331

Bug#873912: coffeescript: Error: Cannot find module '../../package.json'

[Adrian Bunk]

Package: coffeescript
Version: 1.12.7~dfsg-1
Severity: serious

Most (all?) packages build-depending on coffeescript
FTBFS with 1.12.7~dfsg-1, example:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/camo.html

...
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/1st/camo-2.3.0+dfsg'
rake --trace build
** Invoke build (first_time)
** Invoke server.js (first_time)
** Invoke server.coffee (first_time, not_needed)
** Execute server.js
coffee -c -o . server.coffee
module.js:471
throw err;
^

Error: Cannot find module '../../package.json'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. 
(/usr/lib/coffee-script/lib/coffee-script/coffee-script.js:20:17)
at Object. 
(/usr/lib/coffee-script/lib/coffee-script/coffee-script.js:426:4)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
rake aborted!
Command failed with status (1): [coffee -c -o . server.coffee...]
/usr/lib/ruby/vendor_ruby/rake/file_utils.rb:66:in `block in 
create_shell_runner'
/usr/lib/ruby/vendor_ruby/rake/file_utils.rb:56:in `sh'
/build/1st/camo-2.3.0+dfsg/Rakefile:2:in `block in '
/usr/lib/ruby/vendor_ruby/rake/task.rb:250:in `block in execute'
/usr/lib/ruby/vendor_ruby/rake/task.rb:250:in `each'
/usr/lib/ruby/vendor_ruby/rake/task.rb:250:in `execute'
/usr/lib/ruby/vendor_ruby/rake/task.rb:194:in `block in invoke_with_call_chain'
/usr/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'
/usr/lib/ruby/vendor_ruby/rake/task.rb:187:in `invoke_with_call_chain'
/usr/lib/ruby/vendor_ruby/rake/task.rb:216:in `block in invoke_prerequisites'
/usr/lib/ruby/vendor_ruby/rake/task.rb:214:in `each'
/usr/lib/ruby/vendor_ruby/rake/task.rb:214:in `invoke_prerequisites'
/usr/lib/ruby/vendor_ruby/rake/task.rb:193:in `block in invoke_with_call_chain'
/usr/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'
/usr/lib/ruby/vendor_ruby/rake/task.rb:187:in `invoke_with_call_chain'
/usr/lib/ruby/vendor_ruby/rake/task.rb:180:in `invoke'
/usr/lib/ruby/vendor_ruby/rake/application.rb:152:in `invoke_task'
/usr/lib/ruby/vendor_ruby/rake/application.rb:108:in `block (2 levels) in 
top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:108:in `each'
/usr/lib/ruby/vendor_ruby/rake/application.rb:108:in `block in top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:117:in `run_with_threads'
/usr/lib/ruby/vendor_ruby/rake/application.rb:102:in `top_level'
/usr/lib/ruby/vendor_ruby/rake/application.rb:80:in `block in run'
/usr/lib/ruby/vendor_ruby/rake/application.rb:178:in 
`standard_exception_handling'
/usr/lib/ruby/vendor_ruby/rake/application.rb:77:in `run'
/usr/bin/rake:27:in `'
Tasks: TOP => build => server.js
debian/rules:30: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 1

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Julien Puydt]

Le 01/09/2017 à 00:03, Ximin Luo a écrit :
> Thanks for that. I forced the rebuild to continue by skipping the flint tests 
> with DEB_BUILD_OPTIONS=nocheck sbuild --profiles=nocheck , and am 
> pleased to report that singular and pynac built (including tests) 
> successfully.

That is good news, but since FLINT saw problems, they may be hidden.

> If the flint maintainer doesn't fix this "soon" then perhaps we can just 
> disable that one test for the short-term to allow this transition to go 
> forward.

I'm not sure it is a good idea to push things forward: Bill (main
developer) said those tests only pass data to NTL, let it do the
calculation and get the result back. If those conversions are
problematic, the root can be:
- NTL changed something and it wasn't intentional, so NTL will need a fix ;
- NTL changed something and it was intentional, so FLINT will need a fix.

In either case, there is a good chance that this change will break
things also higher up the stack : FLINT is just an early warning sign,
and ignoring it is wrong.

I suggest to wait for a diagnosis before planning anything.

Snark

Bug#873911: default user name doesn't change

[Harald Dunkel]

Package: lightdm
Version: 1.18.3-1

After a first login lightdm reuses this user name as the default
login name forever, instead of using the last user name. Apparently 
there is no way to override. Reinstalling lightdm does not help.

This is highly annoying esp. for a laptop user. A laptop is 
something very personal. My colleagues request to replace lightdm 
by another display manager just to get rid of this.

/usr/share/lightdm/lightdm.conf.d/90_local.setting.conf is attached.

Please fix for Stretch.


Thanx in advance
Harri
[Seat:*]
greeter-hide-users=false

Bug#873910: django-reversion FTBFS: ERROR: testFieldDictFieldExclude (test_app.tests.test_models.FieldDictExcludeTest)

[Adrian Bunk]

Source: django-reversion
Version: 2.0.10-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/django-reversion.html

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/1st/django-reversion-2.0.10'
PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="python{version} tests/manage.py test 
tests" dh_auto_test
I: pybuild base:184: python2.7 tests/manage.py test tests
System check identified some issues:

WARNINGS:
?: (1_10.W001) The MIDDLEWARE_CLASSES setting is deprecated in Django 1.10 and 
the MIDDLEWARE setting takes precedence. Since you've set MIDDLEWARE, the value 
of MIDDLEWARE_CLASSES is ignored.

System check identified 1 issue (0 silenced).
E.sss...ss.ss...sss..sss.s..s.s
==
ERROR: testFieldDictFieldExclude 
(test_app.tests.test_models.FieldDictExcludeTest)
--
Traceback (most recent call last):
  File 
"/build/1st/django-reversion-2.0.10/tests/test_app/tests/test_models.py", line 
267, in testFieldDictFieldExclude
reversion.register(TestModel, exclude=("name",))
  File 
"/build/1st/django-reversion-2.0.10/.pybuild/pythonX.Y_2.7/build/reversion/revisions.py",
 line 404, in register
return register(model)
  File 
"/build/1st/django-reversion-2.0.10/.pybuild/pythonX.Y_2.7/build/reversion/revisions.py",
 line 373, in register
model=model,
RegistrationError:  has already been 
registered with django-reversion

--
Ran 131 tests in 11.009s

FAILED (errors=1, skipped=20)
Creating test database for alias 'default'...
Destroying test database for alias 'default'...
E: pybuild pybuild:283: test: plugin custom failed with: exit code=1: python2.7 
tests/manage.py test tests
dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
debian/rules:12: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 25

Bug#873908: AST-2017-006: Shell access command injection inapp_minivm

[Bernhard Schmidt]

Package: src:asterisk
Severity: important
Tags: security

   Asterisk Project Security Advisory - AST-2017-006

 ProductAsterisk  
 SummaryShell access command injection in app_minivm  
Nature of Advisory  Unauthorized command execution
  SusceptibilityRemote Authenticated Sessions 
 Severity   Moderate  
  Exploits KnownNo
   Reported On  July 1, 2017  
   Reported By  Corey Farrell 
Posted On   
 Last Updated OnJuly 11, 2017 
 Advisory Contact   Richard Mudgett   
 CVE Name   

Description  The app_minivm module has an “externnotify” program
  
 configuration option that is executed by the MinivmNotify
 dialplan application. The application uses the caller-id 
 name and number as part of a built string passed to the OS   
 shell for interpretation and execution. Since the caller-id  
 name and number can come from an untrusted source, a 
 crafted caller-id name or number allows an arbitrary shell   
 command injection.   

Resolution  Patched Asterisk’s app_minivm module to use a different   
system call that passes argument strings in an array instead  
of having the OS shell determine the application parameter
boundaries.   

   Affected Versions   
 Product   Release  
   Series   
  Asterisk Open Source  11.xAll releases  
  Asterisk Open Source  13.xAll releases  
  Asterisk Open Source  14.xAll releases  
   Certified Asterisk   11.6All releases  
   Certified Asterisk   13.13   All releases  

  Corrected In
  Product  Release
Asterisk Open Source   11.25.2, 13.17.1, 14.6.1   
 Certified Asterisk11.6-cert17, 13.13-cert5   

 Patches  
SVN URL   Revision  
   http://downloads.asterisk.org/pub/security/AST-2017-006-11.diffAsterisk  
  11
   http://downloads.asterisk.org/pub/security/AST-2017-006-13.diffAsterisk  
  13
   http://downloads.asterisk.org/pub/security/AST-2017-006-14.diffAsterisk  
  14
   http://downloads.asterisk.org/pub/security/AST-2017-006-11.6.diff  Certified 
  Asterisk  
  11.6  
   http://downloads.asterisk.org/pub/security/AST-2017-006-13.13.diff Certified 
  Asterisk  
  13.13 

Links  https://issues.asterisk.org/jira/browse/ASTERISK-27103 

Asterisk Project Security Advisories are posted at
http://www.asterisk.org/security  
  
This document may be superseded by later versions; if so, the latest  
version will be posted at 
http://downloads.digium.com/pub/security/AST-2017-006.pdf and 
http://downloads.digium.com/pub/security/AST-2017-006.html

Revision History
Date   EditorRevisions Made   
July 11, 2017  Richard Mudgett  Initial document created  

   Asterisk Project Security Advisory - AST-2017-006
   Copyright © 2017 Digium, Inc. All Rights Reserved.
  Permission is hereby granted to distribute and publish this advisory in its
   original, unaltered form.

Bug#873907: AST-2017-005 - Media takeover in RTP stack

[Bernhard Schmidt]

Package: src:asterisk
Severity: important
Tags: security

   Asterisk Project Security Advisory - AST-2017-005

 ProductAsterisk  
 SummaryMedia takeover in RTP stack   
Nature of Advisory  Unauthorized data disclosure  
  SusceptibilityRemote Unauthenticated Sessions   
 Severity   Critical  
  Exploits KnownNo
   Reported On  May 17, 2017  
   Reported By  Klaus-Peter Junghanns 
Posted On   
 Last Updated OnAugust 30, 2017   
 Advisory Contact   Joshua Colp  
 CVE Name   

Description  The "strictrtp" option in rtp.conf enables a feature of the  
 RTP stack that learns the source address of media for a  
 session and drops any packets that do not originate from 
 the expected address. This option is enabled by default in   
 Asterisk 11 and above.   
  
 The "nat" and "rtp_symmetric" options for chan_sip and   
 chan_pjsip respectively enable symmetric RTP support in the  
 RTP stack. This uses the source address of incoming media
 as the target address of any sent media. This option is not  
 enabled by default but is commonly enabled to handle 
 devices behind NAT.  
  
 A change was made to the strict RTP support in the RTP   
 stack to better tolerate late media when a reinvite occurs.  
 When combined with the symmetric RTP support this
 introduced an avenue where media could be hijacked. Instead  
 of only learning a new address when expected the new code
 allowed a new source address to be learned at all times. 
  
 If a flood of RTP traffic was received the strict RTP
 support would allow the new address to provide media and 
 with symmetric RTP enabled outgoing traffic would be sent
 to this new address, allowing the media to be hijacked.  
 Provided the attacker continued to send traffic they would   
 continue to receive traffic as well. 

Resolution  The RTP stack will now only learn a new source address if it  
has been told to expect the address to change. The RTCP   
support has now also been updated to drop RTCP reports that   
are not regarding the RTP session currently in progress. The  
strict RTP learning progress has also been improved to guard  
against a flood of RTP packets attempting to take over the
media stream. 

   Affected Versions   
 Product   Release  
   Series   
  Asterisk Open Source  11.x11.4.0
  Asterisk Open Source  13.xAll Releases  
  Asterisk Open Source  14.xAll Releases  
   Certified Asterisk   11.6All Releases  
   Certified Asterisk   13.13   All Releases  

  Corrected In
  Product  Release
Asterisk Open Source   11.25.2, 13.17.1, 14.6.1   
 Certified Asterisk11.6-cert17, 13.13-cert5   

 Patches  
SVN URL   Revision  
   http://downloads.asterisk.org/pub/security/AST-2017-005-11.diffAsterisk  
  11
   http://downloads.asterisk.org/pub/security/AST-2017-005-13.diffAsterisk  
  13
   http://downloads.asterisk.org/pub/security/AST-2017-005-14.diffAsterisk  
  

Bug#873909: AST-2017-007: Remote Crash Vulerability in res_pjsip

[Bernhard Schmidt]

Package: src:asterisk
Severity: important
Tags: security

   Asterisk Project Security Advisory - AST-2017-007

 ProductAsterisk  
 SummaryRemote Crash Vulerability in res_pjsip
Nature of Advisory  Denial of Service 
  SusceptibilityRemote Unauthenticated Sessions   
 Severity   Moderate  
  Exploits KnownNo
   Reported On  August 30, 2017   
   Reported By  Ross Beer 
Posted On   
 Last Updated OnAugust 30, 2017   
 Advisory Contact   George Joseph  
 CVE Name   

Description  A carefully crafted URI in a From, To or Contact header  
 could cause Asterisk to crash.   

Resolution  Patched pjsip_message_ip_updater to properly ignore the   
trigger URI.  

   Affected Versions  
Product   Release Series  
  Asterisk Open Source   13.15.0  
  Asterisk Open Source14.4.0  

  Corrected In   
Product  Release  
 Asterisk Open Source13.17.1, 14.6.1  

Patches  
SVN URL  Revision 
   http://downloads.asterisk.org/pub/security/AST-2017-007-13.diff   Asterisk 
 13   
   http://downloads.asterisk.org/pub/security/AST-2017-007-14.diff   Asterisk 
 14   

Links  https://issues.asterisk.org/jira/browse/ASTERISK-27152 

Asterisk Project Security Advisories are posted at
http://www.asterisk.org/security  
  
This document may be superseded by later versions; if so, the latest  
version will be posted at http://downloads.digium.com/pub/security/.pdf   
and http://downloads.digium.com/pub/security/.html

Revision History
 Date   Editor   Revisions Made   
August 30, 2017  George Joseph  Initial document created  

  Asterisk Project Security Advisory -
  Copyright (c) 2017 Digium, Inc. All Rights Reserved.
  Permission is hereby granted to distribute and publish this advisory in its
   original, unaltered form.

Bug#871697: jellyfish: Please add arm64

[Edmund Grimley Evans]

> unfortunately the bug does not seem to be sufficient.  See
>
> 
> https://buildd.debian.org/status/fetch.php?pkg=jellyfish=arm64=2.2.6-5=1504220784=0
>
> Any further hints?

"portability.patch" is commented out in debian/patches/series and was
not applied?

Bug#682264: #682264,libapache2-mod-perl2: Crash at server startup when pre-loading Plack app

[Dmitry Smirnov]

I had the same problem until I've realised that Apache now uses event 
module by default. Solution is simple -- just switch to (traditional) 
MPM Prefork model as follows:



a2dismod mpm_event
a2enmod mpm_prefork


--
All the best,
 Dmitry Smirnov

Bug#864620: camo: missing dependency on openssl

[Adrian Bunk]

Control: severity -1 serious

On Sun, Jun 11, 2017 at 02:00:35PM +0200, Jakub Wilk wrote:
> Package: camo
> Version: 2.3.0+dfsg-1
> 
> This happened when installing camo:
> 
>Setting up camo (2.3.0+dfsg-1) ...
>/var/lib/dpkg/info/camo.postinst: 1: /var/lib/dpkg/info/camo.postinst: 
> openssl: not found

IMHO this is an RC issue.

> The installation didn't fail, but I ended up with this:
> 
>$ grep KEY /etc/default/camo
>CAMO_KEY=

I would say not failing is a second bug that masked the first.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#873439: [pkg-fgfs-crew] Bug#873439: flightgear: CVE-2017-13709: Incorrect access control

[Markus Wanner]

Hi,

while this has been fixed in unstable, I have also requested to upload
to stable and unstable. Here are the issues and versions for reference:

stable:#873754 1:2016.4.4+dfsg-3+deb9u1
oldstable: #873877 3.0.0-5+deb8u3

Assuming the release team approves the uploads, the fix should enter
Debian stable and oldstable with the next point release.

Kind Regards

Markus Wanner



signature.asc
Description: OpenPGP digital signature

Bug#669210: gnome-shell-extensions: auto-move-windows does not work with

[Peter Janssen]

Dear Victor,

I'm experiencing the same behaviour with mattermost. This application is
installed through dpgk with a downloaded *.deb package. Initially it did
not show op in the application list but this was fixed by adding %F to the
*.desktop files exec.

Hope this helps track down the issue. Do you need more information?

Kind Regards,

Peter


On Mon, 30 Jul 2012 16:11:25 +0200 Francois Mescam 
wrote:

> Dear Victor,

>

> As you ask I made the test again and it does not work.

>

> The version for gnome-shell-extensions is 3.4.0-2.

>

> The settings are :

> gsettings get org.gnome.shell.extensions.auto-move-windows
application-list

> ['icedove.desktop:2', 'iceweasel.desktop:2', 'zim.desktop:4',

> 'chromium.desktop:8', 'freecell.desktop:8', 'gcalctool.desktop:8']

>

> It works fine for chromium for example and it does not work for freecell.

>

> With my best regards

>

> --

>   Francois Mescam Tel:+33 6 16 05 77 61

>

>