Bug#811185: failed tests

[olivier sallou]

I need to test on my computer, this could be related to a new swi-prolog
version introduction incompatible backwards modifications.

Bug#817018: Some tasks files are encoded in iso-8859 instead of utf-8

[Petter Reinholdtsen]

[Ole Streicher]
> Could you change this in the git repository? A new upload of the package
> is not needed for me.

Done.  Thank you for the discovery.  Some of the files had mixed
encoding.  Now all of them seem to work well with iconv -f utf-8.

--
Happy hacking
Petter Reinholdtsen

Bug#813598: [gnutls-devel] FTBFS[kfreebsd]: tests/mini-loss-time race

[Nikos Mavrogiannopoulos]

On Sat, Mar 5, 2016 at 7:57 PM, Steven Chamberlain  wrote:
> Hi Andreas,
>
> In a future upload please could you try the attached diff, which is a
> much simpler way I found to get the testsuite output into the build log.
> Since more than one set of tests runs in parallel, we only currently see
> the test-suite.log for one set of tests, and not all of them.
>
>> On Sat, 2016-03-05 at 17:30 +0100, Andreas Metzler wrote:
>> > Well with 3.4.10 the timeout does not seem to make any difference.
>> > Any of
>> > gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); [Steven's
>> > patch]
>
> Your commit to the gnutls28 package in experimental
> https://anonscm.debian.org/cgit/pkg-gnutls/gnutls.git/commit/?h=experimental&id=896b247a321271ab61ed1fce5065cadbd472c207
> seems to do the opposite of my patch, it increases the server timeout?
> My patch decreased it:  https://bugs.debian.org/813598#5
>
>> > gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000); [3.4.10]
>> > gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); 
>> > [e6dcb14dbbd3e9e40a1f193a7bf6657e82b88cb9]
>> > *always* fails on kfreebsd-amd64.
>
> If it fails _reliably_ now, I consider that an improvement!
> I'll try to test all of the above and see how often each one fails.

That's quite interesting. It seems that the child times out first and
closes the connection prior to parent detecting the timeout. Would the
attached patch solve the issue?

regards,
Nikos
diff --git a/tests/mini-loss-time.c b/tests/mini-loss-time.c
index 13de21e..8145657 100644
--- a/tests/mini-loss-time.c
+++ b/tests/mini-loss-time.c
@@ -116,7 +116,7 @@ push(gnutls_transport_ptr_t tr, const void *data, size_t 
len)
return send(fd, data, len, 0);
 }
 
-static void client(int fd)
+static void client(int fd, unsigned timeout)
 {
int ret;
gnutls_anon_client_credentials_t anoncred;
@@ -136,7 +136,7 @@ static void client(int fd)
 */
gnutls_init(&session, GNUTLS_CLIENT | GNUTLS_DATAGRAM);
gnutls_dtls_set_mtu(session, 1500);
-   gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000);
+   gnutls_dtls_set_timeouts(session, 1 * 1000, timeout * 1000);
 
/* Use default priorities */
gnutls_priority_set_direct(session,
@@ -178,7 +178,7 @@ static void client(int fd)
 /* These are global */
 pid_t child;
 
-static void server(int fd, int packet)
+static void server(int fd, int packet, unsigned timeout)
 {
gnutls_anon_server_credentials_t anoncred;
gnutls_session_t session;
@@ -196,7 +196,7 @@ static void server(int fd, int packet)
 
gnutls_init(&session, GNUTLS_SERVER | GNUTLS_DATAGRAM);
gnutls_dtls_set_mtu(session, 1500);
-   gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000);
+   gnutls_dtls_set_timeouts(session, 1 * 1000, timeout * 1000);
 
/* avoid calling all the priority functions, since the defaults
 * are adequate.
@@ -265,17 +265,17 @@ static void start(int server_packet, int wait_server)
/* parent */
close(fd[0]);
if (wait_server)
-   server(fd[1], server_packet);
+   server(fd[1], server_packet, 30);
else
-   client(fd[1]);
+   client(fd[1], 30);
close(fd[1]);
kill(child, SIGTERM);
} else {
close(fd[1]);
if (wait_server)
-   client(fd[0]);
+   client(fd[0], 32);
else
-   server(fd[0], server_packet);
+   server(fd[0], server_packet, 32);
close(fd[0]);
exit(0);
}

Bug#800845: autopkgtest: Add support for nested VMs

[Martin Pitt]

Hey Christian,

Christian Seiler [2016-03-06 18:18 +0100]:
> I've implemented this in the following way:
> 
>  - touch /run/autopkgtest-update-initramfs-at-reboot in setup_baseimage()
>  - /sbin/autopkgtest-reboot{,-prepare}:
>   - if /run/autopkgtest-update-initramfs-at-reboot exists AND 
>update-initramfs is present, update the initramfs
>  - /usr/share/initramfs-tools/hooks/autopkgtest (created in
>setup_baseimage()):
>   - unconditionally remove /run/autopkgtest-update-initramfs-at-reboot
> Because a initramfs-tools hook will only be called if an initramfs
> is generated - but if it's generated anyway, we might as well
> remove the flag file, because then we can save ourselves a lot of
> work.

Thanks. I applied [1] this with a few niggles ("anyway" -> "already",
PEP-8, not mix "[] || foo" and "if; then" in the same command).
I also redirected the u-i output to /dev/null, as this is run within
the context of the *test* and thus clutters up or even breaks tests
(those that don't have "allow-stderr) -- see all three
QemuRunner.test_reboot_* test cases which got broken by this. This of
course now means that *if* the command fails then the test will also
fail without any noticeable output :-(

I can't say that this makes me happy, due to the performance impact on
most real-life test runs (--apt-upgrade), not supporting r/o testbeds,
code leaking into common testbed code, and the initramfs update
running in test context. But this at least gets master back to a
reasonably working state.

So I'll still look into adding pre-reboot hooks, removing the drive
there, and writing the new udev rule into /run/ instead of /etc; this
should address the above issues.

As there was quite some back-and-forth in master, I now rebased the
recent commits to make them easier to review/understand. Sorry world
for making the next git pull a bit inconvenient!

Thanks,

Martin

[1] 
http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=bc57502f1bcb

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


signature.asc
Description: PGP signature

Bug#817009: please show Ubuntu versions in -proposed as well, if packages exist there

[Lucas Nussbaum]

On 07/03/16 at 06:07 +0100, Matthias Klose wrote:
> Package: qa.debian.org
> Severity: wishlist
> 
> while looking at
> https://qa.debian.org/developer.php?email=android-tools-devel%40lists.alioth.debian.org
> 
> to see why this stack didn't migrate (both in Debian and Ubuntu), I tried to
> ensure first that all packages were up-to-date in Ubuntu. However this page
> only shows me packages in the release pocket, not in the proposed pocket.
> It would be nice to see the version number of a package in the proposed
> pocket as well, if it exists.

Hi,

Note that this information is available in
https://udd.debian.org/dmd/?android-tools-devel%40lists.alioth.debian.org#versions
(for Debian)
and 
https://udd.debian.org/dmd/?android-tools-devel%40lists.alioth.debian.org#derivatives
(for Ubuntu)

- Lucas

Bug#817019: [INTL:tr] turkish translation update of postfix

[Atila KOÇ]

Package: postfix
Version: N/A
Severity: wishlist
Tags: l10n patch

Please find attached the Turkish translation of postfix package.

Regards,
Atila KOÇ
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# Atila KOÇ , 2012, 2014, 2016.
#
msgid ""
msgstr ""
"Project-Id-Version: postfix\n"
"Report-Msgid-Bugs-To: post...@packages.debian.org\n"
"POT-Creation-Date: 2016-02-26 08:05-0700\n"
"PO-Revision-Date: 2016-03-03 10:03+0200\n"
"Last-Translator: Atila KOÇ \n"
"Language-Team: Turkish \n"
"Language: tr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.5.4\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Add a 'mydomain' entry in main.cf for upgrade?"
msgstr "Yükseltme için main.cf dosyasına bir 'mydomain' girdisi eklensin mi?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"Postfix version 2.3.3-2 and later require changes in main.cf. Specifically, "
"mydomain must be specified, since hostname(1) is not a fully qualified "
"domain name (FQDN)."
msgstr ""
"Postfix'in 2.3.3-2 ve sonraki sürümleri main.cf dosyasında değişiklikler "
"yapılmasını gerektirir. hostname(1) tam tanımlanmış alan adı (FQDN) "
"olmadığından 'mydomain' girdisi özellikle tanımlanmalıdır."

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"Failure to fix this will result in a broken mailer. Decline this option to "
"abort the upgrade, giving you the opportunity to add this configuration "
"yourself. Accept this option to automatically set mydomain based on the FQDN "
"of the machine."
msgstr ""
"Bu sorunun giderilememesi çalışmayan bir posta sunucusu ile sonuçlanacaktır. "
"Bu seçeneği geri çevirip yükseltmeden vazgeçer ve bu yapılandırmayı elle "
"yürütürsünüz ya da bu seçeneği seçer ve 'mydomain' girdisinin bu makinenin "
"FQDN'sine göre belirlenmesine izin verirsiniz."

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Set smtpd_relay_restrictions in main.cf for upgrade?"
msgstr ""
"Yükseltme için main.cf dosyasındaki 'smtpd_relay_restrictions' girdisi "
"ayarlansın mı?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"Postfix version 2.10 adds smtpd_relay_restrictions, to separate relaying "
"restrictions from recipient restrictions, and you have a non-default value "
"for smtpd_recipient_restrictions."
msgstr ""
"Aktarım kısıtlamalarını alıcı kısıtlamalarından ayırmak için, Postfix 2.10 "
"sürümüne 'smtpd_relay_restrictions' girdisi eklenmiştir ve sizin girdiniz "
"öntanımlı değerden farklıdır."

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"Failure to do this may result in deferred or bounced mail after the "
"upgrade.  Accept this option to set smtpd_relay_restrictions equal to "
"smtpd_recipient_restrictions."
msgstr ""
"'smtpd_relay_restrictions' girdisini 'smtpd_recipient_restrictions' girdisi "
"ile aynı yapmak için bu seçeneği kabul edin. Aksi durumda, yükseltme "
"sonrasında geciken ya da geri dönen postalar olabilir."

#. Type: boolean
#. Description
#: ../templates:3001
msgid "Update main.cf for daemon_directory change"
msgstr ""
"main.cf dosyası 'daemon_directory' girdisi değişikliği için güncellensin mi?"

#. Type: boolean
#. Description
#: ../templates:3001
msgid ""
"This upgrade of postfix changes where daemons are located, and your postfix "
"configuration explicitly specifies the old location.  The install will be "
"aborted if you do not allow the change."
msgstr ""
"Postfix'in bu yükseltmesi alan adlarının saklandığı konumu değiştiriyor ve "
"sizin Postfix yapılandırmanız eski konumu gösteriyor. Değişikliğe izin "
"vermezseniz, kurulumdan çıkılacaktır."

#. Type: boolean
#. Description
#: ../templates:4001
msgid "Update dynamicmaps.cf for 3.0"
msgstr "dynamicmaps.cf dosyası 3.0 sürümü için güncellensin mi?"

#. Type: boolean
#. Description
#: ../templates:4001
#| msgid ""
#| "Postfix version 2.9 adds sqlite support to maps, but your dynamicmaps.cf "
#| "does not reflect that.  Accept this option to add support for sqlite maps."
msgid ""
"Postfix version 3.0 changes how dynamic maps are delivered, and your "
"dynamicmaps.cf does not reflect that.  Accept this option to convert "
"dynamicmaps.cf to the version required for 3.0."
msgstr ""
"Postfix'in 3.0 sürümü dinamik eşlemelerin dağıtılma şeklini değiştirmektedir "
"ve sizin dynamicmaps.cf dosyanız bunu yansıtmamaktadır. Bu seçeneği seçerek "
"dynamicmaps.cf dosyanızı 3.0 sürümü gereklerine dönüştürün."

#. Type: boolean
#. Description
#: ../templates:5001
#| msgid "add 'sqlite' entry to dynamicmaps.cf?"
msgid "Add 'sqlite' entry to dynamicmaps.cf?"
msgstr "dynamicmaps.cf dosyasına 'sqlite' girdisi eklensin mi?"

#. Type: boolean
#. Description
#: ../templates:5001
msgid 

Bug#783919: news on ocaml-llvm bindings ?

[Gianfranco Costamagna]

Hi, after checking all the weekend, I got ocaml bindings to build, but the 
testsuite is failing
(talking about llvm-toolchain-3.7)

the debdiff is trivial, and based on what is written on this bug report.
+   --with-ocaml-libdir=/usr/lib/ocaml/llvm-$(LLVM_VERSION) \
-   --disable-bindings \

added
ocaml-findlib, libctypes-ocaml-dev, libounit-ocaml-dev,
to build-dependencies (not sure if they are all needed, but seems so)

and the failure is following:
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
NJOBS="" LD_LIBRARY_PATH=/<>/build-llvm/Release/lib/ /usr/bin/make 
-C build-llvm check
make[2]: Entering directory '/<>/build-llvm'
llvm[2]: Running test suite
make[3]: Entering directory '/<>/build-llvm/test'
Making LLVM 'lit.site.cfg' file...
Making LLVM unittest 'lit.site.cfg' file...
( ulimit -t 1200 ; ulimit -d 512000 ; ulimit -m 512000 ; ulimit -s 8192 ; \
  /usr/bin/python /<>/utils/lit/lit.py -s -v . )
lit.py: lit.cfg:279: note: Did not find llvm-go in 
/<>/build-llvm/Release/bin
GNU ld (GNU Binutils for Debian) 2.26
-- Testing: 14188 tests, 8 threads --
Testing: 0 
FAIL: LLVM :: Bindings/OCaml/ext_exc.ml (673 of 14188)
 TEST 'LLVM :: Bindings/OCaml/ext_exc.ml' FAILED 

Script:
--
cp /<>/test/Bindings/OCaml/ext_exc.ml 
/<>/build-llvm/test/Bindings/OCaml/Output/ext_exc.ml
/usr/bin/ocamlfind ocamlc -cclib -L/<>/build-llvm/Release/lib 
-cclib -Wl,-z,relro -cclib -Wl,-z,relro -cclib -Wl,-z,relro -g -warn-error A 
-package llvm.bitreader -linkpkg 
/<>/build-llvm/test/Bindings/OCaml/Output/ext_exc.ml -o 
/<>/build-llvm/test/Bindings/OCaml/Output/ext_exc.ml.tmp
/<>/build-llvm/test/Bindings/OCaml/Output/ext_exc.ml.tmp
/usr/bin/ocamlfind ocamlopt -cclib -L/<>/build-llvm/Release/lib 
-cclib -Wl,-rpath,/<>/build-llvm/Release/lib -cclib -Wl,-z,relro 
-cclib -Wl,-z,relro -cclib -Wl,-z,relro -g -warn-error A -package 
llvm.bitreader -linkpkg 
/<>/build-llvm/test/Bindings/OCaml/Output/ext_exc.ml -o 
/<>/build-llvm/test/Bindings/OCaml/Output/ext_exc.ml.tmp
/<>/build-llvm/test/Bindings/OCaml/Output/ext_exc.ml.tmp
--
Exit Code: 1

Command Output (stderr):
--
error: Invalid bitcode signature

--


Testing: 0 
FAIL: LLVM :: Bindings/OCaml/bitreader.ml (674 of 14188)
 TEST 'LLVM :: Bindings/OCaml/bitreader.ml' FAILED 

Script:
--
cp /<>/test/Bindings/OCaml/bitreader.ml 
/<>/build-llvm/test/Bindings/OCaml/Output/bitreader.ml
/usr/bin/ocamlfind ocamlc -cclib -L/<>/build-llvm/Release/lib 
-cclib -Wl,-z,relro -cclib -Wl,-z,relro -cclib -Wl,-z,relro -g -warn-error A 
-package llvm.bitreader -package llvm.bitwriter -linkpkg 
/<>/build-llvm/test/Bindings/OCaml/Output/bitreader.ml -o 
/<>/build-llvm/test/Bindings/OCaml/Output/bitreader.ml.tmp
/<>/build-llvm/test/Bindings/OCaml/Output/bitreader.ml.tmp 
/<>/build-llvm/test/Bindings/OCaml/Output/bitreader.ml.tmp.bc
/usr/bin/ocamlfind ocamlopt -cclib -L/<>/build-llvm/Release/lib 
-cclib -Wl,-rpath,/<>/build-llvm/Release/lib -cclib -Wl,-z,relro 
-cclib -Wl,-z,relro -cclib -Wl,-z,relro -g -warn-error A -package 
llvm.bitreader -package llvm.bitwriter -linkpkg 
/<>/build-llvm/test/Bindings/OCaml/Output/bitreader.ml -o 
/<>/build-llvm/test/Bindings/OCaml/Output/bitreader.ml.tmp
/<>/build-llvm/test/Bindings/OCaml/Output/bitreader.ml.tmp 
/<>/build-llvm/test/Bindings/OCaml/Output/bitreader.ml.tmp.bc
/<>/build-llvm/Release/bin/llvm-dis < 
/<>/build-llvm/test/Bindings/OCaml/Output/bitreader.ml.tmp.bc
--
Exit Code: 1

Command Output (stderr):
--
error: Invalid bitcode signature

--


Testing: 0 
FAIL: LLVM :: Bindings/OCaml/core.ml (675 of 14188)
 TEST 'LLVM :: Bindings/OCaml/core.ml' FAILED 

Script:
--
cp /<>/test/Bindings/OCaml/core.ml 
/<>/build-llvm/test/Bindings/OCaml/Output/core.ml
/usr/bin/ocamlfind ocamlc -cclib -L/<>/build-llvm/Release/lib 
-cclib -Wl,-z,relro -cclib -Wl,-z,relro -cclib -Wl,-z,relro -g -warn-error A 
-package llvm.analysis -package llvm.bitwriter -linkpkg 
/<>/build-llvm/test/Bindings/OCaml/Output/core.ml -o 
/<>/build-llvm/test/Bindings/OCaml/Output/core.ml.tmp
/<>/build-llvm/test/Bindings/OCaml/Output/core.ml.tmp 
/<>/build-llvm/test/Bindings/OCaml/Output/core.ml.tmp.bc
/usr/bin/ocamlfind ocamlopt -cclib -L/<>/build-llvm/Release/lib 
-cclib -Wl,-rpath,/<>/build-llvm/Release/lib -cclib -Wl,-z,relro 
-cclib -Wl,-z,relro -cclib -Wl,-z,relro -g -warn-error A -package llvm.analysis 
-package llvm.bitwriter -linkpkg 
/<>/build-llvm/test/Bindings/OCaml/Output/core.ml -o 
/<>/build-llvm/test/Bindings/OCaml/Output/core.ml.tmp
/<>/build-llvm/test/Bindings/OCaml/Output/core.ml.tmp 
/<>/build-llvm/test/Bindings/OCaml/Output/core.ml.tmp.bc
/<>/build-llvm/Release/bin/llvm-dis < 
/<>/build-llvm/test/Bindings/OCaml/Output/core.ml.tmp.bc > 
/<>/build-llvm/test/Bindings/OCaml/Output/core.ml.tmp.ll
/<>/build-llvm/Release/bin/FileCheck 
/<>/test/Bi

Bug#717846: tags 717846 + fixed-upstream

[Rene Engelhard]

On Mon, Mar 07, 2016 at 03:08:03AM +0100, Stéphane Aulery wrote:
> tags 717846 + fixed-upstream
> stop
> -
> 
> I think this bug is fixed upstream because I can't reproduce it with LO
> 5.1.0.3.
> 
> We can test if it is in 5.0.5 and close the bug if there is not.

It's not really that important to know about 5.0.5 (if we do, fine, if not, ok.)
, we could also close in 5.1.0~rc3 or whatever later; 
5.0.5 as in testing is a dead branch anyway.

Regards,

Rene

Bug#816743: llvm-toolchain-3.7: powerpc and mips

[Gianfranco Costamagna]

control: tags -1 patch
control: tags -1 pending

Hi, I uploaded on deferred/2 and committed on svn the changes.

cheers,

Gianfranco

On Fri, 4 Mar 2016 10:01:08 +0100 Mathieu Malaterre  wrote:
> Package: src:llvm-toolchain-3.7
> Version: 1:3.7.1-1
> Severity: important
> Affects: src:castxml
> 
> It looks like 3.7 is targeted to be the default version (llvm-defaults
> / 0.34~exp1), so I would really like to see powerpc/mips support
> resurrected.
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#717846: Re : Bug#717846: tags 717846 + fixed-upstream

[Stéphane Aulery]

- Rene Engelhard  a écrit :
> On Mon, Mar 07, 2016 at 03:08:03AM +0100, Stéphane Aulery wrote:
> > tags 717846 + fixed-upstream
> > stop
> > -
> > 
> > I think this bug is fixed upstream because I can't reproduce it with LO
> > 5.1.0.3.
> > 
> > We can test if it is in 5.0.5 and close the bug if there is not.
> 
> It's not really that important to know about 5.0.5 (if we do, fine, if not, 
> ok.)
> , we could also close in 5.1.0~rc3 or whatever later; 
> 5.0.5 as in testing is a dead branch anyway.

Ok, it will be easier for me.

Regards,

-- 
Stéphane Aulery

Bug#817020: libopenmpi-dev: wrong symlinks with some .so

[Patrice DUROUX]

Package: libopenmpi-dev
Version: 1.10.2-8
Severity: normal

Dear Maintainer,

Here is what I got on a sid/amd64 system after installing libopenmpi-dev:

patrice@kappa2:~$ for file in liboshmem.so libopen-rte.so libopen-pal.so 
libmca_common_sm.so ; do apt-file search "$file" ; ls -l /usr/lib/"$file"* ; 
echo ; done
libopenmpi-dev: /usr/lib/liboshmem.so
libopenmpi-dev: /usr/lib/openmpi/lib/liboshmem.so
libopenmpi1.10: /usr/lib/liboshmem.so.8
libopenmpi1.10: /usr/lib/liboshmem.so.8.1.0
lrwxrwxrwx 1 root root 18 févr. 17 13:40 /usr/lib/liboshmem.so -> 
liboshmem.so.8.1.0

libopenmpi-dev: /usr/lib/libopen-rte.so
libopenmpi-dev: /usr/lib/openmpi/lib/libopen-rte.so
libopenmpi1.10: /usr/lib/libopen-rte.so.12
libopenmpi1.10: /usr/lib/libopen-rte.so.12.0.2
libopenmpi1.10: /usr/lib/openmpi/lib/libopen-rte.so.12.0.2
libopenmpi1.6: /usr/lib/libopen-rte.so.4
libopenmpi1.6: /usr/lib/libopen-rte.so.4.0.3
libopenmpi1.6: /usr/lib/openmpi/lib/libopen-rte.so.4.0.3
lrwxrwxrwx 1 root root 16 févr. 17 13:40 /usr/lib/libopen-rte.so -> 
libopen-rte.so.4
lrwxrwxrwx 1 root root 21 févr. 17 13:40 /usr/lib/libopen-rte.so.12 -> 
libopen-rte.so.12.0.2
lrwxrwxrwx 1 root root 33 févr. 17 13:40 /usr/lib/libopen-rte.so.12.0.2 -> 
openmpi/lib/libopen-rte.so.12.0.2

libopenmpi-dev: /usr/lib/libopen-pal.so
libopenmpi-dev: /usr/lib/openmpi/lib/libopen-pal.so
libopenmpi1.10: /usr/lib/libopen-pal.so.13
libopenmpi1.10: /usr/lib/libopen-pal.so.13.0.2
libopenmpi1.10: /usr/lib/openmpi/lib/libopen-pal.so.13.0.2
libopenmpi1.6: /usr/lib/libopen-pal.so.4
libopenmpi1.6: /usr/lib/libopen-pal.so.4.0.5
libopenmpi1.6: /usr/lib/openmpi/lib/libopen-pal.so.4.0.5
lrwxrwxrwx 1 root root 16 févr. 17 13:40 /usr/lib/libopen-pal.so -> 
libopen-pal.so.4
lrwxrwxrwx 1 root root 21 févr. 17 13:40 /usr/lib/libopen-pal.so.13 -> 
libopen-pal.so.13.0.2
lrwxrwxrwx 1 root root 33 févr. 17 13:40 /usr/lib/libopen-pal.so.13.0.2 -> 
openmpi/lib/libopen-pal.so.13.0.2

libopenmpi-dev: /usr/lib/libmca_common_sm.so
libopenmpi-dev: /usr/lib/openmpi/lib/libmca_common_sm.so
libopenmpi1.10: /usr/lib/libmca_common_sm.so.4
libopenmpi1.10: /usr/lib/libmca_common_sm.so.4.0.4
libopenmpi1.10: /usr/lib/openmpi/lib/libmca_common_sm.so.4.0.4
libopenmpi1.6: /usr/lib/libmca_common_sm.so.3
libopenmpi1.6: /usr/lib/libmca_common_sm.so.3.0.1
libopenmpi1.6: /usr/lib/openmpi/lib/libmca_common_sm.so.3.0.1
lrwxrwxrwx 1 root root 21 févr. 17 13:40 /usr/lib/libmca_common_sm.so -> 
libmca_common_sm.so.3
lrwxrwxrwx 1 root root 25 févr. 17 13:40 /usr/lib/libmca_common_sm.so.4 -> 
libmca_common_sm.so.4.0.4
lrwxrwxrwx 1 root root 37 févr. 17 13:40 /usr/lib/libmca_common_sm.so.4.0.4 -> 
openmpi/lib/libmca_common_sm.so.4.0.4


Strangely target for '/usr/lib/liboshmem.so' is missing and others are using 
wrong numbers.
Any clue?

Regards,
Patrice

ps: I have tried to purge and reinstall but same result.

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

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

Versions of packages libopenmpi-dev depends on:
ii  libc6   2.21-9
ii  libhwloc-dev1.11.2-3
ii  libhwloc5   1.11.2-3
ii  libibverbs-dev  1.1.8-1.1
ii  libopenmpi1.10  1.10.2-8
ii  openmpi-common  1.10.2-8

libopenmpi-dev recommends no packages.

Versions of packages libopenmpi-dev suggests:
pn  opennmpi-doc  

-- no debconf information

Bug#817021: epiphany-browser: inconsistent window management when clicking on titlebar

[Tristan McLeay]

Package: epiphany-browser
Version: 3.18.4-1
Severity: minor

Dear Maintainer,

I use Epiphany with Gnome 3. Gnome is configured to use "focus follows mouse"
(I don't know if that makes a difference).

If I click and drag on a title bar for a normal window in Gnome, the window is
*not* brought to the front. Instead, it is just moved.

However, if I click and drag on an Epiphany title bar, the window *is* brought
to the front. This is inconsistent and annoying. I do not mind which behavior
is chosen, but I would like it to be consistent.



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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=eo_AU.UTF-8, LC_CTYPE= (charmap=locale: Cannot set LC_CTYPE to 
default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages epiphany-browser depends on:
ii  dbus-x11 1.10.6-1
ii  epiphany-browser-data3.18.4-1
ii  gnome-icon-theme 3.12.0-1
ii  gnome-icon-theme-symbolic3.12.0-1
ii  gsettings-desktop-schemas3.18.1-1
ii  iso-codes3.65-1
ii  libatk1.0-0  2.18.0-1
ii  libavahi-client3 0.6.32~rc+dfsg-1
ii  libavahi-common3 0.6.32~rc+dfsg-1
ii  libavahi-gobject00.6.32~rc+dfsg-1
ii  libc62.21-9
ii  libcairo-gobject21.14.6-1
ii  libcairo21.14.6-1
ii  libgck-1-0   3.18.0-1
ii  libgcr-base-3-1  3.18.0-1
ii  libgcr-ui-3-13.18.0-1
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libglib2.0-0 2.46.2-3
ii  libgnome-desktop-3-123.18.2-1
ii  libgtk-3-0   3.18.8-1
ii  libjavascriptcoregtk-4.0-18  2.10.6-1
ii  libnotify4   0.7.6-2
ii  libnspr4 2:4.11-1
ii  libnspr4-0d  2:4.11-1
ii  libnss3  2:3.21-1.1
ii  libnss3-1d   2:3.21-1.1
ii  libp11-kit0  0.23.2-3
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libsecret-1-00.18.3-1
ii  libsoup2.4-1 2.52.2-1
ii  libsqlite3-0 3.10.2-1
ii  libwebkit2gtk-4.0-37 2.10.6-1
ii  libwnck-3-0  3.14.1-1
ii  libx11-6 2:1.6.3-1
ii  libxml2  2.9.3+dfsg1-1
ii  libxslt1.1   1.1.28-2.1

Versions of packages epiphany-browser recommends:
ii  ca-certificates  20160104
ii  evince   3.18.2-1
ii  yelp 3.16.1-1

epiphany-browser suggests no packages.

-- debconf information excluded

Bug#813916: transition: gdal

[Emilio Pozuelo Monfort]

On 07/03/16 06:50, Sebastiaan Couwenberg wrote:
> What to do about the entanglement with the libvigraimpex transition
> (#815153) through saga?
> 
> Should we get saga removed from testing to allow the rest of the
> affected packages in the gdal transition to migrate?

I'm not sure that'll be necessary, as it looks like libgdal20 can migrate while
libgdal1i stays in testing (until those issues are sorted out).

We'll see what happens once gdal is old enough, but if that's a problem, then
yes, I'll add removal hints as necessary.

Cheers,
Emilio

Bug#817003: transition: glibc

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/glibc-2.22.html

On 07/03/16 01:19, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> We would like to get a transition slot for glibc 2.22. It is currently
> available in experimental and has been built successfully on all
> official architectures except hurd-i386. We have fixed the alpha and
> hurd-i386 failures in our git, and we believe the hppa, sparc64 and
> x32 issues are due to a misconfiguration of the experimental chroots
> (the default compiler in the chroots is gcc-6). Therefore the next
> upload should build everywhere.
> 
> As the glibc is using symbol versioning, there is no soname change. That
> said a few packages are using libc internal symbols and have to be
> rebuilt for this transition:
> - apitrace
> - bro
> - dante
> - libnih
> - libnss-db
> - unscd
> 
> Here is the corresponding ben file:
> 
> title = "glibc";
> is_affected = .depends ~ /libc[0-9.]* \(< is_good = .depends ~ /libc[0-9.]* \(<< 2.23\)/;
> is_bad = .depends ~ /libc[0-9.]* \(<< 2.22\)/;
> 
> In addition to that, a few new symbols have been added that might
> prevent a few other packages to transition to testing if they pick up
> the new symbols. They are very few of them, however packages built with
> "-fopenmp -ffast-math" might pick a dependency on the new libmvec
> library on amd64 and x32.

You can go ahead as soon as you're ready.

Cheers,
Emilio

Bug#812087: [pcscd]

[Philippe Teuwen]

I recompiled libusb with debug symbols:


Normal CPU:

Thread 5 (Thread 0x7f0238fcb700 (LWP 24364)):
#0  0x7f02394dfb6d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f0238fdbafc in poll (__timeout=-1, __nfds=2,
__fds=0x7f0238fcaee0)
at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2  linux_udev_event_thread_main (arg=)
at ../../libusb/os/linux_udev.c:175
#3  0x7f02397ab284 in start_thread (arg=0x7f0238fcb700)
at pthread_create.c:333
#4  0x7f02394e8a4d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

100% CPU:

Thread 5 (Thread 0x7fbeac2a4700 (LWP 24181)):
#0 0x7fbeaca8cbdd in recvmsg () at ../sysdeps/unix/syscall-template.S:81
#1 0x7fbead2806ec in udev_monitor_receive_device ()
from /lib/x86_64-linux-gnu/libudev.so.1
#2 0x7fbeac2b4b8b in linux_udev_event_thread_main (arg=)
at ../../libusb/os/linux_udev.c:186
#3 0x7fbeaca84284 in start_thread (arg=0x7fbeac2a4700)
at pthread_create.c:333
#4 0x7fbeac7c1a4d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109



So the diff happens in that code from libusb/os/linux_udev.c:



usbi_dbg("udev event thread entering.");
while (poll(fds, 2, -1) >= 0) {
if (fds[0].revents & POLLIN) {
r = usbi_read(udev_control_pipe[0], &dummy, sizeof(dummy));
if (r <= 0) {
usbi_warn(NULL, "udev control pipe read failed");
}
break;
}
if (fds[1].revents & POLLIN) {
usbi_mutex_static_lock(&linux_hotplug_lock);
udev_dev = udev_monitor_receive_device(udev_monitor);
if (udev_dev)
udev_hotplug_event(udev_dev);
usbi_mutex_static_unlock(&linux_hotplug_lock);
}
}
usbi_dbg("udev event thread exiting");


I added error msgs in the loop.
When 100% CPU, the poll() is non-blocking and the loop becomes a busy loop.



On 03/06/2016 11:49 PM, Philippe Teuwen wrote:
> #0 0x7f196a6cabdd in recvmsg () at ../sysdeps/unix/syscall-template.S:81
> #1 0x7f196aebe6ec in udev_monitor_receive_device () from
> /lib/x86_64-linux-gnu/libudev.so.1
> #2 0x7f1969ef2bcb in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
> #3 0x7f196a6c2284 in start_thread (arg=0x7f1969ee2700) at
> pthread_create.c:333
> #4 0x7f196a3ffa4d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Bug#817009: please show Ubuntu versions in -proposed as well, if packages exist there

[Matthias Klose]

On 07.03.2016 09:29, Lucas Nussbaum wrote:

On 07/03/16 at 06:07 +0100, Matthias Klose wrote:

Package: qa.debian.org
Severity: wishlist

while looking at
https://qa.debian.org/developer.php?email=android-tools-devel%40lists.alioth.debian.org

to see why this stack didn't migrate (both in Debian and Ubuntu), I tried to
ensure first that all packages were up-to-date in Ubuntu. However this page
only shows me packages in the release pocket, not in the proposed pocket.
It would be nice to see the version number of a package in the proposed
pocket as well, if it exists.


Hi,

Note that this information is available in
https://udd.debian.org/dmd/?android-tools-devel%40lists.alioth.debian.org#versions
(for Debian)
and
https://udd.debian.org/dmd/?android-tools-devel%40lists.alioth.debian.org#derivatives
(for Ubuntu)


ok, the latter shows the needed information, but not as convenient as on the 
"main pages".  It however lacks a side by side version representation, and the 
display of both tables is divided by the "Bugs, security issues and Quality 
Assurance Checks" table, so I ended up opening the same page twice to compare 
version strings.


Matthias

Bug#800845: autopkgtest: Add support for nested VMs

[Martin Pitt]

Hello again,

Martin Pitt [2016-03-07  9:27 +0100]:
> So I'll still look into adding pre-reboot hooks, removing the drive
> there, and writing the new udev rule into /run/ instead of /etc; this
> should address the above issues.

The attached commit does that, and I tested it in a few iterations.
WDYT?

However, there's still one major issue left: Despite the
"readonly=on", one can actually mount /dev/vdb1 in the VM and write
files into it! This sounds like a QEMU bug (running
1:2.5+dfsg-5ubuntu4 here), but as long as that exists this is
dangerous as this alters your pristine base images. I already tried to
add the "readonly=on" to the "device_add", but that's just an "unknown
property". Unfortunately this stuff isn't documented very well..

Thanks,

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


signature.asc
Description: PGP signature

Bug#816969: ITP: python-motor -- Non-blocking MongoDB driver for Tornado or asyncio

[Piotr Ożarowski]

[Ondřej Nový, 2016-03-06]
> I'm going to maintain it inside DPMT. I'm DD, I need sponsor for first upload.

if you're NOT DD, then you need one not only for first upload :)

I'm interested, send me RFS email when it's ready.

Bug#812087: [pcscd]

[Philippe Teuwen]

I forgot to say, removing TEMP_FAILURE_RETRY() didn't change anything.

Bug#816991: ITP: aseqjoy -- Joystick to ALSA MIDI Sequencer Converter

[humbert . olivier . 1]

Hi,

> I working o this package on https://github.com/ftoledo/pkg-aseqjoy

I did put some a comment and made a pull request on this page.

Hope that helps
Olivier

Bug#812953: Include complete patch list in -v output

[Víctor M . Jáquez L .]

On 03/06/16 at 11:08pm, Alberto Garcia wrote:
> On Sat, Mar 05, 2016 at 01:32:32PM +0100, Alberto Garcia wrote:
> 
> > > CVE-2014-9116 is already fixed in in mutt-kz since release
> > > 1.5.23.1-2
> > 
> > Ok, thanks.
> > 
> > I think the package looks good, I would just ask you to edit the
> > changelog add a brief description of the new patches and/or the ones
> > that changed.
> 
> Never mind, it looks like Micha already uploaded the package :)

Indeed. Thanks Micha.

I have in my todo for the next release ;)

Thanks!


vmjl

Bug#816743: llvm-toolchain-3.7: powerpc and mips

[Sylvestre Ledru]

Le 07/03/2016 à 09:55, Gianfranco Costamagna a écrit :
> control: tags -1 patch
> control: tags -1 pending
>
> Hi, I uploaded on deferred/2 and committed on svn the changes.
deferred two is not needed, it trust your judgment.
Please upload it now (and check if 3.8 is affected too :)

S




signature.asc
Description: OpenPGP digital signature

Bug#816905: [php-maint] Bug#816905: RM: php-defaults -- RoQA; Name taken over by php-defaults

[Ondřej Surý]

Contro: retitle -1 RM: src:php-soap -- RoQA; Name taken over by
php-defaults

So it should be: RM: src:php-soap ?

Package: php-soap
Binary: php-soap
Version: 0.13.0-1
Maintainer: PKG-PHP-PEAR team 
Uploaders: Thierry Randrianiriana , Prach Pongpanich

Build-Depends: debhelper (>= 9), php-pear, pkg-php-tools
Architecture: all
Standards-Version: 3.9.4
Format: 3.0 (quilt)
Files:
 46d9f65ef34715f15b424283c501a845 1982 php-soap_0.13.0-1.dsc
 c8753c891f63e6875fa09db67b5d635e 85816 php-soap_0.13.0.orig.tar.gz
 2962438813773cccf2cc1dcb46389a0f 3865 php-soap_0.13.0-1.debian.tar.gz
Vcs-Browser:
http://anonscm.debian.org/gitweb/?p=pkg-php/php-soap.git;a=summary
Vcs-Git: git://anonscm.debian.org/pkg-php/php-soap.git
Checksums-Sha1:
 a3a352d316708521579c24495951e5c7336c3e27 1982 php-soap_0.13.0-1.dsc
 8e317a976e111fba1c291a197c1d359c3d851770 85816
 php-soap_0.13.0.orig.tar.gz
 42dd5905b96a7b5749f4bc61c83c72f7ae73495c 3865
 php-soap_0.13.0-1.debian.tar.gz
Checksums-Sha256:
 0e1daa66ccd0199d249c3fbd0aa81e7c6207911b7e66a77e03e270b4e52939f9 1982
 php-soap_0.13.0-1.dsc
 b088d96308da1b5160371f90f58c70f9c4cc4e67ab0b768a85e6ccb93dfadee7 85816
 php-soap_0.13.0.orig.tar.gz
 60a4bc7d872ac34b5a608601bbb1ee145cbd7c34dd06ae939e5bd901a7a77faf 3865
 php-soap_0.13.0-1.debian.tar.gz
Homepage: http://pear.php.net/package/SOAP
Package-List: 
 php-soap deb php optional
Directory: pool/main/p/php-soap
Priority: source
Section: php

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

On Sun, Mar 6, 2016, at 15:17, David Prévot wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> As expected, using the existing php-* naming scheme for the recent PHP
> transition leads to some conflicts. php-soap_0.13.0-1 vanished under
> php-defaults (providing php-soap 1:7.0+35), so there is little point
> keeping it.
> 
> php-services-weather is probably be a bit broken because of that, but we
> might get rid of it at some point anyway, see #792195.
> ___
> pkg-php-maint mailing list
> pkg-php-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

Bug#817022: RM: libjena-iri-java -- ROM; Low popcon, no interest

[Sylvestre Ledru]

Package: ftp.debian.org
Severity: normal

With a popcon of 8, not a single bug report, no interest for me
(I packaged it for a friend and he is no longer using it), outdated,
I think we can remove it from the archive.

Sylvestre

Bug#817023: os-prober doesn't detect EFI partition on MBR

[kay]

Package: os-prober
Version: 1.71

Also reproducible in os-prober 1.65

https://anonscm.debian.org/cgit/d-i/os-prober.git/tree/os-probes/mounted/x86/05efi#n42..n45

Disk has regular MBR table. It has Windows 7 and Ubuntu installed on
different partitions. Os-prober doesn't detect EFI partition on MBR
table because "udevadm info" returns "dos" partition scheme instead of
expected "msdos".

  $ udevadm info /dev/sda1 | grep dos
  E: ID_PART_ENTRY_SCHEME=dos
  E: ID_PART_TABLE_TYPE=dos

  $ fdisk -lu /dev/sda | grep -B1 -A1 ef
 Device Boot Start End Blocks Id System
  /dev/sda1 * 2048 616447 307200 ef EFI (FAT-12/16/32)
  /dev/sda2 616448 128134439 63758996 7 HPFS/NTFS/exFAT

Fixing conditions below resolves the issue:

- \( "$ID_PART_ENTRY_SCHEME" != gpt -a "$ID_PART_ENTRY_SCHEME" != msdos \) -o \
+ \( "$ID_PART_ENTRY_SCHEME" != gpt -a "$ID_PART_ENTRY_SCHEME" != dos \) -o \
  \( "$ID_PART_ENTRY_SCHEME" = gpt -a "$ID_PART_ENTRY_TYPE" !=
c12a7328-f81f-11d2-ba4b-00a0c93ec93b \) -o \
- \( "$ID_PART_ENTRY_SCHEME" = msdos -a "$ID_PART_ENTRY_TYPE" != 0xef \) ]; then
+ \( "$ID_PART_ENTRY_SCHEME" = dos -a "$ID_PART_ENTRY_TYPE" != 0xef \) ]; then

Probably this bug relates to udevinfo replacement
(https://lists.debian.org/debian-user/2010/07/msg01134.html).

P.S. Cross-posting report in ubuntu launchpad
https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1553678

Bug#816743: llvm-toolchain-3.7: powerpc and mips

[Gianfranco Costamagna]

Hi,

>deferred two is not needed, it trust your judgment.

>Please upload it now (and check if 3.8 is affected too :)


disabling polly worked really well on Ubuntu.

I'm not sure it will automagically build everywhere now, but
I have enough confidence that the failures will be fixed,
at least on release architectures.
(the failures were the same as Ubuntu, so even if I didn't directly
test debian I guess they will be fine)

I had to revert your ocaml change, because it wasn't working correctly. :)


3.8 report:

it builds everywhere on Ubuntu
https://launchpad.net/ubuntu/+source/llvm-toolchain-3.8/1:3.8~+rc2-1~exp1ubuntu2
and we are going to upload 3.8 with almost no changes (just some 
breaks+replaces)
on xenial right now
https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.8/+bug/1553923

I disabled polly on s390x (testsuite failure), but I can't sort the powerpc 
issue
dh_install: libclang-common-3.8-dev missing files: 
usr/lib/llvm-3.8/lib/clang/3.8.0/*.txt

"asan_blacklist.txt" and similar aren't generated on powerpc, not sure why.

and many others failures seems to be a bug in binutils/linker, so they should 
probably be reported.


cheers,

Gianfranco

Bug#817027: gstreamer1.0: FTBFS: LaTeX Error: File `ulem.sty' not found.

[Chris Lamb]

Source: gstreamer1.0
Version: 1.6.3-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

gstreamer1.0 fails to build from source in unstable/amd64:

  [..]

  (/usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
  (/usr/share/texlive/texmf-dist/tex/latex/latexconfig/color.cfg)
  (/usr/share/texlive/texmf-dist/tex/latex/graphics/dvips.def)
  (/usr/share/texlive/texmf-dist/tex/latex/graphics/dvipsnam.def))
  (/usr/share/texlive/texmf-dist/tex/latex/colortbl/colortbl.sty)
  (/usr/share/texlive/texmf-dist/tex/latex/marvosym/marvosym.sty)
  (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
  (/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
  (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
  (/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty)
  (/usr/share/texlive/texmf-dist/tex/latex/latexconfig/graphics.cfg)))
  (/usr/share/texlive/texmf-dist/tex/latex/tools/multicol.sty)
  
  ! LaTeX Error: File `ulem.sty' not found.
  
  [..]

The full build log is attached.


Regards,

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


gstreamer1.0.1.6.3-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#817025: fleet: FTBFS: coreos.go:26:2: cannot find package "github.com/opencontainers/runc/libcontainer/netlink

[Chris Lamb]

Source: fleet
Version: 0.11.5+dfsg1-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

fleet fails to build from source in unstable/amd64:

   dpkg-buildpackage -rfakeroot -D -us -uc -b
  dpkg-buildpackage: source package fleet
  dpkg-buildpackage: source version 0.11.5+dfsg1-3
  dpkg-buildpackage: source distribution unstable
  dpkg-buildpackage: source changed by Dmitry Smirnov 
   dpkg-source --before-build fleet-0.11.5+dfsg1
  dpkg-buildpackage: host architecture amd64
   fakeroot debian/rules clean
  dh clean --buildsystem=golang --with=golang,systemd --builddirectory=_build
 dh_testdir -O--buildsystem=golang -O--builddirectory=_build
 dh_auto_clean -O--buildsystem=golang -O--builddirectory=_build
 debian/rules override_dh_clean
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160307093644.V5UHlwQuzu/fleet-0.11.5+dfsg1'
  dh_clean
  ## Remove Files-Excluded (when built from checkout or non-DFSG tarball):
  rm -f -rv `perl -0nE 'say $1 if 
m{^Files\-Excluded\:\s*(.*?)(?:\n\n|Files:|Comment:)}sm;' debian/copyright`
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160307093644.V5UHlwQuzu/fleet-0.11.5+dfsg1'
   debian/rules build
  make: 'build' is up to date.
   fakeroot debian/rules binary
  dh binary --buildsystem=golang --with=golang,systemd --builddirectory=_build
 dh_testdir -O--buildsystem=golang -O--builddirectory=_build
 dh_update_autotools_config -O--buildsystem=golang -O--builddirectory=_build
 debian/rules override_dh_auto_configure
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160307093644.V5UHlwQuzu/fleet-0.11.5+dfsg1'
  dh_auto_configure
  perl -0nE 'say $1 if 
m{^Files\-Excluded\:\s*(.*?)(?:\n\n|Files:|Comment:)}sm;' debian/copyright \
  | while read D; do D="${D##Godeps/_workspace/src/}" ; printf 
"Removing third party bundle: $D\n" ;\
  perl -pi -E 
"s{github.com/coreos/fleet/Godeps/_workspace/src/$D}{$D}msg;" `find _build/src 
-type f -name "*.go"` ;\
  done
  Removing third party bundle: code.google.com/p/go-uuid
  Removing third party bundle: github.com/coreos/etcd
  Removing third party bundle: github.com/coreos/go-semver
  Removing third party bundle: 
~Godeps/_workspace/src/github.com/coreos/go-systemd
  Removing third party bundle: github.com/docker/libcontainer
  Removing third party bundle: github.com/godbus/dbus
  Removing third party bundle: github.com/jonboulle/clockwork
  Removing third party bundle: github.com/rakyll/globalconf
  Removing third party bundle: github.com/rakyll/goini
  Removing third party bundle: golang.org/x/crypto
  Removing third party bundle: golang.org/x/net
  Removing third party bundle: google.golang.org/api/google-api-go-generator
  Removing third party bundle: google.golang.org/api/googleapi
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160307093644.V5UHlwQuzu/fleet-0.11.5+dfsg1'
 dh_auto_build -O--buildsystem=golang -O--builddirectory=_build
go install -v github.com/coreos/fleet/fleetd 
github.com/coreos/fleet/fleetctl
  src/github.com/coreos/fleet/machine/coreos.go:26:2: cannot find package 
"github.com/opencontainers/runc/libcontainer/netlink" in any of:
/usr/lib/go/src/github.com/opencontainers/runc/libcontainer/netlink 
(from $GOROOT)

/home/lamby/temp/cdt.20160307093644.V5UHlwQuzu/fleet-0.11.5+dfsg1/_build/src/github.com/opencontainers/runc/libcontainer/netlink
 (from $GOPATH)
  dh_auto_build: go install -v github.com/coreos/fleet/fleetd 
github.com/coreos/fleet/fleetctl returned exit code 1
  debian/rules:10: recipe for target 'binary' failed
  make: *** [binary] Error 1

  [..]

The full build log is attached.


Regards,

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


fleet.0.11.5+dfsg1-3.unstable.amd64.log.txt.gz
Description: Binary data

Bug#817024: ITP: cmor-tables -- MIP tables for the Climate Model Output Rewriter library

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: cmor-tables
  Version : 1.0
  Upstream Author : Laurence Livermore Labs (LLNL), PCMDI
* URL : https://github.com/PCMDI/
* License : Public
  Programming Lang: None/XML
  Description : MIP tables for the Climate Model Output Rewriter library

 This package contains tables for use with CMOR that describe the variables  
and format of data needed for the CMIP "Coupled Model Intercomparison
  Project".
  .
  CMOR software uses these tables to verify that output is valid.

  This package is a follow-on and replacement to cmip5-cmor-tables, currently 
in Debian,
  and adds CMIP6 and other tables. The tables are copyright but publically 
available
  with license text from LLNL provided in the previous package.

Bug#817026: gstreamer0.10: FTBFS: ! LaTeX Error: File `ulem.sty' not found.

[Chris Lamb]

Source: gstreamer0.10
Version: 0.10.36-1.5
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

gstreamer0.10 fails to build from source in unstable/amd64:

  [..]

DOC   Building XML
  ./gstreamer-decl.txt:7864: warning: GstTagList has multiple definitions.
  ../../gst/gstplugin.h:297: warning: GST_PLUGIN_DEFINE_STATIC is deprecated in 
the inline comments, but no deprecation guards were found around the 
declaration. (See the --deprecated-guards option for gtkdoc-scan.)
  ../../gst/gstiterator.h:204: warning: Field description for 
GstIterator::resync is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for GstIterator::lock 
is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for GstIterator::free 
is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for 
GstIterator::pushed is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for GstIterator::type 
is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for GstIterator::next 
is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for 
GstIterator::master_cookie is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for 
GstIterator::cookie is not used from source code comment block.
  ../../gst/gstiterator.h:204: warning: Field description for GstIterator::item 
is not used from source code comment block.
  ./gstreamer-unused.txt:1: warning: 5 unused declarations.They should be added 
to gstreamer-sections.txt in the appropriate place.
DOC   Building HTML
DOC   Fixing cross-references
  html/gstreamer-GstUriHandler.html:309: warning: no link for: 
'api-index-0.10.13' -> (0.10.13).
  html/gstreamer-GstUriHandler.html:372: warning: no link for: 
'api-index-0.10.4' -> (0.10.4).
  html/gstreamer-GstUriHandler.html:506: warning: no link for: 
'api-index-0.10.33' -> (0.10.33).
  html/GstRegistry.html:424: warning: no link for: 'api-index-0.10.26' -> 
(0.10.26).
  html/GstBus.html:599: warning: no link for: 'api-index-0.10.15' -> (0.10.15).
  html/GstBus.html:644: warning: no link for: 'api-index-0.10.12' -> (0.10.12).
  html/gstreamer-GstDateTime.html:230: warning: no link for: 
'api-index-0.10.31' -> (0.10.31).
  html/gstreamer-GstValue.html:1440: warning: no link for: 'api-index-0.10.32' 
-> (0.10.32).
  html/gstreamer-Gst.html:281: warning: no link for: 'gtk-init' -> (gtk_init()).
  html/gstreamer-Gst.html:470: warning: no link for: 'api-index-0.10.10' -> 
(0.10.10).
  html/gstreamer-GstBufferList.html:462: warning: no link for: 
'api-index-0.10.24' -> (0.10.24).
  html/GstTagSetter.html:253: warning: no link for: 'api-index-0.10.22' -> 
(0.10.22).
  html/gstreamer-GstPoll.html:292: warning: no link for: 'api-index-0.10.18' -> 
(0.10.18).
  html/gstreamer-GstPoll.html:667: warning: no link for: 'api-index-0.10.23' -> 
(0.10.23).
  html/gstreamer-GstIterator.html:530: warning: no link for: 
'api-index-0.10.25' -> (0.10.25).
  html/GstElementFactory.html:871: warning: no link for: 'api-index-0.10.14' -> 
(0.10.14).
  html/gstreamer-GstInfo.html:2018: warning: no link for: 'api-index-0.10.30' 
-> (0.10.30).
  html/GstClock.html:620: warning: no link for: 'api-index-0.10.16' -> 
(0.10.16).
  html/gstreamer-GstMessage.html:1617: warning: no link for: 
'api-index-0.10.11' -> (0.10.11).
  html/gstreamer-GstMessage.html:1700: warning: no link for: 
'api-index-0.10.20' -> (0.10.20).
  html/gstreamer-GstMessage.html:3012: warning: no link for: 
'api-index-0.10.29' -> (0.10.29).
  html/gstreamer-GstMessage.html:3338: warning: no link for: 
'api-index-0.10.22.' -> (0.10.22.).
  html/gstreamer-GstMessage.html:3500: warning: no link for: 
'api-index-0.10.24.' -> (0.10.24.).
  html/GstGhostPad.html:623: warning: no link for: 'api-index-0.10.36' -> 
(0.10.36).
  html/gstreamer-GstTagList.html:4167: warning: no link for: 'GstTagImageType' 
-> (GstTagImageType).
  html/gstreamer-GstTagList.html:4168: warning: no link for: 'api-index-0.10.6' 
-> (0.10.6).
  html/gstreamer-GstTagList.html:4177: warning: no link for: 'api-index-0.10.7' 
-> (0.10.7).
  html/gstreamer-GstTagList.html:4187: warning: no link for: 
'api-index-0.10.21' -> (0.10.21).
  html/gstreamer-GstEvent.html:845: warning: no link for: 'api-index-0.10.3' -> 
(0.10.3).
  html/gstreamer-GstMiniObject.html:339: warning: no link for: 
'api-index-0.10.35' -> (0.10.35).
  html/GstPipeline.html:640: warning: no link for: 'api-index-0.10.5' -> 
(0.10.5).
  html/gstreamer-GstBuffer.html:892: warning: no link for: 'api-index-0.10.9' 
-> (0.10.9).
  html/GstXML.html:202: warning: no link for: 'FILE:CAPS' -> (FILE).
  make[6]: Leavin

Bug#817000: pymvpa2: FTBFS in stretch, build dependencies not in stretch

[Santiago Vila]

On Sun, 6 Mar 2016, Yaroslav Halchenko wrote:

> On Mon, 07 Mar 2016, Santiago Vila wrote:
> > The following packages have unmet dependencies:
> >  sbuild-build-depends-pymvpa2-dummy : Depends: swig2.0 but it is not 
> > installable or
> >swig (<= 3.0.5) but it is 
> > not going to be installed
> 
> well -- swig2.0 was removed from testing but present in sid
> 
> my guess is that pymvpa2 pkg would eventually be autoremoved from
> testing, and there is nothing for me to do about it neither now nor
> later to "close" this issue.
> 
> FWIW -- can't use swig 3.x due to
> https://github.com/swig/swig/issues/563 which could have been a
> proper 'fix'.  But as long as swig2.0 is part of the archive, issue is
> not really an issue for me to tackle.  So I will close it for now, feel
> free to reopen if you feel it would be of some value (please describe of
> which)

Ok, you reopened later but maybe I should explain a little bit:

The testing distribution is supposed to be in an "always releaseable" state.

Since packages in stable should never build-depend on packages not in stable,
it follows that packages in testing should never build-depend on packages
not in testing.

So, even if we are not going to release stretch as stable today or tomorrow,
this would still be a RC bug, i.e. a bug that must not be present in testing.

The scripts that create the testing distribution from the "pool" ensure
that dependencies are always met in testing, by construction, but I think
they do not make the same check for build-depends (yet).

So, if pymvpa2 is to be autoremoved from testing, it would be because
of RC bugs like this one being open (which is why this bug is here to
begin with), not because the testing scripts decide to remove it on
their own.

There are two common cases for bugs like this one:

* The missing build depends package is in unstable but it has not
  entered testing yet. We sort of tolerate bugs like this one (maybe
  to the point of downgrading the bug to "important" to save some
  work), because we know it is a matter of time that they get fixed.

* The missing build depends package was in testing but it was removed
  to not come back again. This is a RC bug in all cases.

As I am building packages with "dpkg-buildpackage -A" in a random
fashion, not because I use those packages myself, I don't have any
familiarity with the affected packages, so I leave to the maintainer
to decide which one of the two common cases is the one that actually
happens.

Thanks.

Bug#816896: [Pkg-mozext-maintainers] Bug#816896: xul-ext-ublock-origin: Doesn't install anything on conkeror

[John Kozak]

Sean Whitton writes:

> As with #680709, I believe that this is a bug in conkeror rather than
> xul-ext-ublock-origin.  There is an entry for Conkeror in install.rdf
> and xul-ext-ublock-origin provides
> /usr/share/mozilla/extensions/{a79fe89b-6662-4ff4-8e88-09950ad4dfde}/ublo...@raymondhill.net
> so Conkeror should find the extension.
>
> It turns out, btw, that Conkeror doesn't work with uBlock Origin at all
> atm: see .  If this
> upstream bug is not fixed, I will remove the package info implying that
> uBlock origin works with Conkeror.

Thanks - this sounds like the right thing to do.

--
John

Bug#817029: iceweasel: Program terminated with signal SIGSEGV, Segmentation fault.

[Paul Menzel]

Package: iceweasel
Version: 38.6.1esr-1~deb8u1
Severity: normal
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1254061

Dear Debian folks,


opening a Google Chromecast page, Iceweasel crashed.

I created a bug in the upstream Bugzilla bug tracker, where all further
information is attached.

The backtrace is below.

```
Core was generated by `iceweasel'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb76fdc11 in __kernel_vsyscall ()
(gdb) bt
#0  0xb76fdc11 in __kernel_vsyscall ()
#1  0xb76c7bb6 in raise (sig=11) at 
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#2  0xb42b147d in nsProfileLock::FatalSignalHandler (signo=11, info=0xaecfc8fc, 
context=0xaecfc8fc) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/profile/dirserviceprovider/nsProfileLock.cpp:180
#3  0xb46fe795 in AsmJSFaultHandler (signum=11, info=0xaecfc9cc, 
context=0xaecfca4c) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/js/src/asmjs/AsmJSSignalHandlers.cpp:940
#4  
#5  mozilla::net::nsHttp::ParseInt64 (input=0x859d "", next=0xaecfcd7c, 
r=0xaecfcd80) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttp.cpp:290
#6  0xb2e140d2 in mozilla::net::nsHttpResponseHead::ParseHeaderLine 
(this=0x84f4f880, line=0x859fffe8 "content-length") at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpResponseHead.cpp:343
#7  0xb2e14b82 in mozilla::net::nsHttpTransaction::ParseLineSegment 
(this=0x7bdabcc0,
segment=0x820db089 "x-content-type-options: nosniff\n\ncache-control: 
public, max-age=300, s-maxage=300\r\np3p: CP=\"This is not a P3P policy! See 
https://de.wikipedia.org/wiki/Spezial:CentralAutoLogin/P3P for more 
info.\"\r\nco"..., len=32)
at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:1287
#8  0xb2e14d3f in mozilla::net::nsHttpTransaction::ParseHead (this=0x7bdabcc0, 
buf=, count=938, countRead=0xaecfce34) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:1413
#9  0xb2e1634e in mozilla::net::nsHttpTransaction::ProcessData 
(this=0x7bdabcc0, buf=0x820db000 "HTTP/1.1 200 OK\n\nserver: 
nginx/1.9.4\n\ndate: Sat, 05 Mar 2016 22:33:29 GMT\n\ncontent-type: text/css; 
charset=utf-8\n\ncontent-length: 15107\n\nx-content-type-options: 
nosniff\n\ncache-control: public, max-age"...,
count=938, countRead=0xaecfcf28) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:1695
#10 0xb2e17f3c in mozilla::net::nsHttpTransaction::WritePipeSegment 
(stream=0x85368668, closure=0x7bdabcc0,
buf=0x820db000 "HTTP/1.1 200 OK\n\nserver: nginx/1.9.4\n\ndate: Sat, 05 Mar 
2016 22:33:29 GMT\n\ncontent-type: text/css; charset=utf-8\n\ncontent-length: 
15107\n\nx-content-type-options: nosniff\n\ncache-control: public, max-age"..., 
offset=0, count=32768, countWritten=0xaecfcf28)
at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:737
#11 0xb2caa49c in nsPipeOutputStream::WriteSegments (this=0x85368668, 
aReader=0xb2e17eb6 
, aClosure=0x7bdabcc0, 
aCount=32768, aWriteCount=0xaecfe038)
at /build/iceweasel-gXiQqV/iceweasel-38.6.1esr/xpcom/io/nsPipe3.cpp:1648
#12 0xb2e12c88 in mozilla::net::nsHttpTransaction::WriteSegments 
(this=0x7bdabcc0, writer=0x84fa8cc4, count=32768, countWritten=0xaecfe038) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpTransaction.cpp:755
#13 0xb2dc7d9b in mozilla::net::SpdyStream31::WriteSegments (this=0x84fa8cc0, 
writer=0x7afe4410, count=32768, countWritten=0xaecfe038) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/SpdyStream31.cpp:231
#14 0xb2de58f1 in mozilla::net::SpdySession31::WriteSegments (this=0x7afe4400, 
writer=0x3afc, count=32768, countWritten=0xaecfe038) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/SpdySession31.cpp:2168
#15 0xb2e0c83a in mozilla::net::nsHttpConnection::OnSocketReadable 
(this=0x832fc5b0) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpConnection.cpp:1736
#16 0xb2e0d195 in mozilla::net::nsHttpConnection::OnInputStreamReady 
(this=0x832fc5b0, in=0x7c7e0998) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/protocol/http/nsHttpConnection.cpp:2046
#17 0xb2d1d5bf in nsSocketInputStream::OnSocketReady (this=0x7c7e0998, 
condition=NS_OK) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/base/nsSocketTransport2.cpp:283
#18 0xb2d265b6 in nsSocketTransport::OnSocketReady (this=0x7c7e08a0, 
fd=0x82644c40, outFlags=1) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/base/nsSocketTransport2.cpp:1833
#19 0xb2d33eb7 in nsSocketTransportService::DoPollIteration (this=0xb7163b80, 
wait=true) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/base/nsSocketTransportService2.cpp:900
#20 0xb2d34073 in nsSocketTransportService::Run (this=0xb7163b80) at 
/build/iceweasel-gXiQqV/iceweasel-38.6.1esr/netwerk/base/nsSocketTransportService2.cpp:732
#21 0xb2cb7936 in

Bug#817028: RFP: dolphin -- [SHORT DESCRIPTION]

[Valerio Passini]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

--- Please fill out the fields below. ---
Hello,

As in the subject, Copy/Paste with folders works well among different windows 
of Dolphin, but has problems when trying to perform the same action between 
two panels in split view. To activate the bug you must change in someway the 
content inside a folder and then try to C/P it somewhere. The workaround is to 
force refresh of the view (press F5).

Valerio

   Package name: dolphin
Version: 4:15.08.3-1
Upstream Author: [NAME ]
URL: [http://example.com]
License: [GPL, LGPL, BSD, MIT/X, etc.]
Description: [DESCRIPTION]
-- 
Valerio

Bug#817016: linux-image-4.3.0-1-amd64: ThinkPad X1 Carbon: Boot stalls at "intel_pstate: HWP enabled"

[Ian Campbell]

Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=110941

On Mon, 2016-03-07 at 07:46 +, Andy Smith wrote:
> Package: src:linux
> Version: 4.3.5-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Booting this kernel (or the debian-installer latest daily) results in a blank
> screen. When removing the quiet option the boot is seen to stall after 
> printing
> "intel_pstate: HWP enabled".
> 
> Here's a screenshot: http://i.imgur.com/cr5i72L.png
> 
> Searching around found me another report from a Yoga 260 owner with the same
> issue. They've got a Skylake i5 whereas I've got a Skylake i7. A suggested
> workaround was to use kernel parameter:
> 
>   intel_pstate=no_hwp
> 
> This allowed boot of the debian-installer and this installed kernel but I
> understand it disables many desirable power efficiency features.

FWIW I also tipped over this on an X1 carbon.

Looks like it is being investigated at https://bugzilla.kernel.org/show
_bug.cgi?id=110941

Ian.

Bug#817009: please show Ubuntu versions in -proposed as well, if packages exist there

[Lucas Nussbaum]

On 07/03/16 at 10:22 +0100, Matthias Klose wrote:
> On 07.03.2016 09:29, Lucas Nussbaum wrote:
> >On 07/03/16 at 06:07 +0100, Matthias Klose wrote:
> >>Package: qa.debian.org
> >>Severity: wishlist
> >>
> >>while looking at
> >>https://qa.debian.org/developer.php?email=android-tools-devel%40lists.alioth.debian.org
> >>
> >>to see why this stack didn't migrate (both in Debian and Ubuntu), I tried to
> >>ensure first that all packages were up-to-date in Ubuntu. However this page
> >>only shows me packages in the release pocket, not in the proposed pocket.
> >>It would be nice to see the version number of a package in the proposed
> >>pocket as well, if it exists.
> >
> >Hi,
> >
> >Note that this information is available in
> >https://udd.debian.org/dmd/?android-tools-devel%40lists.alioth.debian.org#versions
> >(for Debian)
> >and
> >https://udd.debian.org/dmd/?android-tools-devel%40lists.alioth.debian.org#derivatives
> >(for Ubuntu)
> 
> ok, the latter shows the needed information, but not as convenient as on the
> "main pages".  It however lacks a side by side version representation, and
> the display of both tables is divided by the "Bugs, security issues and
> Quality Assurance Checks" table, so I ended up opening the same page twice
> to compare version strings.

Note that there's a json export available, so it should be fairly easy
to write a small script that computes exactly what you want.

Lucas

Bug#800845: autopkgtest: Add support for nested VMs

[Christian Seiler]

On 03/07/2016 10:21 AM, Martin Pitt wrote:
> Martin Pitt [2016-03-07  9:27 +0100]:
>> So I'll still look into adding pre-reboot hooks, removing the drive
>> there, and writing the new udev rule into /run/ instead of /etc; this
>> should address the above issues.
> 
> The attached commit does that, and I tested it in a few iterations.
> WDYT?

Seems good to me. It's a bit unintuitive that device_del also
undoes the drive_add bit, but your code is correct.

I've tested this with my open-iscsi nested tests (see my RFC
to pkg-autopkgtest-devel) and it works out of the box. I also
did a bit of testing with --shell and it seems to work just
fine.

I've attached a patch that updates the man page a bit to make
the current semantics you are using clearer.

> However, there's still one major issue left: Despite the
> "readonly=on", one can actually mount /dev/vdb1 in the VM and write
> files into it! This sounds like a QEMU bug (running
> 1:2.5+dfsg-5ubuntu4 here), but as long as that exists this is
> dangerous as this alters your pristine base images. I already tried to
> add the "readonly=on" to the "device_add", but that's just an "unknown
> property". Unfortunately this stuff isn't documented very well..

I get (w/ qemu-system 1:2.5+dfsg-4~bpo8+1) with current git master
(no changes):
mount: /dev/vdb1 is write-protected, mounting read-only

So I can't really reproduce it. :-(

Looking at the changelog of QEMU between Debian and Ubuntu, there's
also nothing there that would affect this - on the Ubuntu side it's
stuff related to CPU flags and defining additional machine types.

Question: what happens if you do a sync() after writing? Does it
really get written or is it just that your kernel doesn't properly
detect the read-only-ness and modifies the page-cache, not
realizing that the subsequent writes will fail? If it's the latter,
since it is documented that it's read-only, I wouldn't consider
that an issue.

If it's the former, there's an easy workaround: keep the readonly
flag regardless, but create another QEMU overlay for the case that
it doesn't work, and throw the overlay away at reboots - that way,
if a guest does write to it, it's their own fault.

(Note that if this really is buggy on your end, this would be a
real problem for additional images specified on the command line,
because those are also added with readonly=on!)

Regards,
Christian
From d1e18afbf5bbab08c9f05e5c9a235cd5e6037822 Mon Sep 17 00:00:00 2001
From: Christian Seiler 
Date: Mon, 7 Mar 2016 11:21:45 +0100
Subject: [PATCH] Make semantics of /dev/baseimage a bit clearer in manpage.

---
 virt-subproc/adt-virt-qemu.1 | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/virt-subproc/adt-virt-qemu.1 b/virt-subproc/adt-virt-qemu.1
index ea8ef21..2124b2c 100644
--- a/virt-subproc/adt-virt-qemu.1
+++ b/virt-subproc/adt-virt-qemu.1
@@ -29,7 +29,11 @@ primary image, and add all other images as read-only.
 The first image without the overlay is always added as an additional
 read-only hard drive, which will be available for tests as
 .IR /dev/baseimage .
-This allows tests that require nested VMs to reuse the same image.
+This allows tests that require nested VMs to reuse the same image. Be
+aware that the image will not be accessible during reboots of the
+testbed; before requesting a reboot of the testbed, all access to this
+image should cease and may be resumed only after test execution
+continues.
 
 .SH REQUIREMENTS
 .B adt-virt-qemu
-- 
2.1.4



signature.asc
Description: OpenPGP digital signature

Bug#816587: shared-mime-info: FTBFS: LaTeX Error: File `ulem.sty' not found.

[Sebastian Dröge]

reassign 816587 docbook-utils
reassign 817026 docbook-utils
reassign 817027 docbook-utils
forcemerge 816587 817026 817027
thanks

On Do, 2016-03-03 at 10:45 +0200, Sebastian Dröge wrote:
> On Do, 2016-03-03 at 08:36 +, Chris Lamb wrote:
> > 
> > Source: shared-mime-info
> > Version: 1.5-2
> > Severity: serious
> > Justification: fails to build from source
> > User: reproducible-bui...@lists.alioth.debian.org
> > Usertags: ftbfs
> > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> > 
> > Dear Maintainer,
> > 
> > shared-mime-info fails to build from source in unstable/amd64:
> Yes, for whatever reason texlive-generic-recommended is not
> automatically pulled in anymore. Should check first if this was
> intentional.

docbook-utils' docbook2pdf needs ulem.sty from texlive-generic-
recommended. At some point something in the texlive dependencies
changed so it's not automatically pulled in anymore.

Means that either that texlive change has to be reverted, or docbook-
tools has to depend on texlive-generic-recommended.

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

Bug#817030: cryptsetup: no keyscripts support in conjunction with systemd

[Christian Pernegger]

Package: cryptsetup
Version: 2:1.6.6-5
Severity: important

Hi,

At least since jessie (I've pretty much skipped wheezy on the affected
systems) keyscripts do not work, unless handled in the initramfs. So
everything needed for the rootfs is fine, as is anything tagged with
the initramfs option, all other cases are broken.

Apparently this is because systemd doesn't support keyscripts and
upstream are unwilling to add support because it only ever was a
Debian extension. Regardless, there's an open bug against systemd
(#618862) but none against cryptsetup. Why? Cryptsetup has provided
the functionality before, it still does in the initramfs, but it
doesn't anymore in the running system. To me, that's a bug in
cryptsetup.

More importantly, why can't keyscript support be added back to the
running system? How about
* cryptsetup checks crypttab for unsupported options during
configure and offers to handle it (instead of systemd) if any are
found [covers migrations]
* the documentation is updated to clearly state which options and
scenarios are systemd-safe (or not) [new installs]
* provide a debconf switch "Should encrypted blockdevices in
/etc/crypttab be handled by cryptsetup (instead of systemd)?" to
switch manually.

(I don't know if cryptsetup can also add the kernel parameters to
disable systemd's dm-crypt support in a clean way, if not just print a
loud message.)


I reckon there wasn't more of an outcry over this because encrypted
root still works for now and later cryptdisks are much less likely to
require keyscripts. But
1) having to put "initramfs" for everything is ugly and potentially
causes boot failures even though the device(s) in question aren't
critical at all.
2) I dread the day someone decides to drop "all that legacy cruft from
initramfs handling" because "systemd does it all anyway, right?" --
because that's the day all my systems become unbootable. And that's
not something I want to have to deal with in a stable-stable update.


Regards,
Christian


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

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

Versions of packages cryptsetup depends on:
ii  cryptsetup-bin 2:1.6.6-5
ii  debconf [debconf-2.0]  1.5.56
ii  dmsetup2:1.02.90-2.2
ii  libc6  2.19-18+deb8u3

Versions of packages cryptsetup recommends:
ii  busybox 1:1.22.0-9+deb8u1
ii  console-setup   1.123
ii  initramfs-tools [linux-initramfs-tool]  0.120
ii  kbd 1.15.5-2

Versions of packages cryptsetup suggests:
pn  dosfstools  
pn  keyutils
ii  liblocale-gettext-perl  1.05-8+b1

-- debconf information:
  cryptsetup/prerm_active_mappings: true

Bug#770320: reassign to apt

[Peter Palfrader]

reassign 770320 apt
thanks

ISTR that this was/is an apt issue.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#817030: [pkg-cryptsetup-devel] Bug#817030: cryptsetup: no keyscripts support in conjunction with systemd

[Guilhem Moulin]

Control: tag 800147 - moreinfo
Control: merge -1 800147

Hi,

On Mon, 07 Mar 2016 at 11:46:29 +0100, Christian Pernegger wrote:
> Apparently this is because systemd doesn't support keyscripts and
> upstream are unwilling to add support because it only ever was a
> Debian extension. Regardless, there's an open bug against systemd
> (#618862) but none against cryptsetup.

There is #800147 already.  Quoting Jonas' Message #17:

   “What we need to do is take a look at the systemd cryptsetup
implementation and understand how it works. Probably it's possible
to leave the dm-crypt unlocking to systemd whenever the required
features are available and pass the task to the old initscript only
when additional features (e.g. like keyscript) are required.
Otherwise we would have to disable the systemd cryptsetup/dm-crypt
processing features and stick to the init script for now.

In the long term, implementing the missing features in the systemd
code should be the way to go.”

-- 
Guilhem.

Bug#803867: vdr-plugin-softhddevice: FTBFS with FFmpeg 2.9

[Harald Gutmann]

Dear Andreas Cadhalpun,

thank you for providing the patch to fix the FTBFS for ffmepg >=2.9.
With your patch applied I've runtime-tested the plugin, and so far not 
discovered any problem during usage.


Issues only arise, when the plugin is compiled with debug enabled. Then 
at runtime the following error is produced:
vdr: /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.2.0: undefined 
symbol: av_get_AV_PIX_FMT_name


Your patch introduces av_get_AV_PIX_FMT_name instead of 
"av_get_pix_fmt_name" in several lines:
330:++  Debug(3, "\t%#010x %s\n", *fmt_idx, 
av_get_AV_PIX_FMT_name(*fmt_idx));
350:++Debug(3, "\t%#010x %s\n", fmt_idx[0], 
av_get_AV_PIX_FMT_name(fmt_idx[0]));
471:++  Debug(3, "\t%#010x %s\n", *fmt_idx, 
av_get_AV_PIX_FMT_name(*fmt_idx));
503:++Debug(3, "\t%#010x %s\n", fmt_idx[0], 
av_get_AV_PIX_FMT_name(fmt_idx[0]));


Keeping the lines as original, the Debug flag enabled works as expected. 
Therefore I suggest, to re-check and / or revert this particular 
modification.


Many thanks in advance.


Kind regards,
Harald Gutmann



On Mon, 2 Nov 2015 22:08:55 +0100 Andreas Cadhalpun 
 wrote:

> Package: vdr-plugin-softhddevice
> Version: 0.6.0+git20150324-2
> Severity: important
> Tags: patch
> User: pkg-multimedia-maintain...@lists.alioth.debian.org
> Usertags: ffmpeg2.9
>
> Dear Maintainer,
>
> your package fails to build with the upcoming ffmpeg 2.9.
> This bug will become release-critical at some point when the
> ffmpeg2.9 transition gets closer.
>
> Attached is a patch replacing the deprecated functionality.
> It also works with ffmpeg 2.8.
> Please apply this patch and forward it upstream, if necessary.
>
> These changes are non-trivial and should be runtime-tested.
>
> Best regards,
> Andreas
>

Bug#817031: RFP: ots -- OpenType Sanitiser

[Paul Wise]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-fonts-de...@lists.alioth.debian.org
User: check-all-the-thi...@packages.debian.org
Usertags: new-check
Control: affects -1 check-all-the-things

* Package name: ots
  Version : 5.0.0
  Upstream Author : Khaled Hosny 
* URL : https://github.com/khaledhosny/ots
* License : BSD
  Programming Lang: C++
  Description : OpenType Sanitiser

The OpenType Sanitiser (OTS) parses and serialises OpenType files,
validating them and sanitising them as it goes.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#816718: tracker.d.o: missing bugs information?

[Raphael Hertzog]

Control: retitle -1 ensure bugs data does not get dropped when UDD is down
Control: severity -1 wishlist

On Fri, 04 Mar 2016, Sandro Tosi wrote:
> Hello,
> visiting https://tracker.debian.org/pkg/matplotlib i dont see any information
> about the bugs reported against that pkg (and sadly it's not bug free).
> 
> could you check?

Yes, that was due to UDD being down with the recent problems. I agree
though that a failing UDD should not result in bugs data being dropped.
So we should double check that part of the code.

Weirdly the code seems to not have generated an exception, it's like
the connection worked but returned some empty page...

But it might make sense to not accept an empty response as valid.

The only exceptions that I got as notification where the following:


Problem processing a task.
Traceback (most recent call last):
  File "/srv/tracker.debian.org/distro-tracker/distro_tracker/core/tasks.py", 
line 518, in run
task.execute()
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/vendor/debian/tracker_tasks.py",
 line 1670,
in execute
stats = self.get_release_goals_stats()
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/vendor/debian/tracker_tasks.py",
 line 1607,
in get_release_goals_stats
content = self._get_release_goals_content()
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/vendor/debian/tracker_tasks.py",
 line 1601,
in _get_release_goals_content
bugs_list_url, force=self.force_update)
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/core/utils/http.py", 
line 146, in update
allow_redirects=True)
  File "/usr/lib/python2.7/dist-packages/requests/api.py", line 60, in get
return request('get', url, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/api.py", line 49, in request
return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 457, in 
request
resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 569, in 
send
r = adapter.send(request, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 407, in 
send
raise ConnectionError(err, request=request)
ConnectionError: ('Connection aborted.', error(110, 'Connection timed out'))

Request repr(): unavailable

Problem processing a task.
Traceback (most recent call last):
  File "/srv/tracker.debian.org/distro-tracker/distro_tracker/core/tasks.py", 
line 518, in run
task.execute()
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/vendor/debian/tracker_tasks.py",
 line 1778,
in execute
package_versions = self.get_ubuntu_versions()
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/vendor/debian/tracker_tasks.py",
 line 1712,
in get_ubuntu_versions
for line in content.splitlines():
AttributeError: 'NoneType' object has no attribute 'splitlines'

Request repr(): unavailable





Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#816611: RFS: yamllint/1.0.3-1 [ITP] -- A linter for YAML files

[Adrien Vergé]

2016-03-05 3:28 GMT+01:00 Paul Wise :
> There was one issue to fix, I've taken the liberty of doing that myself.

Thanks.

> Add a manual page, you can do that automatically using either sphinx
> and sphinxcontrib-autoprogram or python3-sphinx-argparse.

Good idea. I did this in my local package, should I upload it on
mentors again? Or wait for the package to be published to unstable?
(Sorry, first package on Debian.)

> The URLs in the Vcs-* fields are 404 (see duck output below), probably
> you need to point them at the right branch in the github repo.
>
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields
> https://github.com/adrienverge/yamllint/tree/packaging/

Actually the branch on GitHub is temporary. I thought
git://anonscm.debian.org/collab-maint/yamllint.git was going to be
created once the package is uploaded, isn't it the case? If not,
should I remove the Vcs-* tags?

Thanks again for your help.

Bug#702122: mirrors: add debian-mirror.sakura.ne.jp to syncproxy leaf

[Peter Palfrader]

On Sun, 03 Mar 2013, Hideki Yamane wrote:

> 
>  Some of you may know, I've started debian-mirror.sakura.ne.jp.
>  
> http://henrich-on-debian.blogspot.com/2013/02/introducing-debian-mirrorsakuranejp.html
> 
>  Now it is pushed-mirror under hanzubon.jp, and I think it's better to be 
> pushed 
>  from upstream syncproxy if we can.

Is this request still standing?

The closes syncproxy to .jp would be in the US, syncproxy2.wna.debian.org

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#817030: [pkg-cryptsetup-devel] Bug#817030: cryptsetup: no keyscripts support in conjunction with systemd

[Christian Pernegger]

2016-03-07 12:01 GMT+01:00 Guilhem Moulin :
> There is #800147 already.

I think I'll lay off reporting bugs for a while now. The last few I
missed were at least archived and did not show up in reportbug, this
one did (it was still in the scroll buffer) ... I'm sorry. Does "It's
Monday morning" count as an excuse?"

Maybe just count it as an additional vote for doing something about this, then.

>  Quoting Jonas' Message #17:
> Otherwise we would have to disable the systemd cryptsetup/dm-crypt
> processing features and stick to the init script for now.

But that was sort of my point. Why not *just* stick to the init script
for now and switch on the systemd implementation if and when the
needed functionality is available upstream?

Regards,
Christian

Bug#795270: re

[Liza Kell]

I have a proposal for you kindly E-mail me at mrsshuai...@hotmail.com

Yours Faithfully
Mrs Huian Shao
















__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

Bug#817032: postfix: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: postfix 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch translation of postfix debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Cheers,
Frans

===
http://home.base.be/vt6362833/



nl.po.gz
Description: application/gzip


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

Bug#816607: Simplified steps

[Mathieu Malaterre]

Here are the simplified steps:

$ gunzip encoderstrategy.pgm.gz
$ gdcmimg encoderstrategy.pgm encoderstrategy.dcm
$ dcmcjpls encoderstrategy.dcm compressed.dcm
dcmcjpls: /tmp/buildd/charls-1.0/encoderstrategy.h:81: void
EncoderStrategy::AppendToBitStream(LONG, LONG): Assertion `bitpos >=0'
failed.
Aborted


encoderstrategy.pgm.gz
Description: GNU Zip compressed data

Bug#816183: iceowl-extension: cannot create new calendar

[Carsten Schoenert]

Hello,

On Sun, Mar 06, 2016 at 11:53:22AM +0100, W Forum W wrote:
> Hi Carsten,
> Thanks for the help.
> It seems to be an add-on.
> With this add-on disabled it works again

if this is a packaged plugin we could assign this report to the source
package. Otherwise I would close this report.

PS: Please don't top post.

Regards
Carsten

Bug#73611: re

[Liza Kell]

I have a proposal for you kindly E-mail me at mrrsshhui7...@hotmail.com
Yours Faithfully
Mrs Huian Shao
















__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

Bug#817033: sumo: FTBFS when built with dpkg-buildpackage -A (in a random way)

[Santiago Vila]

Package: src:sumo
Version: 0.25.0+dfsg1-2
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel --with autoreconf
   dh_testdir -i -O--parallel
   dh_update_autotools_config -i -O--parallel
   dh_autoreconf -i -O--parallel
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
libtoolize: 'AC_PROG_RANLIB' is rendered obsolete by 'LT_INIT'
configure.ac:37: installing './compile'
configure.ac:10: installing './missing'
src/Makefile.am: installing './depcomp'
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/sumo-0.25.0+dfsg1'
dh_auto_configure -- --prefix=/usr
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu 
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode 
--disable-dependency-tracking --prefix=/usr
configure: WARNING: unrecognized options: --disable-maintainer-mode
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '924' is supported by ustar format... yes
checking whether GID '924' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... none
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for ranlib... ranlib
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu 
format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... 
func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... (cached) ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for ANSI C header files... no
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static

Bug#816611: RFS: yamllint/1.0.3-1 [ITP] -- A linter for YAML files

[Paul Wise]

On Mon, 2016-03-07 at 12:16 +0100, Adrien Vergé wrote:

> Good idea. I did this in my local package, should I upload it on
> mentors again? Or wait for the package to be published to unstable?
> (Sorry, first package on Debian.)

I would suggest that you make this and other upstream changes in the
upstream git repository and upload a new version to mentors when you
make a new release.

On that note, please file new RFS bugs for future uploads.


> Actually the branch on GitHub is temporary. I thought
> git://anonscm.debian.org/collab-maint/yamllint.git was going to be
> created once the package is uploaded, isn't it the case? If not,
> should I remove the Vcs-* tags?

collab-maint repos are only manually created, perhaps you were thinking
of dgit, but that is also manual creation.

https://wiki.debian.org/Teams/CollabMaint
https://browse.dgit.debian.org/

I suggest keeping the Vcs-* fields but pointing them at the place where
you intend to maintain the packaging, so either github or collab-maint.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#817003: transition: glibc

[Aurelien Jarno]

On 2016-03-07 10:17, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> Control: forwarded -1 
> https://release.debian.org/transitions/html/glibc-2.22.html
> 
> On 07/03/16 01:19, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear release team,
> > 
> > We would like to get a transition slot for glibc 2.22. It is currently
> > available in experimental and has been built successfully on all
> > official architectures except hurd-i386. We have fixed the alpha and
> > hurd-i386 failures in our git, and we believe the hppa, sparc64 and
> > x32 issues are due to a misconfiguration of the experimental chroots
> > (the default compiler in the chroots is gcc-6). Therefore the next
> > upload should build everywhere.
> > 
> > As the glibc is using symbol versioning, there is no soname change. That
> > said a few packages are using libc internal symbols and have to be
> > rebuilt for this transition:
> > - apitrace
> > - bro
> > - dante
> > - libnih
> > - libnss-db
> > - unscd
> > 
> > Here is the corresponding ben file:
> > 
> > title = "glibc";
> > is_affected = .depends ~ /libc[0-9.]* \(< > is_good = .depends ~ /libc[0-9.]* \(<< 2.23\)/;
> > is_bad = .depends ~ /libc[0-9.]* \(<< 2.22\)/;
> > 
> > In addition to that, a few new symbols have been added that might
> > prevent a few other packages to transition to testing if they pick up
> > the new symbols. They are very few of them, however packages built with
> > "-fopenmp -ffast-math" might pick a dependency on the new libmvec
> > library on amd64 and x32.
> 
> You can go ahead as soon as you're ready.

Thanks for the quick answer, I have just uploaded it to unstable.

Aurelien

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

Bug#816557: ITP: gspell -- spell-checking library for GTK

[Tanguy Ortolo]

Packaging work in progress can be checked out at 
.



There is an issue to solve with API breakage without SONAME bump: the 
gspell project show two “development” branches numbered 0.1.* and 0.2.*, 
both of them providing libgspell-1.so.0.0.0, but with an incompatible 
API.


Problem is, another software, LaTeXila, has a dependency against the 
“0.0.0” API from branch 0.1.* only…



I am checking with the upstream maintainer to see what can be done about 
that. I think there are two possibilities:

1. change the SONAME in Debian, so:
  - branch 0.1.* will provide libgspell-1.so.0.1.0 (Debian package 
libgspell1-0.1),
  - branch 0.2.* will provide libgspell-1.so.0.2.0 (Debian package 
libgspell1-0.2);
2. consider these as temporary versions only to be used by LaTeXila 
  (which is the software this library was written for) and package 
  branch 0.1.* to provide libgspell-1.so.0.0.0 (Debian package 
  libgspell1-0), never package branch 0.2.*, and wait for an API 
  version 1.*.


--
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


signature.asc
Description: Digital signature

Bug#804992: mysql-server-5.6: Please drop dependency on initscripts package

[Robie Basak]

Hi Felipe,

On Fri, Mar 04, 2016 at 04:33:20PM -0300, Felipe Sateler wrote:
> It seems that the dependency is a leftover from the /run transition.
> The version was dropped without explanation when updating to 5.6 from
> 5.5[1], probably because the version was satisfied in stable already.
> Please drop the dependency both here and in 5.5.

Thanks for doing that research. We're working on 5.7 at the moment, and
I've dropped the dependency in my local branch but not pushed it yet. So
this should get fixed in testing and unstable soon, when we upload 5.7.

5.5 is pending removal (#811158) so we won't fix it there. I presume
this isn't severe enough to justify fixing in stable?

Robie

Bug#817033: sumo: FTBFS when built with dpkg-buildpackage -A (in a random way)

[Santiago Vila]

On Mon, Mar 07, 2016 at 11:48:40AM +, Santiago Vila wrote:
> The following trivial patch disables parallel building. I have not tested it
> but I have the strong feeling that this should fix this issue.

Unfortunately, it was just a feeling.

I actually tested the patch and it didn't work on the machine where it usually 
fails.

So this needs to be investigated.

Thanks.

Bug#810968: Fwd: [debian-mysql] Bug#810968: Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)

[Sergey Vojtovich]

Hi Lennart,

First, thanks for reporting this problem back to us and for suggested fix.

> March 3 2016 9:35 PM, "Otto Kekäläinen"  wrote:
> > Hello Lennart!
> >
> > I asked core developers to review this and got this reply:
> >
> > It's probably alright for 10.0. But it's not completely suitable for 10.1.
> > As contributor mentioned himself that there's a problem with this patch:
> > "When mysqld is called without mysqld_safe".
> >
> > I'd rather simplify this script to something like (not tested):
> > if [ -x /var/run/mysqld/mysqld.pid ]; then
> > $MYADMIN flush-logs || exit 1
> > fi
> >
> > What do you think?
> 
> The line would result in some other issues. But the general idea was
> already tossed around
> here before. Assume pid file location and then check if the process
> running on the pid
> is named mysqld.
> 
> I don't really see an issue with my current version either though. In
> case that the mysqld_safe script
> will be abandoned in the future a lot of the configuration files and
> init scripts/unit files
> need to be updated anyhow. And the only change here would be removing
> one layer in the hierachy.
In MariaDB 10.1 we introduced optional support for systemd. That is parent
process can be either systemd or mysqld_safe. Also I'm reluctant having
different versions of logrotate script in 10.0 and 10.1.

> 
> From:
> PPID=$(ps -o ppid= -p $PID)
> if [ $(ps -p $PPID -o comm=) = mysqld_safe ]; then
>   test $(ps -o ppid= -p  $PPID) -eq 1 && exit 1
> fi
> 
> To:
> test $(ps -o ppid= -p $PID) -eq 1 && exit 1
> 
> But if you are fine with just checking the PID file at a static
> location something like the attached patch should be fine.
I consider it lesser evil. You may use my_print_defaults to get
pid-file value.

Worth to note that I don't see any value in executing "mysqladmin ping".

Regards,
Sergey

Bug#816479: closed by Sebastian Reichel (Bug#816479: fixed in tt-rss 15.7+git20151123+dfsg-2)

[Sebastian Reichel]

Hi,

On Fri, Mar 04, 2016 at 10:52:55AM +0100, Fredrik Olofsson wrote:
> Thanks, the dependencies works better now :-)
> 
> But I still get the following error when trying to start the daemon.
> Looks like some kind o search path issue, but I don't know PHP well
> enough to fix it.

mh... I cannot reproduce your bug (It works for me).

> ...
> PHP Fatal error:  Uncaught Error: Class 'Db_Prefs' not found in
> /usr/share/tt-rss/www/include/db-prefs.php:5
> Stack trace:
> #0 /usr/share/tt-rss/www/include/digest.php(29):
> get_pref('DIGEST_ENABLE', '1', false)
> #1 /usr/share/tt-rss/www/include/rssfuncs.php(219): 
> send_headlines_digests(true)
> #2 /usr/share/tt-rss/www/update.php(187): update_daemon_common(50)
> #3 {main}
>   thrown in /usr/share/tt-rss/www/include/db-prefs.php on line 5
> ...

So classes/db/prefs.php is not loaded. It should be autoloaded
by the __autoload() function in include/autoload.php. Could you
add some debug prints in there? E.g. replace this part:

---
if (file_exists($file)) {
require $file;
}
---

with

---
if (file_exists($file)) {
_debug("autoload class: $file");
require $file;
} else {
_debug("cannot find class: $file");
}
---

-- Sebastian


signature.asc
Description: PGP signature

Bug#804992: mysql-server-5.6: Please drop dependency on initscripts package

[Felipe Sateler]

Hi Robie,

On 7 March 2016 at 09:07, Robie Basak  wrote:
> Hi Felipe,
>
> On Fri, Mar 04, 2016 at 04:33:20PM -0300, Felipe Sateler wrote:
>> It seems that the dependency is a leftover from the /run transition.
>> The version was dropped without explanation when updating to 5.6 from
>> 5.5[1], probably because the version was satisfied in stable already.
>> Please drop the dependency both here and in 5.5.
>
> Thanks for doing that research. We're working on 5.7 at the moment, and
> I've dropped the dependency in my local branch but not pushed it yet. So
> this should get fixed in testing and unstable soon, when we upload 5.7.

Excellent! I don't know how many versions you plan to keep for
stretch, if 5.6 is to be part of it, please remember to fix it there
as well.

>
> 5.5 is pending removal (#811158) so we won't fix it there. I presume
> this isn't severe enough to justify fixing in stable?

No, there is no point in fixing in stable. A key part of the
dependency removal needed a change in update-rc.d that will not be
backported.


-- 

Saludos,
Felipe Sateler

Bug#804992: mysql-server-5.6: Please drop dependency on initscripts package

[Robie Basak]

On Mon, Mar 07, 2016 at 09:26:43AM -0300, Felipe Sateler wrote:
> Excellent! I don't know how many versions you plan to keep for
> stretch, if 5.6 is to be part of it, please remember to fix it there
> as well.

We expect to ship only one version, so hopefully 5.7 and not 5.6.

Bug#817034: icinga-cgi-bin: notifications.cgi and history.cgi cause general protection traps

[aw]

Package: icinga-cgi-bin
Version: 1.13.3-2
Severity: normal

When using the Alert History for any service I get a truncated output and a
message in /var/log/messages of the form:

Mar  7 12:14:19 monitoring kernel: [228026.372184] traps: notifications.c[7516] 
general protection ip:7fa937634d32 sp:7fff8129d690 error:0 in 
libc-2.21.so[7fa9375ec000+19a000]

I use icinga2 and classicui.

This happens with icinga-cgi-bin and libc6 from jessie-backports and sid.

cu

AW

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

Kernel: Linux 3.14-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE (charmap=locale: Cannot set LC_CTYPE 
to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages icinga-cgi-bin depends on:
ii  libc62.21-9
ii  libgd3   2.1.0-5
ii  libjpeg62-turbo  1:1.3.1-12
ii  libjs-jquery 1.7.2+dfsg-3.2
ii  libjs-jquery-ui  1.10.1+dfsg-1
ii  libpng12-0   1.2.50-2+deb8u2
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages icinga-cgi-bin recommends:
ii  apache2 [httpd]  2.4.10-10+deb8u4
ii  nagios-images0.8

icinga-cgi-bin suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_CTYPE = "de_DE",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Bug#817035: transition: qwt

[Lisandro Damián Nicanor Pérez Meyer]

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

Dear RT: this is a request to transition qwt from experimental to unstable.

As the auto tracker noted this release has an API/ABI breakage without
upstream doing a proper SONAME bump and so Qt4's libqwt6 is transitioning to
libqwt6ab1.

It also adds Qt5's libqwt-qt5-6.

So rdeps can either use the Qt4 version or migrate to Qt5.

Current rdeps and their statuses wrt this transition:

- libterralib: it's not marked in the auto tracker because they are mixing 
  Qt4 and Qt5 and it's probably not using libqwt at all. I already filed a bug 
  for them.

- nlkt: source already builds against libqwt-qt5-dev... in unstable  
  This basically means: binNMU all archs except amd64, as the auto tracker 
  shows.

- qgis: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784514#27 
  So maintainers are ready for the transition. It will also help with removing
  qt4's webkit rdeps.

- qsapecng: It works as well with qwt 6.1.2 as with qwt 6.0.0 so the package
  seems able to be binNMUed. It segfaults on exit (see bug #816898) but this
  doesn't seems to be related to qwt (or at least the transition shouldn't
  neither improve nor worsen the current situation).

- zygrib: version in experimental needs to be pushed to unstable according to
  #798875.

Ben file: the auto-tracker is about right, so let's keep it like that.

Kinds regards, Lisandro.

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

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

Bug#679763: debsnap: bisect option/script

[Osamu Aoki]

Hi,

For source history, "gbp inport-dscs --debsnap" gives you access to real
"git bisect" access.  So no point reinvention it in debsnap itself.

(Yes, I am living in high bandwidth region.)
 
For binary package history checking, dependency etc. matters and most
likely needs your manual attention.  At least with the new --list option
printing out sorted list of versions, you can do bisect like action
manually whice checking dependencyetively recent versions. 

Do you still think we should add complexities into debsnap?

Osamu

Bug#817033: sumo: FTBFS when built with dpkg-buildpackage -A (in a random way)

[Santiago Vila]

Hi. Found this:

Makefile.am says:

pydoc:
rm -rf docs/pydoc
mkdir docs/pydoc
cd docs/pydoc && \
for i in `find ../../tools/traci ../../tools/sumolib -name "*.py" -not 
-executable | sed 's,../../tools/,,;s,/,.,g;s,.py,,;s,.__init__,,'`; do \
PYTHONPATH="../../tools" python -c "import $$i, pydoc; 
pydoc.writedoc($$i)"; \
done

so the order in which the different "python -c" commands are executed
depends on the order in which "find" outputs its result, but this can be
anything because there is no canonical filesystem ordering.

In the end, the build fails or it does not depending on the *last*
executed command.

For example, this simple Makefile will fail:

all:
true; false
echo Hi

and this one will succeed:

all:
false; true
echo Hi


If we are going to forgive failure in any of the "python -c" commands,
maybe adding "|| true" at the end will do.

OTOH, if every "python -c" command should work flawlessly, the
current Makefile does not correctly express such condition.

Thanks.

Bug#817036: samba-dsdb-modules depends on version of libldb1 not in Debian

[Arthur Marsh]

Package: samba-dsdb-modules
Version: 2:4.3.5+dfsg-2
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Attempting to upgrade samba including samba-dsdb-modules  on Debian unstable 
x86-64 to version 2:4.3.5+dfsg-2

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

samba-dsdb-modules 2:4.3.5+dfsg-2 x86-64 depends on:

libldb1 < 2:1.1.25~ 
and
libldb1 > 2:1.1.24~

   * What was the outcome of this action?

I had to remove package samba-dsdb-modules to upgrade the rest of samba

   * What outcome did you expect instead?

What happened on i386 architecture:

libldb1 < 2:1.1.27~
and 
libldb1 > 2:1.1.26~

(Package libldb1 version 2:1.1.26-1 appears in both x86-64 and i386 
architectures in Debian)

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


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

Kernel: Linux 4.5.0-rc6+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages samba-dsdb-modules depends on:
ii  libbsd0 0.8.2-1
ii  libc6   2.21-9
ii  libcomerr2  1.42.13-1
pn  libkrb5-26-heimdal  
ii  libldb1 2:1.1.26-1
ii  libpopt01.16-10
ii  libtalloc2  2.1.5-2
ii  libtdb1 1.3.8-1
ii  libtevent0  0.9.28-1
ii  samba-libs  2:4.3.5+dfsg-2

samba-dsdb-modules recommends no packages.

samba-dsdb-modules suggests no packages.

Bug#803286: mtpaint: diff for NMU version 3.40-2.2

[Markus Koschany]

Control: tags 803286 + pending

Dear maintainer,

I've prepared an NMU for mtpaint (versioned as 3.40-2.2) and
uploaded it to unstable. I am attaching the debdiff to this bug
report.

Regards,

Markus
diff -Nru mtpaint-3.40/debian/changelog mtpaint-3.40/debian/changelog
--- mtpaint-3.40/debian/changelog	2015-12-16 06:10:31.0 +0100
+++ mtpaint-3.40/debian/changelog	2016-03-07 14:02:46.0 +0100
@@ -1,3 +1,15 @@
+mtpaint (3.40-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove unnecessary build-dependency on libgif4. (Closes: #803286)
+  * Refresh giflib5.diff because it did not apply cleanly.
+  * Remove quilt from Build-Depends because source format 3.0 uses quilt by
+default.
+  * Fix Lintian warning dep5-copyright-license-name-not-unique. In fact all
+files are licensed under GPL-3+ now.
+
+ -- Markus Koschany   Mon, 07 Mar 2016 13:46:16 +0100
+
 mtpaint (3.40-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mtpaint-3.40/debian/control mtpaint-3.40/debian/control
--- mtpaint-3.40/debian/control	2014-07-20 13:25:14.0 +0200
+++ mtpaint-3.40/debian/control	2016-03-07 14:02:46.0 +0100
@@ -5,14 +5,12 @@
 Build-Depends: debhelper (>= 7.0.50~),
libpng-dev,
zlib1g-dev,
-   libgif4,
libjpeg-dev,
libtiff-dev,
gettext,
pkg-config,
libgtk2.0-dev,
-   libgif-dev,
-   quilt
+   libgif-dev
 Standards-Version: 3.9.5
 Homepage: http://mtpaint.sourceforge.net/
 
diff -Nru mtpaint-3.40/debian/copyright mtpaint-3.40/debian/copyright
--- mtpaint-3.40/debian/copyright	2012-01-03 15:23:20.0 +0100
+++ mtpaint-3.40/debian/copyright	2016-03-07 14:02:46.0 +0100
@@ -6,24 +6,7 @@
 Files: *
 Copyright: 2004-2007, Mark Tyler 
   Dmitry Groshev 
-License: GPL-3
- This program is free software: you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation, either version 3 of the License, or
- (at your option) any later version.
- .
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- GNU General Public License for more details.
- .
- You should have received a copy of the GNU General Public
- License along with this package; if not, write to the Free
- Software Foundation, Inc., 51 Franklin St, Fifth Floor,
- Boston, MA  02110-1301 USA
- .
- On Debian systems, the full text of the GNU General Public
- License version 3 can be found in the file `/usr/share/common-licenses/GPL-3'.
+License: GPL-3+
 
 Files: po/*.po
 Copyright: 2005, Myrk Tyler 
@@ -32,38 +15,21 @@
2006, Simek 
2006, Tutku Dalmaz 
2006, Wei-Lun Chao 
-	   2007, Norihiro YONEDA 
-	   2008, Sergei Irupin 
-	   2007, Jozef Riha 
-	   2008, Cecc 
-License: GPL-2
- This program is free software; you can redistribute it
- and/or modify it under the terms of the GNU General Public
- License as published by the Free Software Foundation; either
- version 2 of the License, or (at your option) any later
- version.
- .
- This program is distributed in the hope that it will be
- useful, but WITHOUT ANY WARRANTY; without even the implied
- warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
- PURPOSE.  See the GNU General Public License for more
- details.
- .
- You should have received a copy of the GNU General Public
- License along with this package; if not, write to the Free
- Software Foundation, Inc., 51 Franklin St, Fifth Floor,
- Boston, MA  02110-1301 USA
- .
- On Debian systems, the full text of the GNU General Public
- License version 2 can be found in the file `/usr/share/common-licenses/GPL-2'.
+   2007, Norihiro YONEDA 
+   2008, Sergei Irupin 
+   2007, Jozef Riha 
+   2008, Cecc 
+License: GPL-3+
 
 Files: debian/*
 Copyright: 2011, Muammar El Khatib 
-License: GPL-3
+License: GPL-3+
+
+License: GPL-3+
  This program is free software; you can redistribute it
  and/or modify it under the terms of the GNU General Public
  License as published by the Free Software Foundation; either
- version 2 of the License, or (at your option) any later
+ version 3 of the License, or (at your option) any later
  version.
  .
  This program is distributed in the hope that it will be
diff -Nru mtpaint-3.40/debian/patches/giflib5.diff mtpaint-3.40/debian/patches/giflib5.diff
--- mtpaint-3.40/debian/patches/giflib5.diff	2015-12-16 06:10:57.0 +0100
+++ mtpaint-3.40/debian/patches/giflib5.diff	2016-03-07 14:02:46.0 +0100
@@ -1,8 +1,17 @@
-Index: b/src/png.c
+From: Matthias Klose 
+Date: Mon, 7 Mar 2016 13:49:51 +0100
+Subject: giflib5
+
 ===
+---
+ src/pn

Bug#791463: Quick review

[Andrew Shadura]

On 6 March 2016 at 21:16, Pali Rohár  wrote:
>> > But should not be cleandir part of that --buildsystem=bmake? Or why
>> > not?
>>
>> You're actually very right in this, I'm going to implement that right
>> now.
>
> Now I tested bmake version 20160220-2 and looks like it is working...
> Should I upload new version to mentors?

Please do.

-- 
Cheers,
  Andrew

Bug#700487: #700487 RFP: salor-hospitality -- Professional Point of Sale system for the Hospitality Industry, Restaurants and Hotels

[Dmitry Smirnov]

Salor Hospitality is a great project that I'd very much like to see in 
Debian.
Unfortunately since December 2015 project is dormant and no longer actively 
maintained:

https://github.com/michaelfranzl/SalorHospitality#important-notice

Therefore I'm tagging this bug as "wontfix" for now.

New upstream maintainer (or active fork of the project) is needed.

-- 
Cheers,
 Dmitry Smirnov.

---

Democracy is a pathetic belief in the collective wisdom of individual
ignorance.
-- H. L. Mencken



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

Bug#759492: File conflicts between /bin and /usr/bin

[Raphael Hertzog]

On Sat, 05 Mar 2016, Bill Allombert wrote:
> So to recap, Marco proposal is
> 
> diff --git a/policy.sgml b/policy.sgml
> index 404dc73..74f0a3b 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -8508,6 +8508,21 @@ fi
> renamed.  If a consensus cannot be reached, both
> programs must be renamed.
>   
> +
> + 
> +   To support merged /usr systems, packages must not install a
> +   file in /usr/bin with the same name as a file in
> +   /bin or a file in /usr/sbin with the
> +   same name as a file in /sbin.
> +   If such a compatibility symlink is needed then it must be
> +   managed in the maintainer scripts in a way that will not break
> +   when e.g. /usr/bin and /bin are the
> +   same directory.
> +   Packages must not install a file in /usr/lib (or
> +   one of its subdirectories) with the same name as a file in
> +   /lib (or the corresponding subdirectory).
> + 
> +
>   
>Binary executables must not be statically linked with the GNU C
>library, since this prevents the binary from benefiting from
> 
> Who is seconding this ?

Seconded.


-- 
Raphaël Hertzog ◈ Debian Developer

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


signature.asc
Description: PGP signature

Bug#810968: [debian-mysql] Bug#810968: Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)

[Lennart Weller]

On Mon, Mar 07, 2016 at 04:15:54PM +0400, Sergey Vojtovich wrote:
> > March 3 2016 9:35 PM, "Otto Kekäläinen"  wrote:
> I consider it lesser evil. You may use my_print_defaults to get
> pid-file value.
>
> Worth to note that I don't see any value in executing "mysqladmin ping".

I attached a version of the patch using my_print_defaults with its
standard locations. Not specifying any configuration files in case they
change with 10.1. And the ping removed in favor of checking the exit
code of flush-logs.

I did some rudimentary testing. But I can't be sure that I caught all
possible versions of existing files/processes and names. So there might
be some corner cases with incorrect exit codes.

Lennart
diff --git a/mariadb-server-10.0.mysql-server.logrotate.orig b/mariadb-server-10.0.mysql-server.logrotate
index 52f1292..9a2050a 100644
--- a/mariadb-server-10.0.mysql-server.logrotate.orig
+++ b/mariadb-server-10.0.mysql-server.logrotate
@@ -14,14 +14,13 @@
 
 		# If this fails, check debian.conf!
 		MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
-		if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
-		  # Really no mysqld or in incorrect authentication in /etc/mysql/debian.cnf user?
-		  # If this occurs and is not a error please report a bug.
-		  if ps cax | grep -q mysqld; then
- 		exit 1
+		if [ ! $($MYADMIN flush-logs 2>/dev/null) ]; then
+		  # If the pid-file exists and the process is mysqld it should have flushed
+		  PID=$(my_print_defaults mysqld | grep -oP "pid-file=\K[^$]+")
+		  if [ -r $PID ]; then
+		test "$(ps -p $(cat $PID) -o comm=)" = "mysqld" && exit 1 
+		exit 0
 		  fi
-		else
-		  $MYADMIN flush-logs
 		fi
 	endscript
 }


signature.asc
Description: Digital signature

Bug#817037: [mirror.optus.net] out of date (05 Nov 2015)]

[Peter Palfrader]

Package: mirrors
User: devscri...@packages.debian.org
Usertags: mirror-problems
Control: submitter -1 Justin Steven 

- Forwarded message from Justin Steven  -

From: Justin Steven 
Subject: http://mirror.optus.net/debian/ is stale (05 Nov 2015)
To: debian-mirr...@lists.debian.org
Date: Mon, 7 Mar 2016 23:27:05 +1000
Message-ID: 
X-Mailbox-Line: From debian-mirrors-requ...@lists.debian.org  Mon Mar  7 
13:45:11 2016

http://mirror.optus.net/debian/ (run by an Australian ISP) is outrageously
and brokenly stale.

~ % curl -s 'http://mirror.optus.net/debian/dists/jessie-updates/Release' |
grep -P 'Date|Valid-Until'
Date: Thu, 05 Nov 2015 08:49:17 UTC
Valid-Until: Thu, 12 Nov 2015 08:49:17 UTC

I've tried reaching out to their mirror team but battling frontline support
has gotten me nowhere.

Can I please get the contact details for mirror.optus.net, or can they
please be delisted.

Thanks,

--
Justin

- End forwarded message -

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#817038: transifex-client: Use python-six instead of the embedded version of python-urllib3

[Christos Trochalakis]

Package: transifex-client
Version: 0.11.1+git15~g655c5e9
Severity: important
Tags: patch

Transifex imports six from urlilib3 embedded version.
Since python-urllib3 (1.13.1-1) debian dropped the
embedded six module which, although it makes sense, broke
transifex-client.

Please consider applying the attached patch that switches
imports to python-six.


>From 6937c1065204cd6801f6cefe9fa7b5d9a37fe4e3 Mon Sep 17 00:00:00 2001
From: Christos Trochalakis 
Date: Mon, 7 Mar 2016 12:16:39 +0200
Subject: [PATCH] Use six library instead of the one embedded in urllib3

---
 requirements.txt   | 1 +
 txclib/commands.py | 2 +-
 txclib/config.py   | 2 +-
 txclib/project.py  | 2 +-
 txclib/utils.py| 4 ++--
 5 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/requirements.txt b/requirements.txt
index a42590b..71aa090 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1 +1,2 @@
 urllib3
+six
diff --git a/txclib/commands.py b/txclib/commands.py
index 122ecca..b221c02 100644
--- a/txclib/commands.py
+++ b/txclib/commands.py
@@ -25,7 +25,7 @@ try:
 except ImportError:
 import ConfigParser as configparser
 
-from urllib3.packages.six.moves import input
+from six.moves import input
 
 from txclib import utils, project
 from txclib.utils import parse_json, compile_json, files_in_project
diff --git a/txclib/config.py b/txclib/config.py
index f37f0a6..4bad9da 100644
--- a/txclib/config.py
+++ b/txclib/config.py
@@ -3,7 +3,7 @@ try:
 except ImportError:
 import ConfigParser as configparser
 
-from urllib3.packages import six
+import six
 
 
 class OrderedRawConfigParser(configparser.RawConfigParser):
diff --git a/txclib/project.py b/txclib/project.py
index 0961abf..55c24ae 100644
--- a/txclib/project.py
+++ b/txclib/project.py
@@ -18,7 +18,7 @@ except ImportError:
 from txclib import web
 from txclib import utils
 from urllib3.exceptions import SSLError
-from urllib3.packages import six
+import six
 from txclib.urls import API_URLS
 from txclib.config import OrderedRawConfigParser, Flipdict
 from txclib.log import logger
diff --git a/txclib/utils.py b/txclib/utils.py
index 3f4ed81..75263fb 100644
--- a/txclib/utils.py
+++ b/txclib/utils.py
@@ -13,8 +13,8 @@ except ImportError:
 
 from email.parser import Parser
 from urllib3.exceptions import SSLError
-from urllib3.packages import six
-from urllib3.packages.six.moves import input
+import six
+from six.moves import input
 from txclib.urls import API_URLS
 from txclib.exceptions import UnknownCommandError
 from txclib.paths import posix_path, native_path, posix_sep
-- 
2.7.0

Bug#817039: volti: Fails to start due to incorrect python-dbus version check

[Julian Calaby]

Package: volti
Version: 0.2.3-6
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The python-dbus version check on line 27 of /usr/lib/volti/volti.run is
incorrect due to recent changes to how the version of python-dbus is stored.

> assert dbus.version >= (0, 80, 0)

Alternatively, as the version of python-dbus is managed by Debian, this check
is redundant and the line could be removed.

This failed assersion makes the main "volti" command fail on startup rendering
the main part of the package, the systray icon, unusable.

I'd propose a patch, however I don't know enough Python to be certain that
it'd be correct. That said this should be rapidly fixable by anyone fluent in
Python.

Thanks,

Julian Calaby


-- System Information:
Distributor ID: Ubuntu
Description:Ubuntu 12.04.2 LTS
Release:12.04
Codename:   precise
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages volti depends on:
ii  python-alsaaudio  0.7-1
ii  python-dbus   1.2.2-1
ii  python-gobject3.18.2-2
ii  python-gtk2   2.24.0-4
ii  python-xlib   0.14+20091101-5
pn  python:any

volti recommends no packages.

volti suggests no packages.

-- no debconf information

Bug#814360: O: yics -- Yahoo! Chess client for use with FICS interfaces

[Markus Koschany]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: yics -- RoQA;obsolete,defunct

On Wed, 10 Feb 2016 14:23:15 -0500 Christopher David Howie
 wrote:
> Package: wnpp
> Severity: normal
> 
> I'm the packager of this software as well as the upstream author.  The
> Yahoo! Chess service has been permanently closed, so this software is
> now defunct.  This package should probably be removed from Debian
> entirely as it serves no function anymore.
> 
> I uploaded the package as a mentee, so I lack the ability to manipulate
> the package myself.



According to the maintainer and upstream author of yics, the package is
defunct and serves no function anymore. I don't see how it would fit
into Debian without the Yahoo servers it was written for. Please remove
yics from Debian.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#817040: dpkg-deb -c: sort list by name

[Osamu Aoki]

Package: dpkg
Version: 1.18.4
Severity: wishlist
Tags: patch

Making dpkg-deb to be deterministic by fixing #719845 was good for
reproducible build.  But "dpkg-deb -c" output is not human friendly.

Basically, we want it to be sorted by name instead of internal data
order.

Please consider adding patch such as one attached to instruct tar to
change its default behavior.

One debatable point is when to sort output.  Instead of always sorting
by name, should we sort only when LIST?  Should we have option to
control it?
Pertinent code will be around below in dpkg-deb/extract.c:
  if ((taroption & DPKG_TAR_LIST) && (taroption & DPKG_TAR_EXTRACT))
command_add_arg(&cmd, "-xv");
  else if (taroption & DPKG_TAR_EXTRACT)
command_add_arg(&cmd, "-x");
  else if (taroption & DPKG_TAR_LIST)
command_add_arg(&cmd, "-tv");
  else

If this is fixed, people will not complain like:
  https://bugs.debian.org/694515

Regards,

Osamu

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8
ii  libc62.21-9
ii  liblzma5 5.1.1alpha+20120614-2.1
ii  libselinux1  2.4-3+b1
ii  tar  1.28-2.1
ii  zlib1g   1:1.2.8.dfsg-2+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.2.4

-- no debconf information
--- extract.c.orig	2016-03-07 22:44:03.421627595 +0900
+++ extract.c	2016-03-07 22:47:23.810190427 +0900
@@ -320,6 +320,7 @@
   command_init(&cmd, TAR, "tar");
   command_add_arg(&cmd, "tar");
 
+  command_add_arg(&cmd, "--sort=name");
   if ((taroption & DPKG_TAR_LIST) && (taroption & DPKG_TAR_EXTRACT))
 command_add_arg(&cmd, "-xv");
   else if (taroption & DPKG_TAR_EXTRACT)

Bug#817012: ruby-amqp and ruby-amq-client: error when trying to install together

[Sebastien Badia]

tags 817012 + pending
thanks

Hi Ralf,

Thanks for this bug report!

Just fixed the issue (request a ROM of ruby-amq-client, (upstream dead), and
prepared a new version for ruby-amqp).

Cheers,

Seb


signature.asc
Description: PGP signature

Bug#817041: librem0: Missing run-time dependency on libre0

[Guillem Jover]

Package: librem0
Version: 0.4.7-1
Severity: serious

Hi!

This package provides a shared library that is not self-contained, and
it is missing a run-time dependency on libre0, as it uses some of its
symbols. The library should link against all libraries it uses directly,
because otherwise it is pushing an internal implementation detail towards
its users.

A very simple example to illustrate:

  $ echo 'int main() { return 0; }' >rem.c
  $ gcc -o rem rem.c -lrem
  [ lots of undefined references to missing symbols… ]

I guess there's just a «-lre» missing somewhere in the build system.

(I found this while trying to build a local baresip package, so thanks
for trying to get that in Debian. :)

Thanks,
Guillem

Bug#817008: unfulfilled dependencies

[殷啟聰]

Thank you for reporting the bug. Actually the reason to this is that I
used ${source:Version} for "android-sdk-platform-tools" and
"android-sdk-build-tools", which is substituted to the version of the
source package rather than their own. I have fixed it but not yet
uploaded it.

The reason of setting the version differently is simple: They have
different versions :(

Bug#817042: duplicity: corrupted files when backup is interrupted

[Martin Monperrus]

Package: duplicity
Version: 0.7.06-1
Severity: critical
Justification: causes serious data loss


   * What led up to the situation?
I backup my homedir with duplicity

   * What exactly did you do (or not do) that was effective (or ineffective)?
I try to restore a file

   * What was the outcome of this action?
Error 'librsync error 103 while in patch cycle' patching file
python2: ERROR: (rs_file_copy_cb) unexpected eof on fd169
python2: ERROR: (rs_job_complete) patch job failed: unexpected end of input

   * What outcome did you expect instead?
To restore the file


A "duplicity verify" shows that many files are corrupted. Seems related to
https://bugs.launchpad.net/duplicity/+bug/1252484.



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

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

Versions of packages duplicity depends on:
ii  libc62.21-9
ii  librsync10.9.7-10
ii  python   2.7.11-1
ii  python-lockfile  1:0.10.2-2

Versions of packages duplicity recommends:
ii  python-oauthlib  1.0.3-1
ii  python-paramiko  1.15.3-1
ii  python-urllib3   1.13.1-1
ii  rsync3.1.1-3

Versions of packages duplicity suggests:
ii  lftp4.6.3a-1+b2
pn  ncftp   
pn  python-boto 
pn  python-cloudfiles   
ii  python-gdata2.0.18+dfsg1-2
pn  python-swiftclient  
pn  tahoe-lafs  

-- no debconf information

Bug#711238: [debchange] Tests fail if distro-info-data is outdated

[Osamu Aoki]

control: tags 711238 moreinfo

Hi,

For back port, there are some packages which require to be updated even
when versioned dependency is not in place.  dpkg, debhelper, ...

I think distro-info-data is just another such package.  You have to have
latest version.

This bug has been around for 2 years without action and suggested action
there may not be useful by now as proposed.

   sugesstion   >= 0.16~
   current version 0.28(covering Ubuntu 16.04)

So adding such fixed version dependency seems not good idea since we
will forget updating it everytime we upload.

Then what should we add?
distro-info-data (>= ${binary:Version}~)

It looks overkill for me... but something along this thought...

Osamu

Bug#817043: RM: ruby-dev [all] -- RoQA; NBS, changed to arch:any

[Esa Peuha]

Package: ftp.debian.org

Version 1:2.3.0 changed ruby-dev from arch:all to arch:any.
Ideally, the automatic decrufter should remove the obsolete
arch:all ruby-dev 1:2.3~1, but instead it gets confused and
thinks that it would break every package that (build-)depends
on ruby-dev. So this one needs manual decrufting.

Bug#812406: usb: Strange USB bugs

[Aurelien Jarno]

On 2016-01-23 23:56, Aurelien Jarno wrote:
> control: tag -1 + moreinfo
> control: tag -1 - upstream
> 
> Hi,
> 
> On 2016-01-23 15:05, Nickolay Ilyushin wrote:
> > Package: libusb-1.0-0
> > Version: 2:1.0.20-1
> > Severity: critical
> > File: usb
> > Tags: upstream
> > Justification: causes serious data loss
> 
> It is not clear from your description how you have lost data. Can you
> please give us more details?
> 
> > One PC sees only 10 MiB on my JetFlash Transcend USB and NTFS partition. 
> > Second PC (this) sees ~16 GiB and Mac & EFI partitions. But all statements 
> > are false: i don't have Windows, i don't have Mac, size of USB - 4 GiB. 
> > Also, sometimes, sector size from kernel does not matches sector size from 
> > usb driver. Can you fix it, maintainer?
> 
> This is not clear from your description where you "see" the wrong
> information. Without more details like for example the name of your
> desktop environment or a screenshot it would be difficult to get your
> problem fixed.
> 
> Also please note that libusb has nothing to do with USB flash disk, so
> the bug is likely reported against the wrong package.

Any news about this, can you please give us more details about the
issue?

Thanks,
Aurelien

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

Bug#817011: ruby-domain-name: missing RubyGems integration, breaks other softwares like Vagrant

[Pirate Praveen]

On Mon, 07 Mar 2016 15:15:38 +0900 =?UTF-8?Q?Marc_Dequ=C3=A8nes_=28duck=29?= 
 wrote:
> I'm in the team but I don't have time or tools at the moment to get into 
> more details why this file is missing (I remember gem2deb to already 
> have all the necessary magic and this package is using it), sorry.

Its a common issue and I think gem2deb should handle it.

It happens when gemspec uses git ls-files command to list files. It fails when 
building in a clean chroot. The fix is to remove git usage in gemspec.

> Regards.
> 

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

Bug#810968: [debian-mysql] Bug#810968: Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)

[Sergey Vojtovich]

Lennart,

On Mon, Mar 07, 2016 at 02:43:14PM +0100, Lennart Weller wrote:
...skip...

> diff --git a/mariadb-server-10.0.mysql-server.logrotate.orig 
> b/mariadb-server-10.0.mysql-server.logrotate
> index 52f1292..9a2050a 100644
> --- a/mariadb-server-10.0.mysql-server.logrotate.orig
> +++ b/mariadb-server-10.0.mysql-server.logrotate
> @@ -14,14 +14,13 @@
>  
>   # If this fails, check debian.conf!
>   MYADMIN="/usr/bin/mysqladmin 
> --defaults-file=/etc/mysql/debian.cnf"
> - if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
> -   # Really no mysqld or in incorrect authentication in 
> /etc/mysql/debian.cnf user?
> -   # If this occurs and is not a error please report a bug.
> -   if ps cax | grep -q mysqld; then
> - exit 1
> + if [ ! $($MYADMIN flush-logs 2>/dev/null) ]; then
> +   # If the pid-file exists and the process is mysqld it should 
> have flushed
> +   PID=$(my_print_defaults mysqld | grep -oP "pid-file=\K[^$]+")
Good. 

> +   if [ -r $PID ]; then
> + test "$(ps -p $(cat $PID) -o comm=)" = "mysqld" && exit 1 
Existence of pid-file is a sure sign that there's mysqld running, the only
exception is mysqld crash. What do you think about skipping this check?

I'd also suggest to turn things around and check for pid-file first and then
just run "MYADMIN flush-logs" allowing it to return error in case of failure.

If you like I can take your current patch and apply it upstream with some minor
corrections.

Regards,
Sergey

Bug#817044: RM: ruby-amq-client -- ROM; Upstream dead (obsolete)

[Sebastien Badia]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

ruby-amq-client (upstream amq-client) is deprecated since 2011¹, and
the code was integrated in the ruby-amqp (upstream amqp) project.

The new version of ruby-amqp cause a conflict (see 817012²)

I'm DM, so I don't have access to mirror.ftp-master.debian.org to test
the reverse dependency but it seems that only ruby-amqp use this package
(I just prepared a new version of ruby-amqp in order to update the deps).

Please remove it from unstable.

https://github.com/ruby-amqp/amq-client/commit/b32453f1b1ad3b4ea4f967b0db866daa7a2bc6f9
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817012

Thanks in advance,

Seb (for the Ruby team)

Bug#817045: Please mark urfkill binary packages as linux-any

[Michael Biebl]

Source: urfkill
Version: 0.5.0-3
Severity: normal
Tags: patch

Hi,

urfkill seems to be using linux-specific interfaces (rfkill) and has a
build depends on libudev-dev. It therefor won't be buildable on
non-linux architectures.

Please consider applying the attached patch. It marks the binary
packages as linux-any. This avoids that the non-linux buildds pick up
the package but then get stuck in the BD-Uninstallable stage.

Regards,
Michael


[1] https://buildd.debian.org/status/package.php?p=urfkill&suite=unstable

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

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 90e113d418ba6b8987fbd05d9fa9449d6157b23b Mon Sep 17 00:00:00 2001
From: Michael Biebl 
Date: Mon, 7 Mar 2016 15:51:23 +0100
Subject: [PATCH] Mark urfkill packages as linux-any

---
 debian/control | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/debian/control b/debian/control
index b4152dc..b1787c5 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Standards-Version: 3.9.6
 Homepage: http://www.freedesktop.org/wiki/Software/urfkill
 
 Package: urfkill
-Architecture: any
+Architecture: linux-any
 Multi-Arch: foreign
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, libglib2.0-0, libdbus-1-3, libdbus-glib-1-2, dbus, libgudev-1.0-0, libpolkit-gobject-1-0, libexpat1, consolekit
@@ -20,7 +20,7 @@ Description: wireless killswitch management daemon for laptops
 
 Package: liburfkill-glib0
 Section: libs
-Architecture: any
+Architecture: linux-any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Recommends: urfkill
@@ -32,7 +32,7 @@ Description: wireless killswitch management library
 
 Package: liburfkill-glib-dev
 Section: libdevel
-Architecture: any
+Architecture: linux-any
 Pre-Depends: ${misc:Pre-Depends}
 Depends: liburfkill-glib0 (= ${binary:Version}), gir1.2-urfkill-glib0 (= ${binary:Version}), ${misc:Depends}
 Description: wireless killswitch management library (development files)
@@ -43,7 +43,7 @@ Description: wireless killswitch management library (development files)
  This package contains development files for the urfkill library.
 
 Package: liburfkill-glib0-dbg
-Architecture: any
+Architecture: linux-any
 Section: debug
 Priority: extra
 Depends: liburfkill-glib0 (= ${binary:Version}), ${misc:Depends}
@@ -56,7 +56,7 @@ Description: wireless killswitch management library (debug symbols)
 
 Package: gir1.2-urfkill-glib0
 Section: introspection
-Architecture: any
+Architecture: linux-any
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${gir:Depends}, ${misc:Depends}, liburfkill-glib0
 Description: GObject introspection data for the urfkill library
-- 
2.7.0

Bug#759492: File conflicts between /bin and /usr/bin

[Ansgar Burchardt]

Bill Allombert wrote:
> So to recap, Marco proposal is
> 
> diff --git a/policy.sgml b/policy.sgml
> index 404dc73..74f0a3b 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -8508,6 +8508,21 @@ fi
>     renamed.  If a consensus cannot be reached, both
>     programs must be renamed.
>   
> +
> + 
> +   To support merged /usr systems, packages must not install
a
> +   file in /usr/bin with the same name as a file
in
> +   /bin or a file in /usr/sbin with
the
> +   same name as a file in /sbin.
> +   If such a compatibility symlink is needed then it must be
> +   managed in the maintainer scripts in a way that will not
break
> +   when e.g. /usr/bin and /bin are
the
> +   same directory.
> +   Packages must not install a file in /usr/lib
(or
> +   one of its subdirectories) with the same name as a file in
> +   /lib (or the corresponding subdirectory).
> + 
> +
>   
>Binary executables must not be statically linked with the
GNU C
>library, since this prevents the binary from benefiting
from
> 
> Who is seconding this ?

Seconded.

Though shouldn't this be worded a bit more generic? There are also
/lib32 vs /usr/lib32 and /lib64 vs /usr/lib64 (and possibly other
suffixes like libx32).

Also I don't think Policy should require maintainer scripts for the
implementation of compatibility symlinks. I would prefer an
implementation-neutral wording that would allow switching to dpkg
handling these in some declarative way without having to change Policy.

  To support merged-/usr systems, packages must not
  install files in both {path} and
  /usr/{path}.

  In case a file gets moved between {path} and 
  /usr/{path} and a compatibility symlinks is needed,
  the symlink must be managed in such a way that it will not
  break when, for example, /bin and /usr/bin
  are the same directory.

Ansgar

Bug#816114: Pending fixes for bugs in the libalien-sdl-perl package

[pkg-perl-maintainers]

tag 816114 + pending
thanks

Some bugs in the libalien-sdl-perl package are closed in revision
1d93700c3a264b3459103738320e7d182b0d5817 in branch 'master' by
Dominique Dumont

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libalien-sdl-perl.git/commit/?id=1d93700

Commit message:

control: depends on libpng-dev (Closes: #816114)

Bug#816993: wmaker: versions > 0.95.6-1.2 break some fullscreen applications (DOSBox, quakeforge, vavoom)

[Doug Torrance]

(CC'ing the upstream dev list as well)

On 03/06/2016 11:28 PM, Matti Hämäläinen wrote:


Hello again!

After some more detective work, I noticed that the issue did not occur
on self-compiled WindowMaker from the git-repo, which made me think what
the debian packaged version might be doing differently ...

It turns out that the deb passes "--enable-randr" flag to wmaker
configure, which is the root cause of this issue. The option flag
is marked "enable RandR extension support (NOT recommended, buggy)".

Doing a rebuild of the package with edited debian/rules that has
--enable-randr removed fixes the problem.

It seems that the flag was enabled in this change:

https://anonscm.debian.org/git/pkg-wmaker/wmaker.git/commit/debian/rules?id=e737a261679e2db0ae80c8087302f88d8569859a


Thanks for pinpointing this!  That's a nice easy fix.  I'll work on a 
new version omitting --enable-randr soon.


Doug

Bug#817047: nmu: cyphesis-cpp_0.6.0-3

[Esa Peuha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu

It seems that cyphesis-cpp has had problems building on several
architectures, with the result that it depends on various old
library packages on these arches. However the Reproducible Builds
project has managed [1] to build it repeatedly on both amd64 and
armhf since last December, so I think it is worth trying another
binNMU on all the problematic architectures.

[1] https://reproducible.debian.net/history/cyphesis-cpp.html

nmu cyphesis-cpp_0.6.0-3 . amd64 arm64 armel armhf i386 mips mips64el
mipsel . -m 'Rebuild against libmercator-0.3-4'

Bug#817046: libtinyxml2-dev: tinyxml2.h has CR-LF style endlines

[Max Dmitrichenko]

Package: libtinyxml2-dev
Version: 2.2.0-1
Severity: minor

Dear Maintainer,

Open file /usr/include/tinyxml2.h in emacs and see ^M at the end of each line.

Probably dos2unix should be run as a build step of the package.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/3 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 libtinyxml2-dev depends on:
ii  libtinyxml2-2  2.2.0-1

libtinyxml2-dev recommends no packages.

libtinyxml2-dev suggests no packages.

-- no debconf information

Bug#817048: ITP: jo -- command-line processor to output JSON from a shell

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: jo
  Version : git snapshot
  Upstream Author : Jan-Piet Mens
* URL : https://github.com/jpmens/jo
* License : GPL-2+
  Programming Lang: C
  Description : command-line processor to output JSON from a shell

 jo creates a JSON string on stdout from words given it as arguments
 or read from stdin. It can generate both arrays and objects. Here is
 a short example:
 .
 $ jo -p name=jo n=17 parser@0
 {
"name": "jo",
"n": 17,
"parser": false
 }

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJW3ZvvAAoJEJWkL+g1NSX5rnUP/2E8wZnnKAHLwKcfzpi9SHwU
qS3y/p8RMbf1d2N3uC5O05lZE914ookA0T9xOL/gGaqMWyvG8PORcTkpq0SFegxo
sUakv7UaDseAhBPos8Il3GIRLSa1JOBWoqDvivXV85c1thT42cifpTVPDX/2IBqc
Bb6wA7tTThfn6Pmde3OSskqiarcVPHOwcHJFUqR5w1f+BUOCtjUGpqpAN6vAitcj
YcVnGVhvBj/Y81uCc3snGyZWILApG2opL7z7tJrejV7mAgCjACkf/2knGmzUywtQ
0Sl4LWS5uJzWUKvjqg58eE8GU3t0NlZ78l5XV8bPFjzqhVRYLrM1+qqhU2/jcLup
DvA3F76NvvKuKG7KrFoWC/WmQojN3C+TgaTmKsYAh42JeySGcvwCLf5Eoi5Aicft
M/TqjiT1R+EBdqO/4TMg93AQ+GlLv2dU1FgYe19XJ6a9RPfTiVhcgJAtLB+mx3mQ
OYZDga+COjAe22zpI3/6N2yFs+rI3axyIaP/Ban/RIOGpQQDXRuFf4nNZx2x/aei
+SXqilXj6f3GQ/mhQglxH1tCVGMfuXEqgkChUZJhC79t2v0gq4B8KPsLFHrqMmOH
1qtcKH9SUmSNiQ49ZfFC3wHrVU/mcsTDHJbpS4BMKFaT2dxMvHv54qY3qz+D5Jgr
xA9dZgZB0+t/0jqTb4oX
=j6Co
-END PGP SIGNATURE-

Bug#815652: linux-image-4.4.0-1-amd64 spontaneously reboots my Braswell NUC5PPYH

[Ben Hutchings]

Control: severity -1 important
Control: tag -1 moreinfo

On Tue, 23 Feb 2016 05:50:26 -0500 james sarbello  
wrote:
[...]
> Just to note in passing, the last two kernel message lines
> before the reboot is related to ACPI, something like:
> 
> [#] ACPI: Core revision #
> [#] ACPI: 5 ACPI AML tables successfully acquired and loaded
> 
> The bug may be related to the apparent EFI bug described
> in Debian Bug No. 815173, which has been marked as closed.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815173
> 
> However, the boot crash occurs even with the latest patched
> kernel version used as the basis for closing the bug report.

Have you tried adding the kernel parameter "efi=noruntime"?  Does that
make a difference?

Does Linux 4.5-rc4 (available in the experimental suite) have the same
problem?

Is a crash log visible through the pstore interface (files
/sys/fs/pstore/dmesg-*)?

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg

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

Bug#815652: linux-image-4.4.0-1-amd64 spontaneously reboots my Braswell NUC5PPYH

[Ben Hutchings]

Control: severity -1 important
Control: tag -1 moreinfo

On Tue, 23 Feb 2016 05:50:26 -0500 james sarbello  
wrote:
[...]
> 
> Just to note in passing, the last two kernel message lines
> before the reboot is related to ACPI, something like:
>  
> [#] ACPI: Core revision #
> [#] ACPI: 5 ACPI AML tables successfully acquired and loaded
>  
> The bug may be related to the apparent EFI bug described
> in Debian Bug No. 815173, which has been marked as closed.
>  
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815173
>  
> However, the boot crash occurs even with the latest patched
> kernel version used as the basis for closing the bug report.
Have you tried adding the kernel parameter "efi=noruntime"?  Does that
make a difference?

Does Linux 4.5-rc4 (available in the experimental suite) have the same
problem?

Is a crash log visible through the pstore interface (files
/sys/fs/pstore/dmesg-*)?

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg

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

Bug#759492: File conflicts between /bin and /usr/bin

[Andreas Henriksson]

Hello!

On Mon, Mar 07, 2016 at 03:56:31PM +0100, Ansgar Burchardt wrote:
> Bill Allombert wrote:
> > So to recap, Marco proposal is
> > 
> > diff --git a/policy.sgml b/policy.sgml
> > index 404dc73..74f0a3b 100644
> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -8508,6 +8508,21 @@ fi
> >       renamed.  If a consensus cannot be reached, both
> >       programs must be renamed.
> >     
> > +
> > +   
> > +     To support merged /usr systems, packages must not install
> a
> > +     file in /usr/bin with the same name as a file
> in
> > +     /bin or a file in /usr/sbin with
> the
> > +     same name as a file in /sbin.
> > +     If such a compatibility symlink is needed then it must be
> > +     managed in the maintainer scripts in a way that will not
> break
> > +     when e.g. /usr/bin and /bin are
> the
> > +     same directory.
> > +     Packages must not install a file in /usr/lib
> (or
> > +     one of its subdirectories) with the same name as a file in
> > +     /lib (or the corresponding subdirectory).
> > +   
> > +
> >     
> >Binary executables must not be statically linked with the
> GNU C
> >library, since this prevents the binary from benefiting
> from
> > 
> > Who is seconding this ?

Seconded

> 
> Seconded.
> 
> Though shouldn't this be worded a bit more generic? There are also
> /lib32 vs /usr/lib32 and /lib64 vs /usr/lib64 (and possibly other
> suffixes like libx32).
> 
> Also I don't think Policy should require maintainer scripts for the
> implementation of compatibility symlinks. I would prefer an
> implementation-neutral wording that would allow switching to dpkg
> handling these in some declarative way without having to change Policy.

... although I also prefer some more generic wording to cover
multi-arch related directories etc. (to avoid discussions with
people who read policy by the letter), like:

> 
>   To support merged-/usr systems, packages must not
>   install files in both {path} and
>   /usr/{path}.
> 
>   In case a file gets moved between {path} and 
>   /usr/{path} and a compatibility symlinks is needed,
>   the symlink must be managed in such a way that it will not
>   break when, for example, /bin and /usr/bin
>   are the same directory.
> 
> Ansgar
> 

(Maybe it's nice and helpful to include a hint about handling it in
maintainer scripts but at the same time I wonder if the policy document
is the right place for that given it's overly hard to update to future
best practises. Also very few packages where affected by needing this
change to begin with so hopefully extremely few new packages will
even need to take this part of policy into active consideration.)

Regards,
Andreas Henriksson

Bug#815298: linux-image-4.4.0-trunk-686-pae: sdhci module repeatedly crashes, eventually brings whole system down

[Ben Hutchings]

Control: severity -1 important
Control: tag -1 moreinfo

On Sat, 20 Feb 2016 17:30:59 + Thomas Thurman  wrote:
[...]
> Here's an excerpt from kern.log a few days ago, showing the problem:
> 
> Feb 15 11:21:48 emley-moor kernel: [  169.188034] usb 1-1.2: reset high-speed 
> USB device number 4 using xhci_hcd
> Feb 15 11:22:45 emley-moor kernel: [  196.640590] sdhci: Timeout waiting for 
> Buffer Read Ready interrupt during tuning procedure, falling back to fixed 
> sampling clock
> Feb 15 11:22:45 emley-moor kernel: [  196.642950] [ cut here 
> ]
> Feb 15 11:22:45 emley-moor kernel: [  196.642964] WARNING: CPU: 1 PID: 0 at 
> /build/linux-TrvjeN/linux-4.4/drivers/mmc/host/sdhci.c:1003 
> sdhci_send_command+0x727/0xbc0 [sdhci]()
> Feb 15 11:22:45 emley-moor kernel: [  196.642968] Modules linked in: loop 
> fuse nls_utf8 nls_cp437 vfat fat snd_soc_sst_baytrail_pcm snd_soc_sst_ipc 
> iTCO_wdt sparse_keymap iTCO_vendor_support ak8975 snd_soc_sst_byt_rt5640_mach 
> rfkill snd_soc_sst_dsp intel_rapl gpio_keys intel_powerclamp coretemp 
> kvm_intel kvm irqbypass crc32_pclmul aesni_intel aes_i586 xts lrw gf128mul 
> ablk_helper cryptd sg snd_soc_rt5640 snd_soc_rl6231 efi_pstore evdev 
> snd_soc_core joydev snd_pcm_oss snd_mixer_oss snd_pcm efivars hid_multitouch 
> pcspkr snd_timer snd soundcore regmap_i2c inv_mpu6050 
> industrialio_triggered_buffer battery kfifo_buf industrialio i2c_mux i915 
> drm_kms_helper drm i2c_algo_bit lpc_ich mfd_core button 8250_fintek video wmi 
> tpm_crb dw_dmac dw_dmac_core soc_button_array processor_thermal_device 
> intel_soc_dts_iosf iosf_mbi int3400_thermal int3402_thermal int3403_thermal 
> acpi_thermal_rel int340x_thermal_zone snd_soc_sst_acpi 
> i2c_designware_platform i2c_designware_core tpm_tis tpm ac acpi_pad processor 
> parport_pc ppdev lp parport efivarfs autofs4 sd_mod hid_generic usbhid uas 
> usb_storage scsi_mod ext4 crc16 mbcache jbd2 mmc_block crc32c_intel xhci_pci 
> xhci_hcd usbcore usb_common thermal i2c_hid hid sdhci_acpi sdhci mmc_core
> Feb 15 11:22:45 emley-moor kernel: [  196.643119] CPU: 1 PID: 0 Comm: 
> swapper/1 Tainted: G  D W   4.4.0-trunk-686-pae #1 Debian 4.4-1~exp1
[...]

This indicates that there were earlier BUG and WARNING messages; please
send those as well.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg

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

Bug#817049: linux-image-3.16.0-4-amd64: execve() gives EEXIST error under NFS if the file has been regenerated on a different machine

[Vincent Lefevre]

Package: src:linux
Version: 3.16.7-ckt20-1+deb8u3
Severity: normal

Under NFS, when an executable has been regenerated on a different machine,
execve() gives me an EEXIST error. To reproduce the bug:

francine:~> touch bin/tst
francine:~> cat bin/tst

cassis:~> cat tst.c
int main (void)
{ return 0; }
cassis:~> gcc -O3 tst.c -o tst
cassis:~> mv tst bin/
mv: overwrite ‘bin/tst’? y

At this point, I have to wait for 15 seconds for the "mv" to be
done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799838

After that:

francine:~> strace -f -o tst.out sh -c "exec $HOME/bin/tst"
sh: 1: exec: /home/vlefevre/bin/tst: File exists
zsh: exit 2 strace -f -o tst.out sh -c "exec $HOME/bin/tst"
francine:~[2]> cat tst.out
21573 execve("/bin/sh", ["sh", "-c", "exec /home/vlefevre/bin/tst"], [/* 120 
vars */]) = 0
21573 brk(0)= 0x7f4aded7d000
21573 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
21573 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7f4aded46000
21573 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
21573 open("/home/vlefevre/debian8/gmp/westmere/lib/tls/x86_64/libc.so.6", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
21573 stat("/home/vlefevre/debian8/gmp/westmere/lib/tls/x86_64", 
0x7ffec78d5b00) = -1 ENOENT (No such file or directory)
21573 open("/home/vlefevre/debian8/gmp/westmere/lib/tls/libc.so.6", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
21573 stat("/home/vlefevre/debian8/gmp/westmere/lib/tls", 0x7ffec78d5b00) = -1 
ENOENT (No such file or directory)
21573 open("/home/vlefevre/debian8/gmp/westmere/lib/x86_64/libc.so.6", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
21573 stat("/home/vlefevre/debian8/gmp/westmere/lib/x86_64", 0x7ffec78d5b00) = 
-1 ENOENT (No such file or directory)
21573 open("/home/vlefevre/debian8/gmp/westmere/lib/libc.so.6", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
21573 stat("/home/vlefevre/debian8/gmp/westmere/lib", {st_mode=S_IFDIR|0755, 
st_size=13, ...}) = 0
21573 open("/usr/local/lib/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
21573 stat("/usr/local/lib/tls/x86_64", 0x7ffec78d5b00) = -1 ENOENT (No such 
file or directory)
21573 open("/usr/local/lib/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
such file or directory)
21573 stat("/usr/local/lib/tls", 0x7ffec78d5b00) = -1 ENOENT (No such file or 
directory)
21573 open("/usr/local/lib/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
21573 stat("/usr/local/lib/x86_64", 0x7ffec78d5b00) = -1 ENOENT (No such file 
or directory)
21573 open("/usr/local/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
21573 stat("/usr/local/lib", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) 
= 0
21573 open("/lib64/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
such file or directory)
21573 stat("/lib64/tls/x86_64", 0x7ffec78d5b00) = -1 ENOENT (No such file or 
directory)
21573 open("/lib64/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
21573 stat("/lib64/tls", 0x7ffec78d5b00) = -1 ENOENT (No such file or directory)
21573 open("/lib64/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
21573 stat("/lib64/x86_64", 0x7ffec78d5b00) = -1 ENOENT (No such file or 
directory)
21573 open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
21573 read(3, 
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\34\2\0\0\0\0\0"..., 832) = 832
21573 fstat(3, {st_mode=S_IFREG|0755, st_size=1738176, ...}) = 0
21573 mmap(NULL, 3844640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0x7f4ade55f000
21573 mprotect(0x7f4ade701000, 2093056, PROT_NONE) = 0
21573 mmap(0x7f4ade90, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a1000) = 0x7f4ade90
21573 mmap(0x7f4ade906000, 14880, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4ade906000
21573 close(3)  = 0
21573 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7f4aded45000
21573 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7f4aded44000
21573 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7f4aded43000
21573 arch_prctl(ARCH_SET_FS, 0x7f4aded44700) = 0
21573 mprotect(0x7f4ade90, 16384, PROT_READ) = 0
21573 mprotect(0x7f4aded48000, 12288, PROT_READ) = 0
21573 mprotect(0x7f4adeb2a000, 4096, PROT_READ) = 0
21573 getpid()  = 21573
21573 rt_sigaction(SIGCHLD, {0x7f4adeb3efd0, ~[RTMIN RT_1], SA_RESTORER, 
0x7f4ade5940e0}, NULL, 8) = 0
21573 geteuid() = 1114
21573 brk(0)= 0x7f4aded7d000
21573 brk(0x7f4aded9e000)   = 0x7f4aded9e000
21573 getppid() = 21568
21573 stat("/home/vlefevre", {st_mod

Bug#817050: netcat-openbsd: The -q 0 flag does not behave the same as the netcat.traditional

[Lefteris Kritikos]

Package: netcat-openbsd
Version: 1.105-7
Severity: normal

Dear Maintainer,

The -q flag when used with the value 0 in combination with the -u flag does not
behave the same as the netcat.traditional package. The behaviour is as if the
wait value was negative: nc hangs forever waiting for EOF on stdin. This is
also different from the description in the manual page:

 -q seconds
 after EOF on stdin, wait the specified number of seconds and then 
quit. If seconds is negative, wait forever.

To reproduce:

nc.openbsd -u -l -p 12345 &
echo test | nc.openbsd -q 0 -u localhost 12345

and compare with:

nc.traditional -u -l -p 12345 &
echo test | nc.traditional -q 0 -u localhost 12345


Kind regards,
Lefteris


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_GB.utf8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages netcat-openbsd depends on:
ii  libbsd0  0.7.0-2
ii  libc62.19-18+deb8u2

netcat-openbsd recommends no packages.

netcat-openbsd suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "en_GB.utf8",
LC_MONETARY = "en_GB.utf8",
LC_CTYPE = "en_GB.utf8",
LC_MEASUREMENT = "en_GB.utf8",
LC_NUMERIC = "en_GB.utf8",
LC_PAPER = "en_GB.utf8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory