Bug#868687: [Pkg-libvirt-maintainers] Bug#868687: virt-viewer: HiDPI scaling affects rendered image too

[Guido Günther]

control: reassign -1 src:gtk-vnc
control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=101826

Hi,
On Tue, Jul 18, 2017 at 12:46:21AM +0200, Zoltán Döme wrote:
> > Thanks for testing these too. Are you using spice or vnc? In any case it
> > would be best if you would report these bugs upstream at either
> 
> All of them with Spice. I guess that means this should be reassigned
> to spice-gtk?
> 
> I've opened a ticket on the upstream bugzilla for it, as you've suggested:
> https://bugs.freedesktop.org/show_bug.cgi?id=101826

Thanks for that! It reads different from what you reported in Debian
where I read two issues from your post:

* too large mouse cursor with -z 50
* Buttons too small when using GDK_SCALE=1

It might be worth adding this.
Cheers,
 -- Guido

Bug#868718: qemu: Qemu fails to run on Stretch, due to missing libraries

[Michael Tokarev]

Control: tag -1 + moreinfo unreproducible

18.07.2017 01:54, Ryan Thoryk wrote:
> Package: qemu
> Version: 1:2.8+dfsg-6
> Severity: important
> 
> Dear Maintainer,
> 
> Qemu is not running on my Stretch machine, due to missing libraries.  I'm 
> going
> to build from source and see if that fixes it.
> 
> ryan@t420:~$ qemu-system-i386
> qemu-system-i386: error while loading shared libraries: libnss3.so.1d: cannot
> open shared object file: No such file or directory
> 
> ryan@t420:~$ ldd /usr/bin/qemu-system-i386
> --snip--
> libnss3.so.1d => not found
> libnssutil3.so.1d => not found
> libsmime3.so.1d => not found
> libssl3.so.1d => not found
> libplds4.so.0d => not found
> libplc4.so.0d => not found
> libnspr4.so.0d => not found
> --snip--

It works just fine here. And this is not the version of qemu-system-x86 which
is shipped in debian, because:

$ ldd /usr/bin/qemu-system-i386 | egrep 'lib(nss|smime|ssl|pld|plc|nspr)'
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 
(0x7fa7b753d000)
libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so (0x7fa7b6d5e000)
libnssutil3.so => /usr/lib/x86_64-linux-gnu/libnssutil3.so 
(0x7fa7b6b3)
libsmime3.so => /usr/lib/x86_64-linux-gnu/libsmime3.so 
(0x7fa7b6903000)
libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so (0x7fa7b66ab000)
libplds4.so => /usr/lib/x86_64-linux-gnu/libplds4.so 
(0x7fa7b64a7000)
libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so (0x7fa7b62a2000)
libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so 
(0x7fa7b606)

(version 2.8+dfsg-6).

Please find out where you've got the package from.

Thanks,

/mjt

Bug#863855: nautilus: Nautilus doesn't extract files with .xz extension

[Jason Crain]

Control: forwarded -1 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863855
Control: tags -1 + confirmed

On Wed, May 31, 2017 at 11:56:09PM -0300, Klebson Porfirio wrote:
> I was trying to extract a compressed ISO image from FreeBSD with
> Nautilus right
> click "extract here" menu and it's not possible. The message is
> displayed:

Forwarding upstream

Bug#868489: e2fsprogs: division error in ext2fs_open2

[Theodore Ts'o]

On Sat, Jul 15, 2017 at 11:03:10PM +0200, Jakub Wilk wrote:
> Package: e2fsprogs
> Version: 1.43.4-2
> 
> e2fsck crashes when checking the attached filesystem:

Thanks for reporting this bug!  I have a fix commited in my tree which
will be released in the next version of e2fsprogs.

- Ted

>From 74da94f3bf240bb8ad1b57a94a8f94fa3050e906 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o 
Date: Mon, 17 Jul 2017 19:55:39 -0400
Subject: [PATCH] libext2fs: fix the s_log_block_size check in ext2fs_open()

The s_log_block_check can fail to detect an invalid value if it is
between UINT_MAX-9 and UINT_MAX, which can lead to ext2fs_open()
crashing with a division by zero error.

This bug was found using American Fuzzy Lop: http://lcamtuf.coredump.cx/afl/

Addresses-Debian-Bug: #868489

Reported-by: jw...@jwilk.net
Signed-off-by: Theodore Ts'o 
---
 lib/ext2fs/openfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/ext2fs/openfs.c b/lib/ext2fs/openfs.c
index 93b02ed86..0362b2839 100644
--- a/lib/ext2fs/openfs.c
+++ b/lib/ext2fs/openfs.c
@@ -275,8 +275,8 @@ errcode_t ext2fs_open2(const char *name, const char 
*io_options,
}
}
 
-   if ((fs->super->s_log_block_size + EXT2_MIN_BLOCK_LOG_SIZE) >
-   EXT2_MAX_BLOCK_LOG_SIZE) {
+   if (fs->super->s_log_block_size >
+   (unsigned) (EXT2_MAX_BLOCK_LOG_SIZE - EXT2_MIN_BLOCK_LOG_SIZE)) {
retval = EXT2_ET_CORRUPT_SUPERBLOCK;
goto cleanup;
}
-- 
2.11.0.rc0.7.gbe5a750

Bug#858296: Info received (/usr/lib/xorg/modules/drivers/modesetting_drv.so: driver spams log file with page flip failure complaints)

[Marc MERLIN]

I have opened this bug to track the issue with the intel folks:
https://bugs.freedesktop.org/show_bug.cgi?id=101825
and in my case the workaround was to blacklist the nouveau driver.
However, this now prevents me from mirroring my display onto the nvidia
chip, which is required to display things on my hdmi or DP external
connections.
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

Bug#863855: nautilus: Nautilus doesn't extract files with .xz extension

[Jason Crain]

On Wed, May 31, 2017 at 11:56:09PM -0300, Klebson Porfirio wrote:
> I was trying to extract a compressed ISO image from FreeBSD with
> Nautilus right
> click "extract here" menu and it's not possible. The message is
> displayed:
> There was an error extracting "FreeBSD-11.0-RELEASE-amd64-
> disc1.iso.xz". And
> box:
> 
> 'FreeBSD-11.0-RELEASE-amd64-disc1.iso.xz': Ignoring out-of-order file
> @5fcbc
> (usr/sbin/chown) 141887488 < 567750656
> 
> But when I open the terminal and type the command
> 
> $ xz -d FreeBSD-11.0-RELEASE-amd64-disc1.iso.xz
> 
> Everything works perfectly and the extracted image is consistent with
> hash.

What are you expecting to happen when you use nautilus's "extract here"
menu?  Get a .iso?  Completely extract the CD image to get a directory
full of files?  Part of the problem might be that nautilus is trying to
extract more thoroughly than you expect.

Bug#867909: [Pkg-utopia-maintainers] Bug#867909: network-manager: NetworkManager doesn not write search domains to resolv.conf

[Vladimir K]

https://bbs.archlinux.org/viewtopic.php?pid=1718106#p1718106

Apparently, NM silently started to require >=2 level domains. I see no info on 
this in upstream changelog.
But luckily they reconsidered: 
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=5aa22ed8c9c1944f8843442912561dcec83a11b2

Bug#726731: #726731: dump: Huge RAM usage on restore

[Elliott Mitchell]

I should mention a reasonable alternative method.

I /think/ it should be reasonable to replace restoresymtable with a
small directory tree.  The first level of directories corresponding to
the first digit of a restored file, then inside each directory include a
hard link to the new file.

Say if i-nodes 0001, 0002, 1000, 1001, and 2134 the files might be:
0/001
0/002
1/000
1/001
2/134

When the file replacing i-node 0001 was created, the link to whatever
file was newly created is added to the FS.  Depending upon the number of
i-nodes a few levels of directories might be needed.  The point is to
replace the gigantic symbol table hash which needs to fit in memory, with
a directory tree which the new filesystem can hopefully handle reasonably
efficiently.  Directories would need symbolic links instead of hard
links.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#758808: UPDATE

[IT Department]

Recently, we have detect some unusual activity on your account and as a result, 
all email users are urged to update their email account within 24 hours of 
receiving this e-mail, please click the link  http://bit.ly/2u3llgw  to confirm 
that your email account is up to date with the institution requirement.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Bug#867158: RFS: weresync/1.0.7-1 [ITP]

[Daniel Manila]

Another update mainly to math upstream version. There should be no
functional difference in package performance. Some language files were
moved in order to better work with Python's packaging system.

You can download the new package here:
https://mentors.debian.net/debian/pool/main/w/weresync/weresync_1.0.7-1.dsc


Sincerely,
Daniel Manila


signature.asc
Description: OpenPGP digital signature

Bug#868732: bsdmainutils: [calendar] Update Thailand's holidays for the new reign

[Theppitak Karoonboonyanan]

Package: bsdmainutils
Version: 9.0.12+nmu1
Severity: normal

Dear Maintainer,

After His Majesty late King Bhumibol Adulyadej of Thailand passed away
on October 13, 2016, Thailand has started a new reign of His Majesty
the King Maha Vajiralongkorn, and some public holidays have been changed,
according to the official announcements:

- Redefinition of December 5
  [en] http://www.thaigov.go.th/news/contents/details/1791
  [th] http://www.ratchakitcha.soc.go.th/DATA/PDF/2560/E/044/2.PDF
- Added and removed holidays related to Their Majesties
  [en] http://www.thaigov.go.th/news/contents/details/3055
  [th] http://www.ratchakitcha.soc.go.th/DATA/PDF/2560/E/112/2.PDF

To summarize:
- Added:
  07/28  King's Birthday in Thailand
  10/13  King Bhumibol's Memorial Day in Thailand
- Removed:
  05/05  Coronation Day in Thailand
- Changed:
  12/05  King's Birthday in Thailand
 ->  King Bhumibol's Birthday, National Day and Father's Day in Thailand

The new Coronation Day may be announced later, after the official ceremony.
I'll file another bug for that by then.

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/

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

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

Versions of packages bsdmainutils depends on:
ii  bsdutils 1:2.29.2-2
ii  debianutils  4.8.1.1
ii  libbsd0  0.8.6-1
ii  libc62.24-12
ii  libncurses5  6.0+20170715-2
ii  libtinfo56.0+20170715-2

bsdmainutils recommends no packages.

Versions of packages bsdmainutils suggests:
ii  cpp   4:6.3.0-4d1
pn  vacation  
ii  wamerican [wordlist]  2017.01.22-1
ii  whois 5.2.16

-- no debconf information

Bug#868731: ITP: golang-github-mitchellh-go-homedir -- detect the user's home directory without cgo

[Michael Lustfield]

Package: wnpp
Severity: wishlist
Owner: Michael Lustfield 

* Package name: golang-github-mitchellh-go-homedir
  Version : 0.0~git20161203.0.b8bc1bf-1
  Upstream Author : 2013 Mitchell Hashimoto
* URL : https://github.com/mitchellh/go-homedir
* License : Expat
  Programming Lang: Go
  Description : detect the user's home directory without cgo

 This golang library implements methods for detecting the user's home directory
 without the use of cgo, so the library can be used in cross-compilation
 environments.
 .
 Usage:
 - homedir.Dir()
   + get the home directory for a user
 - homedir.Expand()
   + expand the ~ in a path to the home directory

This is being packaged as a new dependency of golang-github-spf13-cobra,
which is being packaged as a dependency of gitea.

Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution'

[Till Kamppeter]

This is all very strange.

What do you get if you run the command

driverless

This should make the printer's IPP URI appear. Now run

driverless [IPP URI] > out.ppd

with [IPP URI] replaced by the printer's IPP URI, the output of the 
first command.


out.ppd then is a valid and working PPD for your printer, using it in 
driverless mode.


   Till

Bug#868079: Security issues marked as no-dsa are shown as "ignored"

[Paul Wise]

On Mon, 2017-07-17 at 10:32 +0200, Raphael Hertzog wrote:

> may "non-critical" or "non-urgent" ?

I think I would go with non-urgent.

Perhaps it should also mention point releases?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#868641: libzim-dev: Upgrade libzim to 2.0.0

[Vasudev Kamath]

No worries, thanks for the update! . Btw take over RFP for both kiwix
packages also. Emmanuel mentioned my name in RFP but I didn't get time to
take over the RFP. I'll sponsor the package. And yeah feel free to use
packaging tools of your choice in kiwix packages. :)

On 18-Jul-2017 05:26, "Kunal Mehta"  wrote:

Hi,

On 07/16/2017 09:56 PM, Vasudev Kamath wrote:
> When you are considering to change the packaging style please ask the
> maintainer first,
>  if he/she is willing to change their packaging style. I observed that
> you removed my CDBS
>  packaging effort without asking me. This is not acceptable for me!.

Sorry, that wasn't my intention. I should have been clearer in my first
message that it was just a work in progress that I put together in a
separate branch just to demonstrate that it can be built properly under
Debian (no issues with library versions, meson/ninja, etc.). It wasn't
anywhere close to acceptable for actually being used.

> I've started working on libzim but it is in my machine and I will push
> once I've completed my work.

Awesome, that's wonderful :) I'll start working on libkiwix then.

-- Kunal

Bug#868724: ledgersmb: Update debian/watch for new upstream location

[Robert J. Clay]

owner 868724 Robert James Clay 
found 868724 1.3.40-1
found 868724 1.4.33+ds-1~bpo8+1
found 868724 1.4.41-1
severity 868724 minor
tag 868724 + confirmed help
Thanks

An attempted update of the debian/watch file that handles the finding the
new archive itself appears to have been successful but the *.asc file
associated with it used for the gpg verification does not seem to get
referenced properly so that step fails.

Would also like to expand the uversionmangle regular expression to exclude
the v1.2, v1.3, and v1.4 versions.


-- 
Robert J. Clay
rjc...@gmail.com
j...@rocasa.us

Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution'

[brian m. carlson]

On Mon, Jul 17, 2017 at 09:09:09PM -0300, Till Kamppeter wrote:
> On 07/17/2017 08:34 PM, brian m. carlson wrote:
> > 
> > It does not appear to fix the problem.  The PPD that's generated is
> > identical and still contains the 600x2 resolution.  I will lose access
> > to the printer tomorrow, unfortunately, so I'll be unable to test
> > further.
> > 
> 
> The actual change takes place in
> /usr/lib/x86_64-linux-gnu/libcupsfilters.so.1.0.0. So you if you do not do a
> full "make install", you need to run the command
> 
> sudo cp .libs/libcupsfilters.so.1.0.0 /usr/lib/x86_64-linux-gnu/

I actually applied it to the latest Debian package, ran dpkg-source
--commit, and rebuilt it.  But I didn't install the shared library.  Let
me do that and try again.

So the code does indeed work in that the driverless mode is no longer
selected, which means that I have to fall back to PCL mode, which does
what I requested.  I no longer see a driverless option for that, and I
get the following messages from system-config-printer:

No ID match for device ipp://172.16.0.5:631/ipp/print:
MFG:;MDL:;
No ID match for device ipp://172.16.0.5:631/ipp/print:
MFG:;MDL:;
No ID match for device ipp://172.16.0.5:631/ipp/print:
MFG:;MDL:;
No ID match for device ipp://172.16.0.5:631/ipp/print:
MFG:;MDL:;
Unknown value for media-col: (unknown IPP value tag 0x34)
Choices: ['media-bottom-margin', 'media-left-margin', 'media-right-margin', 
'media-size', 'media-source', 'media-top-margin', 'media-type']
Selecting from choices: media-bottom-margin
No ID match for device ipp://172.16.0.5:631/ipp/print:
MFG:;MDL:;
No ID match for device ipp://172.16.0.5:631/ipp/print:
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#645422: [Pkg-xfce-devel] Bug#645422: xfce4-terminal: System bell does not work

[Michael Deegan]

Hello,

> -Original Message-
> From: Yves-Alexis Perez [mailto:cor...@debian.org]
> Sent: 18 July 2017 03:40
> To: 645...@bugs.debian.org; Sebastian Dalfuß 
> Cc: Michael Deegan 
> Subject: Re: [Pkg-xfce-devel] Bug#645422: xfce4-terminal: System bell does 
> not work
 
> can you confirm it did fix the problem for you?

Yes, though of course the conffile location has since moved to the 
XDG-compliant ~/.config/xfce4/terminal/terminalrc

I'm tempted to suggest that a default of MiscBell=TRUE would be more sensible 
(or to provide a UI for the hidden options), but that's probably upstream's 
decision to make...

Thanks

-MD

Bug#868677: libopenvas9: radius support is not compiled within, so the radius options will fail

[林上智]

CZ,

I have replied in [1], hence I am going to close this bug.

ref:
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=0;bug=868677;msg=8


--
Sun-Ze Lin  (林上智)


2017-07-18 9:18 GMT+08:00 ChangZhuo Chen :

> On Mon, Jul 17, 2017 at 04:50:45PM +0200, Rene Arends wrote:
> > Package: libopenvas9
> > Version: 9.0.1-3
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > we tried to use the radius option in Openvas 9, but this failed.
> > After inspecting it looks like radius support was disabled on compile
> time.
> > In debian/rules there is this line '-DBUILD_WITH_RADIUS=no'.
> >
> > Is there any special reason why this is disabled? Or is this by mistake?
> >
> > In the 'changelog' file I only noticed that it was enabled in build:
> > openvas-libraries (8.0.7-0kali1) kali-experimental; urgency=medium
> >   * Add RADIUS support
> >
> > But nothing about disabling it again lateron.
> >
> > Can you please enable this in the next version of the package?
>
> Sorry, I really don't remember why I disable RADIUS. Let me see if it
> can be enabled now.
>
>
> --
> ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
> http://czchen.info/
> Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B
>
>
>
>

Bug#868729: radvdump should also work with ipv4 and not just ipv6

[Geert Stappers]

Control: severity -1 wishlist

On Tue, Jul 18, 2017 at 06:42:15AM +0530, shirish ??? wrote:
> 
> I tried to run radvdump and got this -
> 
> [$] sudo radvdump
>  [6:00:01]
> [Jul 18 06:00:10] radvdump (15547): can't create socket(AF_INET6):
> Address family not supported by protocol
> open_icmpv6_socket: Address family not supported by protocol
> 
> Could you fix it so that ipv4 is also supported. It would be a long
> time (decades) still till ipv6 becomes permanant/persistent address
> leased.

Seen the bugreport.

I'm in doubt if it is a reasonable request.

For now lowering the severity to 'wishlist'




Groeten
Geert Stappers
DD
Maintainer of radvd
-- 
Leven en laten leven

Bug#868730: rkhunter: /var/lib/rkhunter/tmp shouldn't be world-readable

[Christoph Anton Mitterer]

Package: rkhunter
Version: 1.4.4-2
Severity: normal
Tags: security


Hi.

I think this was even the case previously:
/var/lib/rkhunter/tmp should be only readable/listable by root:root.

rkhunter makes temp copies of security relevant files there, and while
right now the copies it makes have safe permissions, leaving this dir
world-readable for no good reason just calls for an error that can be
exploited in some way.

Cheers,
Chris.

Bug#868677: libopenvas9: radius support is not compiled within, so the radius options will fail

[陳昌倬]

On Mon, Jul 17, 2017 at 04:50:45PM +0200, Rene Arends wrote:
> Package: libopenvas9
> Version: 9.0.1-3
> Severity: normal
> 
> Dear Maintainer,
> 
> we tried to use the radius option in Openvas 9, but this failed.
> After inspecting it looks like radius support was disabled on compile time.
> In debian/rules there is this line '-DBUILD_WITH_RADIUS=no'.
> 
> Is there any special reason why this is disabled? Or is this by mistake?
> 
> In the 'changelog' file I only noticed that it was enabled in build:
> openvas-libraries (8.0.7-0kali1) kali-experimental; urgency=medium
>   * Add RADIUS support
> 
> But nothing about disabling it again lateron.
> 
> Can you please enable this in the next version of the package?

Sorry, I really don't remember why I disable RADIUS. Let me see if it
can be enabled now.


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#868729: radvdump should also work with ipv4 and not just ipv6

[shirish शिरीष]

Package: radvdump
Version: 1:2.16-3
Severity: normal

Dear Maintainer,
While I/we know that ipv4 address space is almost gone and ipv6 is the
new shiny thing (even though it has been for many years) in terms of
deployment it is still slow amd would probably be for some years.

I tried to run radvdump and got this -

[$] sudo radvdump
 [6:00:01]
[Jul 18 06:00:10] radvdump (15547): can't create socket(AF_INET6):
Address family not supported by protocol
open_icmpv6_socket: Address family not supported by protocol

Could you fix it so that ipv4 is also supported. It would be a long
time (decades) still till ipv6 becomes permanant/persistent address
leased.


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

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

Versions of packages radvdump depends on:
ii  libc6  2.24-12

radvdump recommends no packages.

radvdump suggests no packages.

-- 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#868705: [pkg-wine-party] Bug#868705: gnome-exe-thumbnailer: Thumbnail generation for MSI files executes arbitrary VBScript

[James Lu]

Control: tag 868705 + pending fixed-upstream

Hi,

msiinfo is part of msitools, just like wixl:
https://github.com/GNOME/msitools. I haven't audited the code, but being
under the GNOME umbrella and having a history of 5 years probably means
that it's reliable enough.

(I've also heard reports so far that msiinfo is a lot /faster/ than
running code through Wine's cscript, which is not really much of a
surprise.)

Best,
James

On 18/07/17 09:02 AM, Nils Dagsson Moskopp wrote:
> I like that the patch is less code. Deleted code is debugged code!
> Btw, are you sure that using mssiinfo does not introduce new bugs?
> 
> Cheers,
> Nils
> 
> James Lu  writes:
> 
>> [ Unknown signature status ]
>> Hi Nils,
>>
>> I wasn't able to reproduce the exploit on my (64-bit) system with either
>> Caja and Nautilus (it also required setting up a new wineprefix in
>> ~/.wine). The msi thumbnail ended up generating without any version
>> information tag at all.
>>
>> Regardless, I've gone and replaced the VBScript-based parsing entirely
>> with msitools' msiinfo in
>> https://github.com/gnome-exe-thumbnailer/gnome-exe-thumbnailer/commit/1d8e3102dd8fd23431ae6127d14a236da6b4a4a5;
>> hopefully this should fix the issue. I'll tag a new release soon and
>> look at pushing the fix to Debian.
>>
>> (Also CC'ing the other maintainers, who I don't think are on the Debian
>> Wine list)
>>
>> Best,
>> James
>>
>> On 18/07/17 05:01 AM, Nils Dagsson Moskopp wrote:
>>> Package: gnome-exe-thumbnailer
>>> Version: 0.9.4-2
>>> Severity: grave
>>> Tags: security
>>> Justification: user security hole
>>>
>>> Dear Maintainer,
>>>
>>> the following PoC is copied verbatim from my post about the parsing issue:
>>> http://news.dieweltistgarnichtso.net/posts/gnome-thumbnailer-msi-fail.html
>>>
>>> Proof of Concept
>>>
>>> Install Dependencies
>>>
>>> On Debian GNU/Linux, install the packages gnome-exe-thumbnailer, nautilus 
>>> and wixl. The wixl package is only needed to create MSI files that trigger 
>>> the thumbnailer.
>>>
>>> If the proof of concept does not work, install winetricks and run 
>>> winetricks wsh56 to upgrade the Windows Script Host.
>>>
>>> Create MSI Files
>>>
>>> Create a file named poc.xml with the following content:
>>>
>>> 
>>> http://schemas.microsoft.com/wix/2006/wi;>
>>> 
>>> 
>>>
>>> Execute the following Bourne Shell code:
>>>
>>> wixl -o poc.msi poc.xml
>>> cp poc.msi "poc.msi\",0):Set 
>>> fso=CreateObject(\"Scripting.FileSystemObject\"):Set 
>>> poc=fso.CreateTextFile(\"badtaste.txt\")'.msi"
>>>
>>> Trigger Execution
>>>
>>> Start GNOME Files and navigate to the folder with the MSI files. An empty 
>>> file with the name badtaste.txt should appear.
>>>
>>> *** End of the template - remove these template lines ***
>>>
>>>
>>> -- System Information:
>>> Debian Release: 9.0
>>>   APT prefers stable
>>>   APT policy: (500, 'stable')
>>> Architecture: i386 (i686)
>>>
>>> Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
>>> 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 gnome-exe-thumbnailer depends on:
>>> ii  icoutils 0.31.2-1.1
>>> ii  imagemagick  8:6.9.7.4+dfsg-11
>>> ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11
>>> ii  libglib2.0-bin   2.50.3-2
>>>
>>> Versions of packages gnome-exe-thumbnailer recommends:
>>> pn  wine 
>>> 
>>> pn  wine64-tools | wine32-tools | wine64-development-tools | wine32-dev  
>>> 
>>>
>>> gnome-exe-thumbnailer suggests no packages.
>>>
>>> -- no debconf information
>>>
>>> ___
>>> pkg-wine-party mailing list
>>> pkg-wine-pa...@lists.alioth.debian.org
>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-wine-party
>>>
>>
> 



signature.asc
Description: OpenPGP digital signature

Bug#868705: [pkg-wine-party] Bug#868705: gnome-exe-thumbnailer: Thumbnail generation for MSI files executes arbitrary VBScript

[Nils Dagsson Moskopp]

I like that the patch is less code. Deleted code is debugged code!
Btw, are you sure that using mssiinfo does not introduce new bugs?

Cheers,
Nils

James Lu  writes:

> [ Unknown signature status ]
> Hi Nils,
>
> I wasn't able to reproduce the exploit on my (64-bit) system with either
> Caja and Nautilus (it also required setting up a new wineprefix in
> ~/.wine). The msi thumbnail ended up generating without any version
> information tag at all.
>
> Regardless, I've gone and replaced the VBScript-based parsing entirely
> with msitools' msiinfo in
> https://github.com/gnome-exe-thumbnailer/gnome-exe-thumbnailer/commit/1d8e3102dd8fd23431ae6127d14a236da6b4a4a5;
> hopefully this should fix the issue. I'll tag a new release soon and
> look at pushing the fix to Debian.
>
> (Also CC'ing the other maintainers, who I don't think are on the Debian
> Wine list)
>
> Best,
> James
>
> On 18/07/17 05:01 AM, Nils Dagsson Moskopp wrote:
>> Package: gnome-exe-thumbnailer
>> Version: 0.9.4-2
>> Severity: grave
>> Tags: security
>> Justification: user security hole
>> 
>> Dear Maintainer,
>> 
>> the following PoC is copied verbatim from my post about the parsing issue:
>> http://news.dieweltistgarnichtso.net/posts/gnome-thumbnailer-msi-fail.html
>> 
>> Proof of Concept
>> 
>> Install Dependencies
>> 
>> On Debian GNU/Linux, install the packages gnome-exe-thumbnailer, nautilus 
>> and wixl. The wixl package is only needed to create MSI files that trigger 
>> the thumbnailer.
>> 
>> If the proof of concept does not work, install winetricks and run winetricks 
>> wsh56 to upgrade the Windows Script Host.
>> 
>> Create MSI Files
>> 
>> Create a file named poc.xml with the following content:
>> 
>> 
>> http://schemas.microsoft.com/wix/2006/wi;>
>> 
>> 
>> 
>> Execute the following Bourne Shell code:
>> 
>> wixl -o poc.msi poc.xml
>> cp poc.msi "poc.msi\",0):Set 
>> fso=CreateObject(\"Scripting.FileSystemObject\"):Set 
>> poc=fso.CreateTextFile(\"badtaste.txt\")'.msi"
>> 
>> Trigger Execution
>> 
>> Start GNOME Files and navigate to the folder with the MSI files. An empty 
>> file with the name badtaste.txt should appear.
>> 
>> *** End of the template - remove these template lines ***
>> 
>> 
>> -- System Information:
>> Debian Release: 9.0
>>   APT prefers stable
>>   APT policy: (500, 'stable')
>> Architecture: i386 (i686)
>> 
>> Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
>> 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 gnome-exe-thumbnailer depends on:
>> ii  icoutils 0.31.2-1.1
>> ii  imagemagick  8:6.9.7.4+dfsg-11
>> ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11
>> ii  libglib2.0-bin   2.50.3-2
>> 
>> Versions of packages gnome-exe-thumbnailer recommends:
>> pn  wine 
>> 
>> pn  wine64-tools | wine32-tools | wine64-development-tools | wine32-dev  
>> 
>> 
>> gnome-exe-thumbnailer suggests no packages.
>> 
>> -- no debconf information
>> 
>> ___
>> pkg-wine-party mailing list
>> pkg-wine-pa...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-wine-party
>> 
>

-- 
Nils Dagsson Moskopp // erlehmann



signature.asc
Description: PGP signature

Bug#862133: cppunit 1.14 now in unstable

[Rene Engelhard]

tag 862133 + patch
thanks

Hi,

obviously I forgot this bug in the mail below :/. Where this package is
the most affected by it since it needs to disable the testsuite unless fixed.
My bad, sorry.

Anyways:

diff -Nru gnuradio-3.7.10.1/debian/changelog gnuradio-3.7.10.1/debian/changelog
--- gnuradio-3.7.10.1/debian/changelog  2016-10-10 04:16:42.0 +0200
+++ gnuradio-3.7.10.1/debian/changelog  2017-07-11 00:42:20.0 +0200
@@ -1,3 +1,12 @@
+gnuradio (3.7.10.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  
+  * disable dh_auto_test and remove libcppunit-dev build-dep
+(closes: #862133) 
+
+ -- Rene Engelhard   Tue, 11 Jul 2017 00:42:20 +0200
+
 gnuradio (3.7.10.1-2) unstable; urgency=medium
 
   * update to v3.7.10.1-24-gea2aeca
diff -Nru gnuradio-3.7.10.1/debian/control gnuradio-3.7.10.1/debian/control
--- gnuradio-3.7.10.1/debian/control2016-07-07 03:13:07.0 +0200
+++ gnuradio-3.7.10.1/debian/control2017-07-11 00:42:20.0 +0200
@@ -17,7 +17,6 @@
libboost-thread-dev,
libcodec2-dev (>= 0.4),
   libcomedi-dev [!hurd-i386],
-   libcppunit-dev (>=1.9.14),
libfftw3-dev,
libfontconfig1-dev,
libgsl-dev (>= 2.0),
diff -Nru gnuradio-3.7.10.1/debian/rules gnuradio-3.7.10.1/debian/rules
--- gnuradio-3.7.10.1/debian/rules  2016-07-04 13:14:49.0 +0200
+++ gnuradio-3.7.10.1/debian/rules  2017-07-11 00:42:18.0 +0200
@@ -8,11 +8,13 @@
 override_dh_auto_configure:
dh_auto_configure -- -DLIB_SUFFIX="/$(DEB_HOST_MULTIARCH)" 
-DPYTHON_EXECUTABLE:STRING="/usr/bin/python" -DENABLE_INTERNAL_VOLK=OFF
 
+#override_dh_auto_test:
+#  mkdir debian/test
+#  mkdir debian/test/.gnuradio
+#  - if case "$(DEB_BUILD_ARCH)" in *"i386"*) false;; *) true;; esac; then 
HOME=$(CURDIR)/debian/test dh_auto_test -- ARGS+='--timeout 10 -E systematic' ; 
fi
+#  rm -rf debian/test
 override_dh_auto_test:
-   mkdir debian/test
-   mkdir debian/test/.gnuradio
-   - if case "$(DEB_BUILD_ARCH)" in *"i386"*) false;; *) true;; esac; then 
HOME=$(CURDIR)/debian/test dh_auto_test -- ARGS+='--timeout 10 -E systematic' ; 
fi
-   rm -rf debian/test
+
 
 # Doxygen's jquery.js isn't really jquery.js - look for upstream to ship 
doxygen.js soon instead.
 override_dh_auto_install:

is the (trivial) workaround here.

Regards,

Rene

- Forwarded message from Rene Engelhard  -

Date: Mon, 10 Jul 2017 19:08:35 +0200
From: Rene Engelhard 
To: cont...@bugs.debian.org
Cc: 862...@bugs.debian.org, 862...@bugs.debian.org, 862...@bugs.debian.org
Subject: cppunit 1.14 now in unstable
User-Agent: Mutt/1.5.23 (2014-03-12)

severity 862135 serious
severity 862134 serious
severity 862133 serious
severity 862132 serious
severity 862131 serious
severity 862130 serious
severity 862129 serious
severity 862128 serious
severity 862127 serious
severity 862126 serious
severity 862125 serious
thanks

Hi,

cppunit 1.14 is now in unstable; thus raising the severity of these bugs
to serious.

I intend to NMU very soon.

For gnuradio and ola:

gnuradio will not be able to build against cppunit 1.14 as 1.14 requires c++11.
I pondered introducing cppunit1.13 and actually did so but the RT 
(understandably)
doesn't want two versions of cppunit.

So if that stays as-is you either need to 
 - port gnuradio to supporting building with c++11
 - disable the testsuite

Same for ola, though that one's fixed-upstream and just needs a actual release
to support cppunit 1.14...

Regards,

Rene

- End forwarded message -

Bug#852223: Anyone has objections against maintaining equivs under the Debian Perl Team hat?

[Axel Beckert]

Axel Beckert wrote:
> anyone has objections against maintaining equivs (orphaned, see
> https://bugs.debian.org/852223) under the hat of the Debian Perl Team?
> 
> (If so, I'll maintain it on my own, but I'd prefer team maintenance
> and the Perl team seems be quite fitting.)

JFTR: I've pushed my current work to
https://anonscm.debian.org/git/users/abe/proposed/equivs.git for now.

(It's currently written for a collab-maint repo and single-person
maintenance, but I'll change that to the Debian Perl Team if I don't
get any objections within the next few days.)

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#868728: cups requires do lpadmin configuration to share printers

[Antoine Beaupre]

Package: cups
Version: 2.2.1-8
Severity: normal

Hi!

When trying to share my printers with my roommates through the CUPS
web interface, I quickly found the "Share printers connected to this
system" button and clicked it. And lo and behold, other Linux (and
probably Mac, haven't tried) computers just see the printers and can
print to it. Great!

But when they do, they get this mysterious error message: "Filter
failed". Searching for that error message on the web is a dead end:
you end up with all sorts of errors with foomatic-db not being
configured properly and so on. This problem is remote-specific:
printing works fine on the local machine, just not from the remote
CUPS clients.

I have found this bug in the RedHat bugtracker that seems similar to
the situation I'm seeing here:

https://bugzilla.redhat.com/show_bug.cgi?id=1010580

This is another forum with the simple solution:

https://ubuntuforums.org/showthread.php?t=2254352

.. which is to run the following command, in a terminal:

   sudo lpadmin -p HP-LaserJet-p3015 -m raw

where "HP-LaserJet-p3015" is the printer name.

It seems to me a little odd that I would need to do this, as a user. I
would expect the graphical interface to do the right thing, or just
not offer the functionality at all. In the RH bugtracker, there's a
debate regarding whether this is an actual bug, as this seems to be
upstream's behavior of choice, but I fail to see how this is an
appropriate response... I am using what are mostly default
configurations here and didn't do anything special on the remote
computer.

It seems to me it would be essential to be able to share printers
through the GUI in Debian, out of the box. Having people go through
the commandline to workaround such an issue seems to defeat the whole
point of having that GUI in the first place.

Or did I miss something?

Thanks!

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

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

Versions of packages cups depends on:
ii  cups-client2.2.1-8
ii  cups-common2.2.1-8
ii  cups-core-drivers  2.2.1-8
ii  cups-daemon2.2.1-8
ii  cups-filters   1.11.6-3
ii  cups-ppdc  2.2.1-8
ii  cups-server-common 2.2.1-8
ii  debconf [debconf-2.0]  1.5.61
ii  ghostscript9.20~dfsg-3.2
ii  libavahi-client3   0.6.32-2
ii  libavahi-common3   0.6.32-2
ii  libc-bin   2.24-11+deb9u1
ii  libc6  2.24-11+deb9u1
ii  libcups2   2.2.1-8
ii  libcupscgi12.2.1-8
ii  libcupsimage2  2.2.1-8
ii  libcupsmime1   2.2.1-8
ii  libcupsppdc1   2.2.1-8
ii  libgcc11:6.3.0-18
ii  libstdc++6 6.3.0-18
ii  libusb-1.0-0   2:1.0.21-1
ii  poppler-utils  0.48.0-2
ii  procps 2:3.3.12-3

Versions of packages cups recommends:
ii  avahi-daemon 0.6.32-2
ii  colord   1.3.3-2
ii  cups-filters [ghostscript-cups]  1.11.6-3
ii  printer-driver-gutenprint5.2.11-1+b2

Versions of packages cups suggests:
ii  cups-bsd   2.2.1-8
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20161201-1
ii  hplip  3.16.11+repack0-3
ii  printer-driver-hpcups  3.16.11+repack0-3
pn  smbclient  
ii  udev   232-25

-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true

Bug#868639: [Pkg-cmake-team] Bug#868639: cmake: error while loading shared libraries: libcrypto.so.1.0.0

[Augusto Fraga Giachero]

Hi Felix,

I've figure out the problem, it was my fault... I didn't realized that 
the .bashrc of my user modified the PATH variable and I was executing a 
locally installed cmake binary...


Sorry for the noise :(

Thank you for your help!

On 17-07-2017 17:16, Felix Geyer wrote:

Hi,

On 17.07.2017 04:20, Augusto Fraga Giachero wrote:

I've recently migrated my server from Debian 8 to Debian 9 and installed the 
last version of cmake available to Debian Stretch.

Every time I invoke cmake a get as result:
cmake: error while loading shared libraries: libcrypto.so.1.0.0: cannot open 
shared object file: No such file or directory

And it imediately closes.

It seems that this package has been compiled with an older version of libssl 
than what is available in the Debian Stretch repository (libssl1.0.2 and 
libssl1.1).

cmake doesn't link against libcrypto but transitively through libcurl.

Either the upgrade on your system has been interrupted in the middle or your 
system is modified in
some way.

In a clean stretch chroot cmake links against the following:

# ldd /usr/bin/cmake
linux-vdso.so.1 (0x7ffc8c1de000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f72615ef000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f72613d5000)
libarchive.so.13 => /usr/lib/x86_64-linux-gnu/libarchive.so.13 
(0x7f7261121000)
libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 
(0x7f7260ea1000)
libjsoncpp.so.1 => /usr/lib/x86_64-linux-gnu/libjsoncpp.so.1 
(0x7f7260c6d000)
libuv.so.1 => /usr/lib/x86_64-linux-gnu/libuv.so.1 (0x7f7260a47000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f72606c5000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f72604ae000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f726010f000)
/lib64/ld-linux-x86-64.so.2 (0x55b4020f3000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 
(0x7f725fed8000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x7f725fccf000)
liblzo2.so.2 => /lib/x86_64-linux-gnu/liblzo2.so.2 (0x7f725faab000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f725f885000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f725f673000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f725f463000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 
(0x7f725f0a8000)
libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 
(0x7f725ee82000)
libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 
(0x7f725ec5e000)
librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 
(0x7f725ea41000)
libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1 
(0x7f725e815000)
libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 
(0x7f725e607000)
libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 
(0x7f725e39e000)
libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 
(0x7f725df3a000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
(0x7f725dced000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 
(0x7f725da13000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 
(0x7f725d7e)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 
(0x7f725d5dc000)
liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 
(0x7f725d3cd000)
libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 
(0x7f725d17c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f725cf5d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f725cc59000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f725ca51000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f725c839000)
libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x7f725c634000)
libicui18n.so.57 => /usr/lib/x86_64-linux-gnu/libicui18n.so.57 
(0x7f725c1b8000)
libicuuc.so.57 => /usr/lib/x86_64-linux-gnu/libicuuc.so.57 
(0x7f725be1)
libicudata.so.57 => /usr/lib/x86_64-linux-gnu/libicudata.so.57 
(0x7f725a393000)
libunistring.so.0 => /usr/lib/x86_64-linux-gnu/libunistring.so.0 
(0x7f725a07c000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 
(0x7f7259ce3000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 
(0x7f7259aae000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 
(0x7f7259829000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f725951a000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 
(0x7f725930e000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 

Bug#868718: Acknowledgement (qemu: Qemu fails to run on Stretch, due to missing libraries)

[Ryan Thoryk]

I found that rebuilding the packages from source fixes the problem.

-- 
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#868727: freecad: Package description should drop the "(alpha)"

[Adrian Bunk]

Package: freecad
Version: 0.16+dfsg2-3
Severity: minor

Description-en: Extensible Open Source CAx program (alpha)

Once upon a time this was correct, but FreeCAD is now
clearly out of Alpha quality.

Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution

[Till Kamppeter]

On 07/17/2017 08:34 PM, brian m. carlson wrote:


It does not appear to fix the problem.  The PPD that's generated is
identical and still contains the 600x2 resolution.  I will lose access
to the printer tomorrow, unfortunately, so I'll be unable to test
further.



The actual change takes place in 
/usr/lib/x86_64-linux-gnu/libcupsfilters.so.1.0.0. So you if you do not 
do a full "make install", you need to run the command


sudo cp .libs/libcupsfilters.so.1.0.0 /usr/lib/x86_64-linux-gnu/

to apply the fix to your system.

   Till

Bug#868705: [pkg-wine-party] Bug#868705: gnome-exe-thumbnailer: Thumbnail generation for MSI files executes arbitrary VBScript

[James Lu]

Hi Nils,

I wasn't able to reproduce the exploit on my (64-bit) system with either
Caja and Nautilus (it also required setting up a new wineprefix in
~/.wine). The msi thumbnail ended up generating without any version
information tag at all.

Regardless, I've gone and replaced the VBScript-based parsing entirely
with msitools' msiinfo in
https://github.com/gnome-exe-thumbnailer/gnome-exe-thumbnailer/commit/1d8e3102dd8fd23431ae6127d14a236da6b4a4a5;
hopefully this should fix the issue. I'll tag a new release soon and
look at pushing the fix to Debian.

(Also CC'ing the other maintainers, who I don't think are on the Debian
Wine list)

Best,
James

On 18/07/17 05:01 AM, Nils Dagsson Moskopp wrote:
> Package: gnome-exe-thumbnailer
> Version: 0.9.4-2
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> Dear Maintainer,
> 
> the following PoC is copied verbatim from my post about the parsing issue:
> http://news.dieweltistgarnichtso.net/posts/gnome-thumbnailer-msi-fail.html
> 
> Proof of Concept
> 
> Install Dependencies
> 
> On Debian GNU/Linux, install the packages gnome-exe-thumbnailer, nautilus and 
> wixl. The wixl package is only needed to create MSI files that trigger the 
> thumbnailer.
> 
> If the proof of concept does not work, install winetricks and run winetricks 
> wsh56 to upgrade the Windows Script Host.
> 
> Create MSI Files
> 
> Create a file named poc.xml with the following content:
> 
> 
> http://schemas.microsoft.com/wix/2006/wi;>
> 
> 
> 
> Execute the following Bourne Shell code:
> 
> wixl -o poc.msi poc.xml
> cp poc.msi "poc.msi\",0):Set 
> fso=CreateObject(\"Scripting.FileSystemObject\"):Set 
> poc=fso.CreateTextFile(\"badtaste.txt\")'.msi"
> 
> Trigger Execution
> 
> Start GNOME Files and navigate to the folder with the MSI files. An empty 
> file with the name badtaste.txt should appear.
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
> 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 gnome-exe-thumbnailer depends on:
> ii  icoutils 0.31.2-1.1
> ii  imagemagick  8:6.9.7.4+dfsg-11
> ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11
> ii  libglib2.0-bin   2.50.3-2
> 
> Versions of packages gnome-exe-thumbnailer recommends:
> pn  wine 
> 
> pn  wine64-tools | wine32-tools | wine64-development-tools | wine32-dev  
> 
> 
> gnome-exe-thumbnailer suggests no packages.
> 
> -- no debconf information
> 
> ___
> pkg-wine-party mailing list
> pkg-wine-pa...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-wine-party
> 



signature.asc
Description: OpenPGP digital signature

Bug#865224: uwsgi: ftbfs with multiple supported python3 versions

[Scott Kitterman]

On July 17, 2017 7:19:55 PM EDT, gregor herrmann  wrote:
>On Thu, 13 Jul 2017 18:56:52 -0400, Scott Kitterman wrote:
>
>> > It looks like a cdbs issue to me,
>> >   $(call cdbs_expand_pythonruntime,,python3.6)
>> > breaks while
>> >   $(call cdbs_expand_pythonruntime,,python3.5)
>> > works (and results in "python3" as expected.)
>> > 
>> > A workaround that seems to help is putting
>> >  X-Python3-Version: 3.5
>> > in the Source paragraph of debian/control to prevent it from trying
>3.6
>> > at all. This makes the build work for me (but doesn't help the
>python3.6
>> > transition of course.)
>> > 
>> > This is the worst blocker for the Perl 5.26 transition too (uwsgi
>needs
>> > to be rebuilt because uwsgi-plugin-psgi links against libperl), so
>even
>> > a temporary ugly workaround would be appreciated from this side :)
>> 
>> Changing the python3-all-dev build-depends to python3-dev would
>accomplish the 
>> same thing while allowing a binNMU to work when we make python3.6
>default.  
>> Since this is blocking your work, I would recommend you NMU with that
>change 
>> (I have forgotten approximately everything I ever new about CDBS, so
>I don't 
>> mess with CDBS packages if I can possibly avoid it - I don't plan to
>do this 
>> NMU).
>
>I'm afraid this doesn't help. With the change in Build-Depends from
>python3-all-dev to python3-dev, the build still ends with:
>
>*** asyncio_python27 plugin built and available in
>./asyncio_python27_plugin.so ***
>touch debian/stamp-uwsgi-plugin-asyncio-python
>debian/rules:452: *** no python implementation resolved from flavor
>"python3.6" among packages python-uwsgidecorators
>python3-uwsgidecorators.  Stop.
>dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
>The build log doesn't show anything about python3.6 packages.
>
>From the log:
>
>set -e; \
>sed -e 's/@@pkg_name@@/uwsgi-plugin-python3/g' -e
>'s/@@plugin_name@@/python3/g' -e 's/@@plugin_stem@@/python/g' -e
>'s/@@plugin_alternatives_name@@/uwsgi-plugin-python3/g' -e
>'s/@@plugin_alternatives_stem@@/python3/g' -e
>'s/@@plugin_alternatives_priority@@/35/g' -e
>'s/@@plugin_lang_kind@@/python3/g' -e
>'s/@@plugin_flavors_dotless@@/python36 python35/g' -e
>'s/@@plugin_defaultflavor_dotless@@/python35/g' <
>debian/uwsgi-plugin-__PLUGIN__.rtupdate.in.pri-py >
>debian/uwsgi-plugin-python3.rtupdate;   sed -e
>'s/@@pkg_name@@/uwsgi-plugin-python3/g' -e
>'s/@@plugin_name@@/python3/g' -e 's/@@plugin_stem@@/python/g' -e
>'s/@@plugin_alternatives_name@@/uwsgi-plugin-python3/g' -e
>'s/@@plugin_alternatives_stem@@/python3/g' -e
>'s/@@plugin_alternatives_priority@@/35/g' -e
>'s/@@plugin_lang_kind@@/python3/g' -e
>'s/@@plugin_flavors_dotless@@/python36 python35/g' -e
>'s/@@plugin_defaultflavor_dotless@@/python35/g' <
>debian/uwsgi-plugin-__PLUGIN__.dirs.in.python >
>debian/uwsgi-plugin-python3.dirs; sed -e
>'s/@@pkg_name@@/uwsgi-plugin-python3/g' -e
>'s/@@plugin_name@@/python3/g' -e 's/@@plugin_stem@@/python/g' -e
>'s/@@plugin_alternatives_name@@/uwsgi-plugin-python3/g' -e
>'s/@@plugin_alternatives_stem@@/python3/g' -e
>'s/@@plugin_alternatives_priority@@/35/g' -e
>'s/@@plugin_lang_kind@@/python3/g' -e
>'s/@@plugin_flavors_dotless@@/python36 python35/g' -e
>'s/@@plugin_defaultflavor_dotless@@/python35/g' <
>debian/uwsgi-plugin-__PLUGIN__.prerm.in.pri-py >
>debian/uwsgi-plugin-python3.prerm;   sed -e
>'s/@@pkg_name@@/uwsgi-plugin-python3/g' -e
>'s/@@plugin_name@@/python3/g' -e 's/@@plugin_stem@@/python/g' -e
>'s/@@plugin_alternatives_name@@/uwsgi-plugin-python3/g' -e
>'s/@@plugin_alternatives_stem@@/python3/g' -e
>'s/@@plugin_alternatives_priority@@/35/g' -e
>'s/@@plugin_lang_kind@@/python3/g' -e
>'s/@@plugin_flavors_dotless@@/python36 python35/g' -e
>'s/@@plugin_defaultflavor_dotless@@/python35/g' <
>debian/uwsgi-plugin-__PLUGIN__.postinst.in.pri-py >
>debian/uwsgi-plugin-python3.postinst;sed -e
>"s/@@plugin_name@@/python36/g" <
>debian/uwsgi-plugin-__PLUGIN__.install.in >>
>debian/uwsgi-plugin-python3.install; sed -e
>"s/@@plugin_name@@/python36/g" <
>debian/uwsgi-plugin-__PLUGIN__.links.in >>
>debian/uwsgi-plugin-python3.links; sed -e
>"s/@@plugin_name@@/python36/g" <
>debian/uwsgi-plugin-__PLUGIN__.manpages.in >>
>debian/uwsgi-plugin-python3.manpages;  sed -e
>"s/@@plugin_name@@/python35/g" <
>debian/uwsgi-plugin-__PLUGIN__.install.in >>
>debian/uwsgi-plugin-python3.install; sed -e
>"s/@@plugin_name@@/python35/g" <
>debian/uwsgi-plugin-__PLUGIN__.links.in >>
>debian/uwsgi-plugin-python3.links; sed -e
>"s/@@plugin_name@@/python35/g" <
>debian/uwsgi-plugin-__PLUGIN__.manpages.in >>
>debian/uwsgi-plugin-python3.manpages; chmod 755
>debian/uwsgi-plugin-python3.rtupdate; echo
>"debian/uwsgi-plugin-python3.rtupdate usr/share/python3/runtime.d" >>
>debian/uwsgi-plugin-python3.install
>touch debian/expand-files/uwsgi-plugin-python3
>
>(Note the "python36" parts.)
>
>
>Looking through the not ultra-short debian/rules, it seems that
>$(plugin_flavors) still contains something 

Bug#868726: obvious date bug not obvious

[積丹尼 Dan Jacobson]

Package: perl-doc
Version: 5.24.1-2
Severity: wishlist
File: /usr/share/man/man3/Time::Piece.3perl.gz

We read in the man page:

   (see, it's even smart enough to fix my obvious date bug)

Alas many readers don't know what he means, so please add an explanation
there on the man page, or remove the sentence. Thank you.

Bug#868724: ledgersmb: Update debian/watch for new upstream location

[Robert J. Clay]

Package: ledgersmb
Severity: normal

The LedgerSMB Project has entirely moved from SourceForge.net,
including for where new releases of the application are made
available; so the debian/watch file in the package needs to be`updated
for the new locations of the distribution archive and its detached`gpg
file that is used for verification, which are all now at the existing
LedgerSMB project located at GitHub.

https://github.com/ledgersmb/LedgerSMB/releases

https://github.com/ledgersmb/LedgerSMB



-- 
Robert J. Clay
rjc...@gmail.com
j...@rocasa.us

Bug#868725: redshift-gtk: Info window occasionally shows nothing

[debianuser]

Package: redshift-gtk
Version: 1.11-1
Severity: minor

Dear Maintainer,

The redshift-gtk info screen (from the icon in the taskbar) occasionally shows 
no information, just a blank screen. I assume this is unintentional and a bug


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

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

Versions of packages redshift-gtk depends on:
ii  gir1.2-appindicator3-0.1  0.4.92-4
ii  python3   3.5.3-1
ii  python3-gi3.22.0-2
ii  python3-xdg   0.25-4
ii  redshift  1.11-1

Versions of packages redshift-gtk recommends:
ii  at-spi2-core  2.22.0-6

redshift-gtk suggests no packages.

-- no debconf information

Bug#868641: libzim-dev: Upgrade libzim to 2.0.0

[Kunal Mehta]

Hi,

On 07/16/2017 09:56 PM, Vasudev Kamath wrote:
> When you are considering to change the packaging style please ask the
> maintainer first,
>  if he/she is willing to change their packaging style. I observed that
> you removed my CDBS
>  packaging effort without asking me. This is not acceptable for me!.

Sorry, that wasn't my intention. I should have been clearer in my first
message that it was just a work in progress that I put together in a
separate branch just to demonstrate that it can be built properly under
Debian (no issues with library versions, meson/ninja, etc.). It wasn't
anywhere close to acceptable for actually being used.

> I've started working on libzim but it is in my machine and I will push
> once I've completed my work.

Awesome, that's wonderful :) I'll start working on libkiwix then.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#867345: gmime transition to 3.0

[Alberto Garcia]

Control: tags -1 - fixed-upstream

> This has already been fixed upstream, so I'll close this bug with
> the next grilo-plugins release.

Sorry, this message was intended for bug #867350, please ignore it.

Berto

Bug#867350: Bug#867345: gmime transition to 3.0

[Alberto Garcia]

Control: tags -1 fixed-upstream

On Wed, Jul 05, 2017 at 07:04:56PM -0400, Daniel Kahn Gillmor wrote:

> Please try to convert your debian packages to use libgmime-3.0-dev
> in unstable if possible, so that we can avoid shipping gmime 2.6 in
> buster.

This has already been fixed upstream, so I'll close this bug with the
next grilo-plugins release.

I can backport the patches if there's no release in a reasonable
amount of time.

Berto

Bug#867345: gmime transition to 3.0

[Alberto Garcia]

Control: tags -1 fixed-upstream

On Wed, Jul 05, 2017 at 07:04:56PM -0400, Daniel Kahn Gillmor wrote:

> Please try to convert your debian packages to use libgmime-3.0-dev
> in unstable if possible, so that we can avoid shipping gmime 2.6 in
> buster.

This has already been fixed upstream, so I'll close this bug with the
next grilo-plugins release.

I can backport the patches if there's no release in a reasonable
amount of time.

Berto

Bug#868723: notmuch-addrlookup: please provide Vcs-* headers, if applicable

[David Bremner]

Package: notmuch-addrlookup
Version: 5-1
Severity: wishlist

If the packaging for notmuch-addrlookup is maintained in version
control, please add the appropriate fields to the source package.

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

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

Versions of packages notmuch-addrlookup depends on:
ii  libc6 2.24-12
ii  libglib2.0-0  2.52.3-1
ii  libnotmuch4   0.24.2-2~bpo9+1

notmuch-addrlookup recommends no packages.

notmuch-addrlookup suggests no packages.

Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution

[brian m. carlson]

On Mon, Jul 17, 2017 at 03:08:09PM -0300, Till Kamppeter wrote:
> I have now added a fallback mechanism to the PPD generator in cups-filters
> which does not accept resolutions < 75 dpi.
> 
> It is committed (rev. 7652) to the upstream BZR repository. Please test.

It does not appear to fix the problem.  The PPD that's generated is
identical and still contains the 600x2 resolution.  I will lose access
to the printer tomorrow, unfortunately, so I'll be unable to test
further.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#868476: e2fsck: null pointer dereference in quota_file_close

[Theodore Ts'o]

On Sat, Jul 15, 2017 at 10:50:58PM +0200, Jakub Wilk wrote:
> Package: e2fsprogs
> Version: 1.43.4-2
> 
> e2fsck crashes when trying to fix the attached filesystem:
> 
>   $ /sbin/e2fsck -y quota_file_close.ext4

E2fsck on the maint branch is no longer crashing with the attached
file system.  So the null pointer deference will be fixed in the (soon
to be released) 1.43.5 release.

E2fsck is not able to *fix* the file system, however, so this is
something that I consider a bug and will try to fix.

- Ted

Bug#868640: hdb_generate_key_set_password broke ABI

[Brian May]

On 2017-07-18 08:30, Brian May wrote:

> Please read the bull details of 868640 for more information, and for
> details of similar situation that occured before the Stretch
> release. #848694

Apologies for the typo. 

s/bull/full/

Bug#868722: transition: notmuch

[David Bremner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There is an upstream SONAME bump in libnotmuch due to some long
deprecated symbols changing API.

There are two reverse depends: mutt rebuilds fine.  notmuch-addrlookup
currently fails, but apparently this is fixed with the latest upstream
version.  I can NMU notmuch-addrlookup, but I'd rather the maintainer
uploaded a new pustream version.

Ben file:

title = "notmuch";
is_affected = .depends ~ "libnotmuch4" | .depends ~ "libnotmuch5";
is_good = .depends ~ "libnotmuch5";
is_bad = .depends ~ "libnotmuch4";


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

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

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlltRqEACgkQ8gKXHaSn
niwmAgwAkB4WPQ92AbW74buG6OEtCCgzVZHz0L2m4e7A5vPHqhCW8fJvDGZcr0Iz
iti4Pzu3oQJlcrOQ5dBSR4OOqmXA6++NlYgHxMIRpAXB2fyK0duDjIb8VHipx3yi
ONN+lHBw/6aKlCPE8xzBsr9LLSinM1EGbf8UqZCXhJeZE0kqgTBOVfCR/YZ6qCax
8LLCTtzXgFH5MIkF4RyPWUKAo1H1re+e0zVnkCCDETVgJsC7GP1xz0XQTvofURmr
ggz91XR+FuCPuhzoCWn8SMwvAj9Vq9uQUrAJDXCutCLsTLgAklrJhPlyy0D6AHOt
TBwQ+xSfGD0ym07golCM/YBwSuvC5dvQ9jn4qkOZEKuJCIkeIQ7zXGZAum+aovBi
YAzaJsy2/yHwkZLABC+d8Rqtflevwp4rGaalkOiZo3rqpgso4D51rMGMxhiRZq1i
o8W0//K6cP+dM3n5qwgFZrg8ivcByyIx2a1XloSYNvRYBWE4df5Q18ZWqSyWTDVy
V2jMcWC7
=cvtH
-END PGP SIGNATURE-

Bug#865224: uwsgi: ftbfs with multiple supported python3 versions

[gregor herrmann]

On Thu, 13 Jul 2017 18:56:52 -0400, Scott Kitterman wrote:

> > It looks like a cdbs issue to me,
> >   $(call cdbs_expand_pythonruntime,,python3.6)
> > breaks while
> >   $(call cdbs_expand_pythonruntime,,python3.5)
> > works (and results in "python3" as expected.)
> > 
> > A workaround that seems to help is putting
> >  X-Python3-Version: 3.5
> > in the Source paragraph of debian/control to prevent it from trying 3.6
> > at all. This makes the build work for me (but doesn't help the python3.6
> > transition of course.)
> > 
> > This is the worst blocker for the Perl 5.26 transition too (uwsgi needs
> > to be rebuilt because uwsgi-plugin-psgi links against libperl), so even
> > a temporary ugly workaround would be appreciated from this side :)
> 
> Changing the python3-all-dev build-depends to python3-dev would accomplish 
> the 
> same thing while allowing a binNMU to work when we make python3.6 default.  
> Since this is blocking your work, I would recommend you NMU with that change 
> (I have forgotten approximately everything I ever new about CDBS, so I don't 
> mess with CDBS packages if I can possibly avoid it - I don't plan to do this 
> NMU).

I'm afraid this doesn't help. With the change in Build-Depends from
python3-all-dev to python3-dev, the build still ends with:

*** asyncio_python27 plugin built and available in ./asyncio_python27_plugin.so 
***
touch debian/stamp-uwsgi-plugin-asyncio-python
debian/rules:452: *** no python implementation resolved from flavor "python3.6" 
among packages python-uwsgidecorators python3-uwsgidecorators.  Stop.
dpkg-buildpackage: error: debian/rules build gave error exit status 2

The build log doesn't show anything about python3.6 packages.

From the log:

set -e; \
  sed -e 's/@@pkg_name@@/uwsgi-plugin-python3/g' -e 
's/@@plugin_name@@/python3/g' -e 's/@@plugin_stem@@/python/g' -e 
's/@@plugin_alternatives_name@@/uwsgi-plugin-python3/g' -e 
's/@@plugin_alternatives_stem@@/python3/g' -e 
's/@@plugin_alternatives_priority@@/35/g' -e 's/@@plugin_lang_kind@@/python3/g' 
-e 's/@@plugin_flavors_dotless@@/python36 python35/g' -e 
's/@@plugin_defaultflavor_dotless@@/python35/g' < 
debian/uwsgi-plugin-__PLUGIN__.rtupdate.in.pri-py > 
debian/uwsgi-plugin-python3.rtupdate;   sed -e 
's/@@pkg_name@@/uwsgi-plugin-python3/g' -e 's/@@plugin_name@@/python3/g' -e 
's/@@plugin_stem@@/python/g' -e 
's/@@plugin_alternatives_name@@/uwsgi-plugin-python3/g' -e 
's/@@plugin_alternatives_stem@@/python3/g' -e 
's/@@plugin_alternatives_priority@@/35/g' -e 's/@@plugin_lang_kind@@/python3/g' 
-e 's/@@plugin_flavors_dotless@@/python36 python35/g' -e 
's/@@plugin_defaultflavor_dotless@@/python35/g' < 
debian/uwsgi-plugin-__PLUGIN__.dirs.in.python > 
debian/uwsgi-plugin-python3.dirs; sed -e 
's/@@pkg_name@@/uwsgi-plugin-python3/g' -e 's/@@plugin_name@@/python3/g' -e 
's/@@plugin_stem@@/python/g' -e 
's/@@plugin_alternatives_name@@/uwsgi-plugin-python3/g' -e 
's/@@plugin_alternatives_stem@@/python3/g' -e 
's/@@plugin_alternatives_priority@@/35/g' -e 's/@@plugin_lang_kind@@/python3/g' 
-e 's/@@plugin_flavors_dotless@@/python36 python35/g' -e 
's/@@plugin_defaultflavor_dotless@@/python35/g' < 
debian/uwsgi-plugin-__PLUGIN__.prerm.in.pri-py > 
debian/uwsgi-plugin-python3.prerm;   sed -e 
's/@@pkg_name@@/uwsgi-plugin-python3/g' -e 's/@@plugin_name@@/python3/g' -e 
's/@@plugin_stem@@/python/g' -e 
's/@@plugin_alternatives_name@@/uwsgi-plugin-python3/g' -e 
's/@@plugin_alternatives_stem@@/python3/g' -e 
's/@@plugin_alternatives_priority@@/35/g' -e 's/@@plugin_lang_kind@@/python3/g' 
-e 's/@@plugin_flavors_dotless@@/python36 python35/g' -e 
's/@@plugin_defaultflavor_dotless@@/python35/g' < 
debian/uwsgi-plugin-__PLUGIN__.postinst.in.pri-py > 
debian/uwsgi-plugin-python3.postinst;sed -e "s/@@plugin_name@@/python36/g" 
< debian/uwsgi-plugin-__PLUGIN__.install.in >> 
debian/uwsgi-plugin-python3.install; sed -e "s/@@plugin_name@@/python36/g" < 
debian/uwsgi-plugin-__PLUGIN__.links.in >> debian/uwsgi-plugin-python3.links; 
sed -e "s/@@plugin_name@@/python36/g" < 
debian/uwsgi-plugin-__PLUGIN__.manpages.in >> 
debian/uwsgi-plugin-python3.manpages;  sed -e "s/@@plugin_name@@/python35/g" < 
debian/uwsgi-plugin-__PLUGIN__.install.in >> 
debian/uwsgi-plugin-python3.install; sed -e "s/@@plugin_name@@/python35/g" < 
debian/uwsgi-plugin-__PLUGIN__.links.in >> debian/uwsgi-plugin-python3.links; 
sed -e "s/@@plugin_name@@/python35/g" < 
debian/uwsgi-plugin-__PLUGIN__.manpages.in >> 
debian/uwsgi-plugin-python3.manpages; chmod 755 
debian/uwsgi-plugin-python3.rtupdate; echo 
"debian/uwsgi-plugin-python3.rtupdate usr/share/python3/runtime.d" >> 
debian/uwsgi-plugin-python3.install
touch debian/expand-files/uwsgi-plugin-python3

(Note the "python36" parts.)


Looking through the not ultra-short debian/rules, it seems that
$(plugin_flavors) still contains something python3.6ish, and then we
are at the expansion that Niko already found:

$(if $(filter python,$(plugin_lang)),\

Bug#868721: ocaml-extunix FTBFS on mips*/pc64el/s390x: dh_install: Cannot find (any matches for) "/usr/lib/ocaml/extunix/*.so"

[Adrian Bunk]

Source: ocaml-extunix
Version: 0.1.5-1
Severity: serious

https://buildd.debian.org/status/package.php?p=ocaml-extunix=sid

...
   debian/rules override_dh_install
make[1]: Entering directory '/<>'
dh_install --fail-missing
dh_install: Please use dh_missing --list-missing/--fail-missing instead
dh_install: This feature will be removed in compat 11.
dh_install: Cannot find (any matches for) "/usr/lib/ocaml/extunix/*.so" (tried 
in ., debian/tmp)

dh_install: libextunix-ocaml missing files: /usr/lib/ocaml/extunix/*.so
dh_install: missing files, aborting
debian/rules:49: recipe for target 'override_dh_install' failed
make[1]: *** [override_dh_install] Error 25

Bug#868720: sympa FTBFS: configure: error: invalid value /usr/sbin/newaliases for newaliases command

[Adrian Bunk]

Source: sympa
Version: 6.2.16~dfsg-4
Severity: serious

https://buildd.debian.org/status/package.php?p=sympa=sid

...
checking for pod2man... /usr/bin/pod2man
checking for makemap... /usr/bin/makemap
checking user-supplied newaliases command... non-existing
configure: error: invalid value /usr/sbin/newaliases for newaliases command

Bug#868718: qemu: Qemu fails to run on Stretch, due to missing libraries

[Ryan Thoryk]

Package: qemu
Version: 1:2.8+dfsg-6
Severity: important

Dear Maintainer,

Qemu is not running on my Stretch machine, due to missing libraries.  I'm going
to build from source and see if that fixes it.

ryan@t420:~$ qemu-system-i386
qemu-system-i386: error while loading shared libraries: libnss3.so.1d: cannot
open shared object file: No such file or directory

ryan@t420:~$ ldd /usr/bin/qemu-system-i386
--snip--
libnss3.so.1d => not found
libnssutil3.so.1d => not found
libsmime3.so.1d => not found
libssl3.so.1d => not found
libplds4.so.0d => not found
libplc4.so.0d => not found
libnspr4.so.0d => not found
--snip--



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

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

Versions of packages qemu depends on:
ii  qemu-system  1:2.8+dfsg-6
ii  qemu-user1:2.8+dfsg-6
ii  qemu-utils   1:2.8+dfsg-6

qemu recommends no packages.

Versions of packages qemu suggests:
pn  qemu-user-static  

-- no debconf information

Bug#868717: apertium-dan-nor FTBFS: Error: Position on line 6990 near `O inf)␊;␊#sjeldent i` - stand-alone o or O doesn't make sense - maybe you meant 0?

[Adrian Bunk]

Source: apertium-dan-nor
Version: 1.3.0~r67099-1
Severity: serious
Tags: buster sid

Some recent change in unstable makes apertium-dan-nor FTBFS:

https://tests.reproducible-builds.org/debian/history/apertium-dan-nor.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apertium-dan-nor.html

...
lt-comp rl apertium-dan-nor.dan-nor.dix nor-dan.autobil.bin
main@standard 61064 108866
lt-trim /usr/share/apertium/apertium-nob/nob.automorf.bin nor-dan.autobil.bin 
nob-dan.automorf.bin
final@inconditional 52 244
main@standard 155145 360457
lt-trim /usr/share/apertium/apertium-nno/nno.automorf.bin nor-dan.autobil.bin 
nno-dan.automorf.bin
final@inconditional 43 220
main@standard 88077 227828
cg-comp /usr/share/apertium/apertium-nob/apertium-nob.nob.rlx nob-dan.rlx.bin
apertium-nob.nob.rlx: Warning: Expected closing ; on line 25607 after previous 
rule!
Sections: 4, Rules: 2296, Sets: 882, Tags: 5811
3 rules cannot be skipped by index.
cg-comp /usr/share/apertium/apertium-nno/apertium-nno.nno.rlx nno-dan.rlx.bin
apertium-nno.nno.rlx: Error: Position on line 6990 near `O inf)␊;␊#sjeldent i` 
- stand-alone o or O doesn't make sense - maybe you meant 0?
apertium-nno.nno.rlx: Warning: Expected closing ; on line 52066 after previous 
rule!
Error: Grammar could not be parsed - exiting!
Makefile:805: recipe for target 'nno-dan.rlx.bin' failed
make[1]: *** [nno-dan.rlx.bin] Error 1
make[1]: Leaving directory '/build/1st/apertium-dan-nor-1.3.0~r67099'
dh_auto_build: make -j1 returned exit code 2
debian/rules:9: recipe for target 'build' failed
make: *** [build] Error 2

Bug#868719: golang-github-couchbase-moss FTBFS: FAIL: TestStoreCollHistograms

[Adrian Bunk]

Source: golang-github-couchbase-moss
Version: 0.0~git20170713.0.8ea508f-1
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=golang-github-couchbase-moss=all=0.0~git20170713.0.8ea508f-1=1500331918=0

...
=== RUN   TestStoreReadOnlyOption
--- PASS: TestStoreReadOnlyOption (0.00s)
=== RUN   TestStoreCollHistograms
--- FAIL: TestStoreCollHistograms (0.02s)
store_test.go:1976: Unexpected number of MutationKeyBytes samples!
store_test.go:1980: Unexpected number of MutationValBytes samples!
store_test.go:1984: Unexpected number of ExecutedBatchBytes samples!
store_test.go:1989: Unexpected number of ExecuteBatchOpsCount samples!
=== RUN   TestStoreCompactMaxSegments
--- PASS: TestStoreCompactMaxSegments (0.06s)
=== RUN   TestStoreCrashRecovery
--- PASS: TestStoreCrashRecovery (0.02s)
FAIL
exit status 1
FAILgithub.com/couchbase/moss   4.043s
dh_auto_test: go test -v -p 4 github.com/couchbase/moss returned exit code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1

Bug#852223: Anyone has objections against maintaining equivs under the Debian Perl Team hat?

[Axel Beckert]

Hi,

anyone has objections against maintaining equivs (orphaned, see
https://bugs.debian.org/852223) under the hat of the Debian Perl Team?

(If so, I'll maintain it on my own, but I'd prefer team maintenance
and the Perl team seems be quite fitting.)

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


signature.asc
Description: Digital signature

Bug#826502: quilt: diff for NMU version 0.63-8.1

[gregor herrmann]

On Tue, 18 Jul 2017 00:05:26 +0200, Martin Quinson wrote:

> > I've prepared an NMU for quilt (versioned as 0.63-8.1) and
> > uploaded it to DELAYED/5. Please feel free to tell me if I
> > should delay it longer.
> 
> many thanks for this change, and for the upload. As usual, I'm
> struggling with the maintainance of quilt. Any help is welcome, so
> please do not delay your upload. 

Thank you.
I've rescheduled to upload to 0-day.

> If you want to fix other stuff while
> you are at it (or even package the newer upstream releases), please do
> not hesitate and help me...

I was tempted to include a fix for #851130 but I'm not 100% sure
which of the 2 options is the best solution. So I sticked to the
simple bug which we need for the perl transition :)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Rolling Stones: Shelter69


signature.asc
Description: Digital Signature

Bug#868121: libgssapi-krb5-2: obsolete conffile left behind

[Benjamin Kaduk]

On Mon, Jul 17, 2017 at 04:35:24PM +1000, Paul Wise wrote:
> 
> Sounds like a file that should not have been placed in /etc and
> should be removed from /etc during upgrades.

Some further discussion about the role of this file is in #861218
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861218#15 in particular).
Though, I haven't thought/researched much about how policy applies
in this particular case.

-Ben


signature.asc
Description: PGP signature

Bug#868687: [Pkg-libvirt-maintainers] Bug#868687: virt-viewer: HiDPI scaling affects rendered image too

[Zoltán Döme]

> Thanks for testing these too. Are you using spice or vnc? In any case it
> would be best if you would report these bugs upstream at either

All of them with Spice. I guess that means this should be reassigned
to spice-gtk?

I've opened a ticket on the upstream bugzilla for it, as you've suggested:
https://bugs.freedesktop.org/show_bug.cgi?id=101826

Thanks,
Zoltan

Bug#868370: python3-btrfs: Exception: Unsupported machine type aarch64

[Hans van Kranenburg]

Hi Adam,

On 07/15/2017 03:26 AM, Adam Borowski wrote:
> [...]
> On arm64, both the Debian and kernel architecture name is "arm64", yet
> Python's platform.machine() returns autotoolsey "aarch64".  The latter
> name is not on btrfs/ioctl.py's list.

Thanks for the report, and thanks for testing. Apparently aarch64 is a
newer UTS_MACHINE kernel value for arm64. This is now fixed in the
develop branch of python-btrfs.

https://github.com/knorrie/python-btrfs/commits/develop
  "Update ioctl platform.machine handling"

The bug report caused me to have another look at the UTS_MACHINE
definitions in the linux kernel source, and also simplify a few other
names by doing more startswith matching instead of exact matches.

I'll probably tag a new release within a few days, since the amount of
niceness that's not released yet has been piling up steadily.

Hans

Bug#868640: hdb_generate_key_set_password broke ABI

[Brian May]

Hello Debian-Devel!

I have this tricky situation. It appears in 2011, upstream made a change
to Heimdal that broken the shared library ABI, and didn't change the
SONAME.

=== cut ===
commit af011f57fc4ae6e865bab471c20aa9047e4e19d4
Author: Roland C. Dowdeswell 
Date:   Mon Nov 28 15:18:52 2011 +

Provide server side kadm5_chpass_principal_3() with ks_tuple implementation.

We enable kadm5_chpass_principal_3() in the server side of the
library.  The client kadm5 library calls will still return the
error KAMD5_KS_TUPLE_NO_SUPP.

Signed-off-by: Nicolas Williams 
=== cut ===

This change was undetected, and included in Debian in Wheezy, Jessie,
Stretch.

Now Upstream has realized their
error. https://github.com/heimdal/heimdal/issues/246

There response was to restore the ABI to the previous state. This change
is now in testing and unstable.

What should I do? It appears patch the ABI back to the previous state,
and break compatability with other distributions. Or I can keep it as it
and break upgrades.

Please read the bull details of 868640 for more information, and for
details of similar situation that occured before the Stretch
release. #848694
-- 
Brian May 

Bug#868716: O: ps3-utils

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of ps3-utils, Sean Finney 
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Source: ps3-utils
Section: admin
Priority: extra
Maintainer: Sean Finney 
Standards-Version: 3.8.0
Build-Depends: autoconf, automake, debhelper (>= 5), libtool, quilt
Homepage: http://www.kernel.org/pub/linux/kernel/people/geoff/cell/
Vcs-Git: git://git.debian.org/git/users/seanius/ps3/ps3-utils.git
Vcs-Browser: http://git.debian.org/?p=users/seanius/ps3/ps3-utils.git

Package: ps3-utils
Architecture: powerpc
Depends: ${shlibs:Depends}
Conflicts: ps3pf-utils
Provides: ps3pf-utils
Replaces: ps3pf-utils
Description: Utilities for running Debian on a Sony Playstation 3
 This package contains a number of useful and essential utilities needed for
 running Debian GNU/Linux on a Playstation 3 console.  It includes:
  * ps3-video-mode: display/change the video mode of the PS3.
  * ps3-boot-game-os: reboot the system into the "Game OS".
  * ps3-flash-util: read and manipulate the system flash ROM of the PS3.
  * ps3-dump-bootloader: dump the "Other OS" bootloader image.
  * ps3-rtc-init: initialize the Linux RTC diff value.

Bug#868640: hdb_generate_key_set_password broke ABI

[Brian May]

Ryan Tandy  writes:

> Right. Unfortunately the different signature was in Debian for a long 
> time (since squeeze, I think). I for one always assumed the change was 
> intentional and it would just stay that way.

Oh, yes, looks like you are right. I thought this was introduced in
Stretch, but looks like Wheezy and Jessie has it too.

> Possibly, yeah. The pedantic answer is this requires a SONAME bump and 
> transition; but that may be overkill in this case. smbk5pwd is for sure 
> the only user in Debian, and I'd be surprised if there are any external 
> users (maybe an occasional user building their own smbk5pwd).

The problem with bumping the SONAME, is this means that we are forever
out of sync with the upstream SONAME.

> A symbols file update would be nice, so future builds of slapd-smbk5pwd 
> pick up a minimum dependency. If libhdb would add a Breaks on 
> slapd-smbk5pwd (<< 2.4.44+dfsg-8), that would fix partial upgrades from 
> the other direction too.

We had a similar issue just before the release of Stretch. See
#848694. Two symbols were removed from the upstream library. Adding
breaks headers was suggested, but the release team strongly disliked
this solution.

We ended up patching these symbols back in.

I am not particularly keen on maintaining a growing set of patches that
maintain backward compatability for eternanity while deliberately
breaking compatability with other non-Debian-distributions however.
-- 
Brian May 

Bug#868715: Updating the enemylines7 Uploaders list

[Tobias Frost]

Source: enemylines7
Version: 0.6-4
Severity: minor

Alexander Reichle-Schmehl  has retired, so can't work on
the enemylines7 package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.


signature.asc
Description: PGP signature

Bug#826502: quilt: diff for NMU version 0.63-8.1

[Martin Quinson]

On Mon, Jul 17, 2017 at 08:47:02PM +0200, gregor herrmann wrote:
> Control: tags 826502 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for quilt (versioned as 0.63-8.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.


Hello,

many thanks for this change, and for the upload. As usual, I'm
struggling with the maintainance of quilt. Any help is welcome, so
please do not delay your upload. If you want to fix other stuff while
you are at it (or even package the newer upstream releases), please do
not hesitate and help me...

Thanks again,
Mt.

signature.asc
Description: PGP signature

Bug#868713: Updating the fprint-demo Uploaders list

[Tobias Frost]

Source: fprint-demo
Version: 20080303git-6
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Miguel Gea Milvaques  has retired, so can't work on
the fprint-demo package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#868714: Updating the aes2501-wy Uploaders list

[Tobias Frost]

Source: aes2501-wy
Version: 0.1-5
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Miguel Gea Milvaques  has retired, so can't work on
the aes2501-wy package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#844191: lintian: Check for useless build-depends on dh-autoreconf and autotools-dev

[Chris Lamb]

tags 844191 + pending
thanks

Fixed in Git:

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


Regards,

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

Bug#868711: Updating the cipux-rbac Uploaders list

[Tobias Frost]

Source: cipux-rbac
Version: 3.4.0~svn2868-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint
Tags: experimental

Xavier Oswald  has retired, so can't work on
the cipux-rbac package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#868712: ITP: golang-github-bsm-pool -- simple connection pool in Go

[Michael Lustfield]

Package: wnpp
Severity: wishlist
Owner: Michael Lustfield 

* Package name: golang-github-bsm-pool
  Version : 0.0~git20161215.0.502d32d-1
  Upstream Author : Black Square Media Ltd
* URL : https://github.com/bsm/pool
* License : Expat
  Programming Lang: Go
  Description : simple connection pool in Go

 BSM Pool implements a simple connection pool for Go.
 .
 Features:
 - thread-safe
 - lock-free
 - stack-based rather than queue-based
   + connections that have been used recently are more likely to be re-used
 - supports pool shrinking (reap idle connections)

This is being packaged as a new dependency to golang-github-bsm-redeo.


pgp4wohiF182C.pgp
Description: OpenPGP digital signature

Bug#868710: src:debian-installer: No virtio drivers in initramfs

[Adam Majer]

Package: src:debian-installer
Severity: important

Dear Maintainer,

Trying to install Debian 9.0 x86_64 from CD via qemu with virtio
device for cdrom results in installer unable to find the CD drive.

The expected behaviour is that virtio drivers are present in the
initramfs as these are common when installing Debian in a VM.

Workaround is to use ide-cd or similar emulation.

- Adam

Bug#868074: libfelix-bundlerepository-java: missing requirement osgi.wiring.package; (&(osgi.wiring.package=org.osgi.service.repository)(version>=1.0.0)(!(version>=1.1.0))))

[Mykola Nikishov]

Markus Koschany  writes:

> I tried to update the whole felix-* stack in Debian but I quickly ran
> into more issues. Thus I have decided to replace the newly added
> Import-Package requirement
>
> org.osgi.service.repository;resolution:=mandatory;version="[1.0,1.1)"
>
> with its old value in 2.0.8
>
> org.osgi.service.repository;resolution:=mandatory

As I understand, libfelix-bundlerepository-java should depend on some
Debian package that
a) provides the package org.osgi.service.repository
b) is a valid OSGi bundle

libosgi-compendium-java satisfies a) but fails b) - it's MANIFEST.MF has
no OSGi headers at all.

Is adding Depends:libosgi-compendium-java and fixing
libosgi-compendium-java's manifest the right way to go?

-- 
Mykola
https://manandbytes.github.io/

Bug#868708: Updating the libmad Uploaders list

[Tobias Frost]

Source: libmad
Version: 0.15.1b-8
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Clément Stenac  has retired, so can't work on
the libmad package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#868707: Updating the libid3tag Uploaders list

[Tobias Frost]

Source: libid3tag
Version: 0.15.1b-12
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Clément Stenac  has retired, so can't work on
the libid3tag package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#721430: crosstool-ng packaging for Debian

[Alexis Murzeau]

On 17/07/2017 17:44, Geert Stappers wrote:
>
>> using existing work.
> Most likely you missed some of the existing work.
> We, Chris, you (Alexis Murzeau) and I (Geert),
> need to find out what work exists and merge it in one.
>
> What is needed that some of us says:
>URL is for the time being the leading SCM repository
>
>
>
> Groeten
> Geert Stappers
> Debian Developer
> Uploader of crosstool-ng

I've found so far only the main repository on github at [1] to contains 
Debian packaging files.
I've not checked the package on mentors.debian.net extensively but found 
it relatively close to the one in official sources [1].
I can't find the crosstool-ng package on mentors.debian.net anymore, 
does it get to a new stage ?


Is there other already known repositories out there ? (So I can maybe 
make a pull request or something :-) ).
I guess it's better for the Debian package source repository to be a 
separate one from the upstream crosstool-ng one ?

[1] https://github.com/crosstool-ng/crosstool-ng/tree/master/debian

Alexis Murzeau

Bug#868709: Updating the madplay Uploaders list

[Tobias Frost]

Source: madplay
Version: 0.15.2b-8.1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Clément Stenac  has retired, so can't work on
the madplay package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#868706: no UI after minimizing and unminimizing in Awesome WM

[Toni Mueller]

Package: inkscape
Version: 0.92.1-1
Severity: important


Hi,

I'm using Awesome, the window manager, and ran into a big problem using
Inkscape. I actually can't remember having had this problem before,
because I have been using both Inkscape and Awesome for a long time,
although I use Inkscape only rarely.

The scenario: I start Inscape. Most things work nicely, but then, I
decided to minimize Inkscape, so it is only visible in the task bar at
the top of the screen. Then I tried to unminimize Inkscape again, to
continue to work on that image I was working on

The expected result: I would have expected Inkscape to properly display
again, and let me continue with my work.

The result: Inkscape did get as far as drawing a large grey rectangle
where Inkscape has been visible before, plus some white rectangles for
what were probably input windows (for eg. the font size), and that's it.
Please see the attached screenshot of the Inkscape window at that point.

As a consequence, I am unable to use Inkscape at this point.


Cheers,
--Toni++




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

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

Versions of packages inkscape depends on:
ii  libaspell150.60.7~20110707-3+b2
ii  libatk1.0-02.22.0-1
ii  libatkmm-1.6-1v5   2.24.2-2
ii  libc6  2.24-11+deb9u1
ii  libcairo2  1.14.8-1
ii  libcairomm-1.0-1v5 1.12.0-1+b1
ii  libcdr-0.1-1   0.1.3-3+b1
ii  libdbus-1-31.10.18-1
ii  libdbus-glib-1-2   0.108-2
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3.2
ii  libgc1c2   1:7.4.2-8
ii  libgcc11:6.3.0-18
ii  libgdk-pixbuf2.0-0 2.36.5-2
ii  libglib2.0-0   2.50.3-2
ii  libglibmm-2.4-1v5  2.50.0-1
ii  libgomp1   6.3.0-18
ii  libgsl22.3+dfsg-1
ii  libgtk2.0-02.24.31-2
ii  libgtkmm-2.4-1v5   1:2.24.5-1
ii  libgtkspell0   2.0.16-1.1
ii  libjpeg62-turbo1:1.5.1-2
ii  liblcms2-2 2.8-4
ii  libmagick++-6.q16-78:6.9.7.4+dfsg-11
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-11
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-11
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpangoft2-1.0-0  1.40.5-1
ii  libpangomm-1.4-1v5 2.40.1-3
ii  libpng16-161.6.28-1
ii  libpoppler-glib8   0.48.0-2
ii  libpoppler64   0.48.0-2
ii  libpopt0   1.16-10+b2
ii  libpotrace01.13-3
ii  librevenge-0.0-0   0.0.4-6
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libstdc++6 6.3.0-18
ii  libvisio-0.1-1 0.1.5-4+b1
ii  libwpg-0.3-3   0.3.1-3
ii  libx11-6   2:1.6.4-3
ii  libxml22.9.4+dfsg1-2.2
ii  libxslt1.1 1.1.29-2.1
ii  python 2.7.13-2
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages inkscape recommends:
ii  aspell   0.60.7~20110707-3+b2
ii  fig2dev [transfig]   1:3.2.6a-2
ii  imagemagick  8:6.9.7.4+dfsg-11
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11
ii  libimage-magick-perl 8:6.9.7.4+dfsg-11
ii  libwmf-bin   0.2.8.4-10.6
ii  python-lxml  3.7.1-1
ii  python-numpy 1:1.12.1-3
ii  python-scour 0.32-2
ii  transfig 1:3.2.6a-2

Versions of packages inkscape suggests:
pn  dia | dia-gnome  
pn  libsvg-perl  
pn  libxml-xql-perl  
ii  pstoedit 3.70-3+b2
pn  python-uniconvertor  
ii  ruby 1:2.3.3

-- no debconf information

Bug#846880: lintian: warn if B-D-A or B-D-I is used in sources without Arch:any or Arch:all packages, respectively

[Chris Lamb]

Hi Johannes,

> lintian: warn if B-D-A or B-D-I is used in sources without
> Arch:any or Arch:all packages, respectively

This — in its simplest cases — was implemented by Mattia in lintian
2.3.4:

+ [RA] Also check binary-independent, wildcard, and override rules for
  programs requiring build dependencies, but accept them in either
  Build-Depends or Build-Depends-Indep.

Specifically, the build-depends-indep-without-arch-indep and
build-depends-arch-without-arch-dependent-binary tags.


Regards,

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

Bug#866130: Missing sunxi_wdt.ko for cubietruck

[Ben Hutchings]

On Thu, 2017-07-13 at 21:16 +0200, Karsten Merker wrote:
[...]
> many thanks for tracking this down to the watchdog driver.  We
> had experienced the effect that rebooting from within d-i didn't
> work properly on several sunxi-based systems, but hadn't found
> the actual cause yet.  I've tried to do a bit of further research
> and it looks like sunxi-based platforms are somewhat special in
> requiring the watchdog even for the normal system reset
> functionality and not only for an actual watchdog function.
> I haven't found indicators for similar dependencies on other
> platforms during my search, but of course they might exist
> nonetheless.
> 
> Ben, do you know of any other platforms that require a watchdog
> driver for a "normal" system reset?

No, but then I'm not an ARM porter.

> If sunxi is the sole "odd" platform here, I suppose the best
> solution would be to integrate the sunxi_wdt module directly into
> the kernel-image--armmp-di udeb.

Any driver like this that is needed for basic functionality in every
installer flavour should go into kernel-image.

So I've made this change on the stretch and sid branches for armhf.

> Probably we will need
> to include it for arm64 as well, as AFAIK the 64bit Allwinner
> SoCs A64 and H5 use the same watchdog logic as the older 32bit
> SoCs.  Proper support for A64 and H5 will be available in kernel
> 4.13, so those will become target platforms for d-i in the nearer
> future.

I'll add 'sunxi_wdt ?' for arm64 now so this should work right once we
actually enable the driver.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS teams

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

Bug#868705: gnome-exe-thumbnailer: Thumbnail generation for MSI files executes arbitrary VBScript

[Nils Dagsson Moskopp]

Package: gnome-exe-thumbnailer
Version: 0.9.4-2
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

the following PoC is copied verbatim from my post about the parsing issue:
http://news.dieweltistgarnichtso.net/posts/gnome-thumbnailer-msi-fail.html

Proof of Concept

Install Dependencies

On Debian GNU/Linux, install the packages gnome-exe-thumbnailer, nautilus and 
wixl. The wixl package is only needed to create MSI files that trigger the 
thumbnailer.

If the proof of concept does not work, install winetricks and run winetricks 
wsh56 to upgrade the Windows Script Host.

Create MSI Files

Create a file named poc.xml with the following content:


http://schemas.microsoft.com/wix/2006/wi;>



Execute the following Bourne Shell code:

wixl -o poc.msi poc.xml
cp poc.msi "poc.msi\",0):Set 
fso=CreateObject(\"Scripting.FileSystemObject\"):Set 
poc=fso.CreateTextFile(\"badtaste.txt\")'.msi"

Trigger Execution

Start GNOME Files and navigate to the folder with the MSI files. An empty file 
with the name badtaste.txt should appear.

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


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

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
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 gnome-exe-thumbnailer depends on:
ii  icoutils 0.31.2-1.1
ii  imagemagick  8:6.9.7.4+dfsg-11
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11
ii  libglib2.0-bin   2.50.3-2

Versions of packages gnome-exe-thumbnailer recommends:
pn  wine 
pn  wine64-tools | wine32-tools | wine64-development-tools | wine32-dev  

gnome-exe-thumbnailer suggests no packages.

-- no debconf information

Bug#868704: Thunar: crashes reproducible when folder content is changed by seafile

[Olaf Skibbe]

Package: thunar
Version: 1.6.11-1
Severity: normal

Dear Maintainer,

I use two computers (call them "A" and "B") running debian
stretch. On each, a folder is synchronized to one seafile
folder. On both machines, I use thunar within the xfce WM.

An hourly cronjob runs a script on A which creates some pdf files
and overwrites the existing ones in the synchronized folder. If
the folder is opened during this renewal of the files, thunar
crashes on computer B. The roles can be changed, if I run the
script on B, thunar crashes on A.

I can not trigger that behavior by just manipulating some files
in that folder manually (using touch, rm and mv).

The folder of question contains 16 pdf files with a total size of
2.4M.

The problem occurs just after upgrading from jessie to stretch.

"Crashing" here means that the thunar window gets inactive and
does not react anymore. When I start thunar from a terminal
with "thunar ", no error message shows up.

Only the instance of thunar showing the folder in question
crashes. Other thunar windows are not affected.

Regards,
Olaf


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

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

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-1
ii  exo-utils   0.10.7-1
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-11+deb9u1
ii  libcairo2   1.14.8-1
ii  libdbus-1-3 1.10.18-1
ii  libdbus-glib-1-20.108-2
ii  libexo-1-0  0.10.7-1
ii  libgdk-pixbuf2.0-0  2.36.5-2
ii  libglib2.0-02.50.3-2
ii  libgtk2.0-0 2.24.31-2
ii  libgudev-1.0-0  230-3
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-2
ii  libpango-1.0-0  1.40.5-1
ii  libsm6  2:1.2.2-1+b3
ii  libthunarx-2-0  1.6.11-1
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.8-1
ii  thunar-data 1.6.11-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.10.18-1
ii  dbus-x11 [dbus-session-bus]   1.10.18-1
ii  gvfs  1.30.4-1
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libpangocairo-1.0-0   1.40.5-1
ii  libpangoft2-1.0-0 1.40.5-1
ii  thunar-volman 0.8.1-2
ii  tumbler   0.1.31-2+b3
ii  xdg-user-dirs 0.15-2+b1
ii  xfce4-panel   4.12.1-2

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.3.1-4
ii  thunar-media-tags-plugin  0.2.1-1+b2

-- no debconf information

Bug#868464: Leaves behind /var/lib/fwupd/ directory

[Josh Triplett]

On Mon, Jul 17, 2017 at 08:32:01PM +, mario.limoncie...@dell.com wrote:
> Thanks, I've committed a fix to git.  Will be in next upload.
> https://anonscm.debian.org/cgit/uefi/fwupd.git/commit/?h=debian-next=68dd0bf14227aad93d906b2a47a1803be5790191
> https://anonscm.debian.org/cgit/uefi/fwupd.git/commit/?h=debian-next=5cdc4900c5fe43575dfc4d7d5b1f8d0a66b7067c

Thanks!

- Josh Triplett

Bug#868465: Leaves behind /var/cache/app-info/xmls/fwupd.xml

[Mario.Limonciello]

Thanks, I've committed a fix to git.  Will be in next upload.
https://anonscm.debian.org/cgit/uefi/fwupd.git/commit/?h=debian-next=68dd0bf14227aad93d906b2a47a1803be5790191
https://anonscm.debian.org/cgit/uefi/fwupd.git/commit/?h=debian-next=5cdc4900c5fe43575dfc4d7d5b1f8d0a66b7067c


> -Original Message-
> From: Josh Triplett [mailto:j...@joshtriplett.org]
> Sent: Saturday, July 15, 2017 2:04 PM
> To: Debian Bug Tracking System 
> Subject: Bug#868465: Leaves behind /var/cache/app-info/xmls/fwupd.xml
> 
> Source: fwupd
> Version: 0.8.2-2
> Severity: normal
> 
> Purging fwupd leaves behind a file /var/cache/app-info/xmls/fwupd.xml .
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

Bug#865224: uwsgi: ftbfs with multiple supported python3 versions

[gregor herrmann]

On Mon, 17 Jul 2017 22:29:45 +0200, Jonas Smedegaard wrote:

> Quoting gregor herrmann (2017-07-17 20:30:01)
> > 
> > Jonas, do you have time for an upload? This is more or less the last
> > blocker for the perl 5.26 transition which probably starts later this
> > week.
> > 
> > I'm also happy to do an NMU with the change Scott proposed.
> 
> Please do an NMU: I just started a new job¹ and departing for Debconf 
> (via Iceland for a little week) in a few days, so am swamped with tasks.
> 
> Sorry for not reporting back here earlier.

No worries, and thanks for the quick reply to my mail!
I'll look at the package.
 
> ¹ I will be doing Debian-related packaging work at https://puri.sm/

Congratulations :) 


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Elliott Sharp: Caffiend


signature.asc
Description: Digital Signature

Bug#868702: ros-wstool FTBFS: CalledProcessError: Command '[u'git', u'commit', u'-m', u'initial']' returned non-zero exit status 128

[Adrian Bunk]

Source: ros-wstool
Version: 0.1.13-2
Severity: serious

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

...
==
ERROR: setUpClass (test.local.test_cli.MultiprojectCLITest)
--
Traceback (most recent call last):
  File "test/scm_test_base.py", line 166, in setUpClass
_create_fake_ros_dir(self.test_root_path)
  File "test/scm_test_base.py", line 64, in _create_fake_ros_dir
subprocess.check_call(["git", "commit", "-m", "initial"], cwd=ros_path)
  File "/usr/lib/python2.7/subprocess.py", line 186, in check_call
raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '[u'git', u'commit', u'-m', u'initial']' returned 
non-zero exit status 128

==
ERROR: setUpClass (test.local.test_diff_functions_git.WstoolDiffGitTest)
--
Traceback (most recent call last):
  File "test/local/test_diff_functions_git.py", line 77, in setUpClass
AbstractSCMTest.setUpClass()
  File "test/scm_test_base.py", line 199, in setUpClass
_create_fake_ros_dir(self.test_root_path)
  File "test/scm_test_base.py", line 64, in _create_fake_ros_dir
subprocess.check_call(["git", "commit", "-m", "initial"], cwd=ros_path)
  File "/usr/lib/python2.7/subprocess.py", line 186, in check_call
raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '[u'git', u'commit', u'-m', u'initial']' returned 
non-zero exit status 128

==
ERROR: setUpClass (test.local.test_diff_functions_git.WstoolInfoGitTest)
--
Traceback (most recent call last):
  File "test/scm_test_base.py", line 199, in setUpClass
_create_fake_ros_dir(self.test_root_path)
  File "test/scm_test_base.py", line 64, in _create_fake_ros_dir
subprocess.check_call(["git", "commit", "-m", "initial"], cwd=ros_path)
  File "/usr/lib/python2.7/subprocess.py", line 186, in check_call
raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '[u'git', u'commit', u'-m', u'initial']' returned 
non-zero exit status 128

==
ERROR: setUpClass (test.local.test_diff_functions_hg.WstoolDiffHgTest)
--
Traceback (most recent call last):
  File "test/local/test_diff_functions_hg.py", line 81, in setUpClass
AbstractSCMTest.setUpClass()
  File "test/scm_test_base.py", line 199, in setUpClass
_create_fake_ros_dir(self.test_root_path)
  File "test/scm_test_base.py", line 64, in _create_fake_ros_dir
subprocess.check_call(["git", "commit", "-m", "initial"], cwd=ros_path)
  File "/usr/lib/python2.7/subprocess.py", line 186, in check_call
raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '[u'git', u'commit', u'-m', u'initial']' returned 
non-zero exit status 128

==
ERROR: setUpClass (test.local.test_diff_functions_hg.WstoolInfoHgTest)
--
Traceback (most recent call last):
  File "test/scm_test_base.py", line 199, in setUpClass
_create_fake_ros_dir(self.test_root_path)
  File "test/scm_test_base.py", line 64, in _create_fake_ros_dir
subprocess.check_call(["git", "commit", "-m", "initial"], cwd=ros_path)
  File "/usr/lib/python2.7/subprocess.py", line 186, in check_call
raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '[u'git', u'commit', u'-m', u'initial']' returned 
non-zero exit status 128

==
ERROR: setUpClass (test.local.test_diff_functions_multi.WstoolDiffMultiTest)
--
Traceback (most recent call last):
  File "test/local/test_diff_functions_multi.py", line 57, in setUpClass
AbstractSCMTest.setUpClass()
  File "test/scm_test_base.py", line 199, in setUpClass
_create_fake_ros_dir(self.test_root_path)
  File "test/scm_test_base.py", line 64, in _create_fake_ros_dir
subprocess.check_call(["git", "commit", "-m", "initial"], cwd=ros_path)
  File "/usr/lib/python2.7/subprocess.py", line 186, in check_call
raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '[u'git', u'commit', u'-m', u'initial']' returned 
non-zero exit status 128

==
ERROR: setUpClass (test.local.test_diff_functions_svn.WstoolDiffSvnTest)
--
Traceback (most recent call last):
  File "test/local/test_diff_functions_svn.py", line 84, 

Bug#868701: memcached: CVE-2017-9951: Heap-based buffer over-read in try_read_command function

[Salvatore Bonaccorso]

Source: memcached
Version: 1.4.33-1
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for memcached.

CVE-2017-9951[0]:
| The try_read_command function in memcached.c in memcached before 1.4.39
| allows remote attackers to cause a denial of service (segmentation
| fault) via a request to add/set a key, which makes a comparison between
| signed and unsigned int and triggers a heap-based buffer over-read.
| NOTE: this vulnerability exists because of an incomplete fix for
| CVE-2016-8705.

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-9951
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9951

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#868703: ITP: fonts-sil-awami-nastaliq -- Nastaliq-style Arabic script font

[Bobby de Vos]

Package: wnpp
Version N/A; reported 2017-07-17
Severity: wishlist

I had the wrong package in the previous bug. Sorry about that.

Greetings,

My team at SIL-NRSI has released a font not in Debian, Awami Nastaliq,
that I would like to package for Debian.

Package name: fonts-sil-awami-nastaliq
Version : 1.000
Upstream Author : SIL NRSI 
URL : http://software.sil.org/awami
License : OFL-1.1
Section : fonts
Description : Smart Unicode font for the Nastaliq script

Awami Nastaliq is a Nastaliq-style Arabic script font supporting a wide variety 
of languages of Southwest Asia, including but not limited to Urdu. This font 
is aimed at minority language support. This makes it unique among Nastaliq 
fonts.

Awami means "of the people", "of the common population" or "public". 

The Awami Nastaliq font does not provide complete coverage of all the 
characters 
defined in Unicode for Arabic script. Because the font style is specifically 
intended for languages using the Nastaliq style of southwest Asia, the 
character 
set for this font is aimed at those languages.

This font makes use of state-of-the-art font technologies to support complex 
typographic issues. Font smarts have been implemented using  Graphite only. We 
have 
no current plans to support OpenType.

One font from this typeface family is included in this release:
 * Awami Nastaliq Regular

It builds those binary packages:

fonts-sil-awami-nastaliq - Nastaliq-style Arabic script font

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

http://software.sil.org/awami/

Can a repo for the GBP packaging be created at
https://anonscm.debian.org/cgit/pkg-fonts/ ?

Daniel Glassey can sponsor this package, or Fabian Greffrath might, as
he sponsored the last font I packaged, fonts-sil-annapurna.

Regards,
Bobby

-- 
Bobby de Vos
/bobby_de...@sil.org/

Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3

[Jochen Sprickerhof]

[adding Philipp and Anton as the respective maintainers]

* Emilio Pozuelo Monfort  [2017-07-15 09:40]:
> On 14/07/17 21:42, Jochen Sprickerhof wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: binnmu
> > 
> > Hi,
> > 
> > please rebuild Ceres against the current Eigen3 version, as it encodes the
> > version in the CeresConfig.cmake and makes Google Cartographer to file in 
> > cmake
> > with:
> > 
> > CMake Error at /usr/lib/cmake/ceres/CeresConfig.cmake:88 (message):
> >   Failed to find Ceres - Found Eigen dependency, but the version of Eigen
> >   found (3.3.4) does not exactly match the version of Eigen Ceres was
> >   compiled with (3.3.2).  This can cause subtle bugs by triggering 
> > violations
> >   of the One Definition Rule.  See the Wikipedia article
> >   http://en.wikipedia.org/wiki/One_Definition_Rule for more details
> 
> Why do you need the same version at runtime than the one it was compiled with?
> Multiple definitions doesn't sound like a good reason to me, as eigen and 
> ceres
> shouldn't be defining things in the same namespace in the first place, thus
> conflicts should be impossible.
> 
> Sounds like a too strict check that should be removed.

I think it's an actual problem not only in Ceres:

http://eigen.tuxfamily.narkive.com/fweQWUaX/eigen-and-the-one-definition-rule

At the moment Ceres is not usable in Debian unstable, so as a simple
measure I would propose to do the binnmu.

I'm not sure about a long term solution. I've looked into the
Built-Using field [1]. But we would have to make sure that every package
using Eigen adds this field and I have found nothing about recompiling
every user automatically when a new Eigen version is uploaded.
I assume it would be better to trigger a rebuild of all dependencies
when Eigen is uploaded, but I'm not aware of an automatic mechanism in
Debian to do that. Any ideas?

Cheers Jochen

[1] https://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using


signature.asc
Description: PGP signature

Bug#865224: uwsgi: ftbfs with multiple supported python3 versions

[Jonas Smedegaard]

Quoting gregor herrmann (2017-07-17 20:30:01)
> On Fri, 14 Jul 2017 09:39:57 +0300, Niko Tyni wrote:
> 
> > On Thu, Jul 13, 2017 at 06:56:52PM -0400, Scott Kitterman wrote:
> > > On Friday, July 14, 2017 12:37:12 AM Niko Tyni wrote:
> 
> > > > This is the worst blocker for the Perl 5.26 transition too (uwsgi needs
> > > > to be rebuilt because uwsgi-plugin-psgi links against libperl), so even
> > > > a temporary ugly workaround would be appreciated from this side :)
> > > 
> > > Changing the python3-all-dev build-depends to python3-dev would 
> > > accomplish the 
> > > same thing while allowing a binNMU to work when we make python3.6 
> > > default.  
> > 
> > Thanks, that's indeed even better!
> > 
> > > Since this is blocking your work, I would recommend you NMU with that 
> > > change 
> > 
> > I guess we'll look at an NMU soonish (unless Jonas wants to handle this?)
> 
> Jonas, do you have time for an upload? This is more or less the last
> blocker for the perl 5.26 transition which probably starts later this
> week.
> 
> I'm also happy to do an NMU with the change Scott proposed.

Please do an NMU: I just started a new job¹ and departing for Debconf 
(via Iceland for a little week) in a few days, so am swamped with tasks.

Sorry for not reporting back here earlier.

 - Jonas


¹ I will be doing Debian-related packaging work at https://puri.sm/

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#868464: Leaves behind /var/lib/fwupd/ directory

[Mario.Limonciello]

Thanks, I've committed a fix to git.  Will be in next upload.
https://anonscm.debian.org/cgit/uefi/fwupd.git/commit/?h=debian-next=68dd0bf14227aad93d906b2a47a1803be5790191
https://anonscm.debian.org/cgit/uefi/fwupd.git/commit/?h=debian-next=5cdc4900c5fe43575dfc4d7d5b1f8d0a66b7067c


> -Original Message-
> From: Josh Triplett [mailto:j...@joshtriplett.org]
> Sent: Saturday, July 15, 2017 2:02 PM
> To: Debian Bug Tracking System 
> Subject: Bug#868464: Leaves behind /var/lib/fwupd/ directory
> 
> Source: fwupd
> Version: 0.8.2-2
> Severity: normal
> 
> Purging fwupd leaves behind the following files in /var/lib/fwupd/gnupg:
> 
> total 16
> srwx-- 1 root root0 Jul 15 11:55 S.gpg-agent
> srwx-- 1 root root0 Jul 15 11:55 S.gpg-agent.browser
> srwx-- 1 root root0 Jul 15 11:55 S.gpg-agent.extra
> srwx-- 1 root root0 Jul 15 11:55 S.gpg-agent.ssh
> drwx-- 2 root root 4096 Jul 15 11:55 private-keys-v1.d
> -rw-r--r-- 1 root root  780 Jul 15 11:55 pubring.kbx
> -rw--- 1 root root   32 Jul 15 11:55 pubring.kbx~
> -rw--- 1 root root 1200 Jul 15 11:55 trustdb.gpg
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

Bug#868700: claws-mail: Segfaults when selected from application menu or command line

[Joe]

Package: claws-mail
Version: 3.15.0-2+b1
Severity: grave
Justification: renders package unusable

Since upgrade to 3.15.0-2, claws-mail segfaults when I try to run it:

joe@jrenet:~$ claws-mail

(claws-mail:3276): Claws-Mail-CRITICAL **: imap_item_get_path: assertion 
'folder_path != NULL' failed
folder.c:3967 Condition path != NULL failed
traceback:
0:  claws-mail() [0x80cf2f8]
1:  claws-mail() [0x80d275f]
2:  claws-mail(folder_item_get_msg_list+0x7f) [0x80d311f]
3:  claws-mail() [0x80dc881]
4:  claws-mail() [0x80dd017]
5:  claws-mail(gtk_sctree_insert_gnode+0x136) [0x828f386]
6:  claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
7:  claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
8:  claws-mail(folderview_set+0x25c) [0x80df4bc]
9:  claws-mail() [0x80df701]
10: claws-mail() [0x822de41]
11: /lib/i386-linux-gnu/libglib-2.0.so.0(g_hook_list_marshal+0x67) 
[0xb6a7f847]
12: claws-mail(hooks_invoke+0x64) [0x822e554]
13: claws-mail(folder_add+0xc1) [0x80cc151]
14: claws-mail(folder_read_list+0x79) [0x80d0959]
15: claws-mail(main+0xc65) [0x80839d5]
16: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6) [0xb6191276]
17: claws-mail() [0x80857ea]


(claws-mail:3276): Claws-Mail-CRITICAL **: imap_item_get_path: assertion 
'folder_path != NULL' failed
folder.c:3991 Condition path != NULL failed
traceback:
0:  claws-mail() [0x80cf608]
1:  claws-mail() [0x80d276c]
2:  claws-mail(folder_item_get_msg_list+0x7f) [0x80d311f]
3:  claws-mail() [0x80dc881]
4:  claws-mail() [0x80dd017]
5:  claws-mail(gtk_sctree_insert_gnode+0x136) [0x828f386]
6:  claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
7:  claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
8:  claws-mail(folderview_set+0x25c) [0x80df4bc]
9:  claws-mail() [0x80df701]
10: claws-mail() [0x822de41]
11: /lib/i386-linux-gnu/libglib-2.0.so.0(g_hook_list_marshal+0x67) 
[0xb6a7f847]
12: claws-mail(hooks_invoke+0x64) [0x822e554]
13: claws-mail(folder_add+0xc1) [0x80cc151]
14: claws-mail(folder_read_list+0x79) [0x80d0959]
15: claws-mail(main+0xc65) [0x80839d5]
16: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6) [0xb6191276]
17: claws-mail() [0x80857ea]

msgcache.c:586 Condition cache_file != NULL failed
traceback:
0:  claws-mail(msgcache_read_cache+0xd7b) [0x812e3cb]
1:  claws-mail() [0x80d2783]
2:  claws-mail(folder_item_get_msg_list+0x7f) [0x80d311f]
3:  claws-mail() [0x80dc881]
4:  claws-mail() [0x80dd017]
5:  claws-mail(gtk_sctree_insert_gnode+0x136) [0x828f386]
6:  claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
7:  claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
8:  claws-mail(folderview_set+0x25c) [0x80df4bc]
9:  claws-mail() [0x80df701]
10: claws-mail() [0x822de41]
11: /lib/i386-linux-gnu/libglib-2.0.so.0(g_hook_list_marshal+0x67) 
[0xb6a7f847]
12: claws-mail(hooks_invoke+0x64) [0x822e554]
13: claws-mail(folder_add+0xc1) [0x80cc151]
14: claws-mail(folder_read_list+0x79) [0x80d0959]
15: claws-mail(main+0xc65) [0x80839d5]
16: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6) [0xb6191276]
17: claws-mail() [0x80857ea]


(claws-mail:3276): Claws-Mail-CRITICAL **: imap_item_get_path: assertion 
'folder_path != NULL' failed
Segmentation fault
joe@jrenet:~$ 



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

Kernel: Linux 4.11.0-1-686-pae (SMP w/2 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 claws-mail depends on:
ii  libatk1.0-0  2.24.0-1
ii  libc62.24-12
ii  libcairo21.14.10-1
ii  libcompfaceg11:1.5.2-5+b2
ii  libcurl3-gnutls  7.52.1-5
ii  libdb5.3 5.3.28-13
ii  libdbus-1-3  1.10.20-1
ii  libdbus-glib-1-2 0.108-2
ii  libenchant1c2a   1.6.0-11+b2
ii  libetpan20   1.8.0-1
ii  libexpat12.2.2-2
ii  libfontconfig1   2.12.3-0.2
ii  libfreetype6 2.8-0.2
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.52.3-1
ii  libgnutls30  3.5.14-2
ii  libgtk2.0-0  2.24.31-2
ii  libice6  2:1.0.9-2
ii  libldap-2.4-22.4.44+dfsg-8
ii  liblockfile1 1.14-1+b1
ii  libpango-1.0-0   1.40.6-1
ii  libpangocairo-1.0-0  1.40.6-1
ii  libpangoft2-1.0-01.40.6-1
ii  libpisock9   0.12.5-dfsg-2+b3
ii  librsvg2-2   2.40.16-1+b1
ii  libsasl2-2   2.1.27~101-g0780600+dfsg-3
ii  libsm6   2:1.2.2-1+b3
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages claws-mail recommends:
ii  aspell-en [aspell-dictionary]  2017.01.22-0-0.1
ii  claws-mail-i18n

Bug#868392: lablgtk2: Please drop the (build-)dependency against gnome-vfs

[Stéphane Glondu]

On 15/07/2017 13:40, bi...@debian.org wrote:
> Your package is {build-}depending against gnome-vfs which is
> deprecated for quite some times now and has been replaced by gvfs.

Are you sure? I see no occurrences of "vfs" in the lablgtk2 source package.


Cheers,

-- 
Stéphane

Bug#868639: [Pkg-cmake-team] Bug#868639: cmake: error while loading shared libraries: libcrypto.so.1.0.0

[Felix Geyer]

Hi,

On 17.07.2017 04:20, Augusto Fraga Giachero wrote:
> I've recently migrated my server from Debian 8 to Debian 9 and installed the 
> last version of cmake available to Debian Stretch.
> 
> Every time I invoke cmake a get as result:
> cmake: error while loading shared libraries: libcrypto.so.1.0.0: cannot open 
> shared object file: No such file or directory 
> 
> And it imediately closes.
> 
> It seems that this package has been compiled with an older version of libssl 
> than what is available in the Debian Stretch repository (libssl1.0.2 and 
> libssl1.1).

cmake doesn't link against libcrypto but transitively through libcurl.

Either the upgrade on your system has been interrupted in the middle or your 
system is modified in
some way.

In a clean stretch chroot cmake links against the following:

# ldd /usr/bin/cmake
linux-vdso.so.1 (0x7ffc8c1de000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f72615ef000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f72613d5000)
libarchive.so.13 => /usr/lib/x86_64-linux-gnu/libarchive.so.13 
(0x7f7261121000)
libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 
(0x7f7260ea1000)
libjsoncpp.so.1 => /usr/lib/x86_64-linux-gnu/libjsoncpp.so.1 
(0x7f7260c6d000)
libuv.so.1 => /usr/lib/x86_64-linux-gnu/libuv.so.1 (0x7f7260a47000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f72606c5000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f72604ae000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f726010f000)
/lib64/ld-linux-x86-64.so.2 (0x55b4020f3000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 
(0x7f725fed8000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x7f725fccf000)
liblzo2.so.2 => /lib/x86_64-linux-gnu/liblzo2.so.2 (0x7f725faab000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f725f885000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f725f673000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f725f463000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 
(0x7f725f0a8000)
libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 
(0x7f725ee82000)
libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 
(0x7f725ec5e000)
librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 
(0x7f725ea41000)
libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1 
(0x7f725e815000)
libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 
(0x7f725e607000)
libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 
(0x7f725e39e000)
libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 
(0x7f725df3a000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
(0x7f725dced000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 
(0x7f725da13000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 
(0x7f725d7e)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 
(0x7f725d5dc000)
liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 
(0x7f725d3cd000)
libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 
(0x7f725d17c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f725cf5d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f725cc59000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f725ca51000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f725c839000)
libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x7f725c634000)
libicui18n.so.57 => /usr/lib/x86_64-linux-gnu/libicui18n.so.57 
(0x7f725c1b8000)
libicuuc.so.57 => /usr/lib/x86_64-linux-gnu/libicuuc.so.57 
(0x7f725be1)
libicudata.so.57 => /usr/lib/x86_64-linux-gnu/libicudata.so.57 
(0x7f725a393000)
libunistring.so.0 => /usr/lib/x86_64-linux-gnu/libunistring.so.0 
(0x7f725a07c000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 
(0x7f7259ce3000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 
(0x7f7259aae000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 
(0x7f7259829000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f725951a000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 
(0x7f725930e000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 
(0x7f725910a000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f7258ef3000)
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 
(0x7f7258cd6000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 

Bug#663610: [Pkg-xfce-devel] Bug#663610: Bug#663610: xfce4-terminal: all terminals died, asswertion failed at ring.c:347

[Javier Barroso]

No It did not reproduced anymore (I think)

Closing the bug..

Thank you very much

El lun., 17 jul. 2017 21:41, Yves-Alexis Perez  escribió:

> On Mon, 2012-03-12 at 19:07 +0100, Javier Barroso wrote:
> > > >
> > > > It is the first time I observe this issue. I'm working with awesome
> > > > wm, If you think I should to give you more data, please ask me
> > > >
> > >
> > > If you manage to reproduce, try to get a coredump.
> >
> > Ok, I installed xfce4-terminal-dbg and will launch "ulimit -c
> > unlimited" before than xfce4-terminal. I hope that is sufficient to
> > get coredump, if not, please comment (or give a pointer) what more
> > step to do.
> >
> > Thank you very much
>
> Did you manage to reproduce in the end?
>
> Regards,
> --
> Yves-Alexis

Bug#867623: heirloom-mailx is not an alternative for /usr/bin/mailx

[Steffen Nurpmeso]

Norman Ramsey  wrote:
 |I upgraded from jessie to stretch, and I expected to continue using
 |heirloom-mailx as my implementation of mailx.  But my system was
 |somehow switched to bsd-mailx.  Worse, update-alternatives is not
 |capable of changing back:
 ...
 |I expected /usr/bin/heirloom-mailx to be an alternative on this menu.
 |
 |This is possibly the same bug as 858080, but I don't know enough
 |Debian jargon to know for sure.

The just released S-nail/mailx v14.9.0 adds support for custom
headers, so one could possibly hope something moves on.
That is all i (as the S-nail maintainer) can do,
Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#859577: (no subject)

[Alexandre Viau]

>Britney still thinks this bug is a problem for testing migration.


Yup, this is preventing Syncthing from migrating.

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



signature.asc
Description: OpenPGP digital signature

Bug#868327: [Pkg-cmake-team] Bug#868327: Could NOT find Java: Found unsuitable version "..", but required is at

[Felix Geyer]

Control: severity -1 important

On 14.07.2017 16:26, Mathieu Malaterre wrote:
> Control: severity -1 serious
> 
> Since it fails on release archs, change severity (FTBFS):
> 
> https://buildd.debian.org/status/fetch.php?pkg=gdcm=ppc64el=2.8.0-1%7Eexp1=1500041681=log

Fortunately we don't make releases from experimental.

Felix

Bug#720177: `git debrebase` UI

[Sean Whitton]

Hello Ian,

I'm working my way through NOTES.git-debrebase-pseudomergehandling.

ISTM from your notes that the script will need four user subcommand:

1. strip pseudomerges and cleanup the branch, i.e., start or continue a
   debrebase

2. finish a debrebase by pseudo-merging the remote interchange branch

   This is what the `git debrebase prep-push` hook would do, but the
   user needs to be able to make it happen in order that they can
   publish a branch that fast-forwards from the result of `dgit clone`,
   without doing an upload.

3. start a `git rebase` onto a new upstream version

4. special command to protect pseudomerges that the user wants to keep

Users normally think of rebases as operations that are first started,
potentially interrupted by conflicts, and then finished.  We are fine
with (3), because this is just a wrapper around git-rebase(1) and users
know how to deal with its --continue, --skip and --abort options.

In the case of a debrebase, there will never be any conflicts to
resolve, but until (2) has occurred, the result strikes the user as
unfinished.  The workflow was sold to them as producing something that
is a ff of the interchange branch, but it isn't a ff of the interchange
branch yet.  They wonder "did I forget a --continue somewhere?"

How about calling (2) immediately after (1) -- and if there is a clean
way of doing it, after (3), too?  That way, the user can conceptualise
the debrebase operation as "make the history into a nice patch series,
and use a bit of magic to ensure that this is still fast-forwarding".
They don't have to try to understand the state before the final
pseudomerge is back on top.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#868699: OOPS with kernel (4.9) in debian stable stretch:

[Dave Goel]

Package: linux-image-4.9.0-3-amd64
Version: 4.9.30-2+deb9u2



OOPS with kernel (4.9) in debian stable stretch:

When trying to boot with new debian stable (kernel 4.9), I get a kernel
oops: http://imgur.com/a/CybMP  It seems probably related to nouveau, as
you see in the backtrace. (I end up booting from oldstable). I have purge
xserver-xorg-video-nouveau .. but the oops still happens.

To which, imirkin_ on freenode/#nouveau replies:
 that's a familiar issue
 it should be fixed in ... 4.12 or so?
 yeah... the fan logic gets all upset
 update your kernel to 4.12 and you'll be all set

I'd rather stay with the stable debian.
What's the protocol when the stable kernel leads to unbootable OOPS? Would
you backport the fix to the current kernel? Or to move the fixed kernel
itself to stable?

Bug#663610: [Pkg-xfce-devel] Bug#663610: Bug#663610: xfce4-terminal: all terminals died, asswertion failed at ring.c:347

[Yves-Alexis Perez]

On Mon, 2012-03-12 at 19:07 +0100, Javier Barroso wrote:
> > > 
> > > It is the first time I observe this issue. I'm working with awesome
> > > wm, If you think I should to give you more data, please ask me
> > > 
> > 
> > If you manage to reproduce, try to get a coredump.
> 
> Ok, I installed xfce4-terminal-dbg and will launch "ulimit -c
> unlimited" before than xfce4-terminal. I hope that is sufficient to
> get coredump, if not, please comment (or give a pointer) what more
> step to do.
> 
> Thank you very much

Did you manage to reproduce in the end?

Regards,
-- 
Yves-Alexis

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

Bug#858539: should ca-certificates certdata.txt synchronize across all suites?

[Antoine Beaupré]

On 2017-07-07 16:02:51, Guido Günther wrote:
> On Fri, Jul 07, 2017 at 03:57:35PM +0200, Philipp Kern wrote:
>> On 07/06/2017 08:01 PM, Antoine Beaupré wrote:
>> > In looking at fixing #858539 (blocking WoSign and StartCom, in CC) for
>> > wheezy, I noticed the issue was also pending in jessie. Furthermore, the
>> > idea originally raised by pabs[1] was to also update the packages for
>> > the latest changes in certdata.txt in wheezy, including the ISRG Root
>> > for Let's Encrypt (LE).
>> > 
>> > While it should be fairly trivial to do this update, I wonder if the
>> > same logic should apply to jessie itself. Right now, jessie and stretch
>> > are synchronized, but that's only because there's an update pending in
>> > unstable to synchronize with the upstream 2.11 NSS database.
>> > 
>> > This raises the question of how synchronized we want this file to be? It
>> > seems a little arbitrary to me to synchronize the file from jessie to
>> > wheezy only for this one certificate authority (LE). How about the other
>> > authorities? It doesn't seem like we should be calling the shots on
>> > this: if we follow the Mozilla policies here, either we update all
>> > supported suites at once, or we accept that some suites will have
>> > outdated material.
>> > 
>> > I have therefore opened this specific discussion with the release team
>> > in #867461 (in CC as well). Hopefully this will bring a consistent
>> > policy.
>> > 
>> > For what it's worth, my opinion is that we should attempt to synchronize
>> > certdata.txt (and blacklist.txt, for that matter) across all suites (but
>> > not other changes to the packaging). This would remove another decision
>> > point in our infrastructure and ensure harmonious X509 processing across
>> > suites.
>> > 
>> > [1]: https://lists.debian.org/1490430746.9127.2.ca...@debian.org
>> > 
>> > Thanks for any feedback. For now I'll hold on another week or so for the
>> > wheezy update, since it seems unreasonable to push that update out
>> > before jessie is updated and that question is resolved.
>> 
>> But it's not just about certdata.txt. The WoSign and StartCom distrust
>> was actually hardcoded in NSS and hence what Mozilla enforced in NSS we
>> couldn't check in any other tools using ca-certificates. We also do not
>> sync the NSS version or backport the cert checks when such distrusts
>> happen. So we can only react in a similar way when the time for full
>> distrust has come (which is sort of the case now with these two),
>> otherwise we diverge in logic and potentially break users with different
>> expectations[1].
>
> Which brings us back to #824872 (same nss/nspr in all suites). We're
> basically shipping new NSS with firefox / thunderbird but not for the
> rest.

Let's not jump the gun here. We're not shipping NSS in ca-certificates,
just a tiny part of it: one text file, more or less.

Also, what Mozilla enforced in NSS, we enforced in ca-certificates in
other ways, through the use of a blacklist.txt file. So we can
definitely fix #858539 without syncing all of NSS to wheezy.

The proposed patch here, is more or less only to merge that very file,
blacklist.txt. The *other* thing proposed to the release team (in
#867461) is to sync the *other* changes to certdata.txt from sid. But
considering *that* work seems mostly stalled, I wonder how hard to push
on that. Of course, we could also just decide, in LTS, to sync with
jessie at least: we do not need release-team approval for this. This
would be (let's be honest here) really to get Let's Encrypt directly in
wheezy, and I think it would be worthwhile.

Also I would very well see another NMU that would release those new
changes and sync up ca-certificates with NSS, at least in sid. Then it
could trickle down to buster, and from there, if everyone is okay,
trickle down to all suites. But that discussion concerns mostly the
release team and the maintainer at this point.

I'm not sure I want to bring back the question of syncing NSS across all
suites here again. It's a different question: NSS is a library, not
just a set of policies and certificates (which is, after all, what
ca-certificates is). Backporting it forcefully across all suites
may/will have an impact on programs that link against it, something that
we won't have with ca-certicates.

So while I would like NSS to be sync'd across suites as well, I'd like
to keep the questions separate here because ca-certificates is easier to
fix.

Thanks for your feedback, keep it coming.

A.

-- 
L'homme construit des maisons parce qu'il est vivant, mais il écrit des
livres parce qu'il se sait mortel.
- Daniel Pennac, Comme un roman

Bug#868697: OOPS with kernel (4.9) in debian stable stretch:

[Dave Goel]

Package: linux-image-3.16.0-4-amd64
Version: 3.16.43-2+deb8u2



OOPS with kernel (4.9) in debian stable stretch:

When trying to boot with new debian stable (kernel 4.9), I get a kernel
oops: http://imgur.com/a/CybMP  It seems to be related to nouveau, as you
see in the backtrace. (I end up booting from oldstable). I have purged
xserver-xorg-video-nouveau .. but the oops still happens.

To which, imirkin_ on freenode/#nouveau replies:
 that's a familiar issue
 it should be fixed in ... 4.12 or so?
 yeah... the fan logic gets all upset
 update your kernel to 4.12 and you'll be all set

I'd rather stay with the stable debian.

What's the protocol when the stable kernel leads to unbootable OOPS?
Would you backport the fix to the current kernel?
Or would you move the fixed kernel itself to stable?

Bug#868698: ITP: fonts-sil-awami-nastaliq/1.000-1

[Bobby de Vos]

Package: fonts-sil-awami-nastaliq
Severity: wishlist

Greetings,

My team at SIL-NRSI has released a font not in Debian, Awami Nastaliq,
that I would like to package for Debian.

Package name: fonts-sil-awami-nastaliq
Version : 1.000-1
Upstream Author : SIL NRSI 
URL : http://software.sil.org/awami
License : OFL-1.1
Section : fonts

It builds those binary packages:

fonts-sil-awami-nastaliq - Nastaliq-style Arabic script font

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

http://software.sil.org/awami/

Can a repo for the GBP packaging be created at
https://anonscm.debian.org/cgit/pkg-fonts/ ?

Daniel Glassey can sponsor this package, or Fabian Greffrath might, as
he sponsored the last font I packaged, fonts-sil-annapurna.

Regards,
Bobby

-- 
Bobby de Vos
/bobby_de...@sil.org/