Bug#848287: python-testing.mysqld: (build-)depends on mysql-{client,server}

[Emilio Pozuelo Monfort]

On 01/01/17 12:49, Dominik George wrote:
> Hi,
> 
>> You should have kept me in Cc if you wanted me to see your reply and have a
>> chance to reply.
> 
> sorry, I just cannot remember that the Debian BTS does not automatically
> notify the submitter ☹.
> 
> So, I have several problems:
> 
>  * I cannot find the formal transition for this.
>  * I cannot see that mysql-server will be removed from stretch.
> 
> As a matter of sad fact, testing.mysqld does not work with mariadb right
> now.
> 
> What is wrong with depending on mysql-server, given that mysql-server
> will still exist although mariadb will become the default?

We're aiming at dropping mysql from testing/stretch because of concerns from the
security team. See email threads in debian-release@ and pkg-mysql-maint@.

Cheers,
Emilio

Bug#837167: RFS: aiscm/0.6.2-2

[Andrey Rahmatullin]

You have

override_dh_makeshlibs:
# NOOP to prevent debuild from invoking ldconfig

Debuild doesn't invoke ldconfig. If it's done to avoid adding an ldconfig
trigger you should explain that and explain why it is added because it's
not clear why do you need manual actions here.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#704303: violates Debian Policy 2.3 Copyright considerations

[Andrey Rahmatullin]

Note that since Policy 3.9.9 MPL should be in common-licenses.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#848287: python-testing.mysqld: (build-)depends on mysql-{client,server}

[Dominik George]

Hi,

> You should have kept me in Cc if you wanted me to see your reply and have a
> chance to reply.

sorry, I just cannot remember that the Debian BTS does not automatically
notify the submitter ☹.

So, I have several problems:

 * I cannot find the formal transition for this.
 * I cannot see that mysql-server will be removed from stretch.

As a matter of sad fact, testing.mysqld does not work with mariadb right
now.

What is wrong with depending on mysql-server, given that mysql-server
will still exist although mariadb will become the default?

-nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature

Bug#847015: RFS: debdelta/0.55+nmu1 [RC] [NMU]

[Carlos Maddela]

Hi Tobi,

It's strange, but the BTS didn't forward me your message.

I believe Andrea was X-Debbugs-CCed in my original RFS message.

I'll keep the things you've pointed out in mind in the future.

Anyway, I think Andrea has become active in the RC bug, so it has made
this RFS unnecessary. Should I close this bug?

Thanks,

Carlos

On Sun, 18 Dec 2016 16:24:12 +0100 Tobias Frost wrote:
> Control: tags -1 wontfix
>
> Hallo Carlos,
>
> Did you (try) to contact the maintainers? I could also not see an
> debdiff to the BTS where you announcing the NMU. (If I missed it please
> post the bug number)
>
> Also, there are many changes that are really out of scope an NMU*, like
> the change to debhelper, reproduciblity...
>
> Marking as wontfix -- please provide a more minimalistic patch to just
> fix the important (RC) problem and announce the NMU on the BTS
> (nmudiff(1) is handy here)
>
> Thanks!
>
> * Please read https://www.debian.org/doc/manuals/developers-reference/p
> kgs.html#nmu
>
> --
> tobi
>
> On Mon, 05 Dec 2016 09:15:50 +1100 Carlos Maddela
> wrote:
>
> > Changes since the last upload:
> >Â 
> > debdelta (0.55+nmu1) unstable; urgency=medium
> >Â 
> >Â Â Â [ Carlos Maddela ]
> >Â Â Â * Non-maintainer upload.
> >Â Â Â * Fix i386 debdelta URLs output by debpatch-url on amd64 system.
> >Â Â Â Â Â (Closes: #740552)
> >Â Â Â * Fix guessing of xz parameters for files compressed in parallel.
> >Â Â Â Â Â (Closes: #845173)
> >Â Â Â * Conform to Standards Version 3.9.8.
> >Â Â Â Â Â By converting the build process to use debhelper and include
> rules to
> >Â Â Â Â Â create the documentation and language support files, we can
> guarantee
> >Â Â Â Â Â that the builds are completely reproducible. (Closes: #30,
> #793004)
> >Â Â Â * Include a sample APT conf snippet for debdelta integration with
> APT.
> >Â Â Â Â Â Thanks to Ritesh Raj Sarraf (Closes: #817140)
> >Â 
> >Â Â Â [ Colin Watson ]
> >Â Â Â * Allow applying patches to unpacked .debs in locations other than
> /.
> >Â Â Â Â Â (Closes: #710398)
> >Â 
> >Â Â Â [ Mert Dirik ]
> >Â Â Â * Add timeout option to debdelta-upgrade. (Closes: #735142)
> >Â 
> >  -- Carlos Maddela   Sun, 04 Dec 2016 02:38:46
> +1100
> >Â 
> >Â 
> > Regards,

Bug#849584: Please review proposed service file change

[Raphael Hertzog]

Hi Scott,

On Fri, 30 Dec 2016, Scott Kitterman wrote:
> Since you provided the original postfix service file, would you please review 
> the proposed change in the cc'ed bug:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849584
> 
> and let us know what you think about the change.

It looks like Bartosz did not notice that the reason why no process were
tracked behind the "postfix" unit is because we support multiple postfix
instances and the default instance is named "postfix@-" so he should
do "systemctl status postfix@-" to see his running processes.

The "postfix" service file is just a way to do the reload/restart actions
on all the existing instances.

IMO the bug should just be closed. Or maybe there's a way to improve
the documentation so that others do not do the same mistake, but you
should not change the postfix.service file as requested.

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#845034: initramfs-tools: please ensure initrd images are reproducible

[Chris Lamb]

Hi Ben,

> initramfs-tools: please ensure initrd images are reproducible

Thanks for the review; updated patch attached.

> Control: block -1 with 804063
[..]
> I'd much prefer to add a versioned dependency on the new cpio (when
> available) than to probe for it ar run-time

The new cpio is now available in experimental. Obviously, uploading
this patch to != experimental right now would currently make us
uninstallable, but do you fancy making an upload there?

> I also have a coding style nit-pick - please use [ -n "..." ] rather
> than [ "..." != "" ]

Sure.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/control b/debian/control
index 3be7ff5..0f8c587 100644
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,7 @@ Package: initramfs-tools-core
 Architecture: all
 Multi-Arch: foreign
 Recommends: ${busybox:Recommends}
-Depends: klibc-utils (>= 2.0.4-8~), cpio, kmod | module-init-tools, udev, 
${misc:Depends}
+Depends: klibc-utils (>= 2.0.4-8~), cpio (>= 2.12), kmod | module-init-tools, 
udev, ${misc:Depends}
 Suggests: bash-completion
 Breaks: initramfs-tools (<< 0.121~)
 Replaces: initramfs-tools (<< 0.121~)
diff --git a/mkinitramfs b/mkinitramfs
index 9f207a0..fd68709 100755
--- a/mkinitramfs
+++ b/mkinitramfs
@@ -151,6 +151,7 @@ if dpkg --compare-versions "${version}" lt "2.6.38" 
2>/dev/null; then
echo "linux-2.6 likely misses ${COMPRESS} support, using gzip"
 fi
 
+[ "${compress}" = gzip ] && [ -n "${SOURCE_DATE_EPOCH}" ] && compress="gzip -n"
 [ "${compress}" = lzop ] && compress="lzop -9"
 [ "${compress}" = xz ] && compress="xz --check=crc32"
 
@@ -371,8 +372,18 @@ fi
 # preserve permissions if root builds the image, see #633582
 [ "$(id -ru)" != 0 ] && cpio_owner_root="-R 0:0"
 
+# if SOURCE_DATE_EPOCH is set, try and create a reproducible image
+if [ -n "${SOURCE_DATE_EPOCH}" ]; then
+   # ensure that no timestamps are newer than $SOURCE_DATE_EPOCH
+   find "${DESTDIR}" -newermt "@${SOURCE_DATE_EPOCH}" -print0 | \
+   xargs -0r touch --no-dereference --date="@${SOURCE_DATE_EPOCH}"
+
+   # --reproducible requires cpio >= 2.12
+   cpio_reproducible="--reproducible"
+fi
+
 # work around lack of "set -o pipefail" for the following pipe:
-# cd "${DESTDIR}" && find . | cpio --quiet $cpio_owner_root -o -H newc | gzip 
>>"${outfile}" || exit 1
+# cd "${DESTDIR}" && find . | LC_ALL=C sort | cpio --quiet $cpio_owner_root 
$cpio_reproducible -o -H newc | gzip >>"${outfile}" || exit 1
 exec 3>&1
 eval `
# http://cfaj.freeshell.org/shell/cus-faq-2.html
@@ -381,7 +392,9 @@ eval `
{
find . 4>&-; echo "ec1=$?;" >&4
} | {
-   cpio --quiet $cpio_owner_root -o -H newc 4>&-; echo "ec2=$?;" 
>&4
+   LC_ALL=C sort
+   } | {
+   cpio --quiet $cpio_owner_root $cpio_reproducible -o -H newc 
4>&-; echo "ec2=$?;" >&4
} | ${compress} >>"${outfile}"
echo "ec3=$?;" >&4
 `
diff --git a/mkinitramfs.8 b/mkinitramfs.8
index 4c8bae5..b61fdeb 100644
--- a/mkinitramfs.8
+++ b/mkinitramfs.8
@@ -105,6 +105,12 @@ should not be mounted with the
 .B noexec
 mount option.
 
+If
+.B SOURCE_DATE_EPOCH
+is set,
+.B mkinitramfs
+attempts to generate a reproducible ramdisk.
+
 .SH FILES
 .TP
 .I /etc/initramfs-tools/initramfs.conf

Bug#737167: xfonts-wqy: prompting due to modified conffiles which were not modified by the user

[陳昌倬]

Control: fixed -1 1.0.0~rc1-1

On Sun, Jan 01, 2017 at 01:14:24AM -0800, Paul Hardy wrote:
> Did that upload fix this bug, and the bug just wasn't marked as closed?

Just do the test and it is okay in version 1.0.0~rc1-1. Thanks for the
reminder.

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#804063: cpio: New upstream release 2.12 available

[Chris Lamb]

tags 804063 + pending
thanks

Chris Lamb wrote:

> Just having issues compiling the mingw part

Fixed! Uploading now…


Regards,

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

Bug#849417: [Pkg-nagios-devel] Bug#849417: nagios-nrpe-server: segfault during SSL negotiation with older NRPE 2.15 plugin

[Sebastiaan Couwenberg]

tags 849417 - unreproducible moreinfo
tags 849417 + upstream
forwarded 849417 https://github.com/NagiosEnterprises/nrpe/issues/91
thanks

Hi Adam,

Thanks for the additional debugging. I've now been able to reproduce the
issue on a Debian unstable VM, and have forwarded the issue upstream.

On 01/01/2017 04:07 AM, Adam Di Carlo wrote:
> Sebastiaan Couwenberg  writes:
> 
>> The debug symbols are already available, no need to a rebuild. Just
>> install the nagios-nrpe-server-dbgsym package.
> [...]
> 
> Thanks, that system is new to me!

Debug packages have existed for quite some time, the automatic dbgsym
packages are new in stretch, see: https://wiki.debian.org/DebugPackage

> Let me know if you're still stumped.   I think my next step would be to
> have to try to hack sources and come up with a diff which fixes matters.

That would be excellent, please forward your proposed fix upstream.

> Also, I'm clearly missing some debug symbols, covering
> .../sysdeps/x86_64/strlen.S, but not sure what package I need to install
> to cover that.

You need the libc source for that.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#849849: rabbitmq-server: CVE-2016-9877

[Salvatore Bonaccorso]

Source: rabbitmq-server
Version: 3.6.5-1
Severity: grave
Tags: upstream security
Justification: user security hole

Hi,

the following vulnerability was published for rabbitmq-server.

CVE-2016-9877[0]:
| An issue was discovered in Pivotal RabbitMQ 3.x before 3.5.8 and 3.6.x
| before 3.6.6 and RabbitMQ for PCF 1.5.x before 1.5.20, 1.6.x before
| 1.6.12, and 1.7.x before 1.7.7. MQTT (MQ Telemetry Transport)
| connection authentication with a username/password pair succeeds if an
| existing username is provided but the password is omitted from the
| connection request. Connections that use TLS with a client-provided
| certificate are not affected.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9877
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9877
[1] https://github.com/rabbitmq/rabbitmq-mqtt/pull/98
[2] https://github.com/rabbitmq/rabbitmq-mqtt/issues/96

Please adjust the affected versions in the BTS as needed. I was only
able to check the vulnerability sourcewise for 3.6.5 in unstable,
older version have not been checked so far.

Regards,
Salvatore

Bug#849804: /etc/init.d/asterisk debug unusable for continous output

[Joerg Dorchain]

On Sun, Jan 01, 2017 at 11:22:25AM +0100, Bernhard Schmidt wrote:
> Hi,
> 
> > The messages comes from pjproject. The messages are relatively low
> > priority ones there.
> > 
> > However just from reading the code I'm a bit lost. That message seems to
> > be at log priorty 6 in pjproject:
> > http://sources.debian.net/src/pjproject/2.5.5~dfsg-5/pjlib/src/pj/os_core_unix.c/?hl=1361#L1361
> > (And likewise in 2.4.5)
> > 
> > Asterisk maps by default pjproject log levels 3, 4 and 5 to "debug" (see
> > pjproject.conf) and I don't see anything about 6. Do you have anything
> > customized there? Can you play with the definitions in that file?
> 
> As a sidenote, I have enabled log level 6 in pjproject 2.5.5~dfsg-4
> (which has hit testing as well yesterday) following the non-ABI breaking
> suggestions in
> https://github.com/asterisk/asterisk/blob/master/third-party/pjproject/patches/config_site.h
> . So these messages weren't generated before I guess.
> 
> Joerg, can you test downgrading pjproject to -3?

Hm, I have some packages with that version number indeed:
dpkg-query -W|grep 2.5.5~dfsg-5
libpj2:amd642.5.5~dfsg-5
libpjlib-util2:amd642.5.5~dfsg-5
libpjmedia-audiodev2:amd64  2.5.5~dfsg-5
libpjmedia-codec2:amd64 2.5.5~dfsg-5
libpjmedia-videodev2:amd64  2.5.5~dfsg-5
libpjmedia2:amd64   2.5.5~dfsg-5
libpjnath2:amd642.5.5~dfsg-5
libpjsip-simple2:amd64  2.5.5~dfsg-5
libpjsip-ua2:amd64  2.5.5~dfsg-5
libpjsip2:amd64 2.5.5~dfsg-5
libpjsua2:amd64 2.5.5~dfsg-5
libpjsua2-2v5:amd64 2.5.5~dfsg-5
and asterisk has it in its dependency chain.

Downgrading these to 2.5.5~dfsg-3 from snapshot.debian.org indeed
helped the problem. So far, so easy.

To keep me happy, I see some options. Most obvious, do we really
need that loglevel? If yes, it should be mentioned in
pjproject.conf, with the option to silence them, maybe with a
word of warning for the clutter on the console.

Bye,

Joerg



signature.asc
Description: PGP signature

Bug#828607: closing 828607

[Ferenc Wágner]

wf...@niif.hu (Ferenc Wágner) writes:

> Niels Thykier  writes:
>
>> Ferenc Wágner:
>> 
>>> Thanks for re-closing this bug.  Could you please help me understand why
>>> xml-security-c 1.7.3-4 hasn't migrated to testing yet, even though
>>> https://qa.debian.org/excuses.php?package=xml-security-c says it's "47
>>> days old (needed 10 days)" and "valid candidate"?  Is this related to
>>> the ssl1.0 transition?  Do I have to do anything to move things forward?
>>
>> According to Britney, migrating xml-security-c would break
>> "libsaml2-dev, libshibsp-dev, libxmltooling-dev" (at least on mipsel).
>>
>> The latter two looks like they will become ready to migrate later today,
>> so it /might/ fix itself tonight.
>
> shibboleth-sp2 migrated successfully, but xml-security-c and xmltooling
> is still stuck.  Installing the mipsel dev packages in a porterbox
> chroot is successful (I know this isn't a good test, but no idea how to
> run a better one).  Could you please help resolving this?

I don't know who or what fixed it, but xml-security-c and xmltooling
finally migrated to testing.  Thanks for the nice new year gift!
-- 
Regards,
Feri

Bug#849848: blhc: Architecture independent packages shouldn't log compiler commands

[Ferenc Wágner]

Package: blhc
Severity: normal

Dear Maintainer,

https://qa.debian.org/bls/bytag/I-no-compiler-commands.html says:

  Possible issues this might hint at:
  * A package being Architecture: all, though it only contains architecture
independent data. 

which I don't get.  The very point of Architecture: all packages is that they
contain architecture independent data (or code) only.  So why is this flagged
as a possible issue?  Either I misunderstand something, or this is completely
backwards.  Please fix what needs to be fixed. :)
-- 
Thanks,
Feri.

Bug#849843: libyaml-libyaml-perl: [PATCH] lazy load B::Deparse for big speedup

[Salvatore Bonaccorso]

Hello Eric,

Thanks for your patch. I have forwarded it upstream at
https://github.com/ingydotnet/yaml-libyaml-pm/issues/52

Regards,
Salvatore

Bug#848559: zeroinstall-injector: Don't recommend python3-aptdaemon.pkcompat

[Thomas Leonard]

On 18 December 2016 at 11:52, Jeremy Bicha  wrote:
> Package: zeroinstall-injector
> Version: 2.12-2
> Severity: important
>
> Please don't recommend python3-aptdaemon.pkcompat. aptdaemon has been
> removed from Debian and we don't want an obsolete recommends to keep
> it installed.
>
> See https://bugs.debian.org/825272

OK. I've removed it from the control file:

https://github.com/0install/0install-debian/commit/0dc07b3cd4487fb0bed282495ccef26ed314fbe0

Here's a 2.12-3 version with the change, if someone wants to approve it:

  https://mentors.debian.net/package/zeroinstall-injector


-- 
talex5 (GitHub/Twitter)http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

Bug#805857: Does not do a SRV lookup, tries A/AAAA record instead

[Christoph Biedl]

[ Just another sendxmpp user ]

martin f krafft wrote...

> If a SRV record is present, this should lead the way to the server
> for an address, not the A/ records of the domain.

Ouch, in my opinion this justifies a higher priority.

After digging in the sources of libnet-xmpp-perl (where this bug
probably belongs) I reckon the issue will resolve by installing
libnet-dns-perl. Can you please check?

Christoph


signature.asc
Description: Digital signature

Bug#849838: firefox: Fix broken hppa build support

[John Paul Adrian Glaubitz]

Hi Dave!

On 01/01/2017 02:33 AM, John David Anglin wrote:
> The attached patch fixes the compile issues and includes the comment that I 
> had.  My icedove
> build still isn't complete yet but it's well past the point where the compile 
> breakage occurred.

I don't think it makes much sense to update the patch for the Debian package, 
but I can
update the upstream patch accordingly by adding the comment. I won't change 
anything
else though. Although I'm not even sure how important the comment is either as 
the
commit message I added explains the change in every detail.

If you look at the rest of the PA-RISC assembly code in xptcall, you'll see 
that all
mnemonics are written in upper-case, so I'm going to keep 'STW' instead of 
'stw'.

Adrian

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

Bug#840132: xrdp-sesman.service sometimes fails to start on boot

[Dominik George]

Hi,

> One thing possibly interesting about both systems is that they are both
> kvm hosts.  After each system reaches network.target, the dependency for
> starting xrdp in systemd, quite a bit of subsequent network
> configuration takes place:

So why is network.target reached, then? This seems to be a local
configuration issue.

What you report looks related to some issues we had when IPv6 was
enabled but no addresses configured (not even link-local).

In any case, there have been related changes, and I am not sure whether
they fix that for you or not.

Can you please test with 0.9.1-1 and report back?

Cheers,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature

Bug#849847: base: fails to lock screen

[Akshat]

Package: base
Severity: important

Dear Maintainer,

The lock screen does not activate when I logout or turn the pc on. I hv also
set the screen to lock automatically after 30 seconds, but nothing happens.
even pressing Ctrl+Alt+L at desktop is unable to lock the screen.   

-- System Information:
Distributor ID: BOSS
Description:BOSS GNU/Linux 6.1 (anoop)
Release:6.1
Codename:   anoop
Architecture: x86_64

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

Bug#849467: jessie-pu: package hplip/3.14.6-1+deb8u1

[Didier 'OdyX' Raboud]

Le samedi, 31 décembre 2016, 17.10:09 h CET Adam D. Barratt a écrit :
> Control: tags -1 + confirmed
> 
> On Tue, 2016-12-27 at 14:18 +0100, Didier 'OdyX' Raboud wrote:
> > I'd like to get CVE-2015-0839 fixed in jessie, it's a no-DSA issue, and
> > security team members suggested to get it fixed through stable updates.
> > 
> > This bug is a simple 'fetching gpg key from keyservers with a short
> > keyid' problem, and upstream's fix is to use the full fingerprint.
> 
> Please go ahead.

Uploaded, thanks for the confirmation.

-- 
Cheers,
OdyX

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

Bug#600543: ctrl-k in emacs23 crashes xrdp

[Dominik George]

Control: tags -1 + moreinfo

Hi,

can you please check with 0.9.1, both with the xorgxrdp and VNC
backends?

Cheers,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature

Bug#600912: xrdp: Problem with Ctrl+AltGR+KEY combinations on German keyboard

[Dominik George]

Control: tags -1 + moreinfo

Hi,

can you please check this with 0.9.1, both with xorgxrdp and VNC as
backend?

Cheers,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature

Bug#849804: /etc/init.d/asterisk debug unusable for continous output

[Joerg Dorchain]

On Sun, Jan 01, 2017 at 11:06:30AM +0100, Tzafrir Cohen wrote:
> On Sat, Dec 31, 2016 at 09:30:35AM +0100, Joerg Dorchain wrote:
> > Package: asterisk
> > Version: 1:13.13.1~dfsg-2
> > 
> > Hello,
> > 
> > following testing, after upgrading to asterisk 1:13.13.1~dfsg-2,
> > /etc/init.d/asterisk debug endlessly repeats the following screen
> > output rapidly:
> > ...
> > 09:22:39.015 rtp0x558b74e70  Mutex: thread timer is waiting
> > 09:22:39.015 rtp0x558b74e70  Mutex acquired by thread timer
> 
> AST_DEBUG_PARAMS=-cvd. That is: verbose level 4 and debug level
> 5. It also means that asterisk remains attached to the terminal it was
> run from and offers aconsole there. Frankly I hardly recall needing to
> use this while debugging and frankly I completely forgot this option.

I like it as I start my low-usage home PBX manually.

When I start it with /etc/init.d/asterisk start, and then connect
to the console with asterisk -rvd, I do not see these
messages. It only says Core debug is still 6.

I suppose some logging logic changed from the previous release
when there is a controlling tty at startup.

> The messages comes from pjproject.

I do not use pjproject knowingly. As least, I do not have any
modules loaded that have *pj* in the name and use chan_sip for
sip connections.

> The messages are relatively low
> priority ones there.
> 
> However just from reading the code I'm a bit lost. That message seems to
> be at log priorty 6 in pjproject:
> http://sources.debian.net/src/pjproject/2.5.5~dfsg-5/pjlib/src/pj/os_core_unix.c/?hl=1361#L1361
> (And likewise in 2.4.5)
> 
> Asterisk maps by default pjproject log levels 3, 4 and 5 to "debug" (see
> pjproject.conf) and I don't see anything about 6. Do you have anything
> customized there? Can you play with the definitions in that file?

I have not modified this file from the default distribution. I
can try different settings there. What would you suggest?

> 
> That said, I'm not really surprise if at debug level 5 the console is
> not usable. I suppose there may be other messages that may lead to such
> a flood.

Actually, I use that feature (/etc/init.d/asterisk debug) since
asterisk 1.2 and it worked quite well since then. It helps me to
determine reasons for failed calls more easily.

Bye,

Joerg


signature.asc
Description: PGP signature

Bug#716554: [Mayhem] Bug report on xrdp: xrdp-chansrv crashes with exit status 139

[Dominik George]

Control: tags -1 + moreinfo

> re-running it in a fresh debian unstable installation.
> 
> The attachment [1] contains a testcase (under ./crash) crashing the
> program. It ensures that you can easily reproduce the bug. Additionally,
> under ./crash_info/, we include more information about the crash such as
> a core dump, the dmesg generated by the crash, and its output.

Can you please try to reproduce this with 0.9.1?

Cheers,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature

Bug#710089: xrdp: Should handle PAM conversation() callback in sesman

[Dominik George]

Control: tags -1 + moreinfo

Hi Petter,

> When using xrdp together with the libpam-mklocaluser, to create a local
> user with a local home directory when the user log in for the first
> time, xrdp/sesman fail to show the message passed back from the PAM
> module using the PAM conversation() callback mechanism.  This make users
> confused, as they get no feedback about why the first login fail.
> 
> Please change the PAM handling to also handle messages passed back from
> the PAM modules.

Can you please check how 0.9.1 handles this?

Cheers,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature

Bug#849804: /etc/init.d/asterisk debug unusable for continous output

[Bernhard Schmidt]

On Sun, Jan 01, 2017 at 11:06:30AM +0100, Tzafrir Cohen wrote:

Hi,

> The messages comes from pjproject. The messages are relatively low
> priority ones there.
> 
> However just from reading the code I'm a bit lost. That message seems to
> be at log priorty 6 in pjproject:
> http://sources.debian.net/src/pjproject/2.5.5~dfsg-5/pjlib/src/pj/os_core_unix.c/?hl=1361#L1361
> (And likewise in 2.4.5)
> 
> Asterisk maps by default pjproject log levels 3, 4 and 5 to "debug" (see
> pjproject.conf) and I don't see anything about 6. Do you have anything
> customized there? Can you play with the definitions in that file?

As a sidenote, I have enabled log level 6 in pjproject 2.5.5~dfsg-4
(which has hit testing as well yesterday) following the non-ABI breaking
suggestions in
https://github.com/asterisk/asterisk/blob/master/third-party/pjproject/patches/config_site.h
. So these messages weren't generated before I guess.

Joerg, can you test downgrading pjproject to -3?

Bernhard


signature.asc
Description: Digital signature

Bug#849342: [xrdp] xrdp-sesman: Fails to start Xorg

[Dominik George]

Control: tags -1 + moreinfo

Hi Ben,

> Dec 25 15:49:14 lear xrdp-sesman[15632]: (15632)(-148605184)[INFO ] Xorg :10 
> -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp

Can you please try running this exact command manually as the same user?

Cheers,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature

Bug#849846: logrotate: Add support for systemd timers

[Daniel Schaal]

Source: logrotate
Version: 3.8.7-2
Severity: wishlist
Tags: patch

Hi,

the attached patch backports the systemd timer and service units from upstream
version 3.11.0 and adds a check to the cron script to only run on non-systemd
systems.

-- Package-specific info:
Contents of /etc/logrotate.d
total 20
-rw-r--r-- 1 root root 173 Apr  5  2016 apt
-rw-r--r-- 1 root root  79 Mar  5  2016 aptitude
-rw-r--r-- 1 root root 181 Jun 17  2016 cups-daemon
-rw-r--r-- 1 root root 232 Jun 10  2015 dpkg
-rw-r--r-- 1 root root  82 Mar 21  2016 dracut-core


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

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

-- no debconf information
>From 1a162ea16ea651f3b5f6a14ac93ec0d4a62f3a15 Mon Sep 17 00:00:00 2001
From: Daniel Schaal 
Date: Sat, 31 Dec 2016 17:49:17 +0100
Subject: [PATCH] Add systemd timer and skip cron script on systems running
 systemd

---
 debian/control   |  2 +-
 debian/cron.daily|  2 +-
 debian/logrotate.install |  6 --
 debian/logrotate.service | 11 +++
 debian/logrotate.timer   | 11 +++
 debian/rules | 11 ++-
 6 files changed, 38 insertions(+), 5 deletions(-)
 create mode 100644 debian/logrotate.service
 create mode 100644 debian/logrotate.timer

diff --git a/debian/control b/debian/control
index 4e6a9ad..15e0d87 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: logrotate
 Section: admin
 Priority: important
 Maintainer: Paul Martin 
-Build-Depends: libpopt-dev, debhelper (>= 9),
+Build-Depends: libpopt-dev, debhelper (>= 9), dh-systemd,
  libselinux1-dev [linux-any], libacl1-dev [linux-any]
 Vcs-Svn: http://svn.fedorahosted.org/svn/logrotate/
 Homepage: https://fedorahosted.org/logrotate/
diff --git a/debian/cron.daily b/debian/cron.daily
index f4f56a9..1d907be 100644
--- a/debian/cron.daily
+++ b/debian/cron.daily
@@ -1,4 +1,4 @@
 #!/bin/sh
 
-test -x /usr/sbin/logrotate || exit 0
+test -x /usr/sbin/logrotate -a \! -d /lib/systemd/system || exit 0
 /usr/sbin/logrotate /etc/logrotate.conf
diff --git a/debian/logrotate.install b/debian/logrotate.install
index d4696ba..2291f02 100644
--- a/debian/logrotate.install
+++ b/debian/logrotate.install
@@ -1,2 +1,4 @@
-logrotate  usr/sbin/
-debian/logrotate.conf  etc/
+logrotate  usr/sbin/
+debian/logrotate.conf  etc/
+debian/logrotate.service   lib/systemd/system
+debian/logrotate.timer lib/systemd/system
diff --git a/debian/logrotate.service b/debian/logrotate.service
new file mode 100644
index 000..e276878
--- /dev/null
+++ b/debian/logrotate.service
@@ -0,0 +1,11 @@
+[Unit]
+Description=Rotate log files
+Documentation=man:logrotate(8) man:logrotate.conf(5)
+ConditionACPower=true
+
+[Service]
+Type=oneshot
+ExecStart=/usr/sbin/logrotate /etc/logrotate.conf
+Nice=19
+IOSchedulingClass=best-effort
+IOSchedulingPriority=7
diff --git a/debian/logrotate.timer b/debian/logrotate.timer
new file mode 100644
index 000..8f405d5
--- /dev/null
+++ b/debian/logrotate.timer
@@ -0,0 +1,11 @@
+[Unit]
+Description=Daily rotation of log files
+Documentation=man:logrotate(8) man:logrotate.conf(5)
+
+[Timer]
+OnCalendar=daily
+AccuracySec=12h
+Persistent=true
+
+[Install]
+WantedBy=timers.target
diff --git a/debian/rules b/debian/rules
index ad020e4..4628b3b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,7 +22,7 @@ endif
 
 
 %:
-   dh $@
+   dh $@ --with systemd
 
 override_dh_auto_build:
 ifeq ($(DEB_HOST_ARCH_OS),linux)
@@ -46,3 +46,12 @@ ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
cd test ; ./test
   endif
 endif
+
+override_dh_systemd_enable:
+   dh_systemd_enable --package=logrotate logrotate.timer
+
+override_dh_systemd_start:
+   dh_systemd_start --package=logrotate logrotate.timer
+   dh_systemd_start --package=logrotate --no-start logrotate.service
+
+override_dh_installinit:
-- 
2.11.0

Bug#849804: /etc/init.d/asterisk debug unusable for continous output

[Tzafrir Cohen]

Hi,

On Sat, Dec 31, 2016 at 09:30:35AM +0100, Joerg Dorchain wrote:
> Package: asterisk
> Version: 1:13.13.1~dfsg-2
> 
> Hello,
> 
> following testing, after upgrading to asterisk 1:13.13.1~dfsg-2,
> /etc/init.d/asterisk debug endlessly repeats the following screen
> output rapidly:
> ...
> 09:22:39.015 rtp0x558b74e70  Mutex: thread timer is waiting
> 09:22:39.015 rtp0x558b74e70  Mutex acquired by thread timer

AST_DEBUG_PARAMS=-cvd. That is: verbose level 4 and debug level
5. It also means that asterisk remains attached to the terminal it was
run from and offers aconsole there. Frankly I hardly recall needing to
use this while debugging and frankly I completely forgot this option.

The messages comes from pjproject. The messages are relatively low
priority ones there.

However just from reading the code I'm a bit lost. That message seems to
be at log priorty 6 in pjproject:
http://sources.debian.net/src/pjproject/2.5.5~dfsg-5/pjlib/src/pj/os_core_unix.c/?hl=1361#L1361
(And likewise in 2.4.5)

Asterisk maps by default pjproject log levels 3, 4 and 5 to "debug" (see
pjproject.conf) and I don't see anything about 6. Do you have anything
customized there? Can you play with the definitions in that file?

That said, I'm not really surprise if at debug level 5 the console is
not usable. I suppose there may be other messages that may lead to such
a flood.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Bug#849845: dirmngr: Can't resolve keyserver hostname anymore

[intrigeri]

Package: dirmngr
Version: 2.1.17-2
Severity: important

Hi!

since the upgrade to 2.1.17 (not sure if it's in -1 or -2), my dirmngr
is unusable. Any network operation triggers:

  can't connect to 'hkps.pool.sks-keyservers.net': no IP address for host

... almost immediately, i.e. resolver-timeout seems to be ignored.

I've tried multiple combinations of the following settings in
dirmngr.conf:

 * disabling "use-tor"
 * enabling "standard-resolver"
 * pointing "nameserver" to 127.0.0.1 (my Tor DNSPort, that only
   listens on UDP 127.0.0.1:53)
 * pointing "nameserver" to 8.8.8.8 (which should be the default
   given I have "use-tor" enabled, but well)
 * raising the value of "resolver-timeout"

… but none of them helped.

Downgrading to 2.1.16-3 fixes this problem.

The only weird thing about my system that I can think of is that my
/etc/resolv.conf points to 127.0.0.1 (where I have Tor's DNSPort
listening, that only handles A, , and PTR requests). In theory
this should not matter since with use-tor, DNS queries are done over
Tor to 8.8.8.8, if I got the manpage right. However, my limited strace
skills allow me to notice that dirmngr reads /etc/resolv.conf and then
connects to 127.0.0.1 and not to 8.8.8.8 (even if I explicitly set
"nameserver 8.8.8.8" in dirmngr.conf):

  23694 10:51:07.455096 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 
IPPROTO_IP) = 6 <0.15>
  23694 10:51:07.455145 bind(6, {sa_family=AF_INET, sin_port=htons(53891), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.07>
  23694 10:51:07.455196 connect(6, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("127.0.0.1")}, 16) = 0 <0.09>
  23694 10:51:07.455218 sendto(6, 
"\250\302\1\0\0\1\0\0\0\0\0\0\4hkps\4pool\16sks-keyse"..., 46, 0, NULL, 0) = 46 
<0.39>
   | 0  a8 c2 01 00 00 01 00 00  00 00 00 00 04 68 6b 70  .hkp |
   | 00010  73 04 70 6f 6f 6c 0e 73  6b 73 2d 6b 65 79 73 65  s.pool.sks-keyse |
   | 00020  72 76 65 72 73 03 6e 65  74 00 00 01 00 01rvers.net.   |
  23694 10:51:07.455298 recvfrom(6, 0x7fda90009d4c, 768, 0, NULL, NULL) = -1 
EAGAIN (Resource temporarily unavailable) <0.04>
  23694 10:51:07.455318 select(7, [6], [], NULL, {tv_sec=1, tv_usec=0}) = 1 (in 
[6], left {tv_sec=0, tv_usec=922029}) <0.077993>
  23694 10:51:07.533390 recvfrom(6, 
"\250\302\201\200\0\1\0\1\0\0\0\0\4hkps\4pool\16sks-keyse"..., 768, 0, NULL, 
NULL) = 62 <0.32>
   | 0  a8 c2 81 80 00 01 00 01  00 00 00 00 04 68 6b 70  .hkp |
   | 00010  73 04 70 6f 6f 6c 0e 73  6b 73 2d 6b 65 79 73 65  s.pool.sks-keyse |
   | 00020  72 76 65 72 73 03 6e 65  74 00 00 01 00 01 c0 0c  rvers.net... |
   | 00030  00 01 00 01 00 00 00 3c  00 04 d1 87 d3 8d...<..   |
  23694 10:51:07.533551 connect(6, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("127.0.0.1")}, 16) = 0 <0.41>
  23694 10:51:07.533627 sendto(6, 
"\3601\1\0\0\1\0\0\0\0\0\0\4hkps\4pool\16sks-keyse"..., 46, 0, NULL, 0) = 46 
<0.46>
   | 0  f0 31 01 00 00 01 00 00  00 00 00 00 04 68 6b 70  .1...hkp |
   | 00010  73 04 70 6f 6f 6c 0e 73  6b 73 2d 6b 65 79 73 65  s.pool.sks-keyse |
   | 00020  72 76 65 72 73 03 6e 65  74 00 00 1c 00 01rvers.net.   |
  23694 10:51:07.533720 recvfrom(6, 0x7fda9000a10c, 768, 0, NULL, NULL) = -1 
EAGAIN (Resource temporarily unavailable) <0.10>
  23694 10:51:07.533763 select(7, [6], [], NULL, {tv_sec=1, tv_usec=0}) = 1 (in 
[6], left {tv_sec=0, tv_usec=921164}) <0.078863>
  23694 10:51:07.612705 recvfrom(6, 
"\3601\201\203\0\1\0\0\0\0\0\0\4hkps\4pool\16sks-keyse"..., 768, 0, NULL, NULL) 
= 46 <0.22>
   | 0  f0 31 81 83 00 01 00 00  00 00 00 00 04 68 6b 70  .1...hkp |
   | 00010  73 04 70 6f 6f 6c 0e 73  6b 73 2d 6b 65 79 73 65  s.pool.sks-keyse |
   | 00020  72 76 65 72 73 03 6e 65  74 00 00 1c 00 01rvers.net.   |
  23694 10:51:07.612832 connect(6, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("127.0.0.1")}, 16) = 0 <0.14>
  23694 10:51:07.612894 sendto(6, 
"\224J\1\0\0\1\0\0\0\0\0\0\4hkps\4pool\16sks-keyse"..., 47, 0, NULL, 0) = 47 
<0.49>
   | 0  94 4a 01 00 00 01 00 00  00 00 00 00 04 68 6b 70  .J...hkp |
   | 00010  73 04 70 6f 6f 6c 0e 73  6b 73 2d 6b 65 79 73 65  s.pool.sks-keyse |
   | 00020  72 76 65 72 73 03 6e 65  74 00 00 00 1c 00 01 rvers.net..  |
  23694 10:51:07.612999 recvfrom(6, 
"\224J\201\204\0\1\0\0\0\0\0\0\4hkps\4pool\16sks-keyse"..., 768, 0, NULL, NULL) 
= 46 <0.23>
   | 0  94 4a 81 84 00 01 00 00  00 00 00 00 04 68 6b 70  .J...hkp |
   | 00010  73 04 70 6f 6f 6c 0e 73  6b 73 2d 6b 65 79 73 65  s.pool.sks-keyse |
   | 00020  72 76 65 72 73 03 6e 65  74 00 00 00 1c 00rvers.net.   |
  23694 10:51:07.613070 close(6)  = 0 <0.17>
  23694 10:51:07.613113 write(2, "can't connect to 'hkps.pool.sks-"..., 71) = 
71 <0.18>
  23694 10:51:07.613149 write(2, "\n", 1) = 1 <0.11>
  23694 10:51:07.613198 write(2, 

Bug#844578: logrotate: Upstream has moved to GitHub

[Daniel Schaal]

Package: logrotate
Version: 3.8.7-2
Followup-For: Bug #844578

Hi,

the attached patch updates the watch file to check github for new releases.

-- Package-specific info:
Contents of /etc/logrotate.d
total 20
-rw-r--r-- 1 root root 173 Apr  5  2016 apt
-rw-r--r-- 1 root root  79 Mar  5  2016 aptitude
-rw-r--r-- 1 root root 181 Jun 17  2016 cups-daemon
-rw-r--r-- 1 root root 232 Jun 10  2015 dpkg
-rw-r--r-- 1 root root  82 Mar 21  2016 dracut-core


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

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

Versions of packages logrotate depends on:
ii  anacron 2.3-23
ii  base-passwd 3.5.42
ii  cron [cron-daemon]  3.0pl1-128
ii  libacl1 2.2.52-3
ii  libc6   2.24-8
ii  libpopt01.16-10
ii  libselinux1 2.6-3

Versions of packages logrotate recommends:
pn  mailx  

logrotate suggests no packages.

-- no debconf information
>From ebfca579c0cb30cda869f57ebc2e3b7f256ad1dc Mon Sep 17 00:00:00 2001
From: Daniel Schaal 
Date: Sun, 1 Jan 2017 10:29:43 +0100
Subject: [PATCH] Update watch file for upstream move to github

---
 debian/watch | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/debian/watch b/debian/watch
index 6997217..c513332 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,6 +1,2 @@
-# Compulsory line, this is a version 3 file
 version=3
-
-http://fedorahosted.org/releases/l/o/logrotate/logrotate-([\d\.]+).tar.gz
-
-
+https://github.com/logrotate/logrotate/releases .*/logrotate-(\d\S*)\.tar\.xz
-- 
2.11.0

Bug#849631: dnscrypt-proxy

[peter.newey]

Hallo Eric
after a complete purge of dnscrypt-proxy files and a reinstall of version 
1.8.1-4 it appears to be working correctly.
I have only needed to alter the :
etc/dnscrypt-proxy/dnscrypt-proxy.conf

to change to my preferred  DNSCRYPT_PROXY_RESOLVER_NAME=
thanks for your help
Peter

Bug#568094: Processed: Re: Bug#568094: fwvm-crystal: clock freezes after sleep

[Jaimos Skriletz]

On Sun, 27 Jan 2013 12:17:24 +0100 Vincent Bernat  wrote:
> reassign 568094 fvwm
> retitle  568094 fvwm: periodic tasks in a module won't work after sleep
> thanks
>
> Hi!
>
> The clock is a FVWM script swallowed into a fvwm button. There is no way
> that every script should handle low-level details like IPC stuff being
> stateful or not (I don't know what it means). The script makes use of a
> documented interface for a module (PeriodicTasks[1]).
>

As a suggestion if it is still the case that a suspend sometimes
causes the clock to stop and requires restarting either fvwm or the
FvwmButtons panel is instead of swallowing FvwmScript, use the
Schedule command to schedule a periodic task and SendToModule to
change the Title of the button that has the time in it.

This should be more internal to Fvwm and I think should work (not that
i really know what the IPC state means either).

jaimos

Bug#737167: xfonts-wqy: prompting due to modified conffiles which were not modified by the user

[Paul Hardy]

This RC bug from 2014 reports packaging problems with configuration
files.  In 2015, ChangZhuo Chen uploaded a new version with suffix
"rc1-1" having the changelog entry "Fix wrong configuration file."
See the changelog entry excerpted below:

--start changelog entry---
xfonts-wqy (1.0.0~rc1-1) unstable; urgency=medium

  * New upstream release.
  * Bump Standards-Version to 3.9.6.
  * Use copyright-format 1.0.
  * Fix wrong configuration file.
  * Update watch.
  * Remove patches.
  * Add ChangZhuo Chen as Uploaders.

 -- ChangZhuo Chen (陳昌倬)   Sun, 22 Nov 2015 21:56:25 +0800
--end changelog entry

Did that upload fix this bug, and the bug just wasn't marked as closed?

There is also a FTBFS bug for this package (#808850).  I posted a
patch that is a workaround for the FTBFS problem.

These are the only two RC bugs for xfonts-wqy.

Right now, xfonts-wqy is marked for removal from testing on January
14th because of these two RC bugs.  I just noticed this a little over
a day ago.

Popcon reports over 1000 installations of this package.  Can the
Debian Fonts Task Force please prepare a new upload to prevent this
package from being removed from testing?

Thank you,


Paul Hardy

Bug#784286: dirmngr keyserver should default to hkps://hkps.pool.sks-keyservers.net

[intrigeri]

Hi Daniel,

that's fixed in 2.1.16, right?

The upstream changelog reads:

2016-11-17  Daniel Kahn Gillmor  

dirmngr: Use a default keyserver if none is explicitly set.

Cheers,
-- 
intrigeri

Bug#816249: debian-policy: C.2.4 does not reflect current practises

[Niels Thykier]

Russ Allbery:
> Niels Thykier  writes:
> 
>> The section C.2.4 seems to be a bit outdated.  Quote:
> 
>> """
>> [...]
>> """
> 
>> However, the default used by debhelper is "debian/", which covers
>> up to 99% of all packages.
> 
> Thanks for pointing this out.  The (non-normative) appendices have not
> gotten a lot of love.  I've applied the following patch to update this at
> least somewhat:
> 
> [...]
>  

Thanks for picking this up (and a happy year)! :)

Also, great job on the other policy changes in git today/yesterday! :)

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Bug#845173: Cannot handle new debs with data component XZ compressed in parallel

[A Mennucc1]

Il 21/11/2016 04:27, Carlos Maddela ha scritto:
> Ever since dpkg 1.18.14 or 1.18.15 was released there haven't been too
> many usable debdeltas available for download. The reason being that debs
> that have their data component compressed in XZ format are now being
> done so in parallel, which produces a file that debdelta cannot
> reproduce.

Dear Carlos,

thanks a lot,

I have applied the patch from your GIT tree into the server, soon we
will see if it works fine,

Andrea





signature.asc
Description: OpenPGP digital signature

Bug#849844: RFS: manpages-zh/1.6.0-1

[Boyuan Yang]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: chinese-develop...@lists.alioth.debian.org

Dear mentors and chinese-developer folks,

I am looking for a sponsor for my package "manpages-zh".

 * Package name: manpages-zh
   Version : 1.6.0-1
   Upstream Author : Boyuan Yang <073p...@gmail.com>
 * URL : https://github.com/man-pages-zh/manpages-zh
 * License : GFDL-1.2+
   Section : doc

It builds the following packages:

manpages-zh - Chinese manual pages

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

https://mentors.debian.net/package/manpages-zh

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

dget -x https://mentors.debian.net/debian/pool/main/m/manpages-zh/
manpages-zh_1.6.0-1.dsc

Alternatively, one can download packages on debomatic-amd64:

http://debomatic-amd64.debian.net/distribution#unstable/manpages-zh/
1.6.0-1/buildlog

Changes since last upload:
 manpages-zh (1.6.0-1) unstable; urgency=medium
 .
   * New upstream release.
 - Import more translations for coreutils.
 - Various updates.

Some explanations:

This is a new upstream release, mainly about cleanup for historical cruft.

Lintian warnings for man pages is being tracked by upstream and will release
fixes in next release. Those warnings do not affect user experience.

Regards,
Boyuan Yang


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

Bug#849631: dnscrypt-proxy

[peter.newey]

Hallo Eric
I am seeing the same:dnscrypt-proxy.service: Failed   with result 
'start-limit-hit'.
after update to Version: 1.8.1-4
I notice the change in the files list from :

/./etc/etc/default/etc/default/dnscrypt-proxy/etc/init.d/etc/init.d/dnscrypt-proxy.

to :

/./etc/etc/dnscrypt-proxy/etc/dnscrypt-proxy/dnscrypt-proxy.conf.
I am only a novice but this seems to be my problem:
I was changing the 3 files

/etc/default/dnscrypt-proxy/etc/init.d/dnscrypt-proxy/lib/systemd/system/dnscrypt-proxy.service
to show my preferred   DNSCRYPT_PROXY_RESOLVER_NAME=
and it was working quite successfully until the update

does this throw any light on our problem ?
thanks  
Peter

Bug#849578: task-xfce-desktop: Why you use the vlc player in the task-xfce-desktop meta package?

[Christian PERRIER]

Quoting Jürgen Göricke (juergengoeri...@smart-mail.de):
> Dear Maintainer,
> 
> see all the dependencies from package vlc in Debian Sid.
> 
> https://packages.debian.org/sid/vlc
> 
> http://paste.debian.net/905778
> 
> Vlc needs Qt dependencies by default.
> 
> What is the problem with parole to add the task-xfce-desktop respectively
> tasksel meta packages?
> 
> Why you wan't change the packages? I can't understand it.
> 
> Parole is the default media player from xfce project and not so bloated
> as the vlc player.

The more impatient you appear, the less likely is that the change will
happen.

Corsac gave a good answer, which, somehow, may trigger discussion
about the fact that doing such change so late in the release process
may not be a good idea.

Let other people give some advice.




signature.asc
Description: PGP signature

Bug#849843: libyaml-libyaml-perl: [PATCH] lazy load B::Deparse for big speedup

[Eric Wong]

Package: libyaml-libyaml-perl
Version: 0.63-1
Severity: normal
Tags: patch upstream

This speeds up startup time dramatically and is noticeable with
small scripts on my weak hardware where loading B::Deparse takes
a significant amount of time.  Lazy loading it helps for the
common case when I do not need to dump a coderef.

"require" is idempotent in Perl, so it has virtually no overhead
across repeated invocations of coderef2text.

With this patch, the following script runs in around 30ms
without any args passed; and around 150ms with "code" as the
first arg.  Without the patch, it takes around 150ms regardless.

---8<---
use YAML::XS qw(Dump);
my $h = { a => 'b', c => 'd' };
warn Dump($h);
if (shift eq 'code') {
warn $YAML::XS::coderef2text->(sub { print "Hi\n" });
}
---8<---

Note: I realize upstream has a git repository and bug tracker;
but I will not use that as that requires registering on a site
which is non-Free Software, requires non-Free JavaScript (which
I wouldn't run regardless given my slow hardware) and has an
unacceptable terms-of-service.  So, thank you to Debian
for continuing to host an open-to-all bug tracker :)
>From 8c51950fa3796346542ca01ee04659edaaf81cc3 Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Sun, 1 Jan 2017 08:05:59 +
Subject: [PATCH] load B::Deparse lazily

This speeds up startup time dramatically and is noticeable with
small scripts on my weak hardware where loading B::Deparse takes
a significant amount of time.  Lazy loading it helps for the
common case when I do not need to dump a coderef.

"require" is idempotent in Perl, so it has virtually no overhead
across repeated invocations of coderef2text.

With this patch, the following script runs in around 30ms
without any args passed; and around 150ms with "code" as the
first arg.  Without the patch, it takes around 150ms regardless.

---8<---
use YAML::XS qw(Dump);
my $h = { a => 'b', c => 'd' };
warn Dump($h);
if (shift eq 'code') {
	warn $YAML::XS::coderef2text->(sub { print "Hi\n" });
}
---8<---
---
 lib/YAML/XS.pm | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/lib/YAML/XS.pm b/lib/YAML/XS.pm
index 90253c8..0fd2df4 100644
--- a/lib/YAML/XS.pm
+++ b/lib/YAML/XS.pm
@@ -50,15 +50,11 @@ sub LoadFile {
 return YAML::XS::LibYAML::Load(do { local $/; local $_ = <$IN> });
 }
 
-# XXX Figure out how to lazily load this module.
-# So far I've tried using the C function:
-#  load_module(PERL_LOADMOD_NOIMPORT, newSVpv("B::Deparse", 0), NULL);
-# But it didn't seem to work.
-use B::Deparse;
 
 # XXX The following code should be moved from Perl to C.
 $YAML::XS::coderef2text = sub {
 my $coderef = shift;
+require B::Deparse;
 my $deparse = B::Deparse->new();
 my $text;
 eval {
-- 
EW

Bug#849841: [src:linux] bpfcc-tools don't work on 4.8 signed kernels

[Ritesh Raj Sarraf]

On Sun, 2017-01-01 at 09:24 +0800, Liang Guo wrote:
> Package: src:linux
> Version: linux-image-4.8.0-2-amd64
> Severity: serious
> 

I don't think this severity is justified, when the regular kernels work fine
with it.

> Hi, I found bpfcc-tools don't work on linux-image-4.8.0-2-amd64 and 
> linux-image-4.8.0-2-rt-amd64, for these kernels are signed kernel, I think
> bpfcc-tools don't work on all signed kernels on x86_64 platform. bpfcc-tools 
> works on linux-image-4.8.0-2-amd64-unsigned, 
> linux-image-4.8.0-2-rt-amd64-unsigned and linux-image-4.7.0-1-amd64, following
> is my detailed test log:
> 
> ##linux-image-4.8.0-2-amd64
> root@bcat:~# python /usr/share/doc/bpfcc-tools/examples/hello_world.py  
> bpf: Invalid argument 
> 


This seems to be the problem. I am not sure what is causing it on a signed 
linux package.

Please also see a similar issue upstream:
https://github.com/iovisor/bcc/issues/283

Going by the bug report upstream, it may not necessarily be a signed linux
package issue; but I'm not sure right now.

> Traceback (most recent call last): 
>  File "/usr/share/doc/bpfcc-tools/examples/hello_world.py", line 11, in
>  
>    BPF(text='int kprobe__sys_clone(void *ctx) { bpf_trace_printk("Hello,
> World!\\n"); return 0; }').trace_print() 
>  File "/usr/lib/python2.7/dist-packages/bcc/__init__.py", line 203, in
> __init__ 
>    self._trace_autoload() 
>  File "/usr/lib/python2.7/dist-packages/bcc/__init__.py", line 679, in
> _trace_autoload 
>    fn = self.load_func(func_name, BPF.KPROBE) 
>  File "/usr/lib/python2.7/dist-packages/bcc/__init__.py", line 243, in
> load_func 
>    raise Exception("Failed to load BPF program %s" % func_name) 
> Exception: Failed to load BPF program kprobe__sys_clone
-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

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