date:20170604

Control: reassign 864177 libssl1.1
Control: reassign 864186 libssl1.1
Control: forcemerge -1 864177 864186
Control: affects -1 src:nordugrid-arc src:xtensor-python

On Mon, Jun 05, 2017 at 01:10:34AM +0200, Kurt Roeckx wrote:
> On Mon, Jun 05, 2017 at 12:45:33AM +0300, Adrian Bunk wrote:
> > Control: reassign -1 libssl1.1 1.1.0f-1
> > Control: affects -1 src:simple-tpm-pk11
> > 
> > Looking at the reproducible builds results, I noticed that 
> > simple-tpm-pk11 always FTBFS in unstable but never FTBFS in stretch.
> > 
> > I confirmed that "make check" always succeeds with libssl1.1 1.1.0e-2 
> > installed and always fails with 1.1.0f-1 installed.
> 
> Nothing of the backtrace seems to relate to OpenSSL. All I can see
> is:
> [ FATAL ] /usr/include/gtest/internal/gtest-port.h:2044:: 
> pthread_key_delete(key_)failed with error 22
> 
> But I can confirm that just upgrading libssl1.1 triggers the problem.
> The only idea that I currently have is that it's related to a
> cleanup handler after the program terminates.

All three FTBFS are fixed by reverting
https://github.com/openssl/openssl/commit/7dca72af91936d246700b78e06def16561a36028

> Kurt

cu
Adrian

-- 

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

Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect

2017-06-04 Thread Prescott Hidalgo-Monroy

Please see below for updated logs regarding the issue, from the VPN start to 
it's timeout.

1 Jun 04 19:15:13 $hostname NetworkManager[531]:  [1496621713.5396] 
audit: op="connection-activate" uuid="$uuid" name="$vpn_name" pid=28504 
uid=1000 result="success"
2 Jun 04 19:15:13 $hostname NetworkManager[531]:  [1496621713.5457] 
vpn-connection[0x5639c894a360,$uuid,"$vpn_name",0]: Started the VPN service, 
PID 28510
3 Jun 04 19:15:13 $hostname NetworkManager[531]:  [1496621713.5583] 
vpn-connection[0x5639c894a360,$uuid,"$vpn_name",0]: Saw the service appear; 
activating connection
4 Jun 04 19:15:13 $hostname NetworkManager[531]:  [1496621713.5967] 
vpn-connection[0x5639c894a360,$uuid,"$vpn_name",0]: VPN plugin: state changed: 
starting (3)
5 Jun 04 19:15:13 $hostname NetworkManager[531]:  [1496621713.5968] 
vpn-connection[0x5639c894a360,$uuid,"$vpn_name",0]: VPN connection: 
(ConnectInteractive) reply rec
6 Jun 04 19:15:13 $hostname nm-openvpn[28513]: OpenVPN 2.4.0 
[git:master/d73f7253d939e293+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] 
[EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 22 2017
7 Jun 04 19:15:13 $hostname nm-openvpn[28513]: library versions: OpenSSL 1.0.2k 
26 Jan 2017, LZO 2.08
8 Jun 04 19:15:13 $hostname nm-openvpn[28513]: WARNING: --ping should normally 
be used with --ping-restart or --ping-exit
9 Jun 04 19:15:13 $hostname nm-openvpn[28513]: NOTE: the current 
--script-security setting may allow this configuration to call user-defined 
scripts
10 Jun 04 19:15:13 $hostname nm-openvpn[28513]: TCP/UDP: Preserving recently 
used remote address: [AF_INET]$ip
11 Jun 04 19:15:13 $hostname nm-openvpn[28513]: UDP link local: (not bound)
12 Jun 04 19:15:13 $hostname nm-openvpn[28513]: UDP link remote: [AF_INET]$ip
13 Jun 04 19:15:13 $hostname nm-openvpn[28513]: NOTE: chroot will be delayed 
because of --client, --pull, or --up-delay
14 Jun 04 19:15:13 $hostname nm-openvpn[28513]: NOTE: UID/GID downgrade will be 
delayed because of --client, --pull, or --up-delay
15 Jun 04 19:15:15 $hostname nm-openvpn[28513]: WARNING: 'link-mtu' is used 
inconsistently, local='link-mtu 1602', remote='link-mtu 1634'
16 Jun 04 19:15:15 $hostname nm-openvpn[28513]: WARNING: 'tun-mtu' is used 
inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
17 Jun 04 19:15:15 $hostname nm-openvpn[28513]: [$server] Peer Connection 
Initiated with [AF_INET]$ip
18 Jun 04 19:15:16 $hostname nm-openvpn[28513]: AUTH: Received control message: 
AUTH_FAILED
19 Jun 04 19:15:16 $hostname nm-openvpn[28513]: SIGUSR1[soft,auth-failure] 
received, process restarting
20 Jun 04 19:15:21 $hostname NetworkManager[531]:  [1496621721.8481] 
vpn-connection[0x5639c894a360,$uuid,"$vpn_name",0]: VPN plugin: requested 
secrets; state connect (
21 Jun 04 19:15:21 $hostname nm-openvpn[28513]: WARNING: --ping should normally 
be used with --ping-restart or --ping-exit
22 Jun 04 19:15:21 $hostname nm-openvpn[28513]: NOTE: the current 
--script-security setting may allow this configuration to call user-defined 
scripts
23 Jun 04 19:15:21 $hostname nm-openvpn[28513]: TCP/UDP: Preserving recently 
used remote address: [AF_INET]$ip
24 Jun 04 19:15:21 $hostname nm-openvpn[28513]: UDP link local: (not bound)
25 Jun 04 19:15:21 $hostname nm-openvpn[28513]: UDP link remote: [AF_INET]$ip
26 Jun 04 19:15:23 $hostname nm-openvpn[28513]: WARNING: 'link-mtu' is used 
inconsistently, local='link-mtu 1602', remote='link-mtu 1634'
27 Jun 04 19:15:23 $hostname nm-openvpn[28513]: WARNING: 'tun-mtu' is used 
inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
28 Jun 04 19:15:23 $hostname nm-openvpn[28513]: [$server] Peer Connection 
Initiated with [AF_INET]$ip
29 Jun 04 19:15:24 $hostname nm-openvpn[28513]: AUTH: Received control message: 
AUTH_FAILED
30 Jun 04 19:15:24 $hostname nm-openvpn[28513]: SIGUSR1[soft,auth-failure] 
received, process restarting
31 Jun 04 19:15:29 $hostname NetworkManager[531]:  [1496621729.7477] 
vpn-connection[0x5639c894a360,$uuid,"$vpn_name",0]: VPN plugin: requested 
secrets; state connect (
32 Jun 04 19:15:29 $hostname nm-openvpn[28513]: WARNING: --ping should normally 
be used with --ping-restart or --ping-exit
33 Jun 04 19:15:29 $hostname nm-openvpn[28513]: NOTE: the current 
--script-security setting may allow this configuration to call user-defined 
scripts
34 Jun 04 19:15:29 $hostname nm-openvpn[28513]: TCP/UDP: Preserving recently 
used remote address: [AF_INET]$ip
35 Jun 04 19:15:29 $hostname nm-openvpn[28513]: UDP link local: (not bound)
36 Jun 04 19:15:29 $hostname nm-openvpn[28513]: UDP link remote: [AF_INET]$ip
37 Jun 04 19:15:31 $hostname nm-openvpn[28513]: WARNING: 'link-mtu' is used 
inconsistently, local='link-mtu 1602', remote='link-mtu 1634'
38 Jun 04 19:15:31 $hostname nm-openvpn[28513]: WARNING: 'tun-mtu' is used 
inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
39 Jun 04 19:15:31 $hostname nm-openvpn[28513]: [$server] Peer Connection 
Initiated with [AF_INET]$ip
40 Jun 04 19:15:32 $hostname

Bug#863914: linux-libc-dev: Install separate from /usr/include

2017-06-04 Thread Ben Hutchings

Control: tag -1 - moreinfo

On Sun, 2017-06-04 at 09:14 -0400, Zack Weinberg wrote:
> > On Sat, Jun 3, 2017 at 5:05 PM, Ben Hutchings  wrote:
> > > It would be much easier to arrange
> > > this if the kernel's headers were installed in a location separate from
> > > /usr/include and then symlinked into /usr/include.  (It would be fine to
> > > symlink just the directories.)
> > 
> > I don't understand how this would help.
> 
> Suppose there exists a directory (let's call it
> /usr/src/linux/include, just for concreteness) that contains all the
> kernel headers and no other headers. Then my Makefiles can pass
> -nostdinc -isystem $(gcc -print-file-name=include) -isystem
> /usr/src/linux/include in CFLAGS to see only the kernel's headers and
> the compiler's headers. Without such a directory, the only way to get
> the same effect that I can think of is to manually create that
> directory somehow. It'd be much easier to do this in linux-libc-dev,
> which already knows what all the files are.

OK, I get it.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program than to understand a correct
one.



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

Bug#864147: [Debian-Islamic-maintainers] Bug#864147: Updated thawab to latest version

2017-06-04 Thread أحمد المحمودي

I see that you have filed an upstream bug that indexing fails. Maybe updating 
to 4.1 should wait ?


On June 4, 2017 3:31:45 PM EET, Shanavas  wrote:
>I have updated thawab to 4.1
>
>The repo is at https://git.fosscommunity.in/shanavasm/thawab/
>
>Please check

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#864189: unblock: systemd/232-25

2017-06-04 Thread Michael Biebl

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

Hi,

please consider unblocking systemd.

The changes include two fixes for selinux, a fix for a dist-upgrade
failure and an important performance regression.

None of those should affect the udev/libudev1 udeb, i.e. the installer.

That said, I've CCed debian-boot for a d-i/KiBi ack.

Here's an annotated changelog


systemd (232-25) unstable; urgency=medium

  * hwdb: Use path_join() to generate the hwdb_bin path.
This ensures /lib/udev/hwdb.bin gets the correct SELinux context. Having
double slashes in the path makes selabel_lookup_raw() return the wrong
context. (Closes: #851933)

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=stretch=16508bf

I was asked by the SELinux maintainers to fix this for stretch. In the
end, it turned out to be a bug in libselinux (#863854). But the fix for
libselinux is rather invasive so will likely not make it into stretch
and it's easy to avoid triggering the bug, so I've decided to fix/work
around this in systemd.

  * selinux: Enable labeling and access checks for unprivileged users.
Revert commit that inadvertently broke a lot of SELinux related
functionality for both unprivileged users and systemd instances running
as MANAGER_USER and instead deal with the auditd issue by checking for
the CAP_AUDIT_WRITE capability before opening an audit netlink socket.
(Closes: #863800)

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=stretch=5088d0

Laurent Bigonville, one of the SELinux maintainers, asked me to pull
those fixes for stretch. He tested the patches and confirmed that they
work. The patches are from upstream.

  * Revert "systemd-sysv: Add Conflicts: systemd-shim"
Under certain conditions this confuses Jessies's apt which then tries to
remove systemd while being the active init system, resulting in a failed
dist-upgrade. While this turned out to be a bug in apt, avoid this
situation by dropping the Conflicts. (Closes: #854041)

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=stretch=a99075

This is bug which imho is the most important one to get fixed for r0.
It was (sometimes) causing dist-upgrade failures, if prior to the upgrade
systemd-shim was installed. David Kalnischkies identified this as a bug
in apt, but since we can't retroactively fix apt in jessie, I decided to
drop this Conflicts again to avoid this situation.

  * link: Fix offload features initialization.
This fixes a regression introduced in v232 which caused TCP
segmentation offloads being disabled by default, resulting in
significant performance issues under certain conditions. (Closes: #864073)

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=stretch=551b79

This seemed like a rather straightforward fix which was unfortuantely
only reported the other day. Otherwise I would have pulled it earlier.
The patch is from upstream.

Full debdiff is attached as well.

Regards,
Michael

unblock systemd/232-25

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index 68276b7..d3789db 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,27 @@
+systemd (232-25) unstable; urgency=medium
+
+  * hwdb: Use path_join() to generate the hwdb_bin path.
+This ensures /lib/udev/hwdb.bin gets the correct SELinux context. Having
+double slashes in the path makes selabel_lookup_raw() return the wrong
+context. (Closes: #851933)
+  * selinux: Enable labeling and access checks for unprivileged users.
+Revert commit that inadvertently broke a lot of SELinux related
+functionality for both unprivileged users and systemd instances running
+as MANAGER_USER and instead deal with the auditd issue by checking for
+the CAP_AUDIT_WRITE capability before opening an audit netlink socket.
+(Closes: #863800)
+  * Revert "systemd-sysv: Add Conflicts: systemd-shim"
+Under certain conditions this confuses Jessies's apt which then tries to
+remove systemd while being the active init system, resulting in a failed
+dist-upgrade. While this turned out to be a bug in apt, avoid this
+situation by dropping the Conflicts. (Closes: #854041)
+  * link: Fix offload features initialization.
+This fixes a regression introduced in v232 which caused TCP
+segmentation offloads being disabled by default, resulting in
+significant performance issues under certain conditions. (Closes: #864073)
+
+ -- Michael Biebl   Sun, 04 Jun 2017 22:58:32

Bug#862576: [Pkg-sugar-devel] Bug#862576: etoys: Doesn't get beyond Squeak security key generation

2017-06-04 Thread James Cameron

@Petter, thanks for asking.

@Bert, etoys 5.0.2408 does not complete "Initializing Squeak security
system" on Debian Stretch, but it did on Debian Jessie.

I don't know what's wrong, yet.

I've reproduced the problem.

CPU is 100%.  strace shows the process making syscalls, of which the
most frequent are gettimeofday and recvfrom on socket, with occasional
SIGARLM.  http://dev.laptop.org/~quozl/z/1dHfBq.txt

The process has one thread with a backtrace;

(gdb) thread apply all bt

Thread 1 (Thread 0x7f46b3f3c500 (LWP 954)):
#0  0x55f77704d270 in ?? ()
#1  0x55f77704d40b in ?? ()
#2  0x55f777013f77 in interpret ()
#3  0x55f776ff9d39 in main ()

Repeated continue, ctrl+c and backtrace shows the squeak-vm is
actually doing something, but I've no idea what;

#0  0x55f777007800 in success ()
#1  0x55f77704cef8 in ?? ()
#2  0x55f777013f77 in interpret ()
#3  0x55f776ff9d39 in main ()

#0  0x55f77700f758 in stObjectat ()
#1  0x55f77700f861 in commonAt ()
#2  0x55f777013f77 in interpret ()
#3  0x55f776ff9d39 in main ()

#0  0x55f77700d8e0 in primitiveFloatSubtractfromArg ()
#1  0x55f777014d90 in interpret ()
#2  0x55f776ff9d39 in main ()

#0  0x55f7770078cd in sweepPhase ()
#1  0x55f77700946c in incrementalGC ()
#2  0x55f777009a35 in instantiateClassindexableSize ()
#3  0x55f77704b4d0 in ?? ()
#4  0x55f77704dc45 in ?? ()
#5  0x55f777013f77 in interpret ()
#6  0x55f776ff9d39 in main ()

#0  0x55f777013dc0 in interpret ()
#1  0x55f776ff9d39 in main ()

#0  0x7ffc4053ed80 in gettimeofday ()
#1  0x55f77701955e in ioMSecs ()
#2  0x55f777007f9d in checkForInterrupts ()
#3  0x55f777013e3c in interpret ()
#4  0x55f776ff9d39 in main ()

generate-core-file can be used, and the resulting core file can be
reloaded in gdb.  http://dev.laptop.org/~quozl/z/1dHfAf.txt

Perhaps one of the libraries changed between Jessie and Stretch to
cause this problem; but finding which one will be a long task.

Perhaps etoys upstream may have some ideas.  I've copied Bert.

On Sun, Jun 04, 2017 at 10:23:51PM +0200, Petter Reinholdtsen wrote:
> This issue is going to cause etags to be removed from Stretch.
> Anyone have any idea what is wrong?

-- 
James Cameron
http://quozl.netrek.org/

Bug#864188: libbpp-core2v5: symbols removed without soname bump

Package: libbpp-core2v5
Version: 2.3.0-1~exp1
Severity: serious
Control: affects -1 libbpp-seq9v5 src:libbpp-phyl

2.3.0-1~exp1 in unstable (sic) removes symbols without changing soname,
causing the following FTBFS in libbpp-phyl:

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

...
[ 93%] Linking CXX executable test_bowker
cd /build/1st/libbpp-phyl-2.2.0/obj-x86_64-linux-gnu/test && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/test_bowker.dir/link.txt --verbose=1
/usr/bin/c++   -Wall -Wshadow -Weffc++ -Wconversion  -Wl,-z,relro 
CMakeFiles/test_bowker.dir/test_bowker.cpp.o  -o test_bowker -rdynamic 
-lbpp-seq -lbpp-core -L../src -lbpp-phyl 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libbpp-seq.so: 
undefined reference to `bpp::RandomTools::lnGamma(double)'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libbpp-seq.so: 
undefined reference to 
`bpp::TextTools::startsWith(std::__cxx11::basic_string const&, 
std::__cxx11::basic_string 
const&)'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libbpp-seq.so: 
undefined reference to 
`bpp::ApplicationTools::parameterExists(std::__cxx11::basic_string const&, 
std::map, std::__cxx11::basic_string, 
std::less >, 
std::allocator const, 
std::__cxx11::basic_string 
> > >&)'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libbpp-seq.so: 
undefined reference to 
`bpp::ApplicationTools::getStringParameter(std::__cxx11::basic_string const&, 
std::map, std::__cxx11::basic_string, 
std::less >, 
std::allocator const, 
std::__cxx11::basic_string 
> > >&, std::__cxx11::basic_string const&, std::__cxx11::basic_string const&, bool, int)'
collect2: error: ld returned 1 exit status
test/CMakeFiles/test_bowker.dir/build.make:99: recipe for target 
'test/test_bowker' failed
make[3]: *** [test/test_bowker] Error 1

Bug#862371: RFS: budgie-desktop/10.3.1-1

2017-06-04 Thread foss.freedom

Tim,

  absolutely superb - that worked very nicely :D

Not quite sure I understand why since I dont recognise that locale -
some-sort of special "C language" unicode locale? - but it works so
thats the main thing.


Gianfranco,

  A new version of the package has been uploaded with Tim's
suggestion.  Tested by building in a Stretch chroot.

In addition - as requested - the .installs have been simplified.

I also doubled checked this and threw this up on a launchpad PPA.

cheers

David

On 4 June 2017 at 22:15, Tim Dengel  wrote:
> Hi David,
>
> I haven't specifically looked into your issue and the build log doesn't
> seem to be available anymore, but it sounds like you're having trouble
> with meson being unable to deal with Unicode symbols inside a pbuilder
> chroot.
> I also have a package that builds with meson and had a FTBFS due to
> Unicode support (gnome-twitch), although admittedly it is a much simpler
> package than budgie. I fixed my issue by adding LC_ALL=C.UTF-8 in the
> d/rules file[0]. Maybe it helps.
>
> [0] https://github.com/dengelt/gnome-twitch/blob/debian/sid/debian/rules
>
>
> Regards,
>
> Tim
>
>
> Am 04.06.2017 um 19:46 schrieb foss.freedom:
>> Hi Gianfranco,
>>
>>   I'm struggling with this - any thoughts on my investigations below.
>>
>> On Debian Stretch I've created a chroot for unstable and installed the
>> build dependencies for budgie-desktop + locales + meson
>>
>> In debian/rules I've changed the two export LANG and LANGUAGE vars to
>> en_US.UTF-8
>>
>> Then manually (in the chroot) I have run the following:
>>
>> debconf-set-selections <<< 'locales locales/default_environment_locale
>> select en_US.UTF-8'
>>
>> dpkg-reconfigure locales
>>
>> update-locale LANGUAGE='en_US.UTF-8'
>>
>> N.B. the debconf-set-selections is to ensure dpkg-reconfigure locales
>> runs without the user having to manually select en_US.UTF-8 to the two
>> questions asked.
>>
>> That's enough to convince the dpkg-buildpackage -us -uc to work
>> correctly within the chroot
>>
>> The question I have is how to tuck the three commands above into the
>> Debian package to run before the main meson callout in debian/rules ?
>> i.e. I'm hoping this is the answer how to get the Debian build system
>> to default to a UTF-8 locale.
>>
>> I added the three commands within override_dh_auto_configure: but I
>> get a "sh:1  Syntax error: redirection unexpected" - so I'm kind of
>> stuck on how to move forward.
>>
>> I was hoping to find an existing Debian package that uses meson
>> building Vala within the archives to see how the maintainer did
>> something similar but my Google-fu has failed to find such a package
>> :(
>>
>> David
>>
>>
>> On 12 May 2017 at 19:09, foss.freedom  wrote:
>>> Thanks Gianfranco for the review.  Much appreciated.
>>>
>>> I have completely redone the licenses and files in debian/copyight and
>>> double checked via "check-all-the-things"
>>>
>>> For the .install files - all debian/tmp has been removed.
>>>
>>> the FTBFS is concerning.  I don't understand why there is a difference
>>> between the build systems of launchpad (it works) and Debian (it
>>> doesnt).
>>>
>>> I asked this question here -
>>> https://github.com/budgie-desktop/budgie-desktop/issues/921
>>>
>>> The advice is to ensure the environment variables LANG and LANGUAGE is
>>> set to en_US - I've added two export lines for these environment vars
>>> at the top of the debian/rules
>>>
>>> I've tested the rules changes on launchpad.  However I dont have
>>> access to the debian build system so I cannot verify.
>>>
>>> I have rebuilt on my debian stretch VM and this is OK.
>>>
>>> David
>>>
>>> On 11 May 2017 at 22:27, Gianfranco Costamagna  
>>> wrote:
 control: owner -1 !
 control: tags -1 moreinfo

 Hello, I will sponsor it,
 but please have a deep look at missing copyrights for a next upload, e.g.
 + * Copyright (C) 2017 taaem 


 other things:
 I don't understand why you prepended debian/tmp to install files, but as 
 you wish

 2) FTBFS
 http://debomatic-amd64.debian.net/distribution#experimental/budgie-desktop/10.3.1-1/buildlog

 G.
>>

Bug#861840: google sign in error in thunderbird

2017-06-04 Thread Jason Cohen

I am also seeing this behavior in Thunderbird 45.8.0 on a fresh install
of Debian Stretch.  While Mozilla has fixed this issue in 52.1, they
have indicated that they do not intend to fix the issue in 45.8.0.  It
will have to be backported.

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

Bug#863707: [Pkg-openssl-devel] Bug#863707: simple-tpm-pk11: FTBFS: ./m4/test-driver: line 107: 4695 Aborted (core dumped)

2017-06-04 Thread Kurt Roeckx

On Mon, Jun 05, 2017 at 12:45:33AM +0300, Adrian Bunk wrote:
> Control: reassign -1 libssl1.1 1.1.0f-1
> Control: affects -1 src:simple-tpm-pk11
> 
> Looking at the reproducible builds results, I noticed that 
> simple-tpm-pk11 always FTBFS in unstable but never FTBFS in stretch.
> 
> I confirmed that "make check" always succeeds with libssl1.1 1.1.0e-2 
> installed and always fails with 1.1.0f-1 installed.

Nothing of the backtrace seems to relate to OpenSSL. All I can see
is:
[ FATAL ] /usr/include/gtest/internal/gtest-port.h:2044:: 
pthread_key_delete(key_)failed with error 22

But I can confirm that just upgrading libssl1.1 triggers the problem.
The only idea that I currently have is that it's related to a
cleanup handler after the program terminates.

Kurt

Bug#864187: libpam-google-authenticator: Security issue when using a common configuration scheme

2017-06-04 Thread tmolitor

Package: libpam-google-authenticator
Version: 20160607-2+b1
Severity: grave
Tags: security patch
Justification: user security hole

When configuring this pam module to add two-factor authentification to your ssh 
daemon (for example)
every ssh enabled user has to be configured for google-authenticator.
If you want to configure google-authenticator only for some users, not
all, various howtos available on the internet suggest to use the "nullok" 
argument in the pam config.

But this opens a security hole for all users not configured to use the
google-authenticator, as these users can access the ssh server without
supplying any credentials at all.

There is essentially no way to use pam to ask for the user's password,
if the authenticator is not configured for this user, and to only ask
for the otp code if it is configured for the user.

See also https://github.com/google/google-authenticator-libpam/issues/55
for a more complete description of the issue
(especially this comment: 
https://github.com/google/google-authenticator-libpam/issues/55#issuecomment-275943553
 ).

See commit 
https://github.com/google/google-authenticator-libpam/commit/4f7d3b13d1850108be91b63de2aec22538d8be6e
for a patch.

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

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

Versions of packages libpam-google-authenticator depends on:
ii  libc6 2.24-11
ii  libpam0g  1.1.8-3.6
ii  libqrencode3  3.4.4-1+b2

libpam-google-authenticator recommends no packages.

libpam-google-authenticator suggests no packages.

-- no debconf information

Bug#791944: /etc/init.d/sendsigs kills systemd-udevd upon shutdown, causing dmsetup to hang

2017-06-04 Thread Michael Biebl

Am 03.06.2017 um 19:44 schrieb Michael Biebl:
> Am 03.06.2017 um 17:24 schrieb Felipe Sateler:
> 
>> diff --git a/debian/udev.init b/debian/udev.init
>> index ffef3ea6a..dcc5c29d5 100644
>> --- a/debian/udev.init
>> +++ b/debian/udev.init
>> @@ -208,6 +208,7 @@ case "$1" in
>>  stop)
>>  log_daemon_msg "Stopping $DESC" "$NAME"
>>  if start-stop-daemon --stop --name $NAME --user root --quiet --oknodo 
>> --retry 5; then
>> +rm -f /run/udev/control
> 
> I think this is the correct fix, yes.
> 
> We need to keep in mind though, that udev currently does not install any
> stop (K) symlinks in runlevel 0 and 6, but we rely on the killing spree
> in sendsigs to kill the udev process on shutdown.
> 
> Which means, we'd need to start installing those K symlinks in 0 6.
> For that, edit /etc/init.d/udev, add
> # Default-Stop: 0 6
> to the LSB header, then run
> 
> # rm /etc/rcS.d/???udev
> # update-rc.d udev defaults

We need people using sysvinit to test that proposed fix and report back
if it fixes that issue and does not introduce any new regressions.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#864186: xtensor-python FTBFS: [ FATAL ] gtest-port.h:2044:: pthread_key_delete(key_)failed with error 22

Source: xtensor-python
Version: 0.12.1-1
Severity: serious

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

...
[--] Global test environment tear-down
[==] 32 tests from 3 test cases ran. (2 ms total)
[  PASSED  ] 32 tests.

[ FATAL ] 
xtensor-python_0.12.1-1/obj-x86_64-linux-gnu/test/googletest-src/googletest/include/gtest/internal/gtest-port.h:2044::
 pthread_key_delete(key_)failed with error 22
Aborted
test/CMakeFiles/xtest.dir/build.make:60: recipe for target 
'test/CMakeFiles/xtest' failed
make[5]: *** [test/CMakeFiles/xtest] Error 134


Looking at the test history at reproducible builds, it is likely
that some change in a dependency between 2017-05-19 and 2017-05-31
causes this issues:
https://tests.reproducible-builds.org/debian/history/xtensor-python.html

Bug#860504: kubernetes: FTBFS on ppc64el: relocations too big

2017-06-04 Thread Potter, Tim

Looks like this has been identified as an issue with the Golang linker:

https://github.com/golang/go/issues/15823

Unfortunately it doesn't look like this will be fixed until Go 1.9 or 1.10:

https://github.com/golang/go/issues/17917


Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#862053: marked as pending

2017-06-04 Thread Moritz Mühlenhoff

On Sun, Jun 04, 2017 at 09:54:33PM +, Craig Small wrote:
> Hi Moritz,
>   My gpg key expired and while I have uploaded an updated expiry date it
> takes some time to get into the ftp server keyring.  The problem is I dont
> know when that is.
> 
> So to your question I can upload it after the ftp server keyring updates
> plus some time it takes for me to realise it is updated. If you know how to
> check for the keyring the actual server uses that can help the second part.

Ah, I missed that. Sorry.

> Also which version of WordPress are you referring to? I upload a minimum of
> 3 each security release.

I was primarily referring to the sid upload, since the time window for uploads
aimed to stretch closes in a few days.

Cheers,
Moritz

Bug#864184: oping: No more works as non-root

2017-06-04 Thread Axel Beckert

Package: oping
Version: 1.10.0-1
Severity: important

Hi,

since the upload of 1.10.0-1, neither oping nor noping work as
unprivileged user (i.e. non-root) anymore.

noping crashes with "ping_send failed: Operation not permitted" and
leaves the terminal in broken state: It doesn't seem to switch the
terminal back properly into scrolling mode. Calling "reset" usually
helps to fix the terminal.

oping exits with exit-code 1 as follows:

~ → oping 192.168.1.232
PING 192.168.1.232 (192.168.1.232) 56 bytes of data.
ping_send failed: Operation not permitted

Downgrading both, oping and liboping0 suffices to fix this issue, so it
was introduced in the 1.10.0-1 upload. (Just downgrading oping doesn't
seem to suffice.)

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-amd64 (SMP w/8 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: sysvinit (via /sbin/init)

Versions of packages oping depends on:
ii  libc6 2.24-11
ii  libncursesw5  6.0+20161126-1
ii  liboping0 1.10.0-1
ii  libtinfo5 6.0+20161126-1

oping recommends no packages.

oping suggests no packages.

-- no debconf information

Bug#864185: sqlite3 built without fts5 support (upstream bug)

2017-06-04 Thread Yuriy M. Kaminskiy


Package: sqlite3
Version: 3.19.2-1
Severity: normal
Tags: upstream fixed-upstream patch

Dear Maintainer,

I noticed that libsqlite3_3.19.2-1 is accidentally built without fts4 
and fts5 support due to broken handling of --enable-* flags in 
configure.ac (already fixed upstream,

https://www.sqlite3.org/info/43ce3bd3
) [and that's why symbol sqlite3_fts5_may_be_corrupt@Base disappeared; 
it should be reinstated in .symbols].

This bug is only present in experimental;
jessie{,-backports}/stretch/sid are not affected.

-- System Information:
Debian Release: 8.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

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

Versions of packages sqlite3 depends on:
ii  libc6 2.19-18+deb8u9
ii  libreadline6  6.3-8+b3
ii  libsqlite3-0  3.16.2-3~bpo8+1

sqlite3 recommends no packages.

Versions of packages sqlite3 suggests:
ii  sqlite3-doc  3.16.2-3~bpo8+1

-- no debconf information

--- sqlite3-3.19.2/configure.ac.orig	2017-06-02 12:59:06.0 +0300
+++ sqlite3-3.19.2/configure.ac	2017-06-02 13:56:39.0 +0300
@@ -628,7 +628,7 @@
   [enable_memsys5=yes],[enable_memsys5=no])
 AC_MSG_CHECKING([whether to support MEMSYS5])
 if test "${enable_memsys5}" = "yes"; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_MEMSYS5"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_MEMSYS5"
   AC_MSG_RESULT([yes])
 else
   AC_MSG_RESULT([no])
@@ -638,7 +638,7 @@
   [enable_memsys3=yes],[enable_memsys3=no])
 AC_MSG_CHECKING([whether to support MEMSYS3])
 if test "${enable_memsys3}" = "yes" -a "${enable_memsys5}" = "no"; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_MEMSYS3"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_MEMSYS3"
   AC_MSG_RESULT([yes])
 else
   AC_MSG_RESULT([no])
@@ -650,20 +650,20 @@
   [Enable the FTS3 extension]),
   [enable_fts3=yes],[enable_fts3=no])
 if test "${enable_fts3}" = "yes" ; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_FTS3"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_FTS3"
 fi
 AC_ARG_ENABLE(fts4, AC_HELP_STRING([--enable-fts4],
   [Enable the FTS4 extension]),
   [enable_fts4=yes],[enable_fts4=no])
 if test "${enable_fts4}" = "yes" ; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_FTS4"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_FTS4"
   AC_SEARCH_LIBS([log],[m])
 fi
 AC_ARG_ENABLE(fts5, AC_HELP_STRING([--enable-fts5],
   [Enable the FTS5 extension]),
   [enable_fts5=yes],[enable_fts5=no])
 if test "${enable_fts5}" = "yes" ; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_FTS5"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_FTS5"
   AC_SEARCH_LIBS([log],[m])
 fi
 
@@ -673,7 +673,7 @@
   [Enable the JSON1 extension]),
   [enable_json1=yes],[enable_json1=no])
 if test "${enable_json1}" = "yes" ; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_JSON1"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_JSON1"
 fi
 
 #
@@ -682,7 +682,7 @@
   [Enable the RTREE extension]),
   [enable_rtree=yes],[enable_rtree=no])
 if test "${enable_rtree}" = "yes" ; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_RTREE"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_RTREE"
 fi
 
 #
@@ -691,12 +691,12 @@
   [Enable the SESSION extension]),
   [enable_session=yes],[enable_session=no])
 if test "${enable_session}" = "yes" ; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_SESSION"
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_PREUPDATE_HOOK"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_SESSION"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_PREUPDATE_HOOK"
 fi
 
 #
-# attempt to duplicate any OMITS and ENABLES into the $(OPT_FEATURE_FLAGS) parameter
+# attempt to duplicate any OMITS and ENABLES into the ${OPT_FEATURE_FLAGS} parameter
 for option in $CFLAGS $CPPFLAGS
 do
   case $option in
@@ -707,7 +707,7 @@
 AC_SUBST(OPT_FEATURE_FLAGS)
 
 
-# attempt to remove any OMITS and ENABLES from the $(CFLAGS) parameter
+# attempt to remove any OMITS and ENABLES from the ${CFLAGS} parameter
 ac_temp_CFLAGS=""
 for option in $CFLAGS
 do
@@ -720,7 +720,7 @@
 CFLAGS=$ac_temp_CFLAGS
 
 
-# attempt to remove any OMITS and ENABLES from the $(CPPFLAGS) parameter
+# attempt to remove any OMITS and ENABLES from the ${CPPFLAGS} parameter
 ac_temp_CPPFLAGS=""
 for option in $CPPFLAGS
 do
@@ -733,7 +733,7 @@
 CPPFLAGS=$ac_temp_CPPFLAGS
 
 
-# attempt to remove any OMITS and ENABLES from the $(BUILD_CFLAGS) parameter
+# attempt to remove any OMITS and ENABLES from the ${BUILD_CFLAGS} parameter

Bug#862053: marked as pending

2017-06-04 Thread Craig Small

Hi Moritz,
  My gpg key expired and while I have uploaded an updated expiry date it
takes some time to get into the ftp server keyring.  The problem is I dont
know when that is.

So to your question I can upload it after the ftp server keyring updates
plus some time it takes for me to realise it is updated. If you know how to
check for the keyring the actual server uses that can help the second part.

Also which version of WordPress are you referring to? I upload a minimum of
3 each security release.

 - Craig

-- 
Craig Small https://dropbear.xyz/ csmall at : enc.com.au
Debian GNU/Linuxhttps://www.debian.org/   csmall at : debian.org
Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees
GPG fingerprint:  5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Bug#863519: unblock blockdiag/1.5.3+dfsg-2

2017-06-04 Thread Kouhei Maeda

retitile 863519: unblock blockdiag/1.5.3+dfsg-5

Hi, Niels

2017-06-04 0:30 GMT+09:00 Niels Thykier :
> I am not confident that the "install -d" variant used in the -4 upload
> is entirely safe from this symlink attack.  Furthermore, it still causes
> issues by:
>
>  * It would (still?) cause issues if multiple versions of blockdiag are
>built on the same machine concurrently.
>  * It assumes /tmp rather than using $(TMPDIR) if set (minor issue)
>
> A quick fix to both of these would be to place the temporary directory
> in the "debian" directory (instead of /tmp/).  That
> would solve all of my concerns with the temporary directory used by the
> build.

I changed to use PYBUILD {build_dir} instead of
/tmp/ in the "-5" upload.

Attached is the source debdiff.

Regards,

diff -Nru blockdiag-1.5.3+dfsg/debian/changelog
blockdiag-1.5.3+dfsg/debian/changelog
--- blockdiag-1.5.3+dfsg/debian/changelog2017-05-31 07:19:40.0 +0900
+++ blockdiag-1.5.3+dfsg/debian/changelog2017-06-04 12:08:49.0 +0900
@@ -1,3 +1,21 @@
+blockdiag (1.5.3+dfsg-5) unstable; urgency=medium
+
+  * debian/rules
+- Fixes to use PYBUILD {build_dir} instead of hardcoded temporary directory
+  on PYBUILD_BEFORE_TEST.
+- Updates PYBUILD_AFTER_TEST.
+- Removes overrider_dh_python2 target.
+- Removes copying test image files to testimages directory
+  on overrider_dh_python3.
+  * debian/patches
+- Deletes fixes-ghostscript_not_found_test.patch
+- Updates Fixed-remote-image-resouces.patch.
+  * Removes unnecessary files.
+- debian/python-blockdiag.links
+- debian/python3-blockdiag.links
+
+ -- Kouhei Maeda   Sun, 04 Jun 2017 12:08:49 +0900
+
 blockdiag (1.5.3+dfsg-4) unstable; urgency=medium

   * debian/rules
diff -Nru blockdiag-1.5.3+dfsg/debian/patches/Fixed-remote-image-resouces.patch
blockdiag-1.5.3+dfsg/debian/patches/Fixed-remote-image-resouces.patch
--- blockdiag-1.5.3+dfsg/debian/patches/Fixed-remote-image-resouces.patch
   2017-05-31 07:19:40.0 +0900
+++ blockdiag-1.5.3+dfsg/debian/patches/Fixed-remote-image-resouces.patch
   2017-06-04 11:19:43.0 +0900
@@ -4,25 +4,25 @@

 Index: 
blockdiag-1.5.3+dfsg/src/blockdiag/tests/diagrams/background_url_image.diag
 ===
 
blockdiag-1.5.3+dfsg.orig/src/blockdiag/tests/diagrams/background_url_image.diag
   2017-06-04 11:06:19.475245999 +0900
-+++ blockdiag-1.5.3+dfsg/src/blockdiag/tests/diagrams/background_url_image.diag
   2017-06-04 11:06:50.142572000 +0900
+--- 
blockdiag-1.5.3+dfsg.orig/src/blockdiag/tests/diagrams/background_url_image.diag
   2017-06-04 11:17:13.518449125 +0900
 blockdiag-1.5.3+dfsg/src/blockdiag/tests/diagrams/background_url_image.diag
   2017-06-04 11:19:16.593641793 +0900
 @@ -1,7 +1,8 @@
  {
 -  A [background = "http://python.org/images/python-logo.gif;];
 -  B [background = "http://blockdiag.com/favicon.ico;];
 -  C [background =
"http://upload.wikimedia.org/wikipedia/commons/9/9b/Scalable_Vector_Graphics_Circle2.svg;];
 -  D [background = "http://people.sc.fsu.edu/~jburkardt/data/eps/circle.eps;];
-+  A [background = "/usr/lib/python3.5/idlelib/Icons/python.gif"];
++  A [background = "blockdiag/tests/diagrams/white.gif"];
 +  B [background = "/usr/lib/python3.5/idlelib/Icons/idle.ico"];
-+  C [background = "/usr/lib/python3.5/idlelib/Icons/idle_16.png"];
++  C [background =
"blockdiag/tests/diagrams/debian-logo-256color-palettealpha.png"];
 +  D [background = "circle.eps"];
 +  E [background = "circle.svg"];
Z;
  }
 Index: blockdiag-1.5.3+dfsg/src/blockdiag/tests/diagrams/node_icon.diag
 ===
 blockdiag-1.5.3+dfsg.orig/src/blockdiag/tests/diagrams/node_icon.diag
   2017-06-04 11:06:19.475245999 +0900
-+++ blockdiag-1.5.3+dfsg/src/blockdiag/tests/diagrams/node_icon.diag
  2017-06-04 11:06:19.471244000 +0900
+--- blockdiag-1.5.3+dfsg.orig/src/blockdiag/tests/diagrams/node_icon.diag
   2017-06-04 11:17:13.518449125 +0900
 blockdiag-1.5.3+dfsg/src/blockdiag/tests/diagrams/node_icon.diag
  2017-06-04 11:17:13.514449125 +0900
 @@ -2,5 +2,5 @@
A -> B;

diff -Nru blockdiag-1.5.3+dfsg/debian/python-blockdiag.links
blockdiag-1.5.3+dfsg/debian/python-blockdiag.links
--- blockdiag-1.5.3+dfsg/debian/python-blockdiag.links2014-09-01
07:58:18.0 +0900
+++ blockdiag-1.5.3+dfsg/debian/python-blockdiag.links1970-01-01
09:00:00.0 +0900
@@ -1,2 +0,0 @@
-usr/share/doc/python-blockdiag/testimages/debian-logo-256color-palettealpha.png
usr/lib/python2.7/dist-packages/blockdiag/tests/diagrams/debian-logo-256color-palettealpha.png
-usr/share/doc/python-blockdiag/testimages/white.gif
usr/lib/python2.7/dist-packages/blockdiag/tests/diagrams/white.gif
diff -Nru blockdiag-1.5.3+dfsg/debian/python3-blockdiag.links
blockdiag-1.5.3+dfsg/debian/python3-blockdiag.links
---

Bug#863707: simple-tpm-pk11: FTBFS: ./m4/test-driver: line 107: 4695 Aborted (core dumped)

Control: reassign -1 libssl1.1 1.1.0f-1
Control: affects -1 src:simple-tpm-pk11

Looking at the reproducible builds results, I noticed that 
simple-tpm-pk11 always FTBFS in unstable but never FTBFS in stretch.

I confirmed that "make check" always succeeds with libssl1.1 1.1.0e-2 
installed and always fails with 1.1.0f-1 installed.

On Thu, Jun 01, 2017 at 09:55:02AM +0200, Michael Stapelberg wrote:
> Thomas, here are the steps to reproduce using docker. They should be easily
> transferrable to a VM:
> 
> % docker run -t -i debian:sid /bin/bash
> root# echo deb-src http://deb.debian.org/debian sid main >>
> /etc/apt/sources.list
> root# apt update
> root# apt build-dep simple-tpm-pk11
> root# apt source simple-tpm-pk11
> root# cd simple-tpm-pk11-0.06/
> root# dpkg-buildpackage -b
> 
> The backtrace of the coredump is:
> 
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x7f89a890c3fa in __GI_abort () at abort.c:89
> #2  0x55cebe316ca5 in testing::internal::posix::Abort ()
> at /usr/include/gtest/internal/gtest-port.h:2410
> #3  testing::internal::GTestLog::~GTestLog (this=,
> __in_chrg=)
> at /usr/src/gtest/src/gtest-port.cc:923
> #4  0x55cebe33d86d in testing::internal::GTestLog::~GTestLog
> (this=,
> __in_chrg=) at /usr/src/gtest/src/gtest-port.cc:921
> #5
>  testing::internal::ThreadLocal std::allocator > >::~ThreadLocal
> (this=, __in_chrg=)
> at /usr/include/gtest/internal/gtest-port.h:2044
> #6  testing::internal::UnitTestImpl::~UnitTestImpl (this=0x55cebf698e10,
> __in_chrg=) at /usr/src/gtest/src/gtest.cc:4359
> #7  0x55cebe33d979 in testing::internal::UnitTestImpl::~UnitTestImpl
> (this=0x55cebf698e10,
> __in_chrg=) at /usr/src/gtest/src/gtest.cc:4367
> #8  0x55cebe33d461 in testing::UnitTest::~UnitTest (
> this=0x55cebe56d7e0 ,
> __in_chrg=)
> at /usr/src/gtest/src/gtest.cc:4307
> #9  0x7f89a890d910 in __run_exit_handlers (status=0,
> listp=0x7f89a8c715d8 <__exit_funcs>,
> run_list_atexit=run_list_atexit@entry=true, 
> run_dtors=run_dtors@entry=true)
> at exit.c:83
> #10 0x7f89a890d96a in __GI_exit (status=) at exit.c:105
> #11 0x7f89a88f82b8 in __libc_start_main (main=0x55cebe317520  char**)>, argc=1,
> argv=0x7ffe994d5118, init=, fini=,
> rtld_fini=,
> stack_end=0x7ffe994d5108) at ../csu/libc-start.c:325
> #12 0x55cebe3178ba in _start ()
> 
> Any ideas what could cause this?
> 
> On Wed, May 31, 2017 at 4:09 PM, Chris Lamb  wrote:
> 
> > Hi Michael,
> >
> > > Thanks for the report. Do you have a VM in which upstream (Thomas Habets)
> > > could reproduce the failure?
> >
> > I'm inferring from this that you cannot reproduce it yourself? :)
> >
> > I'm not sure I can provide any more details apart from that it also fails
> > on the Reproducible Builds testing framework (as well as my personal laptop
> > from which I submitted my bug report):
> >
> >   https://tests.reproducible-builds.org/debian/rb-pkg/
> > unstable/amd64/simple-tpm-pk11.html
> >
> >
> > Regards,
> >
> > --
> >   ,''`.
> >  : :'  : Chris Lamb
> >  `. `'`  la...@debian.org / chris-lamb.co.uk
> >`-
> >
> 
> 
> 
> -- 
> Best regards,
> Michael

Bug#863290: src:linux: no warning that btrfs RAID5/6 is buggered up

2017-06-04 Thread waxhead




RAID1 actually needs a warning too. It will not work as "classic" RAID1 e.g.
it need to be able to make two copies always to not get stuck in read only mode.
You will not loose your data which is a good thing, but to be safe you need a
minimum of 3 devices (I would prefer four or more to be on the safe side).

Do you mean that btrfs raid1 profile (assume raid1 profile for both
data and metadata) is 2 copies on n devices?  Adding more devices to
the volume does not increase copies or reduce risk; it increases the
size of the volume, but there are still only 2 copies on two different
devices.   As things stand, n-way raid1 profile will not be worked on
until work on raid5/6 profile is in a good state, so many, many years
out.

Ok, I was a bit unclear about this. Let met try to explain.
In RAID1 if you loose one disk for example normal RAID1 remains operational.
BTRFS on the other hand can easily get stuck in read only mode forever.
(explained in detail here : 
https://www.spinics.net/lists/linux-btrfs/msg63370.html )


So what I mean is that if you only have two devices and loose one you 
may end

up with a unwriteable filesystem which is not what people expect.
If you have three devices BTRFS RAID1 will continue to work since it can 
still place

a copy on another drive (thus not creating single chunks).

Now to make matters a tad worse, if you have a drive disappear and 
reappear due to
a controller reset or something other nasty BTRFS does not keep track of 
the device
ID that it use. For example /dev/sdx = id 1, /dev/sdy= id 2 , /dev/sdz = 
id 3. Now let's
pretende that /dev/sdy disappears and reappears as /dev/sdd then idealy 
BTRFS
would know that /dev/sdd now have ID 2. However BTRFS will happily still 
try to write

to /dev/sdy even if the device ID reappeared as another device.

So that is why I say that three or more devices will reduce the risk of 
ending up

in a read only mode.

I hope this was a tad cleared.


I've updated the TODO items at https://wiki.debian.org/Btrfs to
explain this in more depth and will write the new sections when I have
a long enough chunk of free time to streamline the article for
Stretch's release.  If there is anything anyone feels should be on our
btrfs wiki page, please let me know so that I can add it to the queue,
or alternatively add it directly to the TODO items.  Also, if there is
anything in that article that seems like it should be moved to the
upstream wiki I would be happy to do that.

For the Debian wiki I think you should include these links:

BTRFS disk usage/utilization calculator
http://carfax.org.uk/btrfs-usage/

I also think the Debian wiki should simply write a few things about
"supported" configurations that BTRFS will run fine under.

If there is anything I can help out with on the BTRFS wiki page,
I would be happy to volunteer to assist with the documentation
a bit in between other things.


Cheers,
Nicholas

Bug#864183: CVE-2017-6886 CVE-2017-6887

2017-06-04 Thread Moritz Muehlenhoff

Source: libraw
Severity: grave
Tags: security

Please see
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6886
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6887

Cheers,
Moritz

Bug#864182: debhelper: dh_md5sums can fail on packages with many/long conffiles

2017-06-04 Thread Niels Thykier

Package: debhelper
Version: 10.2.5
Severity: minor

I noticed this stackoverflow question: 
https://stackoverflow.com/questions/30185972/dh-md5sums-argument-list-too-long?rq=1

Looking at the code, it appears to still apply to debhelper/10.2.5:

"""
# Check if we should exclude conffiles.
my $exclude="";
if (! $dh{INCLUDE_CONFFILES} && -r "$tmp/DEBIAN/conffiles") {
# Generate exclude regexp.
open(my $fd, '<', "$tmp/DEBIAN/conffiles")
  or die("open $tmp/DEBIAN/conffiles failed: $!");
while (<$fd>) {
chomp;
s/^\///;
$exclude.="! -path \"./$_\" ";
}
close($fd);
}

# See if we should exclude other files.
if (defined($dh{EXCLUDE_FIND}) && $dh{EXCLUDE_FIND} ne '') {
$exclude.="! \\( $dh{EXCLUDE_FIND} \\) ";
}

my $find="find . -type f $exclude ! -regex './DEBIAN/.*' -printf 
'%P\\0'";
complex_doit("(cd $tmp >/dev/null ; $find | LC_ALL=C sort -z | xargs 
-r0 md5sum | " .
  q{perl -pe 'if (s@^@@) { s///g; }' > 
DEBIAN/md5sums) >/dev/null});
"""

Imagine "$tmp/DEBIAN/conffiles" containing 1000 paths of 1000 bytes
each, then we end up with over a million bytes in $exclude[1].  This
is later shoved into a shell, which then chokes on it.

Thanks,
~Niels

[1] Admittedly, this can occur via -X as well, but it seems less
likely to be an issue as the caller of dh_md5sums would probably run
into the issue first.

Bug#864014: Pristine tar for python-pydap is missing

2017-06-04 Thread Ghislain Vaillant

https://anonscm.debian.org/git/debian-science/packages/python-pydap.git/commit/?h=pristine-tar

?

On Sun, 2017-06-04 at 23:14 +0200, Andreas Tille wrote:
> Hi Ghislain,
> 
> see subject.
> 
> Kind regards
> 
>   Andreas.
>

Bug#864181: os-prober: dmraid detection not functional.

2017-06-04 Thread Mike Mestnik

Package: os-prober
Version: 1.75
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here is the code as found in os-prober:17
: >"$OS_PROBER_TMP/dmraid-map"
DMRAID=$(type dmraid >/dev/null 2>&1 || true)
if [ "$DMRAID" ]; then
dmraid -r -c >"$OS_PROBER_TMP/dmraid-map"
fi

The problem is that $DMRAID will always be empty because stdout is redirected.

- -- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (500, 'stable'), (490, 'testing'), (480, 'unstable'), (470, 
'experimental')
Architecture: i386 (x86_64)

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

Versions of packages os-prober depends on:
ii  grub-common  2.02~beta3-5
ii  libc62.24-9

os-prober recommends no packages.

os-prober suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJZNHjXAAoJEOPRqa2O3KuKcVMP/0Ad2IjgqvOCVuQgu3aSmc4P
390JFx8OPEBNh0C8OAEy+1d4EhKi2n50nvMUBy8Kg3iNpKBdwEgTAnGe3P35wkHZ
QKW4deSvHLg0jutuodiLzANTdc7UKGwpF1js3oEB73Yrg1WOyj+0uLGMGnwnu3a7
uYWzuwyZlRaBenMAFD52Uov6zUNo7i/LTUwUIXI4qzGtycHkYVZhLPe6XolnfK/w
BMugsTxWC4a7Y5d0WK/eQn1qEkqaB5NHV3OWgVnzhKqSAZa3ucnSyETAHgp/aJZT
S2+WNsNEC3t1nZdQz5gmzK1bGn6AmmSIS1RMO2n20Ih/e+7gbfbqSo3WETwFuX+o
LGefi+PFp5Jv9524e2T2DTPwfTFfvaes2+L5NFlvWV6oYf2rXLdt6Ky5wWJJBhg6
illjQVOGAwwkbEdB3xlv+zjx91vgrbQKhE2XN2eHcM0xIhd84BEuvnyOBK7BL07Z
PuF0+FfAHNYi/jra6Q+0Ddtuc2QS/tkEJ+kYCn5TU+c6d0265sBCM3lQueNj4Tdz
4lPsd6AHOYL7l03XQ0i0+IifnYWAV97l2oauKToIujaBcTfJ9VoDS++Jik1UrXwE
o9KNQJQ8gq7wRpeKTZr+fmiUulfvXId2ETXXnSTbfJvv2hJJpjtGBnq1jHsWb219
8DgV9lKM1ys/brYwq/NU
=aTuF
-END PGP SIGNATURE-

Bug#864014: Pristine tar for python-pydap is missing

2017-06-04 Thread Andreas Tille

Hi Ghislain,

see subject.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#862371: RFS: budgie-desktop/10.3.1-1

2017-06-04 Thread Tim Dengel

Hi David,

I haven't specifically looked into your issue and the build log doesn't
seem to be available anymore, but it sounds like you're having trouble
with meson being unable to deal with Unicode symbols inside a pbuilder
chroot.
I also have a package that builds with meson and had a FTBFS due to
Unicode support (gnome-twitch), although admittedly it is a much simpler
package than budgie. I fixed my issue by adding LC_ALL=C.UTF-8 in the
d/rules file[0]. Maybe it helps.

[0] https://github.com/dengelt/gnome-twitch/blob/debian/sid/debian/rules


Regards,

Tim


Am 04.06.2017 um 19:46 schrieb foss.freedom:
> Hi Gianfranco,
> 
>   I'm struggling with this - any thoughts on my investigations below.
> 
> On Debian Stretch I've created a chroot for unstable and installed the
> build dependencies for budgie-desktop + locales + meson
> 
> In debian/rules I've changed the two export LANG and LANGUAGE vars to
> en_US.UTF-8
> 
> Then manually (in the chroot) I have run the following:
> 
> debconf-set-selections <<< 'locales locales/default_environment_locale
> select en_US.UTF-8'
> 
> dpkg-reconfigure locales
> 
> update-locale LANGUAGE='en_US.UTF-8'
> 
> N.B. the debconf-set-selections is to ensure dpkg-reconfigure locales
> runs without the user having to manually select en_US.UTF-8 to the two
> questions asked.
> 
> That's enough to convince the dpkg-buildpackage -us -uc to work
> correctly within the chroot
> 
> The question I have is how to tuck the three commands above into the
> Debian package to run before the main meson callout in debian/rules ?
> i.e. I'm hoping this is the answer how to get the Debian build system
> to default to a UTF-8 locale.
> 
> I added the three commands within override_dh_auto_configure: but I
> get a "sh:1  Syntax error: redirection unexpected" - so I'm kind of
> stuck on how to move forward.
> 
> I was hoping to find an existing Debian package that uses meson
> building Vala within the archives to see how the maintainer did
> something similar but my Google-fu has failed to find such a package
> :(
> 
> David
> 
> 
> On 12 May 2017 at 19:09, foss.freedom  wrote:
>> Thanks Gianfranco for the review.  Much appreciated.
>>
>> I have completely redone the licenses and files in debian/copyight and
>> double checked via "check-all-the-things"
>>
>> For the .install files - all debian/tmp has been removed.
>>
>> the FTBFS is concerning.  I don't understand why there is a difference
>> between the build systems of launchpad (it works) and Debian (it
>> doesnt).
>>
>> I asked this question here -
>> https://github.com/budgie-desktop/budgie-desktop/issues/921
>>
>> The advice is to ensure the environment variables LANG and LANGUAGE is
>> set to en_US - I've added two export lines for these environment vars
>> at the top of the debian/rules
>>
>> I've tested the rules changes on launchpad.  However I dont have
>> access to the debian build system so I cannot verify.
>>
>> I have rebuilt on my debian stretch VM and this is OK.
>>
>> David
>>
>> On 11 May 2017 at 22:27, Gianfranco Costamagna  
>> wrote:
>>> control: owner -1 !
>>> control: tags -1 moreinfo
>>>
>>> Hello, I will sponsor it,
>>> but please have a deep look at missing copyrights for a next upload, e.g.
>>> + * Copyright (C) 2017 taaem 
>>>
>>>
>>> other things:
>>> I don't understand why you prepended debian/tmp to install files, but as 
>>> you wish
>>>
>>> 2) FTBFS
>>> http://debomatic-amd64.debian.net/distribution#experimental/budgie-desktop/10.3.1-1/buildlog
>>>
>>> G.
>

Bug#864083: unblock: libgcrypt20/1.7.6-2

2017-06-04 Thread Cyril Brulebois

Cyril Brulebois  (2017-06-04):
> I'm missing cryptsetup test cases right now, so I can't tell in a few
> minutes. I'll try to add one and/or run this manually on monday, but
> not making any promises. At some point, late requests will need to be
> punted for r1. Especially given the current amount and the timing
> getting tighter and tighter.

I actually managed to get that on today's schedule: I had a playbook for
full images (but none for netboot-gtk yet), and after some tweaks I've
confirmed a basic encrypted LVM setup with default encryption settings
still works fine with an updated libgcrypt20-udeb.

ACK.


KiBi.


signature.asc
Description: Digital signature

Bug#863927: qtwebengine-opensource-src: FTBFS: memory exhausted

On Sat, Jun 03, 2017 at 09:33:38PM +0200, Sandro Knauß wrote:
> Hey,
> 
> > No, the fix would be to not produce 1 GB of debug info for this library:
> 
> > The build log [1] confirms that -g is used in the i386 build.
> > 
> > -g0 instead of -g (or no -g option) would surely solve this problem.
> > 
> > -g1 would likely be sufficient to fix the problem on i386,
> > while still providing enough debug information for backtraces.
> > 
> > A similar -g0/-g1 fix could also fix the armhf and mipsel builds (untested).
> 
> interessting point and a year ago I also ask for ideas and nothing came. I 
> tested a lot to get it building on other platforms without success. At the 
> moment I'm hardy using my computer, so I can't test it at the moment, sorry.

I found the problem:
The -g is coming from dpkg-buildflags.

Below is the smallest patch I see for this, a proper reshuffle of the 
debug settings in debian/rules looked too heavy so near to the release.

Could you upload this, or can I do an NMU?

> Best Regards,
> 
> sandro

cu
Adrian


--- qtwebengine-opensource-src-5.7.1+dfsg/debian/rules  2017-01-18 
20:00:38.0 +0200
+++ qtwebengine-opensource-src-5.7.1+dfsg/debian/rules  2017-06-04 
22:12:35.0 +0300
@@ -6,16 +6,22 @@
 export NINJAFLAGS=-v
 include /usr/share/dpkg/default.mk
 
-export CFLAGS := $(shell dpkg-buildflags --get CFLAGS) $(shell dpkg-buildflags 
--get CPPFLAGS)
-export CXXFLAGS := $(shell dpkg-buildflags --get CXXFLAGS) $(shell 
dpkg-buildflags --get CPPFLAGS)
+DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
+DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+
+# TODO: properly integrate with the other debug setting for buster
+ifneq (,$(filter $(DEB_HOST_ARCH), armel armhf i386 mips mipsel))
+   export CFLAGS := $(shell dpkg-buildflags --get CFLAGS) $(shell 
dpkg-buildflags --get CPPFLAGS) -g1
+   export CXXFLAGS := $(shell dpkg-buildflags --get CXXFLAGS) $(shell 
dpkg-buildflags --get CPPFLAGS) -g1
+else
+   export CFLAGS := $(shell dpkg-buildflags --get CFLAGS) $(shell 
dpkg-buildflags --get CPPFLAGS)
+   export CXXFLAGS := $(shell dpkg-buildflags --get CXXFLAGS) $(shell 
dpkg-buildflags --get CPPFLAGS)
+endif
 export LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS) -Wl,--as-needed
 export QT_SELECT := qt5
 
 VERSION_CLEAN_UPSTREAM = $(call dpkg_late_eval,VERSION_CLEAN_UPSTREAM,echo 
'$(DEB_VERSION_UPSTREAM)' | sed -e 's/\(~\|+\).*//')
 
-DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
-
 gstab_architectures :=
 fulldebug_architectures :=
 disabled_jit_architectures := armel mips mipsel

Bug#864180: openjdk-8: Please update the patch for m68k support

2017-06-04 Thread John Paul Adrian Glaubitz

Source: openjdk-8
Version: 8u131-b11-2
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

openjdk-8 on m68k currently fails to build from source on m68k because
the current patch for m68k support is broken. With the old patch, the
generated JVM just hangs forever when trying to execute any Java
commands, for example "javac".

The attached patch comes directly from Andreas Schwab who is using it
to build openjdk-8 on openSUSE/m68k. The patch applies with some fuzz
but otherwise fine. Although, the original patch contained a few
changes to icedtea-sound which I had to remove as otherwise the patch
wouldn't apply. However, openjdk-8 builds fine on m68k with the updated
patch, provided that the jvmtidocs target is disabled as it eats up
all the heap space. I'll send a second patch for that.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Index: jdk8u-c684352da3e3/common/autoconf/generated-configure.sh
===
--- jdk8u-c684352da3e3.orig/common/autoconf/generated-configure.sh
+++ jdk8u-c684352da3e3/common/autoconf/generated-configure.sh
@@ -6883,6 +6883,12 @@ test -n "$target_alias" &&
   VAR_CPU_BITS=64
   VAR_CPU_ENDIAN=big
   ;;
+m68k)
+  VAR_CPU=m68k
+  VAR_CPU_ARCH=m68k
+  VAR_CPU_BITS=32
+  VAR_CPU_ENDIAN=big
+  ;;
 *)
   as_fn_error $? "unsupported cpu $build_cpu" "$LINENO" 5
   ;;
@@ -7026,6 +7032,12 @@ $as_echo "$OPENJDK_BUILD_OS-$OPENJDK_BUI
   VAR_CPU_BITS=64
   VAR_CPU_ENDIAN=big
   ;;
+m68k)
+  VAR_CPU=m68k
+  VAR_CPU_ARCH=m68k
+  VAR_CPU_BITS=32
+  VAR_CPU_ENDIAN=big
+  ;;
 *)
   as_fn_error $? "unsupported cpu $host_cpu" "$LINENO" 5
   ;;
Index: jdk8u-c684352da3e3/common/autoconf/platform.m4
===
--- jdk8u-c684352da3e3.orig/common/autoconf/platform.m4
+++ jdk8u-c684352da3e3/common/autoconf/platform.m4
@@ -102,6 +102,12 @@ AC_DEFUN([PLATFORM_EXTRACT_VARS_FROM_CPU
   VAR_CPU_BITS=64
   VAR_CPU_ENDIAN=big
   ;;
+m68k)
+  VAR_CPU=m68k
+  VAR_CPU_ARCH=m68k
+  VAR_CPU_BITS=32
+  VAR_CPU_ENDIAN=big
+  ;;
 *)
   AC_MSG_ERROR([unsupported cpu $1])
   ;;
Index: 
jdk8u-c684352da3e3/hotspot/src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp
===
--- 
jdk8u-c684352da3e3.orig/hotspot/src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp
+++ 
jdk8u-c684352da3e3/hotspot/src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp
@@ -38,7 +38,7 @@
  * __m68k_cmpxchg
  *
  * Atomically store newval in *ptr if *ptr is equal to oldval for user space.
- * Returns newval on success and oldval if no exchange happened.
+ * Returns oldval on success and *ptr if no exchange happened.
  * This implementation is processor specific and works on
  * 68020 68030 68040 and 68060.
  *
@@ -62,40 +62,48 @@ static inline int __m68k_cmpxchg(int old
 static inline int m68k_compare_and_swap(volatile int *ptr,
 int oldval,
 int newval) {
+  int prev = *ptr;
   for (;;) {
-  int prev = *ptr;
+  int newprev;
   if (prev != oldval)
 return prev;
 
-  if (__m68k_cmpxchg (prev, newval, ptr) == newval)
+  newprev = __m68k_cmpxchg (prev, newval, ptr);
+  if (newprev == prev)
 // Success.
 return prev;
 
   // We failed even though prev == oldval.  Try again.
+  prev = newprev;
 }
 }
 
 /* Atomically add an int to memory.  */
 static inline int m68k_add_and_fetch(volatile int *ptr, int add_value) {
+  int prev = *ptr;
   for (;;) {
   // Loop until success.
+  int newprev;
 
-  int prev = *ptr;
-
-  if (__m68k_cmpxchg (prev, prev + add_value, ptr) == prev + add_value)
+  newprev = __m68k_cmpxchg (prev, prev + add_value, ptr);
+  if (newprev == prev)
 return prev + add_value;
+  prev = newprev;
 }
 }
 
 /* Atomically write VALUE into `*PTR' and returns the previous
contents of `*PTR'.  */
 static inline int m68k_lock_test_and_set(volatile int *ptr, int newval) {
+  int prev = *ptr;
   for (;;) {
   // Loop until success.
-  int prev = *ptr;
+  int newprev;
 
-  if (__m68k_cmpxchg (prev, newval, ptr) == prev)
+  newprev = __m68k_cmpxchg (prev, newval, ptr);
+  if (newprev == prev)
 return prev;
+  prev = newprev;
 }
 }
 #endif // M68K
Index: jdk8u-c684352da3e3/hotspot/src/share/vm/memory/allocation.hpp
===
--- jdk8u-c684352da3e3.orig/hotspot/src/share/vm/memory/allocation.hpp
+++

Bug#861734: gcc-7 fails to build gnattools on armel

Package: src:gcc-7
Followup-For: Bug #861734

Please build the native gnat on armel by reverting
svn://anonscm.debian.org/gcccvs/branches/sid/gcc-7@9434 
6ca36cf4-e1d1-0310-8c6f-e303bb2178ca
Since then, the link step for the tools has changed a lot, and a
recent build log would be more helpful. Moreover, --as-needed -z,defs
have been added to libgnat linker options, and should help locating
the problem.

Bug#864055: (no subject)

2017-06-04 Thread kuLa

1st of all I agree that we should be as close to the default Debian image as we
can and we should generate those host keys as well.

I don't think I'll be able to do much work before Stretch release, so I'm even
less confident that I should ask for freeze exception.
But I'm pretty sure we can push patched version after Stretch release with
proposed-updates.

Anyway thx for filling the bug and I'll try what I can to push it asap.
-- 

|_|0|_|  |
|_|_|0|  "Panta rei" |
|0|0|0|  kuLa    |

gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3
3DF1  A4DF  C732  4688  38BC  F121  6869  30DD  58C3  38B3


signature.asc
Description: PGP signature

Bug#864144: e2fsprogs strangeness about mips* multilibs

2017-06-04 Thread James Cowgill

Hi,

On 04/06/17 20:51, Helmut Grohne wrote:
> Hi Ted,
> 
> On Sun, Jun 04, 2017 at 02:46:08PM -0400, Theodore Ts'o wrote:
>> I'm going to confess complete ignorance to what's going on with mips.
>> In the past my modus operandi is that I would make changes in response
>> to requests to the MIPS porters, in some cases with incomplete
>> understand why they were needed in the first place.
>>
>> My bias would be to remove *all* of the mips specific exceptions in
>> the debian directory, and then see if things still build on mips, and
>> if there are any known problems caused by the mips installer or mips
>> bootpath.  And if we do need to add back any exceptions for the MIPS
>> architecture, let's make sure it's very clearly documented why they
>> are there.  Because at the moment, I'm a bit embarassed at my
>> inability to answer your perfectly reasonable questions.  :-)
> 
> I think the approach is reasonable. I did put
> debian-m...@lists.debian.org into X-Debbugs-Cc for this reason and am
> full quoting your reply to that list now to have them object.

From what I can tell, the only purpose of the extra mips libraries is to
support some old bootloaders/firmware - arcboot being the only package I
know which used this. No "normal" packages in the archive would have
been able to use them unless they were statically linked. Since arcboot
was removed, I think it should be safe to remove these special libraries
from e2fsprogs.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#856274: removal of ada-gcc-name patch causes build failures for non default gnat builds

Package: gnat-5,gnat-6,gnat-7
Followup-For: Bug #856274

The workaround for 814978 is a symbolic link
  /usr/bin/gcc-7-7 -> gcc-7
Is it still required?

Bug#864060: minetest: Please package the new upstream version 0.4.16

2017-06-04 Thread Martin Quinson

Hello Markus,

On Sat, Jun 03, 2017 at 10:16:16PM +0200, Markus Koschany wrote:
> Am 03.06.2017 um 22:08 schrieb Martin Quinson:
> > Package: minetest
> > Version: 0.4.15+repack2-1
> > Severity: normal
> > 
> > Hello people,
> > 
> > The new version of minetest was released today. I think we should package 
> > it as
> > soon as the current freeze period is over. I'm filling this bug to not 
> > forget
> > about it.
> 
> Hey Martin,
> 
> I volunteer to package the new version because I'm about to start a new
> Minetest world on my private server and some players asked me to do
> that. I probably can do that in the course of the upcoming week.

You'd be more than welcome because I don't use minetest that much
nowadays, and I'm rather short on time right now. Thanks!

> However feel free to fix the next bug / package the next version. :)

Ok, will see how things come. Someone will have to backport the 0.4.16
to stretch after the release, too. I'm not sure I know how to do it,
actually.

Bye, Mt.

-- 
Quand on a du blé plein ses étables, on prend vite des réflexes de veau.
Faire l'aumone au bon misérable plutôt que de payer des impots, 
et traiter les profs d'incapables en laissant l'école prendre l'eau.
   -- Les malpolis


signature.asc
Description: PGP signature

Bug#672435: x11vnc: Option -localhost seems to fail to restrict ipv6 access

2017-06-04 Thread Moritz Mühlenhoff

On Sat, Apr 02, 2016 at 08:43:34PM +0200, Thomas Braun wrote:
> tags 672435 security
> thanks
> 
> On Fri, 11 May 2012 11:12:46 +0900 Ryo IGARASHI  wrote:
> > Today I found that the option -localhost does not restrict ipv6 access to 
> > ::1(localhost).
> > Looking at the -localhost option section of 'man x11vnc', the ipv6 access 
> > seems to
> > be restricted to ::1 (loopback) as well. However, the output of 'netstat 
> > -ln' shows:
> > 
> > $ netstat -ln
> > Proto Recv-Q Send-Q Local Address   Foreign Address State
> > ...
> > tcp6   0  0 :::5900 :::*LISTEN
> > ...
> 
> I've just verified that bug with the current version in jessie.
> 
> x11vnc -localhost -create
> 
> netstat -lntp | grep 5900
> 
> tcp0  0 127.0.0.1:5900  0.0.0.0:*   LISTEN
>   -
> tcp6   0  0 :::5900 :::*LISTEN
>   -
> 
> The manpage states 
> 
> -localhost
> [...]
> IPv6: if IPv6 is supported, this option automatically implies the IPv6 
> loopback address '::1' as well.
> 
> This bug should be treated as a SECURITY relevant bug. Offering VNC services 
> on the network interface while claiming that it is only accessible via 
> loopback is really bad.

In the absence of a proper code fix, this could at least be properly documented
for the upcoming stretch release?

Cheers,
Moritz

Bug#862576: etoys: Doesn't get beyond Squeak security key generation

2017-06-04 Thread Petter Reinholdtsen

This issue is going to cause etags to be removed from Stretch.  Anyone have any 
idea what is wrong?
-- 
Happy hacking
Petter Reinholdtsen

Bug#863290: src:linux: no warning that btrfs RAID5/6 is buggered up

2017-06-04 Thread Nicholas D Steeves

On 4 June 2017 at 05:46, Svein Engelsgjerd  wrote:
>
> I would like voice my concern as well. Btrfs RAID5/6 really needs a warning.
> These days most (if not all) of the problems you see with Btrfs is caused by
> the unstable features (https://btrfs.wiki.kernel.org/index.php/Status).
>
> RAID5/6 in kernel 4.9 is less than stellar and should absolutely not be used
> for anything except testing and experimentation.

+1 It's been well known that it causes problems since before
2016-06-26, and the consensus on the upstream btrfs mailing list is
that in the absence of an unexpected and heroic feat reliable raid5/6
profile is years away from completion.

> RAID1 actually needs a warning too. It will not work as "classic" RAID1 e.g.
> it need to be able to make two copies always to not get stuck in read only 
> mode.
> You will not loose your data which is a good thing, but to be safe you need a
> minimum of 3 devices (I would prefer four or more to be on the safe side).

Do you mean that btrfs raid1 profile (assume raid1 profile for both
data and metadata) is 2 copies on n devices?  Adding more devices to
the volume does not increase copies or reduce risk; it increases the
size of the volume, but there are still only 2 copies on two different
devices.   As things stand, n-way raid1 profile will not be worked on
until work on raid5/6 profile is in a good state, so many, many years
out.

I've updated the TODO items at https://wiki.debian.org/Btrfs to
explain this in more depth and will write the new sections when I have
a long enough chunk of free time to streamline the article for
Stretch's release.  If there is anything anyone feels should be on our
btrfs wiki page, please let me know so that I can add it to the queue,
or alternatively add it directly to the TODO items.  Also, if there is
anything in that article that seems like it should be moved to the
upstream wiki I would be happy to do that.

Cheers,
Nicholas

Bug#862053: marked as pending

2017-06-04 Thread Moritz Mühlenhoff

On Wed, May 24, 2017 at 08:40:57PM +, Craig Small wrote:
> tag 862053 pending
> thanks
> 
> Hello,
> 
> Bug #862053 reported by you has been fixed in the Git repository. You can
> see the changelog below, and you can check the diff of the fix at:

Hi Craig,
since the window for stretch is closing, could you please upload
a targeted fix for sid to get unblocked by the release team?

Cheers,
Moritz

Bug#856274: removal of ada-gcc-name patch causes build failures for non default gnat builds

Package: gnat-5,gnat-6,gnat-7
Followup-For: Bug #856274

>From this bug log and title, it is not clear for me whether
7-20170314-1 fixes the issue: ada-gcc-name.diff modifies gnatmake so
that it calls gcc-BV.

Are the other problems with tests fixed by these changes?

Should this bug be closed because the packages do not FTBFS anymore,
or track the upstream feature request at https://gcc.gnu.org/PR79724?

Bug#864179: synaptic: Message appears:"W: Download is performed unsandboxed as root as file '/root/.synaptic/tmp//tmp_sh' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permiso denegado)"

2017-06-04 Thread ajandromi

Package: synaptic
Version: 0.84.2
Severity: normal

Dear Maintainer,

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

   This message appears in synaptic after installing anything

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


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

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

Versions of packages synaptic depends on:
ii  hicolor-icon-theme   0.15-1
ii  libapt-inst2.0   1.4.6
ii  libapt-pkg5.01.4.6
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-10
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libept1.5.0  1.1+nmu3+b1
ii  libgcc1  1:6.3.0-18
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgnutls30  3.5.8-5
ii  libgtk-3-0   3.22.11-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpcre2-8-0 10.22-3
ii  libstdc++6   6.3.0-18
ii  libvte-2.91-00.46.1-1
ii  libx11-6 2:1.6.4-3
ii  libxapian30  1.4.3-2
ii  policykit-1  0.105-17
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages synaptic recommends:
ii  libgtk2-perl   2:1.2499-1
ii  rarian-compat  0.8.1-6+b1
ii  xdg-utils  1.1.1-1

Versions of packages synaptic suggests:
pn  apt-xapian-index 
pn  deborphan
pn  dwww 
pn  menu 
pn  software-properties-gtk  
ii  tasksel  3.39

-- no debconf information

Bug#864144: e2fsprogs strangeness about mips* multilibs

2017-06-04 Thread Helmut Grohne

Hi Ted,

On Sun, Jun 04, 2017 at 02:46:08PM -0400, Theodore Ts'o wrote:
> I'm going to confess complete ignorance to what's going on with mips.
> In the past my modus operandi is that I would make changes in response
> to requests to the MIPS porters, in some cases with incomplete
> understand why they were needed in the first place.
> 
> My bias would be to remove *all* of the mips specific exceptions in
> the debian directory, and then see if things still build on mips, and
> if there are any known problems caused by the mips installer or mips
> bootpath.  And if we do need to add back any exceptions for the MIPS
> architecture, let's make sure it's very clearly documented why they
> are there.  Because at the moment, I'm a bit embarassed at my
> inability to answer your perfectly reasonable questions.  :-)

I think the approach is reasonable. I did put
debian-m...@lists.debian.org into X-Debbugs-Cc for this reason and am
full quoting your reply to that list now to have them object.

> Does that seem reasonable?  Are you willing to work with me to figure
> out whether such a plan is going to cause problems with the installer
> team, et. al?  And I assume that because we're just about to release
> Debian stable, this is really a post stretch activity, yes?  Or is the
> current state sufficient undesirable that it rises to the level of
> release critical?  (I don't think so, but I'm willing to be
> pursuaded.)

I actually thought that severity wishlist would have made it perfectly
clear that this is intended post-stretch, but I can spell it out
explicitly: No, I didn't expect this to be fixed in stretch.

The context of my work is making Debian cross buildable and
bootstrappable. Preferably, reproducibly. At least for the first part we
know roughly 1300 packages are cross buildable. So this bug really is a
drop in the bucket.

So let's give d-mips@l.d.o time to object until stretch is released.

Helmut

Bug#857831: gcc build in gnattools apparently not safe for parallel builds

Package: src:gcc-7
Followup-For: Bug #857831
Control: tags -1 + patch

The attached patch fixes the new race condition introduced by previous
attempt.
--- a/debian/patches/ada-gnattools-cross.diff
+++ b/debian/patches/ada-gnattools-cross.diff
@@ -247,23 +247,28 @@ Index: b/src/gnattools/Makefile.in
  	"exeext=$(exeext)" \
  	"fsrcdir=$(fsrcdir)" \
  	"srcdir=$(fsrcdir)" \
-@@ -192,12 +199,18 @@
+@@ -190,6 +199,10 @@
+ # to be able to build gnatmake without a version of gnatmake around. Once 
+ # everything has been compiled once, gnatmake can be recompiled with itself 
  # (see target regnattools) 
++gnattools-native: export LD_LIBRARY_PATH := \
++  '$(if $(LD_LIBRARY_PATH),$(LD_LIBRARY_PATH):)$(vsndir):$(rtsdir)'
++# Useful even for 1st pass, as ../../gnatmake may already be
++# dynamically linked in case this target has already been invokated.
  gnattools-native: $(GCC_DIR)/stamp-tools $(GCC_DIR)/stamp-gnatlib-rts
  	# gnattools1
-+# The export is necessary in case the target is run twice.
-+	LD_LIBRARY_PATH='$(if $(LD_LIBRARY_PATH),$(LD_LIBRARY_PATH):)$(vsndir):$(rtsdir)' \
  	$(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
- 	  $(TOOLS_FLAGS_TO_PASS_NATIVE) \
- 	  ../../gnatmake$(exeext) ../../gnatlink$(exeext)
+@@ -198,6 +211,13 @@
  	# gnattools2
+ 	$(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
+ 	  $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools
 +# The hard-coded object lists for gnatbind/make/link contain unneeded
 +# objects. Use the fresh tools to recompute dependencies.
-+	LD_LIBRARY_PATH='$(if $(LD_LIBRARY_PATH),$(LD_LIBRARY_PATH):)$(vsndir):$(rtsdir)' \
- 	$(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
--	  $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools
-+	  $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools \
-+	  gnatbind-re gnatmake-re gnatlink-re
++# A separate Make run avoids race conditions between gnatmakes
++# building the same object for common-tools and gnat*-re.
++# (parallelism is already forbidden between gnat*-re targets)
++	$(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
++	  $(TOOLS_FLAGS_TO_PASS_NATIVE) gnatbind-re gnatmake-re gnatlink-re
  
  # gnatmake/link can be built with recent gnatmake/link if they are available.
  # This is especially convenient for building cross tools or for rebuilding

Bug#806481: [pkg-go] Bug#806481: Backport etcd to Stretch

2017-06-04 Thread Potter, Tim

On 5 Jun 2017, at 5:17 am, Christoph Berg  wrote:
> 
> Re: Matthew Dawson 2015-11-28 <1478545.P9uMUQs38u@cwmtaff>
>> On November 28, 2015 03:14:16 PM Dmitry Smirnov wrote:
>>> On Friday 27 November 2015 21:56:36 Paul Tagliamonte wrote:
 Mind if I do it?
>>> 
>>> Not at all, if you have time... I have no objections. :)
>>> 
 After it's in Jessie, it might be easier to keep up to date, too.
>>> 
>>> Unfortunately I can't promise that I will be of help with maintaining
>>> backport...
>> Hi Paul,
>> 
>> If I can help with this effort, let me know as I'm also interested in having 
>> etcd in Jessie.  I already started trying to get everything to compile 
>> against 
>> a stock Jessie, and was mostly successful.  To get everything working did 
>> require a newer golang (1.4 in my case).  I'm not currently a Debian project 
>> member, so I'm not sure how I can help.  Let me know either way.
> 
> It looks like etcd won't be part of stretch either - is anyone looking
> into backporting it?

There have been conversations with the security team about supporting Go
applications but they are not comfortable with it due to the compile-time 
nature of the packaging.  

If there is a CVE in package X you need to recompile and upload everything
that Build-Depends on X.  Maintainers will also need to recompile and upload
everything that B-D's on the B-Ds as it's not transitive.

There is a plan somewhere to move to creating shared libraries instead of
packaging source code in -dev debs and I may get around to doing this during
the Buster cycle.  It's only relatively recently that this feature was 
available in
Go and in Debian.

Tim.

> 
> Christoph
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#864040: Remove "1.4. What is Debian GNU/kFreeBSD?" ?

2017-06-04 Thread Holger Wansing

Control: tags -1 + pending

Adrian Bunk  wrote:
> Package: src:installation-guide
> Version: 20170525
> Severity: minor
> 
> No kFreeBSD port is part of stretch, does it make sense to describe it?
> 
> Like with Hurd, it would IMHO be better not to discuss
> non-release ports here.

I set 'condition="unofficial-build"' for that chapter (as it is for hurd), so 
it does not appear in official manual, but the content and translations still
remain in the tree.

Thanks

-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#864178: fsl-5.0-core: depends on no longer available fslview

Package: fsl-5.0-core
Version: 5.0.8-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

The following packages have unmet dependencies:
 fsl-5.0-core : Depends: fslview but it is not installable

fslview has been removed from the archive, see
https://bugs.debian.org/861330 for details.


Cheers,

Andreas

Bug#806481: Backport etcd to Stretch

2017-06-04 Thread Christoph Berg

Re: Matthew Dawson 2015-11-28 <1478545.P9uMUQs38u@cwmtaff>
> On November 28, 2015 03:14:16 PM Dmitry Smirnov wrote:
> > On Friday 27 November 2015 21:56:36 Paul Tagliamonte wrote:
> > > Mind if I do it?
> > 
> > Not at all, if you have time... I have no objections. :)
> > 
> > > After it's in Jessie, it might be easier to keep up to date, too.
> > 
> > Unfortunately I can't promise that I will be of help with maintaining
> > backport...
> Hi Paul,
> 
> If I can help with this effort, let me know as I'm also interested in having 
> etcd in Jessie.  I already started trying to get everything to compile 
> against 
> a stock Jessie, and was mostly successful.  To get everything working did 
> require a newer golang (1.4 in my case).  I'm not currently a Debian project 
> member, so I'm not sure how I can help.  Let me know either way.

It looks like etcd won't be part of stretch either - is anyone looking
into backporting it?

Christoph


signature.asc
Description: PGP signature

Bug#864176: fex: broken symlinks: /usr/share/fex/bin/*

Package: fex
Version: 20160919-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

4m29.1s ERROR: FAIL: Broken symlinks:
  /usr/share/fex/htdocs/download/sex.stream -> :sexsend:sexget:
  /usr/share/fex/bin/sexsend -> ../htdocs/download/sexsend
  /usr/share/fex/bin/sexget -> ../htdocs/download/sexget
  /usr/share/fex/bin/fexget -> ../htdocs/download/fexget


cheers,

Andreas


fex_20160919-1.log.gz
Description: application/gzip

Bug#864175: otrs2: broken symlink: /var/lib/otrs/httpd/htdocs/js/thirdparty/jquery-ui -> /usr/share/javascript/jquery-ui

Package: otrs2
Version: 5.0.19-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

10m39.4s ERROR: FAIL: Broken symlinks:
  /var/lib/otrs/run -> /run/otrs
  /var/lib/otrs/httpd/htdocs/js/thirdparty/jquery-ui -> 
/usr/share/javascript/jquery-ui
  /usr/share/otrs/Kernel/Config/GenericAgent.pm -> 
/etc/otrs/Kernel/Config/GenericAgent.pm

The first and third broken link are probably ok, but the second
looks like a missing dependency on libjs-jquery-ui.


cheers,

Andreas


otrs2_5.0.19-1.log.gz
Description: application/gzip

Bug#864174: RFS: wallpaperdownloader/2.7-1 [ITP] -- Download wallpapers from the Internet and more

2017-06-04 Thread Eloy García Almadén

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for my package "wallpaperdownloader":

 * Package name: wallpaperdownloader
   Version : 2.7-1
   Upstream Author : Eloy García Almadén 
 * URL : https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader
 * License : GPL-3
   Section : misc

  What is WallpaperDownloader? What can it do for you?

  Ok, lets see: Are you bored with the set of the default wallpapers which come
with your desktop environment? Are you tired of wasting time going to different
web sites to search and download wallpapers of your taste?. WallpaperDownloader
is a graphical tool to automate this workflow. It is Java based and is as easy
as typing the keywords you want to use to search for your favorite wallpapers,
select the providers you want to dig in and you are done! WallpaperDownloader
will search and download those wallpapers for you periodically and you will be
able to set them as favorite, remove those you don't like or just ignore them
to randonmly be replaced.

  It supports different Desktop Environments (currently MATE, XFCE, GNOME
Shell, Plasma 5.8 and greater and Unity), so you can change the wallpaper
directly from the application when you want or schedule a background process to
do it for you.

  WallpaperDownloader is currently packaged in AUR for Arch Linux users
(https://aur.archlinux.org/packages/wallpaperdownloader/) and as a snap package
in the Ubuntu Store (https://uappexplorer.com/app/wallpaperdownloader.egarcia)
but I would like to publish the application in Debian's repository because it
works better natively (snap packages are great but some functionalities don't
work at all) and Debian is one of the most respected, long-lived distributions
out there.

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

  https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader/wiki/Home

  Regards,
  Eloy García Almadén



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

Kernel: Linux 4.9.0-3-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)

Bug#863472: unblock: openssl/1.1.0f-1

2017-06-04 Thread Kurt Roeckx

On Sun, Jun 04, 2017 at 06:53:29PM +0200, Cyril Brulebois wrote:
> Kurt Roeckx  (2017-06-04):
> > So I changed it this instead:
> > dh_makeshlibs -a -V --add-udeb="libcrypto1.1-udeb" -Xengines
> > 
> > the shlib files now looks like:
> > libcrypto 1.1 libssl1.1 (>= 1.1.0f)
> > libssl 1.1 libssl1.1 (>= 1.1.0f)
> > udeb: libcrypto 1.1 libcrypto1.1-udeb (>= 1.1.0f)
> > udeb: libssl 1.1 libssl1.1-udeb (>= 1.1.0f)
> > 
> > Since we have symbol files, this does not affect non-udeb
> > packages.
> 
> As discussed on IRC (#debian-devel), the earlier syntax (-V with a
> version) was fine, and more accurate as it only needs to be bumped
> when symbols change. However, using -V without a specific version
> should get us updated dependencies every time; they might be stricter
> than needed, but that's better than forgetting about bumping the
> version IMHO, so fine with me.

So I've uploaded openssl 1.1.0f-2 and openssl1.0 1.0.2l-2


Kurt

Bug#864173: check_backuppc does not compile

2017-06-04 Thread Peter Palfrader

Package: nagios-plugins-contrib
Version: 21.20170222
Severity: important
Tags: patch

} root@ajax:~# sudo -u backuppc /usr/lib/nagios/plugins/check_backuppc -H ajax
} Global symbol "%ERRORS" requires explicit package name (did you forget to 
declare "my %ERRORS"?) at /usr/lib/nagios/plugins/check_backuppc line 99.
} Global symbol "%ERRORS" requires explicit package name (did you forget to 
declare "my %ERRORS"?) at /usr/lib/nagios/plugins/check_backuppc line 123.
} Global symbol "%ERRORS" requires explicit package name (did you forget to 
declare "my %ERRORS"?) at /usr/lib/nagios/plugins/check_backuppc line 124.
} Global symbol "%ERRORS" requires explicit package name (did you forget to 
declare "my %ERRORS"?) at /usr/lib/nagios/plugins/check_backuppc line 129.
} Global symbol "%ERRORS" requires explicit package name (did you forget to 
declare "my %ERRORS"?) at /usr/lib/nagios/plugins/check_backuppc line 137.
} Global symbol "%ERRORS" requires explicit package name (did you forget to 
declare "my %ERRORS"?) at /usr/lib/nagios/plugins/check_backuppc line 147.
} Global symbol "%ERRORS" requires explicit package name (did you forget to 
declare "my %ERRORS"?) at /usr/lib/nagios/plugins/check_backuppc line 177.
} Global symbol "%ERRORS" requires explicit package name (did you forget to 
declare "my %ERRORS"?) at /usr/lib/nagios/plugins/check_backuppc line 240.
} Global symbol "%ERRORS" requires explicit package name (did you forget to 
declare "my %ERRORS"?) at /usr/lib/nagios/plugins/check_backuppc line 260.
} Global symbol "%ERRORS" requires explicit package name (did you forget to 
declare "my %ERRORS"?) at /usr/lib/nagios/plugins/check_backuppc line 286.
} Execution of /usr/lib/nagios/plugins/check_backuppc aborted due to 
compilation errors.
} root@ajax:~# 

This makes it work for me:

root@ajax:~# diff -u ./check_backuppc /usr/lib/nagios/plugins/check_backuppc 
--- ./check_backuppc2017-06-04 20:51:45.838141051 +0200
+++ /usr/lib/nagios/plugins/check_backuppc  2017-06-04 20:52:07.342331799 
+0200
@@ -32,28 +32,7 @@
 
 # Nagios
 use lib "/usr/lib/nagios/plugins";
-sub load_module {
-my @names = @_;
-my $module;
-for my $name (@names) {
-my $file = $name;
-# requires need either a bare word or a file name
-$file =~ s{::}{/}gsxm;
-$file .= '.pm';
-eval {
-require $file;
-$name->import(qw(%ERRORS));
-$module = $name;
-   };
-   last if $module;
-}
-return $module;
-}
-
-my $plugin_module;
-BEGIN {
-   $plugin_module = load_module( 'Monitoring::Plugin', 'Nagios::Plugin' );
-}
+use utils qw(%ERRORS);
 use POSIX qw(strftime difftime);
 use Getopt::Long;
 Getopt::Long::Configure('bundling');

} root@ajax:~# sudo -u backuppc /usr/lib/nagios/plugins/check_backuppc -H ajax
} BACKUPPC OK - (0/1) failures


Cheers,

Bug#864144: e2fsprogs strangeness about mips* multilibs

2017-06-04 Thread Theodore Ts'o

On Sun, Jun 04, 2017 at 01:29:08PM +0200, Helmut Grohne wrote:
> Source: e2fsprogs
> Version: 1.43.4-2
> Severity: wishlist
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> I'm having difficulties figuring the intended behaviour of e2fsprogs for
> mips* hosts. Can you clarify the following questions and update the
> packaging accordingly?
> 
>  * e2fsprogs Build-Depends: gcc-multilib [mips mipsel], yet it only
>actually builds 64bit libs during native builds. I think that either
>the build dependency should be annotated with  to indicate
>that gcc-multilib is not used during cross builds or e2fsprogs should
>build the 64bit libs during cross builds. What is preferred?
> 
>  * Having native builds differ from cross builds is considered bad
>practise. Ideally, we want to validate cross builds against native
>builds using diffoscope, i.e. we aim for reproducible cross builds.
>Please rethink whether this difference is really necessary. Building
>cross toolchains with multilib support is feasible. I've been doing
>that for like 2 years now. If opting out of these builds is
>necessary, the  build profile should be used rather than
>doing so unconditionally for cross builds.
> 
>  * It seems that the extra libraries are called libext2fs-nopic.a and
>lib64ext2fs-nopic.a (i.e. static libraries). Are they really still in
>use? They were added for #329074. As far as I understand that bug
>report, they were added for arcboot, which got removed November last
>year. So maybe these can go away as well?

I'm going to confess complete ignorance to what's going on with mips.
In the past my modus operandi is that I would make changes in response
to requests to the MIPS porters, in some cases with incomplete
understand why they were needed in the first place.

My bias would be to remove *all* of the mips specific exceptions in
the debian directory, and then see if things still build on mips, and
if there are any known problems caused by the mips installer or mips
bootpath.  And if we do need to add back any exceptions for the MIPS
architecture, let's make sure it's very clearly documented why they
are there.  Because at the moment, I'm a bit embarassed at my
inability to answer your perfectly reasonable questions.  :-)

Does that seem reasonable?  Are you willing to work with me to figure
out whether such a plan is going to cause problems with the installer
team, et. al?  And I assume that because we're just about to release
Debian stable, this is really a post stretch activity, yes?  Or is the
current state sufficient undesirable that it rises to the level of
release critical?  (I don't think so, but I'm willing to be
pursuaded.)

Cheers,

- Ted

Bug#862698: ITP: minecraft -- blocks to build anything you can imagine

2017-06-04 Thread Carlos Donizete Froes

On Sun, 4 Jun 2017 00:09:27 -0400 Nicholas D Steeves  wrote:
> I merged the bugs so both ITPs are closed when the package on mentors
> is uploaded.

Thanks! :)

> I gave it a quick look at to my eyes it looks good.  Unfortunately I'm
> not yet able to sponsor uploads.  Would you please go to the mentors
> page for this package, generate a template, and file an RFS bug if
> you're ready for it to be uploaded?  After that, your sponsor might
> ask you to change some things to make the package meet his or her
> standards/preferences.

Okay, I've made a sponsor request again.

> The best of reasons :-)

Thank you for the recognition

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

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

Bug#863897: sudo: Further issue in parsing /proc/[pid]/stat when process name contains newline

2017-06-04 Thread Salvatore Bonaccorso

Hi Bdale

Since time is pressing a bit for the release of stretch, any problem
in if I would prepare a NMU for both stretch (targetted) and sid for
this issue?

Regards,
Salvatore

Bug#864085: unblock: dnsmasq/2.76-5

2017-06-04 Thread Simon Kelley



On 04/06/17 16:36, Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
> 
> On Sun, Jun 04, 2017 at 09:58:44AM +0100, ? wrote:
>> The dnsmasq package in testing has a serious problem when dns-root-data is
>> installed, due to changes in the format of the dns-root-data files.
>> The effect is to render dnsmasq unusable.
> 
> Bother.
> 
>> There are several serious bugs filed to this effect, but they should
>> really be release-critical, eg 863896
>>
>> There are also several bugs in the DNSSEC validation code, which are fixed
>> upstream, and really should be in stretch.
>>
>> Therefore, if we can get dnsmasq-2.77-1, currently in unstable, into Stretch,
>> that would be a Good Thing. If not, it will need a point release.
> 
> The delta from testing to unstable right now is not really suitable this
> late in the process. I would prefer a targetted fix through t-p-u.

I understand.

> 
> However, I wonder if that format change in dns-root-data risks problems in
> other packages. Ondřej, is there any advantage to reverting that (keeping
> the RC fix for parse-root-anchors.sh)?
> 

The patch to fix this in dnsmasq is at :

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=44eb875a5ab2e3b862a6b2bc9fbbb919475d2107

(that regexp handles both old and new formats.)

Cheers,

Simon.

Bug#863289: libada/libgnat now built with dpkg-buildflags

Package: src:gcc-7
Followup-For: Bug #863289
Control: tags -1 + patch

The attached commit reverts any dpkg-buildflags handling from the Ada patches.
The right way for the build to receive flags is *FLAGS_FOR_TARGET.
--- a/debian/patches/ada-gnattools-cross.diff
+++ b/debian/patches/ada-gnattools-cross.diff
@@ -13,9 +13,6 @@
 * Create libgnat-BV.so symbolic link, use it and -L to link libgnarl.
   This prevents undefined symbols or unwanted usage of host libgnat.
 * Compile with -gnatn, link with --as-needed -z defs.
-* Force addition of the build flags from dpkg-buildflags.
-  One day they may be transmitted via *FLAGS_FOR_TARGET,
-  but at least this allows to set noopt for the Ada components.
 * set LD_LIBRARY_PATH so that rebuilt tools can be executed.
 
 This patch depends on ada-libgnatvsn.diff.
@@ -225,7 +222,7 @@ Index: b/src/gnattools/Makefile.in
 ===
 --- a/src/gnattools/Makefile.in
 +++ b/src/gnattools/Makefile.in
-@@ -75,15 +75,24 @@
+@@ -75,15 +75,21 @@
   -L../../../$(target_noncanonical)/libstdc++-v3/libsupc++/.libs
  
  # Variables for gnattools, native
@@ -237,11 +234,8 @@ Index: b/src/gnattools/Makefile.in
  	"CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
 -	"LDFLAGS=$(LDFLAGS)" \
 -	"ADAFLAGS=$(ADAFLAGS)" \
-+	"LDFLAGS=$(LDFLAGS) -Wl,--as-needed -Wl,-z,defs \
-+	  $(shell dpkg-buildflags --get LDFLAGS)" \
-+	"ADAFLAGS=$(ADAFLAGS) -gnatn \
-+	  $(filter-out -Wformat -Werror=format-security, \
-+	$(subst -O3,-O2,$(shell dpkg-buildflags --get CFLAGS)))" \
++	"LDFLAGS=$(LDFLAGS) -Wl,--as-needed -Wl,-z,defs" \
++	"ADAFLAGS=$(ADAFLAGS) -gnatn" \
  	"ADA_CFLAGS=$(ADA_CFLAGS)" \
  	"INCLUDES=$(INCLUDES_FOR_SUBDIR)" \
 -	"ADA_INCLUDES=-I- -I../rts $(ADA_INCLUDES_FOR_SUBDIR)"\
--- a/debian/patches/ada-libgnatvsn.diff
+++ b/debian/patches/ada-libgnatvsn.diff
@@ -46,7 +46,7 @@
 +} | tee -a config.log
 --- /dev/null
 +++ b/src/libgnatvsn/Makefile.in
-@@ -0,0 +1,156 @@
+@@ -0,0 +1,150 @@
 +# Makefile for libgnatvsn.
 +#   Copyright (c) 2006 Ludovic Brenta 
 +#   Copyright (c) 2017 Nicolas Boulenguez 
@@ -126,12 +126,6 @@
 +cppflags += $(CPPFLAGS)
 +ldflags  += $(LDFLAGS)
 +
-+deb_cflags := $(subst -O3,-O2,$(shell dpkg-buildflags --get CFLAGS))
-+adaflags += $(filter-out -Wformat -Werror=format-security,$(deb_cflags))
-+cflags   += $(deb_cflags)
-+cppflags += $(shell dpkg-buildflags --get CPPFLAGS)
-+ldflags  += $(shell dpkg-buildflags --get LDFLAGS)
-+
 +# Link wanted Ada sources from source tree, so that gnat fails when new
 +# dependencies are missing in the current directory, instead of silently
 +# using the ones in the distant directory.
--- a/debian/patches/ada-link-lib.diff
+++ b/debian/patches/ada-link-lib.diff
@@ -61,29 +61,19 @@
  	-fexceptions -DIN_RTS @have_getipinfo@
  
  host_subdir = @host_subdir@
-@@ -78,14 +78,19 @@
- # a *target* library, aren't we?!?  Likewise for CC.  Still, provide bogus
- # definitions just in case something slips through the safety net provided
+@@ -78,10 +78,10 @@
  # by recursive make invocations in gcc/ada/Makefile.in
-+deb_cflags := $(subst -O3,-O2,$(shell dpkg-buildflags --get CFLAGS))
  LIBADA_FLAGS_TO_PASS = \
  "MAKEOVERRIDES=" \
 -"LDFLAGS=$(LDFLAGS)" \
-+"LDFLAGS=$(LDFLAGS) -Wl,--as-needed -Wl,-z,defs \
-+  $(shell dpkg-buildflags --get LDFLAGS)" \
++"LDFLAGS=$(LDFLAGS) -Wl,--as-needed -Wl,-z,defs" \
  "LN_S=$(LN_S)" \
  "SHELL=$(SHELL)" \
 -"GNATLIBFLAGS=$(GNATLIBFLAGS) $(MULTIFLAGS)" \
-+"GNATLIBFLAGS=$(GNATLIBFLAGS) $(MULTIFLAGS) -gnatn \
-+  $(filter-out -Wformat -Werror=format-security,$(deb_cflags))" \
++"GNATLIBFLAGS=$(GNATLIBFLAGS) $(MULTIFLAGS) -gnatn" \
  "GNATLIBCFLAGS=$(GNATLIBCFLAGS) $(MULTIFLAGS)" \
--"GNATLIBCFLAGS_FOR_C=$(GNATLIBCFLAGS_FOR_C) $(MULTIFLAGS)" \
-+"GNATLIBCFLAGS_FOR_C=$(GNATLIBCFLAGS_FOR_C) $(MULTIFLAGS) \
-+  $(deb_cflags) \
-+  $(shell dpkg-buildflags --get CPPFLAGS)" \
+ "GNATLIBCFLAGS_FOR_C=$(GNATLIBCFLAGS_FOR_C) $(MULTIFLAGS)" \
  "PICFLAG_FOR_TARGET=$(PICFLAG)" \
- "THREAD_KIND=$(THREAD_KIND)" \
- "TRACE=$(TRACE)" \
 @@ -122,7 +122,7 @@
  	$(MAKE) -C $(GCC_DIR)/ada $(LIBADA_FLAGS_TO_PASS) ./bldtools/oscons/xoscons
  
@@ -163,14 +153,12 @@
  # these tools are built using the target libraries, and are intended to
 --- a/src/gcc/ada/gcc-interface/Make-lang.in
 +++ b/src/gcc/ada/gcc-interface/Make-lang.in
-@@ -45,7 +45,9 @@
+@@ -45,7 +45,7 @@
  
  
  # Extra flags to pass to recursive makes.
 -COMMON_ADAFLAGS= -gnatpg
-+deb_cflags := $(subst -O3,-O2,$(shell dpkg-buildflags --get CFLAGS))
-+COMMON_ADAFLAGS= -gnatpgn \
-+  $(filter-out -Wformat -Werror=format-security,$(deb_cflags))
++COMMON_ADAFLAGS= -gnatpgn
  ifeq ($(TREECHECKING),)
  CHECKING_ADAFLAGS=
  else
@@ -186,23 +174,12 @@
  
  ALL_ADAFLAGS = \
$(CFLAGS) $(ADA_CFLAGS) $(ADAFLAGS)

Bug#864172: samba: [INTL:pt] Portuguese translation for debconf messages

2017-06-04 Thread Traduz - DebianPT


Package: samba
Version: 2-4.5.8+dfsg-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for samba's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
--
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org





# Portuguese translation for samba4's debconf messages
# This file is distributed under the same license as the samba4 package.
#
# Miguel Figueiredo , 2004-2011.
# Rui Branco - DebianPT , 2017.
msgid ""
msgstr ""
"Project-Id-Version: samba 2-4.5.8+dfsg-2\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2013-10-22 20:32+0200\n"
"PO-Revision-Date: 2017-06-04 14:58+\n"
"Last-Translator: Rui Branco - DebianPT \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../samba-ad-dc.templates:1001
msgid "Upgrade from Samba 3?"
msgstr "Actualizar a partir do Samba 3?"

#. Type: boolean
#. Description
#: ../samba-ad-dc.templates:1001
msgid ""
"It is possible to migrate the existing configuration files from Samba 3 to "
"Samba 4. This is likely to fail for complex setups, but should provide a "
"good starting point for most existing installations."
msgstr ""
"Ã possÃvel migrar os ficheiros de configuraÃ§Ã£o existentes do Samba 3 para "
"Samba 4. Ã provÃ¡vel que falhe para configuraÃ§Ãµes complexas, mas deve "
"disponibilizar um bom ponto de partida para a maioria das instalaÃ§Ãµes "
"existentes."

#. Type: select
#. Description
#: ../samba-ad-dc.templates:2001
msgid "Server role"
msgstr "Papel do servidor"

#. Type: select
#. Description
#: ../samba-ad-dc.templates:2001
msgid ""
"Domain controllers manage NT4-style or Active Directory domains and provide "
"services such as identity management and domain logons. Each domain needs to "
"have a at least one domain controller."
msgstr ""
"Os controladores de domÃnio gerem domÃnios estilo-NT4 ou Active Directory e "
"disponibilizam serviÃ§os tais como a gestÃ£o de identidades e identificaÃ§Ã£o em "
"domÃnio. Cada domÃnio tem de ter pelo menos um controlador de domÃnio."

#. Type: select
#. Description
#: ../samba-ad-dc.templates:2001
msgid ""
"Member servers can be part of a NT4-style or Active Directory domain but do "
"not provide any domain services. Workstations and file or print servers are "
"usually regular domain members."
msgstr ""
"Os servidores membros podem fazer parte de um domÃnio estilo-NT4 ou Active "
"Directory mas nÃ£o disponibilizam quaisquer serviÃ§os de domÃnio. EstaÃ§Ãµes de "
"trabalho, servidores de ficheiros ou de impressÃ£o sÃ£o normalmente membros de "
"domÃnio."

#. Type: select
#. Description
#: ../samba-ad-dc.templates:2001
msgid ""
"A standalone server can not be used in a domain and only supports file "
"sharing and Windows for Workgroups-style logins."
msgstr ""
"Um servidor independente nÃ£o pode ser utilizado num domÃnio e apenas suporta "
"partilha de ficheiros e logins do tipo Windows for Workgroups."

#. Type: select
#. Description
#: ../samba-ad-dc.templates:2001
msgid ""
"If no server role is specified, the Samba server will not be provisioned, so "
"this can be done manually by the user."
msgstr ""
"Se nÃ£o for especificado nenhum papel para o servidor, o servidor Samba nÃ£o "
"serÃ¡ provisionado e assim poderÃ¡ ser feito manualmente pelo utilizador."

#. Type: string
#. Description
#: ../samba-ad-dc.templates:3001
msgid "Realm name:"
msgstr "Nome do reino:"

#. Type: string
#. Description
#: ../samba-ad-dc.templates:3001
msgid ""
"Please specify the Kerberos realm for the domain that this domain controller "
"controls."
msgstr ""
"Por favor especifique o reino Kerberos para o domÃnio que este controlador "
"de domÃnio controla."

#. Type: string
#. Description
#: ../samba-ad-dc.templates:3001
msgid "Usually this is the a capitalized version of your DNS hostname."
msgstr ""
"Normalmente isto Ã© a versÃ£o em maiÃºsculas do seu nome de mÃ¡quina de DNS."

#. Type: password
#. Description
#: ../samba-ad-dc.templates:4001
msgid "New password for the Samba \"administrator\" user:"
msgstr "Nova palavra-chave para o utilizador \"administrator\" Samba:"

#. Type: password
#. Description
#: ../samba-ad-dc.templates:4001
msgid "If this field is left blank, a random password will be generated."
msgstr "Se for deixado em branco, serÃ¡ gerada uma palavra-chave aleatÃ³ria."

#. Type: password
#. Description
#: ../samba-ad-dc.templates:4001
msgid "A password can be set later by running, as root:"
msgstr "A palavra-chave pode ser definida mais tarde usando como root:"

#. Type: password
#. Description
#: ../samba-ad-dc.templates:5001
msgid "Repeat password for the Samba \"administrator\" user:"
msgstr "Repita a palavra-chave para o

Bug#864171: grub2: [INTL:pt] Portuguese translation for debconf messages

2017-06-04 Thread Traduz - DebianPT


Package: grub2
Version: 2.02-beta3-5
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for grub2's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
--
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org




# Portuguese translation for grub2's debconf messages
# Copyright (C) 2007 Miguel Figueiredo
# This file is distributed under the same license as the grub2 package.
#
# Miguel Figueiredo , 2007, 2010, 2011.
# Ricardo Silva , 2008.
# Tiago Fernandes , 2010.
# Rui Branco - DebianPT , 2017.
msgid ""
msgstr ""
"Project-Id-Version: grub2 2.02-beta3-5\n"
"Report-Msgid-Bugs-To: gr...@packages.debian.org\n"
"POT-Creation-Date: 2017-01-20 00:29+\n"
"PO-Revision-Date: 2017-06-04 12:30+\n"
"Last-Translator: Rui Branco - DebianPT \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid "Chainload from menu.lst?"
msgstr "Carregar em cadeia a partir do menu.lst?"

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid "GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub."
msgstr ""
"Os scripts de actualizaÃ§Ã£o do GRUB detectaram uma configuraÃ§Ã£o do GRUB "
"Legacy em /boot/grub."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"In order to replace the Legacy version of GRUB in your system, it is "
"recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image "
"from your existing GRUB Legacy setup. This step can be automatically "
"performed now."
msgstr ""
"Por forma a substituir a versÃ£o antiga do GRUB que se encontra no sistema, Ã© "
"recomendado que o /boot/grub/menu.lst seja ajustado para permitir carregar "
"imagem de boot do GRUB 2 a partir da configuraÃ§Ã£o actual do GRUB antigo. "
"Esta etapa agora pode ser feita automaticamente."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"It's recommended that you accept chainloading GRUB 2 from menu.lst, and "
"verify that the new GRUB 2 setup works before it is written to the MBR "
"(Master Boot Record)."
msgstr ""
"Ã recomendado que aceite carregar em cadeia o GRUB 2 a partir do menu.lst, e "
"verificar que a configuraÃ§Ã£o do novo GRUB 2 estÃ¡ funcional, antes de ser "
"escrito no MBR (Master Boot Record)."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"Whatever your decision, you can replace the old MBR image with GRUB 2 later "
"by issuing the following command as root:"
msgstr ""
"Qualquer que seja a sua decisÃ£o, pode substituir mais tarde a antiga imagem "
"do MBR com o GRUB 2, executando como root o seguinte comando:"

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid "GRUB install devices:"
msgstr "dispositivos de instalaÃ§Ã£o GRUB:"

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid ""
"The grub-pc package is being upgraded. This menu allows you to select which "
"devices you'd like grub-install to be automatically run for, if any."
msgstr ""
"O pacote grub-pc estÃ¡ a ser actualizado. Este menu permite-lhe seleccionar "
"quais os dispositivos onde gostaria que o grub-install corresse "
"automaticamente, se algum."

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid ""
"Running grub-install automatically is recommended in most situations, to "
"prevent the installed GRUB core image from getting out of sync with GRUB "
"modules or grub.cfg."
msgstr ""
"Correr o grub-install automaticamente Ã© recomendado na maior parte das "
"situaÃ§Ãµes, para prevenir que a imagem core do GRUB instalada nÃ£o fique "
"dessincronizada com os mÃ³dulos do GRUB ou grub.cfg."

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid ""
"If you're unsure which drive is designated as boot drive by your BIOS, it is "
"often a good idea to install GRUB to all of them."
msgstr ""
"Se nÃ£o tÃªm a certeza de qual a drive designada como driver de arranque pela "
"sua BIOS, Ã© normalmente boa ideia instalar o GRUB em todas elas."

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid ""
"Note: it is possible to install GRUB to partition boot records as well, and "
"some appropriate partitions are offered here. However, this forces GRUB to "
"use the blocklist mechanism, which makes it less reliable, and therefore is "
"not recommended."
msgstr ""
"Nota: Ã© possÃvel instalar o GRUB no boot

Bug#841859: shotwell: Broken pathways for icons

2017-06-04 Thread Jörg Frings-Fürst

tags 841859 +pending
thanks

Hello Marc,

many thanks for your testing! :-)


CU
Jörg

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

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

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

Threema: SYR8SJXB
Wire: @joergfringsfuerst

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

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


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

Bug#858664: ITA: dfc -- display file system usage using graph and colors

2017-06-04 Thread sab



On 03/06/2017 13:53, Axel Beckert wrote:

Hi sab,

sab wrote:

retitle 858664  ITA: dfc -- display file system usage using graph and colors
owner 858664 sp...@onenetbeyond.org

Nice to see that someone is caring about dfc.

I've already prepared a new dfc upstream release (3.1.0) in the
packaging git repository
(https://anonscm.debian.org/cgit/collab-maint/dfc.git) for upload
after the stretch release.

Please build upon that state in the git repo when working on the dfc
package.

Regards, Axel

Hi Axel,
I've built with last commits on repository and i've changed compat file, 
caporight and changelog.
On repository I don't have the permissions when I push the response is: 
"remote: error: insufficient permission for adding an object to 
repository database ./objects"

how can I do?

Anyway I have packege in mentors website 
https://mentors.debian.net/package/dfc


Thank you.
Sabino

Bug#862673: Please support power management with logind/systemd

2017-06-04 Thread jcfp

Control: forwarded -1 https://github.com/sabnzbd/sabnzbd/issues/931
Control: tags -1 + confirmed upstream

Hi Laurent,

there's already an upstream issue about this as well as a pull request
at https://github.com/sabnzbd/sabnzbd/pull/939

Feel free to test and/or leave comments there.


pgpF9mnV9jLjT.pgp
Description: OpenPGP digital signature

Bug#845159: gcc-7: gnat fails to build on kfreebsd-*

Package: src:gcc-7
Followup-For: Bug #845159
Control: unmerge -1
Control: notfound -1 gcc-7/7.1.0-2
Control: tags 861737 - buster sid
Control: tags -1 + patch

The merge with 861737 was an error.
The attached patch should fix 845159.
--- /dev/null
+++ b/debian/patches/ada-drop-termio-h.diff
@@ -0,0 +1,39 @@
+Description: ada/terminals.c: remove obsolete termio.h
+ On all architectures, the terminals.c source file #includes
+  and declares variables with type struct termios.
+ .
+ Some platforms provide a compatibility termio.h, which only defines
+ the termio structure.
+ .
+ terminals.c also #includes , probably for historical
+ reasons since no termio structure is ever used.
+ .
+ Drop the #include instead of maintaining a list of architectures.
+Author: Nicolas Boulenguez 
+Bug-Debian: https://bugs.debian.org/845159
+
+--- a/src/gcc/ada/terminals.c
 b/src/gcc/ada/terminals.c
+@@ -1060,14 +1060,6 @@
+ #include 
+ #include 
+ #include 
+-
+-/* On some system termio is either absent or including it will disable termios
+-   (HP-UX) */
+-#if !defined (__hpux__) && !defined (BSD) && !defined (__APPLE__) \
+-  && !defined (__rtems__)
+-#   include 
+-#endif
+-
+ #include 
+ #include 
+ #include 
+@@ -1083,7 +1075,6 @@
+ #   include 
+ #endif
+ #if defined (__hpux__)
+-#   include 
+ #   include 
+ #endif
+ 
--- a/debian/patches/ada-kfreebsd.diff
+++ b/debian/patches/ada-kfreebsd.diff
@@ -1,17 +1,5 @@
 # DP: add support for GNU/kFreeBSD.
 
 a/src/gcc/ada/terminals.c
-+++ b/src/gcc/ada/terminals.c
-@@ -1064,7 +1064,8 @@
- /* On some system termio is either absent or including it will disable termios
-(HP-UX) */
- #if !defined (__hpux__) && !defined (BSD) && !defined (__APPLE__) \
--  && !defined (__rtems__)
-+  && ! defined (__FreeBSD_kernel__) && ! defined (__GNU__) \
-+  && ! defined (__rtems__)
- #   include 
- #endif
- 
 --- /dev/null
 +++ b/src/gcc/ada/s-osinte-kfreebsd-gnu.adb
 @@ -0,0 +1,158 @@
--- a/debian/rules.patch
+++ b/debian/rules.patch
@@ -233,6 +233,7 @@ debian_patches += skip-bootstrap-multilib
 debian_patches += libffi-ro-eh_frame_sect
 debian_patches += libffi-mips
 debian_patches += ada-kfreebsd
+debian_patches += ada-drop-termio-h
 
 # sigaction on sparc changed between glibc 2.19 and 2.21
 ifeq (,$(filter 2.1%, $(shell dpkg-query -l libc-bin | awk '/^.i/ {print $$3}')))

Bug#796129: FWIW

2017-06-04 Thread Geert Stappers

On Sun, Jun 04, 2017 at 07:39:15PM +0200, Geert Stappers wrote:
> For What Its Worth
> +  * Drop the build-dependency on libkcddb-dev (now libkf5cddb-dev), as
> +cmake was failing to detect the KCDDB library in both the previous
> +builds with libkcddb-dev and a new test build with libkf5cddb-dev.

So when the Build-Depends on  libkcompactdisc-dev  returns,
also check if cmake can detect the KCDDB library

Bug#862371: RFS: budgie-desktop/10.3.1-1

2017-06-04 Thread foss.freedom

Hi Gianfranco,

  I'm struggling with this - any thoughts on my investigations below.

On Debian Stretch I've created a chroot for unstable and installed the
build dependencies for budgie-desktop + locales + meson

In debian/rules I've changed the two export LANG and LANGUAGE vars to
en_US.UTF-8

Then manually (in the chroot) I have run the following:

debconf-set-selections <<< 'locales locales/default_environment_locale
select en_US.UTF-8'

dpkg-reconfigure locales

update-locale LANGUAGE='en_US.UTF-8'

N.B. the debconf-set-selections is to ensure dpkg-reconfigure locales
runs without the user having to manually select en_US.UTF-8 to the two
questions asked.

That's enough to convince the dpkg-buildpackage -us -uc to work
correctly within the chroot

The question I have is how to tuck the three commands above into the
Debian package to run before the main meson callout in debian/rules ?
i.e. I'm hoping this is the answer how to get the Debian build system
to default to a UTF-8 locale.

I added the three commands within override_dh_auto_configure: but I
get a "sh:1  Syntax error: redirection unexpected" - so I'm kind of
stuck on how to move forward.

I was hoping to find an existing Debian package that uses meson
building Vala within the archives to see how the maintainer did
something similar but my Google-fu has failed to find such a package
:(

David


On 12 May 2017 at 19:09, foss.freedom  wrote:
> Thanks Gianfranco for the review.  Much appreciated.
>
> I have completely redone the licenses and files in debian/copyight and
> double checked via "check-all-the-things"
>
> For the .install files - all debian/tmp has been removed.
>
> the FTBFS is concerning.  I don't understand why there is a difference
> between the build systems of launchpad (it works) and Debian (it
> doesnt).
>
> I asked this question here -
> https://github.com/budgie-desktop/budgie-desktop/issues/921
>
> The advice is to ensure the environment variables LANG and LANGUAGE is
> set to en_US - I've added two export lines for these environment vars
> at the top of the debian/rules
>
> I've tested the rules changes on launchpad.  However I dont have
> access to the debian build system so I cannot verify.
>
> I have rebuilt on my debian stretch VM and this is OK.
>
> David
>
> On 11 May 2017 at 22:27, Gianfranco Costamagna  
> wrote:
>> control: owner -1 !
>> control: tags -1 moreinfo
>>
>> Hello, I will sponsor it,
>> but please have a deep look at missing copyrights for a next upload, e.g.
>> + * Copyright (C) 2017 taaem 
>>
>>
>> other things:
>> I don't understand why you prepended debian/tmp to install files, but as you 
>> wish
>>
>> 2) FTBFS
>> http://debomatic-amd64.debian.net/distribution#experimental/budgie-desktop/10.3.1-1/buildlog
>>
>> G.

Bug#864170: martian-modem-source: broken symlink: /usr/share/modass/overrides/martian-modem-source -> /packages/default.sh

Package: martian-modem-source
Version: 20080625-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + martian-modem

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

2m30.3s ERROR: FAIL: Broken symlinks:
  /usr/share/modass/overrides/martian-modem-source -> /packages/default.sh

You probably wanted to target /usr/share/modass/packages/default.sh
(or just ../packages/default.sh)


cheers,

Andreas

Bug#796129: FWIW

2017-06-04 Thread Geert Stappers


For What Its Worth


This from tellico_2.3.9+dfsg.1-1.1ubuntu1.patch

--- 2.3.9+dfsg.1-1.1/debian/changelog   2016-07-15 13:42:28.0 +
+++ 2.3.9+dfsg.1-1.1ubuntu1/debian/changelog2017-04-06 09:14:13.0 
+
@@ -1,3 +1,11 @@
+tellico (2.3.9+dfsg.1-1.1ubuntu1) zesty; urgency=medium
+
+  * Drop the build-dependency on libkcddb-dev (now libkf5cddb-dev), as
+cmake was failing to detect the KCDDB library in both the previous
+builds with libkcddb-dev and a new test build with libkf5cddb-dev.
+
+ -- Adam Conrad   Thu, 06 Apr 2017 03:14:13 -0600
+
 tellico (2.3.9+dfsg.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.

$ diff -u crmin crplus
--- crmin   2017-06-04 19:13:41.678882350 +0200
+++ crplus  2017-06-04 19:13:55.006914738 +0200
@@ -1,4 +1,4 @@
--Build-Depends: debhelper (>= 9),
++Build-Depends: debhelper (>= 9),
  cmake,
  pkg-config,
  pkg-kde-tools (>= 0.9),
@@ -7,7 +7,6 @@
  libxslt1-dev,
  libtag1-dev,
  libyaz4-dev,
- libkcddb-dev,
  kdepimlibs5-dev (>=4:4.7),
  libpoppler-qt4-dev,
  libexempi-dev,

Bug#864168: CVE-2015-8366: Index overflow in smal_decode_segment

2017-06-04 Thread Moritz Muehlenhoff

Package: dcraw
Severity: important
Tags: security

dcraw embeds a copy of libraw, which is affected by an integer
overflow in smal_decode_segment().

Patch is here: 
https://github.com/LibRaw/LibRaw/commit/89d065424f09b788f443734d44857289489ca9e2

Cheers,
Moritz

Bug#841859: shotwell: Broken pathways for icons

2017-06-04 Thread Marc Jeffrey Driftmeyer

New Bild by Jorge Frings-Furst works without errors.

- Marc

Marc Jeffrey Driftmeyer
Founder & CEO of Reanimality Studios LLC
Cell: (509) 435-5212
url: https://www.reanimastudios.com 
url: https://www.holoworlds.net 
email: m...@reanimality.com 
email: m...@holoworlds.net 





> On Oct 24, 2016, at 11:45 PM, Marc Jeffrey Driftmeyer  
> wrote:
> 
> 
> 
> It is completely odd. What other hidden config paths might be causing it?
> 
> - Marc
> 
>> On Oct 24, 2016, at 9:11 PM, Jörg Frings-Fürst  
>> wrote:
>> 
>> tags 841860 + unreproducible moreinfo
>> tags 841859 + unreproducible moreinfo
>> severity 841859 normal
>> retitle 841859 [shotwell] Broken pathways for icons
>> retitle 841860 [shotwell] Broken pathways for icons
>> merge 841859 841860
>> thanks
>> 
>> 
>> Hello Marc,
>> 
>> thank you for spending your time helping to make Debian better with
>> this bug report.
>> 
>> I have test the install / update of shotwell, but I can't reproduce
>> your bug.
>> 
>> The icons are installed from shotwell-common into
>> /usr/share/shotwell/icons. And shotwell found them there.
>> 
>> 
>> Please can you attach you apt log and the output of df, 
>> ls -l /usr/share/shotwell/icons and md5sum /usr/bin/shotwell.
>> 
>> CU
>> Jörg
>> 
>> 
>> 
>> -- 
>> New:
>> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
>> GPG key (long) : 09F89F3C8CA1D25D
>> GPG Key: 8CA1D25D
>> CAcert Key S/N : 0E:D4:56
>> 
>> Old pgp Key: BE581B6E (revoked since 2014-12-31).
>> 
>> Jörg Frings-Fürst
>> D-54470 Lieser
>> 
>> Threema: SYR8SJXB
>> 
>> IRC: j_...@freenode.net
>> j_...@oftc.net
>> 
>> My wish list: 
>> - Please send me a picture from the nature at your home.
>

Bug#864169: RFS: minecraft-installer/0.1-2 [ITP] -- Unofficial way to easily install Minecraft game

2017-06-04 Thread Carlos Donizete Froes

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "minecraft-installer"

 * Package name: minecraft-installer
   Version : 0.1-2
   Upstream Author : Carlos Donizete Froes 
 * URL : https://github.com/coringao/minecraft-installer
 * License : BSD-2-Clause
   Section : contrib/games

  It builds those binary packages:

minecraft-installer - Unofficial way to easily install game

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

  https://mentors.debian.net/package/minecraft-installer

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

  dget -x https://mentors.debian.net/debian/pool/contrib/m/minecraft-
installer/minecraft-installer_0.1-2.dsc

  More information about Minecraft Installer can be obtained from
https://github.com/coringao/minecraft-installer/wiki.

  This package does NOT contain the Minecraft itself as that would breach
copyright
  laws and the wishes of authors of Minecraft/Mojang and Microsoft.

  Changes since the last upload:

  minecraft-installer (0.1-2) unstable; urgency=medium

  * debian/control:
- Change maintainer Debian Games Team
- Add myself as Uploader
- Add Vcs URLs pkg-games

 -- Carlos Donizete Froes   Sun, 04 Jun 2017 12:31:13
-0300

  minecraft-installer (0.1-1) unstable; urgency=medium

  * Initial release (Closes: #863105)

 -- Carlos Donizete Froes   Sun, 21 May 2017 16:47:14
-0300

  Regards,
   Carlos Donizete Froes



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

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

Bug#850785: llvm-toolchain-3.9 make some reverse-dependencies FTBFS on i386

2017-06-04 Thread Graham Inggs

This is fixed in LLVM 4.0.

Bug#863472: unblock: openssl/1.1.0f-1

2017-06-04 Thread Cyril Brulebois

Kurt Roeckx  (2017-06-04):
> So I changed it this instead:
>   dh_makeshlibs -a -V --add-udeb="libcrypto1.1-udeb" -Xengines
> 
> the shlib files now looks like:
> libcrypto 1.1 libssl1.1 (>= 1.1.0f)
> libssl 1.1 libssl1.1 (>= 1.1.0f)
> udeb: libcrypto 1.1 libcrypto1.1-udeb (>= 1.1.0f)
> udeb: libssl 1.1 libssl1.1-udeb (>= 1.1.0f)
> 
> Since we have symbol files, this does not affect non-udeb
> packages.

As discussed on IRC (#debian-devel), the earlier syntax (-V with a
version) was fine, and more accurate as it only needs to be bumped
when symbols change. However, using -V without a specific version
should get us updated dependencies every time; they might be stricter
than needed, but that's better than forgetting about bumping the
version IMHO, so fine with me.

Thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#864167: python-autopep8: please supply a man page for autopep8

2017-06-04 Thread David Bremner

Package: python-autopep8
Version: 0.9.1-2.1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


/usr/bin/autopep8 could use some documentation. The output of "pydoc autopep8" 
doesn't really look
helpful for users of the script.

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

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

Versions of packages python-autopep8 depends on:
ii  pep8  1.7.0-4
ii  python2.7.13-2
ii  python-pep8   1.7.0-4
ii  python-pkg-resources  33.1.1-1
pn  python:any

python-autopep8 recommends no packages.

python-autopep8 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlk0O3oACgkQ8gKXHaSn
niz+oQv+N3QrDjCbH7BPtEvezK/QGb5RJJjlKq04jEQbOsg7qaoQKrbL/I5S6pej
pliCTiBx5T/vBBQQmp66XofIHSfrsuAF9gRpTpnJ7AzT8ZhQ3smsSp489B3sp1BI
bRiKVwr1djKZRRT9JGrBfz2NvIJFdva9rH5TXOa0GoirzLK6JHGJoxMrPnf3JtiG
f10bY9EYlEvy6ZFpAGmLa6K7QWD7TQ7viJ15gjO/fpuehBwTvdUIs2KAZ0sJ8IUN
OM33e2lunikaQdarnXGzAs51fL3gH85DltVW/WpKOpox5d16pbGwM9DUR8+XdZ18
1Y+wwDvjQ116lhYio8EGQOzfdge5MAf2e/KSlTN3MjApnUcYize628rueheJ6kR4
sHXtv6vgOLM2+Ma0shJcT7n2/S+avjDcImhYSxXOc4/2uSYWEP4QgXiKmBozS2HF
Eb1q+x8W3GtmgYS/RC1rLOnBSVKczNwghq6GAN5i3fZbCLYSslzxwIPrlmqusZKS
qtKdVYsv
=mTXN
-END PGP SIGNATURE-

Bug#864166: release-notes: proofreading sweep - issues.dbk

2017-06-04 Thread Justin B Rye

Package: release-notes
Severity: wishlist

All of these are "stylistic", and could thus be put off until after
the release if we have to; they include some pretty annoying errors,
but nothing that would stop readers understanding what's intended.

Index: issues.dbk
===
--- issues.dbk (revision 11524)
+++ issues.dbk (working copy)
@@ -17,10 +17,10 @@

- Upgrade specific items for
+ Upgrade specific items for

This section covers items related to the upgrade from
- to
+ to

@@ -42,7 +42,7 @@

This means that for all systems where
/usr
is a separate partition need to use an initramfs generator that will
mount
- /usr. All initramfs generators in do
so.
+ /usr. All initramfs generators in do
so.

In all the pages I've reviewed so far the dominant standard is
lowercase "stretch", even when it appears in an otherwise capitalising
context such as the start of a sentence. (It's not clear why
even exists.)

@@ -50,9 +50,10 @@
FTP access to Debian hosted mirrors will be removed

Debian hosted mirrors will stop providing FTP access. If you
- have been using the ftp protocol in your sources.list, please
- migrate to http. Please consider the following example for
- migrating:
+ have been using the ftp: protocol in your
+ sources.list, please migrate to
+ http:. Please consider the following example
+ for migrating:
deb http://deb.debian.org/debian stretch main
deb http://deb.debian.org/debian-security stretch/updates main

FTP is either a capitalised initialism or a literal string; and the
string that needs to go in an APT sources-list file has a colon (we
*don't* want people to search-and-replace ftp://ftp.debian.org into
http://http.debian.org). Ideally we'd rephrase this not to assume the
APT sources-list file is called sources.list, but that's going beyond
a stylistic change.

@@ -91,35 +92,42 @@
The list of obsolete packages includes:

- Most "-dbg" packages have been removed from the main
- archive. They have been replaced by "-dbgsym" packages that
- are available from the "debian-debug" archive. Please see
+ Most -dbg packages have been removed
+ from the main archive. They have been replaced by
+ -dbgsym packages that are available from the
+ debian-debug archive. Please see

Just standardising the use of markup. Or maybe some of them should be
instead? Anyway, reserve ASCII-quotes for the commandline.

The password managers fpm2
and kedpm
are no longer maintained upstream. Please use another password
- manager like pass, keepassx, or keepass2. Make sure that you
- extract your passwords from fpm2 and kedpm before removing the
packages.
+ manager like pass,
+ keepassx, or
+ keepass2.
+ Make sure that you extract your passwords from fpm2 and kedpm before removing the packages.

Consistency again. Last time I checked docbook actually supported
, but maybe that would require some sort of extra setup.

The net-tools package
- will be deprecated in favor of
+ is being deprecated in favor of
iproute2.
See or the
https://www.debian.org/doc/manuals/debian-reference/ch05#_the_low_level_network_configuration;>
- Debian reference manual for more informations.
+ Debian reference manual for more information.

"Will be deprecated" tells me nothing - I'm pretty sure
network-manager *will* one day be deprecated. If we're already moving
away from it, it already *is* deprecated. But I'll assume this is
just an English usage problem (like the pluralised "information") and
classify it in with the stylistic bugs.

(It would be nice if the releasenotes *also* mentioned that things
have stopped depending on ifupdown, with the result that it runs the
risk of being automatically uninstalled by aptitude - a nasty
potential upgrade glitch not related to the one that keeps disabling
my wifi. But that's a content change, so it should go in a separate
bugreport, and maybe not for this page.)

@@ -119,10 +123,10 @@

-Deprecated components for
+Deprecated components for

With the next release of (codenamed
- ) some features will be deprecated. Users
+ ) some features will be deprecated. Users
will need to migrate to other alternatives to prevent
trouble when updating to .

@@ -170,7 +174,7 @@
has an issue that can cause some programs compiled as position
independent

Bug#864083: unblock: libgcrypt20/1.7.6-2

2017-06-04 Thread Cyril Brulebois

Hi,

Niels Thykier  (2017-06-04):
> Ack from here, CC'ing KiBi for a d-i ack - assuming there is still
> time.  Worst case, we will have to defer it to 9.1.

I'm missing cryptsetup test cases right now, so I can't tell in a few
minutes. I'll try to add one and/or run this manually on monday, but
not making any promises. At some point, late requests will need to be
punted for r1. Especially given the current amount and the timing
getting tighter and tighter.


KiBi.


signature.asc
Description: Digital signature

Bug#863890: dblatex: postrm fails on jessie to stretch upgrade

On Sun, Jun 04, 2017 at 12:15:56AM +0200, Andreas Beckmann wrote:
>...
> dpkg spews a lot of warnings about dependency problems, so it's not
> dblatex's fault if its postrm failed due to dependency violations.
> More likely apt (from jessie) is at fault here for choosing a broken
> upgrade path.
>...
> I don't see a point of updating dblatex in jessie to make its postrm
> handle "invalid states", at least not until the underlying cause has
> been identified.

Policy version 3.9.8.0 says in section 6.5:

  `remove'
  `purge'
  `upgrade' 
  `disappear'  
  The `postrm' script is called after the package's files have been
  removed or replaced.  The package whose `postrm' is being called
  may have previously been deconfigured and only be "Unpacked", at
  which point subsequent package changes do not consider its
  dependencies.  Therefore, all `postrm' actions may only rely on
  essential packages and must gracefully skip any actions that
  require the package's dependencies if those dependencies are
  unavailable.

> Andreas

cu
Adrian

-- 

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

Bug#864164: Please add an alternative for leafpad in the dependencies

2017-06-04 Thread Alf Gaida

Source: lxde-metapackages
Severity: wishlist

Dear maintainer,

please change the dependency leafpad to leafpad | mousepad -  reason: leafpad 
is a little bit to minimalistic,
mousepad (a leafpad fork) is more comfty. A tiny graphical editor is fine as a 
dependency, but it make no sense
to have leafpad in the system if one decide to have mousepad as the primary 
LXDE editor.

Cheers Alf

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

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

Bug#864163: openstack-dashboard-apache: fails to upgrade from 'jessie': 'dashboard/less/horizon.less' could not be found in the COMPRESS_ROOT '/usr/share/openstack-dashboard/static' or with staticfile

Package: openstack-dashboard-apache
Version: 3:9.0.1-2~bpo8+1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'jessie-backports' fails.

>From the attached log (scroll to the bottom...):

  Setting up openstack-dashboard-apache (3:9.0.1-2~bpo8+1) ...
  Installing new version of config file 
/etc/apache2/sites-available/openstack-dashboard-ssl.conf ...
  Installing new version of config file 
/etc/apache2/sites-available/openstack-dashboard.conf ...
  Site 000-default already enabled
  Enabling site default-ssl.
  To activate the new configuration, you need to run:
service apache2 reload
  Site openstack-dashboard already disabled
  Site openstack-dashboard-ssl-redirect already disabled
  Site openstack-dashboard-ssl already disabled
  Enabling site openstack-dashboard-alias-only.
  To activate the new configuration, you need to run:
service apache2 reload
  Deleting 'horizon/lib/jquery/jquery.min.js'
  Deleting 'horizon/lib/jquery/jquery.cookie.js'
  Deleting 'bootstrap/img/glyphicons-halflings-white.png'
  Deleting 'bootstrap/img/glyphicons-halflings.png'
  Deleting 'bootstrap/less/accordion.less'
  Deleting 'bootstrap/less/alerts.less'
  Deleting 'bootstrap/less/bootstrap.less'
  Deleting 'bootstrap/less/breadcrumbs.less'
  Deleting 'bootstrap/less/button-groups.less'
  Deleting 'bootstrap/less/buttons.less'
  Deleting 'bootstrap/less/carousel.less'
  Deleting 'bootstrap/less/close.less'
  Deleting 'bootstrap/less/code.less'
  Deleting 'bootstrap/less/component-animations.less'
  Deleting 'bootstrap/less/datepicker.less'
  Deleting 'bootstrap/less/dropdowns.less'
  Deleting 'bootstrap/less/forms.less'
  Deleting 'bootstrap/less/grid.less'
  Deleting 'bootstrap/less/hero-unit.less'
  Deleting 'bootstrap/less/labels.less'
  Deleting 'bootstrap/less/layouts.less'
  Deleting 'bootstrap/less/mixins.less'
  Deleting 'bootstrap/less/modals.less'
  Deleting 'bootstrap/less/navbar.less'
  Deleting 'bootstrap/less/navs.less'
  Deleting 'bootstrap/less/pager.less'
  Deleting 'bootstrap/less/pagination.less'
  Deleting 'bootstrap/less/popovers.less'
  Deleting 'bootstrap/less/progress-bars.less'
  Deleting 'bootstrap/less/reset.less'
  Deleting 'bootstrap/less/responsive.less'
  Deleting 'bootstrap/less/scaffolding.less'
  Deleting 'bootstrap/less/sprites.less'
  Deleting 'bootstrap/less/tables.less'
  Deleting 'bootstrap/less/thumbnails.less'
  Deleting 'bootstrap/less/tooltip.less'
  Deleting 'bootstrap/less/type.less'
  Deleting 'bootstrap/less/utilities.less'
  Deleting 'bootstrap/less/variables.less'
  Deleting 'bootstrap/less/wells.less'
  Deleting 'dashboard/manifest.json'
  Deleting 'dashboard/js/cc5f5101bb22.js'
  Deleting 'dashboard/js/0272dc9e5c21.js'
  Deleting 'dashboard/css/17e660320de4.css'
  Deleting 'dashboard/fonts/Anivers_Regular-webfont.eot'
  Deleting 'dashboard/fonts/Anivers_Regular-webfont.svg'
  Deleting 'dashboard/fonts/Anivers_Regular-webfont.ttf'
  Deleting 'dashboard/fonts/Anivers_Regular-webfont.woff'
  Deleting 'dashboard/img/action_required.png'
  Deleting 'dashboard/img/db-gray.gif'
  Deleting 'dashboard/img/db-gray.svg'
  Deleting 'dashboard/img/db-green.svg'
  Deleting 'dashboard/img/db-red.svg'
  Deleting 'dashboard/img/drag.png'
  Deleting 'dashboard/img/drop_arrow.png'
  Deleting 'dashboard/img/favicon.ico'
  Deleting 'dashboard/img/lb-gray.gif'
  Deleting 'dashboard/img/lb-gray.svg'
  Deleting 'dashboard/img/lb-green.svg'
  Deleting 'dashboard/img/lb-red.svg'
  Deleting 'dashboard/img/loading.gif'
  Deleting 'dashboard/img/logo-splash.png'
  Deleting 'dashboard/img/logo.png'
  Deleting 'dashboard/img/profile_drop.png'
  Deleting 'dashboard/img/right_droparrow.png'
  Deleting 'dashboard/img/router.png'
  Deleting 'dashboard/img/search.png'
  Deleting 'dashboard/img/server-gray.gif'
  Deleting 'dashboard/img/server-gray.svg'
  Deleting 'dashboard/img/server-green.svg'
  Deleting 'dashboard/img/server-red.svg'
  Deleting 'dashboard/img/server.png'
  Deleting 'dashboard/img/spinner.gif'
  Deleting 'dashboard/img/stack-gray.gif'
  Deleting 'dashboard/img/stack-gray.svg'
  Deleting 'dashboard/img/stack-green.svg'
  Deleting 'dashboard/img/stack-red.svg'
  Deleting 'dashboard/img/unknown-gray.gif'
  Deleting 'dashboard/img/unknown-gray.svg'
  Deleting 'dashboard/img/unknown-green.svg'
  Deleting 'dashboard/img/unknown-red.svg'
  Deleting 'dashboard/img/up_arrow.png'
  Deleting 'dashboard/less/accordion_nav.less'
  Deleting 'dashboard/less/horizon.less'
  Deleting 'dashboard/less/horizon_charts.less'
  Deleting 'dashboard/less/horizon_workflow.less'
  Deleting 'dashboard/less/rickshaw.css'
  Copying 
'/usr/lib/python2.7/dist-packages/horizon/static/horizon/tests/templates.js'
  Copying 
'/usr/lib/python2.7/dist-packages/horizon/static/horizon/tests/tables.js'
  Copying

Bug#864161: ceph-mon: missing Breaks+Replaces: ceph-common (<< 10)

Package: ceph-mon
Version: 10.2.5-7
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: found -1 10.2.5-6~bpo8+1
Control: affects -1 + ceph

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'jessie-backports' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

The same could happen in stretch, since the Breaks+Replaces are missing
there, too. apt just seems to use a different unpacking order for the
upgrades from jessie to stretch, but that will depend on the set of
installed packages ...

According to snapshot.d.o ceph-rest-api disappeared from ceph-common between
0.94.5-1.1 and 10.2.5-1

Once that is fixed in stretch, please also update the package in
jessie-backports.


See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../ceph_10.2.5-6~bpo8+1_amd64.deb ...
  Unpacking ceph (10.2.5-6~bpo8+1) over (0.80.7-2+deb8u2) ...
  dpkg: warning: unable to delete old directory '/etc/pm/sleep.d': Directory 
not empty
  dpkg: warning: unable to delete old directory '/etc/pm': Directory not empty
  dpkg: warning: unable to delete old directory '/etc/ceph': Directory not empty
  Selecting previously unselected package ceph-mon.
  Preparing to unpack .../ceph-mon_10.2.5-6~bpo8+1_amd64.deb ...
  Unpacking ceph-mon (10.2.5-6~bpo8+1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/ceph-mon_10.2.5-6~bpo8+1_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/ceph-rest-api', which is also in package 
ceph-common 0.80.7-2+deb8u2


cheers,

Andreas


ceph_10.2.5-7.log.gz
Description: application/gzip

Bug#796129: milage report

2017-06-04 Thread Geert Stappers

Control: tags -1 -patch +confirmed

Adding 'libkcompactdisc-dev' to the Build-Depends of Tellico 3.0.2.
The bug, "grey CD import",  is still present.

Bug#864162: opendkim: systemd ExecStart ignore configuration options

2017-06-04 Thread François Poulain

Package: opendkim
Version: 2.11.0~alpha-10
Severity: important

Dear Maintainer,

I was unable to make opendkim listening on the 12301 port.

It appears that the ExecStart in
/etc/systemd/system/multi-user.target.wants/opendkim.service
ignore configuration options.

I fixed it locally by defining
ExecStart=/usr/sbin/opendkim -P /var/run/opendkim/opendkim.pid -p $(awk '$1 == 
"Socket" { print $2 }' /etc/opendkim.conf)
(inspired by init script).

François

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

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

Versions of packages opendkim depends on:
ii  adduser  3.115
ii  dns-root-data2017041101
ii  init-system-helpers  1.48
ii  libbsd0  0.8.3-1
ii  libc62.24-10
ii  libdb5.3 5.3.28-12+b1
ii  libldap-2.4-22.4.44+dfsg-5
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libmemcached11   1.0.18-4.1
ii  libmemcachedutil21.0.18-4.1
ii  libmilter1.0.1   8.15.2-8
ii  libopendbx1  1.4.6-11+b1
ii  libopendkim112.11.0~alpha-10
ii  librbl1  2.11.0~alpha-10
ii  libssl1.11.1.0e-2
ii  libunbound2  1.6.0-3
ii  libvbr2  2.11.0~alpha-10
ii  lsb-base 9.20161125

opendkim recommends no packages.

Versions of packages opendkim suggests:
ii  opendkim-tools  2.11.0~alpha-10
pn  unbound 

-- Configuration Files:
/etc/default/opendkim changed:
RUNDIR=/var/run/opendkim
SOCKET=inet:12301@localhost
USER=opendkim
GROUP=opendkim
PIDFILE=$RUNDIR/$NAME.pid
EXTRAAFTER=

/etc/opendkim.conf changed:
Syslog  yes
UMask   007
Modesv
OversignHeaders From
TrustAnchorFile   /usr/share/dns/root.key
AutoRestart Yes
AutoRestartRate 10/1h
UMask   002
Syslog  yes
SyslogSuccess   Yes
LogWhy  Yes
Canonicalizationrelaxed/simple
KeyTable/etc/postfix/dkim/keytable
SigningTable/etc/postfix/dkim/signingtable 
ExternalIgnoreList  /etc/postfix/dkim/TrustedHosts
InternalHosts   /etc/postfix/dkim/TrustedHosts
Modesv
PidFile /var/run/opendkim/opendkim.pid
SignatureAlgorithm  rsa-sha256
UserID  opendkim:opendkim
Socket  inet:12301@localhost


-- no debconf information

Bug#864027: unblock: swift/2.10.2-1

2017-06-04 Thread Ondrej Novy

Hi,

2017-06-04 16:55 GMT+02:00 Jonathan Wiltshire :

> Let's defer this, I'm not comfortable with such changes this close to
> release.
>

so let's wait for p-u and first stretch point release?

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Bug#864160: Release notes should document how to compile 3rd party software against OpenSSL