from:"arno"


Hi Diederik,

Am 13.01.2024 um 17:13 schrieb Diederik de Haas:
...

Via https://snapshot.debian.org/package/linux-signed-amd64/ you have easy
access to previous (6.1) kernels uploaded to Debian with which you can check
if the problem was present in early 6.1 kernels.


The oldest record of this issue has happened with Linux version 
6.1.0-11-amd64


As I usually keep this box updated, and the problems happens only 
randomly, I think the best way forward might be to try with a kernel 
that did *not* show this problem.


Does that look reasonable?

So, I have:
# journalctl --grep PCIe\ link\ lost
-- Boot 86e1a04baba04a409c34796c0fb079ff --
Sep 20 14:21:17 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, 
device now detached

-- Boot da6a00d9278a422686ca46d80e2f3ca6 --
-- Boot 28fcdfe079c446c6b184bb5b6407da73 --
Okt 06 05:44:20 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, 
device now detached
Okt 07 16:39:10 Zwerg kernel: igc :0a:00.0 (unnamed net_device) 
(uninitialized): PCIe link lost, device now detached

-- Boot 51e3605887764b60b6d0130d4f6356c0 --
-- Boot ce944a4bbffc45b38c1357d3e822cd46 --
Okt 23 18:31:25 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, 
device now detached

-- Boot e6d80407cab74d0b9e28b74642b544c0 --
Okt 30 11:16:06 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, 
device now detached
Okt 31 13:50:06 Zwerg kernel: igc :0a:00.0 (unnamed net_device) 
(uninitialized): PCIe link lost, device now detached

-- Boot 452f25ce23fe4d569490fbc42683ecd6 --
Nov 22 18:59:11 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, 
device now detached

-- Boot f1add031e2fa495aba569ab9c374ce65 --
Nov 23 15:45:49 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, 
device now detached

-- Boot f766dabb981e4aa49f0922d7794dea76 --
-- Boot 6d7c91a86ab44da1973f5ca716dad105 --
-- Boot 3ba3df042e0648a1aebfa4fcea5499bf --
Dez 19 07:33:02 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, 
device now detached

-- Boot a4aea30bb33747e7853abec194a2a395 --
Jan 01 09:57:40 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, 
device now detached

-- Boot 377a326561dc4909b45c55cffcd1a94d --
Jan 10 16:15:20 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, 
device now detached

-- Boot 50c5a6a9cc34496984fe3cde6ba8b72a --
Jan 13 11:16:31 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, 
device now detached

-- Boot a3c69838cab4426992a2f518a72a5e2b --


So I conclude I should look at something earlier than what was used with 
boot 86e1a04baba04a409c34796c0fb079ff, i.e.


journalctl --boot 86e1a04baba04a409c34796c0fb079ff  | head -n 1
Aug 30 18:16:18 Zwerg kernel: Linux version 6.1.0-11-amd64 
(debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU 
ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 
6.1.38-4 (2023-08-08)


correct?

Via the page you reference, I find a kernel package 
linux-image-6.1.0-1-amd64 6.1.4-1 which might be worth a try.


I'll need some time to sort out how to install such a package...

Thanks for your suggestion,

Arno


--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable


Hi Salvatore,

Am 13.01.2024 um 13:47 schrieb Salvatore Bonaccorso:


Just to be clear, can you confirm this is or is not a regression from
a previous running 6.1.y kernel?


On this hardware, the network issues appeared right from the start.

First time I encountered it was with the Debian installation sime time 
last year, and that's where my research led me to turn off PCIe power 
management.


Actually I don't even know which was the first kernel version I had on 
this host, but it's been on Bookworm for all its lifetime.



I'm asking because I suspect that
this similar to
https://lore.kernel.org/intel-wired-lan/20221031170535.77be0...@kernel.org/
and did not ever worked reliably with your hardware?


The symptoms sound quite different to me. But I can't claim to know 
anything interesting about the different functionalities of PCIe or the 
Linux way to use them...


Cheers,

Arno


--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable


Am 13.01.2024 um 12:48 schrieb Diederik de Haas:

On Saturday, 13 January 2024 11:45:29 CET Arno Lehmann wrote:

Hardware name: ASUS System Product Name/ROG STRIX X670E-A GAMING WIFI,
BIOS 1410 04/28/2023


Possibly not related, but there's BIOS 1807 available.


I'll definitely give that a try -- when I'm physically close to the box! 
Thanks for reminding me!


Arno

--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable

Package: src:linux
Version: 6.1.69-1
Severity: normal
Tags: upstream

Dear Maintainer,


just having the computer run for a while, the network loses connection because
the NIC detached from PCIe. I suspect this is related to power management but
am not really sure.

As this seemed to be a known problem, I added pcie_aspm=off to the kernel
command line.

The problem happens more or less randomly, the computer is usually running 24/7:

# journalctl --grep 'PCIe link lost' --quiet | cat
Sep 20 14:21:17 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Okt 06 05:44:20 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Okt 07 16:39:10 Zwerg kernel: igc :0a:00.0 (unnamed net_device) 
(uninitialized): PCIe link lost, device now detached
Okt 23 18:31:25 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Okt 30 11:16:06 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Okt 31 13:50:06 Zwerg kernel: igc :0a:00.0 (unnamed net_device) 
(uninitialized): PCIe link lost, device now detached
Nov 22 18:59:11 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Nov 23 15:45:49 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Dez 19 07:33:02 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Jan 01 09:57:40 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Jan 10 16:15:20 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Jan 13 11:16:31 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached


This is what I find in the kernel or system log:

Jan 13 11:16:31 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Jan 13 11:16:31 Zwerg kernel: [ cut here ]
Jan 13 11:16:31 Zwerg kernel: igc: Failed to read reg 0xc030!
Jan 13 11:16:31 Zwerg kernel: WARNING: CPU: 18 PID: 6389 at 
drivers/net/ethernet/intel/igc/igc_main.c:6482 igc_rd32+0x91/0xa0 [igc]
Jan 13 11:16:31 Zwerg kernel: Modules linked in: rfcomm cpufreq_userspace 
cpufreq_powersave cpufreq_ondemand cpufreq_conservative nfsv3 nfs_acl rpcs>
Jan 13 11:16:31 Zwerg kernel:  configfs efivarfs ip_tables x_tables autofs4 xfs 
libcrc32c crc32c_generic dm_crypt dm_mod hid_generic amdgpu crc32_pc>
Jan 13 11:16:31 Zwerg kernel: CPU: 18 PID: 6389 Comm: kworker/18:1 Not tainted 
6.1.0-17-amd64 #1  Debian 6.1.69-1
Jan 13 11:16:31 Zwerg kernel: Hardware name: ASUS System Product Name/ROG STRIX 
X670E-A GAMING WIFI, BIOS 1410 04/28/2023
Jan 13 11:16:31 Zwerg kernel: Workqueue: events igc_watchdog_task [igc]
Jan 13 11:16:31 Zwerg kernel: RIP: 0010:igc_rd32+0x91/0xa0 [igc]
Jan 13 11:16:31 Zwerg kernel: Code: 48 c7 c6 d0 55 56 c0 e8 0b 7d 6c f8 48 8b 
bd 28 ff ff ff e8 31 c7 23 f8 84 c0 74 b4 89 de 48 c7 c7 f8 55 56 c0 e>
Jan 13 11:16:31 Zwerg kernel: RSP: 0018:ac56d5f13df0 EFLAGS: 00010286
Jan 13 11:16:31 Zwerg kernel: RAX:  RBX: c030 RCX: 
0027
Jan 13 11:16:31 Zwerg kernel: RDX: a046f85a03a8 RSI: 0001 RDI: 
a046f85a03a0
Jan 13 11:16:31 Zwerg kernel: RBP: a03f45710c28 R08:  R09: 
ac56d5f13c68
Jan 13 11:16:31 Zwerg kernel: R10: 0003 R11: a04717f7ffe8 R12: 
a03f4571
Jan 13 11:16:31 Zwerg kernel: R13:  R14: a03f456efd40 R15: 
c030
Jan 13 11:16:31 Zwerg kernel: FS:  () 
GS:a046f858() knlGS:
Jan 13 11:16:31 Zwerg kernel: CS:  0010 DS:  ES:  CR0: 80050033
Jan 13 11:16:31 Zwerg kernel: CR2: 7f1fc894f000 CR3: 0008a8538000 CR4: 
00750ee0
Jan 13 11:16:31 Zwerg kernel: PKRU: 5554
Jan 13 11:16:31 Zwerg kernel: Call Trace:
Jan 13 11:16:31 Zwerg kernel:  


Obviously, the kernel parameter to disable PCIe power management was not 
solving this problem.

The way to recover is to restart the computer.


-- Package-specific info:
** Version:
Linux version 6.1.0-17-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-17-amd64 root=/dev/mapper/Zwerg--vg-root ro 
pcie_aspm=off quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: ASUS
product_name: System Product Name
product_version: System Version
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: 1410
board_vendor: ASUSTeK COMPUTER INC.
board_name: ROG STRIX X670E-A GAMING WIFI
board_version: Rev 1.xx

** Loaded modules:
rfcomm
cpufreq_userspace
cpufreq_powersave
cpufreq_ondemand
cpufreq_conservative
nfsv3
nfs_acl
rpcsec_gss_krb5
auth_rpcgss
nfsv4
dns_resolver
nfs
lockd
grace
fscache
netfs
qrtr
overlay
cmac
algif_hash
algif_skcipher
af_alg
bnep
sunrpc

Bug#1020460: some people ....

2023-10-23 Thread Arno Wagner

Some people have no clue what software maintenance means. 
How pathetic. This thing has not been "improved", it 
has been fundamentally broken in 2.46. 

So, just took the 2.44 soruces from bullseye, compiled 
with a simlpe "make x" and put the binary into /usr/local/bin
and archived the soruces on my side. Problem fixed. 

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform.,Email: a...@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718

A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Bug#1019559: RFS: rrep/1.3.7-1 -- recursive pattern replacement utility

2022-09-11 Thread Arno Onken

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: rrep
   Version : 1.3.7-1
   Upstream Author : Arno Onken 
 * URL : https://sourceforge.net/projects/rrep/
 * License : GFDL-1.3+, permissive, GPL-3+
 * Vcs : https://sourceforge.net/p/rrep/code/
   Section : utils

The source builds the following binary packages:

  rrep - recursive pattern replacement utility

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

  https://mentors.debian.net/package/rrep/

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

  dget -x https://mentors.debian.net/debian/pool/main/r/rrep/rrep_1.3.7-1.dsc

Changes since the last upload:

 rrep (1.3.7-1) unstable; urgency=low
 .
   * New upstream release.
   * Corrected GFDL license text.
   * Removed upstream patches now included in new release.

Regards,
-- 
  Arno Onken

Bug#1019097: RFS: rrep/1.3.6-3 -- recursive pattern replacement utility

2022-09-03 Thread Arno Onken

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: rrep
   Version : 1.3.6-3
   Upstream Author : Arno Onken 
 * URL : https://sourceforge.net/projects/rrep/
 * License : GFDL-1.3+, GPL-3+, permissive
 * Vcs : https://sourceforge.net/p/rrep/code/
   Section : utils

The source builds the following binary packages:

  rrep - recursive pattern replacement utility

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

  https://mentors.debian.net/package/rrep/

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

  dget -x https://mentors.debian.net/debian/pool/main/r/rrep/rrep_1.3.6-3.dsc

Changes since the last upload:

 rrep (1.3.6-3) unstable; urgency=low
 .
   * Fixed spelling mistake and character omission.
   * Updated debhelper-compat-version to 13.
   * Updated watch-file-standard to 4.
   * Secured copyright-format-uri.
   * Updated Standards-Version to 4.6.1.
   * Declared no need for root privileges.
   * Added upstream metadata file.
   * Introduced check for GPG signature.
   * Removed trailing whitespaces.

Regards,
-- 
  Arno Onken

Bug#1011146: Autoremoval of non related package

2022-06-24 Thread Arno van Amersfoort

Same problem with the "arno-iptables-firewall"-package: It also got 
tagged for auto removal due to this. And again: no relationship 
whatsoever

On Mon, 30 May 2022 18:38:47 +0100 Kartik Kulkarni 
 wrote:

> Hello,
> I received an email for auto removal for source-highlight which has 
nothing

> to do with nvidia-graphics-drivers. If my assumption is wrong, please let
> me know what sort of changes you would expect me to make.
> Regards,
> Kartik

Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

2022-03-18 Thread Arno Töll


clone 1006917 -1
reassign -1 libfile-keepass-perl
retitle -1 libfile-keepass-perl: crashes "not well-formed (invalid token)" when 
finding escape characters
severity -1 important
thanks

Hey,

Am 18.03.22 um 12:02 schrieb Rhonda D'Vine:

* Arno Töll  [2022-03-17 14:07:02 CET]:

Hi Rhonda,

Am 08.03.22 um 16:31 schrieb Rhonda D'Vine:

   Upstream is at 3.6 in the meantime, I'm willing to update it now that I
digged a bit further into it.  If I don't hear back in the next few days
I propose an NMU for it, as thanks for having it around in the first
place. :)

please feel free to do, and go ahead. Feel free to add yourself as a
maintainer/uploader if you wish. ;-)

  Do you have a copy of the git repository you used still around?  It
never seems to have been moved to salsa, and I for obvious reasons would
work based on what's there already. :)


Alioth's archive of the repository is at 
https://alioth-archive.debian.org/git/collab-maint/kpcli.git.tar.xz. 
That allows for bare import, including git history into salsa.


Unfortunately I don't have a lot of time for Debian these days, sorry 
about that.



The issue has been properly reassigned in the meantime. Thanks for that
Lester.

  It actually hasn't been reassigned but closed I noticed, and I'm also
not so convinced to call it only a minor issue, because as I explained,
I managed to fix it because I know my way around the code, but that's
not something to expect from regular users.  I will be looking into
filing this with the upstream tracker though.



How about duplicating the issue and reassigning one to 
libfile-keepass-perl? I'm not sure about the priority, but something 
below RC might do for that. I did so as per this mail.




--
Arno Töll

Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

2022-03-17 Thread Arno Töll


Hi Rhonda,

Am 08.03.22 um 16:31 schrieb Rhonda D'Vine:

  Upstream is at 3.6 in the meantime, I'm willing to update it now that I
digged a bit further into it.  If I don't hear back in the next few days
I propose an NMU for it, as thanks for having it around in the first
place. :)


please feel free to do, and go ahead. Feel free to add yourself as a 
maintainer/uploader if you wish. ;-)


The issue has been properly reassigned in the meantime. Thanks for that 
Lester.



--

Arno Töll

Bug#956552: arno-iptables-firewall: 90-rpc.plugin causes arno to fail to start.

2020-04-13 Thread Arno van Amersfoort

Upstream fix here: 
https://github.com/arno-iptables-firewall/aif/commit/d145f9b665ae3573055470cd45c750e63e7bebf6


On 12-04-2020 21:05, Julia Longtin wrote:

Package: arno-iptables-firewall
Version: 2.1.0-2
Severity: normal
Tags: patch upstream

Dear Maintainer,

90-rpc.plugin does not see carriage return as a line break when running rpcinfo -p |awk 
"/tcp.*$service/"' { print $4 }' |uniq

this causes arno to fail to start if you have NFS services, and have turned 
this plugin on.

--- 90rpc.plugin~   2020-01-03 10:38:03.0 +
+++ 90rpc.plugin2020-04-10 20:34:11.124131255 +0100
@@ -38,7 +38,7 @@

echo "${INDENT}Enabling RPC service(s) $RPC_SERVICES for net(s) $RPC_NETS"

-  IFS=' ,'
+  IFS=$" ,\n"
for service in $RPC_SERVICES; do
 ports="$(rpcinfo -p |awk "/tcp.*$service/"' { print $4 }' |uniq)"
 echo "${INDENT}Adding TCP ports $ports for RPC service $service"

fixes it.

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

Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages arno-iptables-firewall depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  iproute2   5.6.0-1
ii  iptables   1.8.4-3
ii  kmod   27-2
ii  procps 2:3.3.16-4

Versions of packages arno-iptables-firewall recommends:
ii  bind9-dnsutils [dnsutils]  1:9.16.1-2
ii  curl   7.68.0-1
ii  dnsutils   1:9.16.1-2
ii  rsyslog8.2002.0-2

arno-iptables-firewall suggests no packages.

-- Configuration Files:
/etc/arno-iptables-firewall/plugins/rpc.conf changed:
ENABLED=1
RPC_SERVICES="portmapper status statd nfs mountd nlockmgr"
RPC_NETS="10.0.2.0/24"

-- debconf information excluded

-- debsums errors found:
debsums: changed file /usr/share/arno-iptables-firewall/plugins/90rpc.plugin 
(from arno-iptables-firewall package)

Bug#956552: arno-iptables-firewall: 90-rpc.plugin causes arno to fail to start.

2020-04-13 Thread Arno van Amersfoort

Thanks for the report. We will fix it upstream as well. Please note that 
the patch you provided is not POSIX-compatible since $'\n' is not POSIX. 
The correct fix should be something like:

IFS=" ,
"

cheers,

Arno

On 12-04-2020 21:05, Julia Longtin wrote:

Package: arno-iptables-firewall
Version: 2.1.0-2
Severity: normal
Tags: patch upstream

Dear Maintainer,

90-rpc.plugin does not see carriage return as a line break when running rpcinfo -p |awk 
"/tcp.*$service/"' { print $4 }' |uniq

this causes arno to fail to start if you have NFS services, and have turned 
this plugin on.

--- 90rpc.plugin~   2020-01-03 10:38:03.0 +
+++ 90rpc.plugin2020-04-10 20:34:11.124131255 +0100
@@ -38,7 +38,7 @@

echo "${INDENT}Enabling RPC service(s) $RPC_SERVICES for net(s) $RPC_NETS"

-  IFS=' ,'
+  IFS=$" ,\n"
for service in $RPC_SERVICES; do
 ports="$(rpcinfo -p |awk "/tcp.*$service/"' { print $4 }' |uniq)"
 echo "${INDENT}Adding TCP ports $ports for RPC service $service"

fixes it.

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

Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages arno-iptables-firewall depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  iproute2   5.6.0-1
ii  iptables   1.8.4-3
ii  kmod   27-2
ii  procps 2:3.3.16-4

Versions of packages arno-iptables-firewall recommends:
ii  bind9-dnsutils [dnsutils]  1:9.16.1-2
ii  curl   7.68.0-1
ii  dnsutils   1:9.16.1-2
ii  rsyslog8.2002.0-2

arno-iptables-firewall suggests no packages.

-- Configuration Files:
/etc/arno-iptables-firewall/plugins/rpc.conf changed:
ENABLED=1
RPC_SERVICES="portmapper status statd nfs mountd nlockmgr"
RPC_NETS="10.0.2.0/24"

-- debconf information excluded

-- debsums errors found:
debsums: changed file /usr/share/arno-iptables-firewall/plugins/90rpc.plugin 
(from arno-iptables-firewall package)

Bug#953172: kerneloops: service http://oops.kernel.org no longer available

2020-03-05 Thread Arno Peters

Source: kerneloops
Version: 0.12+git20140509-6
Severity: normal

Dear Maintainer,

The server at http://oops.kernel.org is no longer accepting submissions.  As
far as I can see, this has been the case since 2017.  The developer mentions a
migration of code at that time in an open issue on github.  The corresponding
issue was never closed.

This package is therefore no longer relevant or useful. In my opinion, it
should be removed from the Debian repository.




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

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8), 
LANGUAGE=nl_NL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#935067: RFS: rrep/1.3.6-2 [RC] -- recursive pattern replacement utility

2019-08-18 Thread Arno Onken

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "rrep"

 * Package name: rrep
   Version : 1.3.6-2
   Upstream Author : Arno Onken 
 * URL : https://sourceforge.net/projects/rrep/
 * License : GPL-3+
 * Vcs : https://sourceforge.net/p/rrep/code/
   Section : utils

It builds those binary packages:

  rrep - recursive pattern replacement utility

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

  https://mentors.debian.net/package/rrep

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

  dget -x https://mentors.debian.net/debian/pool/main/r/rrep/rrep_1.3.6-2.dsc

Changes since the last upload:

   * Reordered LDADD libraries to make the compiler aware of the
 needed libacl references (Closes: #925819)
   * Removed obsolete man macro and fixed spelling mistake.
   * Updated Standards-Version to 4.4.0.
   * Fixed copyright format.

The changeset to upstream is very small: just three lines.  The patch for 
#925819 fixes a ftbfs by changing one Makefile.am line.  Because of #925819, 
rrep 1.3.6-1 is marked for autoremoval from testing on 2019-08-30.

Regards,

--
  Arno Onken

Bug#925819: rrep ftbfs: patch available

2019-08-18 Thread Arno Onken

Dear Matthias,

Thank you for reporting the rrep ftbfs with GCC-9.

The build failed because GCC-9 has the --as-needed flag enabled by default and 
misses libacl references present in libgnu.a.  Simply reordering the LDADD 
libraries in Makefile.am fixes this bug.

I uploaded rrep_1.3.6-2 to mentors:
https://mentors.debian.net/package/rrep
The changeset is very small and I am looking for a sponsor.

Regards,
Arno

Bug#824684: arno-iptables-firewall: Please fix the startup problem!

2018-02-18 Thread Arno van Amersfoort

This has already been fixed upstream in version 2.0.2a. Unfortunately it 
seems this package is no longer maintained on Debian. The fix is simply 
using the newer systemd service file 
(/lib/systemd/system/arno-iptables-firewall.service) that comes with 2.0.2a.


You can either manually overwrite this file it or instead of the Debian 
package use the upstream version to fix this issue.


On 17/02/18 21:07, Odd Martin Baanrud wrote:

Package: arno-iptables-firewall
Version: 2.0.1.f-1.1
Followup-For: Bug #824684

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please fix the problem which causes the script not "starting" upon system 
reboot.
And if possible, please backport it to Stretch.
One should not have to log in to the system just to "start" a script like 
'arno-iptables-firewall'.

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

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

Versions of packages arno-iptables-firewall depends on:
ii  debconf [debconf-2.0]  1.5.65
ii  gawk   1:4.1.4+dfsg-1+b1
ii  iproute2   4.14.1-2
ii  iptables   1.6.2-1

Versions of packages arno-iptables-firewall recommends:
ii  curl  7.58.0-2
ii  dnsutils  1:9.11.2.P1-1
ii  rsyslog   8.32.0-1

arno-iptables-firewall suggests no packages.

- -- Configuration Files:
/etc/arno-iptables-firewall/custom-rules changed [not included]
/etc/arno-iptables-firewall/firewall.conf changed [not included]
/etc/arno-iptables-firewall/plugins/dyndns-host-open.conf changed [not included]
/etc/arno-iptables-firewall/plugins/ssh-brute-force-protection.conf changed 
[not included]
/etc/arno-iptables-firewall/plugins/traffic-shaper.conf changed [not included]

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEnp1Ho3Mxq+xtrc2yL2O/igQUx+IFAlqIi1kACgkQL2O/igQU
x+I3iA/+JzBoGJCSEhVmSnZ63jQ9i/HuLRSA4XD/L4/oPaG9DXxHersLjg9+Bd5e
eR0NzlVyu8mqEPV5rkckUcVttRBKf5Z3LuRMdkCLGPp+CI8AODok/ot9iLKKsfBL
uSr2SnRJny80fJfDGaG3s5opbZ4De6dgYQoYJMUaZFL+sO/oNC6Wy8RtCILhLC7I
6gz3bOCDmbNaUBCoWzaNFRAaOIVwJz9OjkTz70Ed3Dlb5ntyyalOhbU8eBbllrOB
1EZnBq2LWIhtpdnDbg7fcrM/7LdbzaPuJJyyM6qmrLqqtn1NpLfcLRPoThBHXkXw
v0jUeBbUpMYJLk9XRX4OX0kjNVYSGY/8cjVbqsLE1BV0199a+zntzF3lhoTAj/eS
RPnJr006TdRKS3C/zhHi8jgv1PGEo9ntXA39nM1Asdc0sfKt7M4lNqv3UGgaWKBs
5tSSJbwwHLU8myh6kWoe8dbyy/tvRgc1mdKaYhPy0t3KZRL2/6VvqlconzS1/31n
iTwK92uxos7DtmSyIz2ikAVqilSJyVBSHtGbgaGUq+UBNVy7tcwlQEltQOH8xJGG
Yy9e6UTEsOQ03bwccDjjoHA0KJOU0CnOhaDN8R00Id9YGCYkl35IfPGHMIToVCSX
qsJ/ozNljtG+1vd/Y9e7umiCvkNT8AAuezkmUe2waIvXCsYDGXY=
=ZNSl
-END PGP SIGNATURE-

Bug#886991: New upstream version of arno-iptables-firewall

2018-01-12 Thread Arno van Amersfoort


Package: arno-iptables-firewall
Version: 2.0.1.f-1

A new upstream version (v2.0.2a) of arno-iptables-firewall is available. 
It corrects/improves a few things. Most important fix concerns boot 
start failures on some systemd-enabled systems.


I therefor strongly recommend to update Debian's version to the latest 
version. It's also strongly recommended to backport the systemd start 
file to the current stable version of Debian (9) to fix the boot start 
failures some systems are experiencing.


The new version can be found here: 
https://github.com/arno-iptables-firewall/aif/releases



cheers,

Arno

--
Arno van Amersfoort
E-mail: arn...@rocky.eld.leidenuniv.nl
Donations are welcome through Paypal!
---
Arno's (Linux IPTABLES Firewall) Homepage:
http://rocky.eld.leidenuniv.nl

Bug#876912: lirc: nodaemon option

2017-09-26 Thread Arno None

Source: lirc
Version: 0.10.0
Severity: normal

Dear Maintainer,

To start the lirc service lircd with the option 'nodaemon' in 
/etc/lirc/lirc_options.conf I had to remove the option --nodaemon from 
/etc/systemd/system/multi-user.target.wants/lircd.service
Why is this option set in a file that starts a service (daemon)?

When this option is removed the 'nodaemon' option in 
/etc/lirc/lirc_options.conf has to be set to 'True' to start lircd
Shouldn't that be 'False'?


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.1 (stretch)
Release:9.1
Codename:   stretch
Architecture: armv7l

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

Bug#876750: lirc: Configuration loglevel

2017-09-25 Thread Arno None

Source: lirc
Severity: normal

Dear Maintainer,

When trying to get lirc running with an IguanaIR transceiver I came accross the 
followig:

After I added some log messages to 
/usr/src/iguanair/software/lirc-drv-iguanair/iguanair.c I searched how to 
configure loglevel.
Loglevel is not configured with 'loglevel' in lirc_options.conf but with 
'debug'.

./lib/lirc_options.c
line 49 and 180 in raspbian source file

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.1 (stretch)
Release:9.1
Codename:   stretch
Architecture: armv7l

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

Bug#857976: ifupdown: Failure to create VLAN interface on an Infiniband-capable port running in Ethernet mode

2017-05-10 Thread Arno Töll

Hi Alex,

> I found that the VLAN interfaces specified in /etc/network/interfaces had
> not been created. This is the output when attempting to bring up a vlan
> interface manually:
> 
> $ ifup eth0.220
> /bin/sh: 1: cannot create /sys/class/net/eth0/create_child: Permission
> denied
> ifup: ignoring unknown interface eth0.220=eth0.220
> 
> The server has a Mellanox ConnectX-3 Pro card, which has two interfaces that
> are configurable to run in either Infiniband or Ethernet mode. I am running
> both ports in Ethernet mode, but ifupdown is treating the interfaces as
> Infiniband and trying to add an Infiniband partition to the interface
> instead of an Ethernet VLAN. This fails, and the expected VLAN interfaces
> are never created.
> 
> I have attached a patch which resolves the issue by only attempting to
> create Infiniband partitions when an interface has type ARPHRD_INFINIBAND,
> i.e. that is its current opera

you are right that these cards can run in either mode and that the pure 
presence of /sys/class/net//device/infiniband might not suffice to qualify 
as port in IB mode.

I cannot currently test with a card running in Ethernet mode, but I will ask 
Benjamin who eventually contributed this patch, to test your patch in our IB 
environment.

From a first glance it looks good and your check for ARPHRD_INFINIBAND sounds 
plausible. The question remains if the card port configuration is reliably 
available at early boot.


Arno Töll

Bug#838657: /usr/bin/php5: segfault in add_assoc_string_ex reading x509 certificate with composer

2016-09-23 Thread Arno Peters

Package: php5-cli
Version: 5.6.24+dfsg-0+deb8u1
Severity: normal
File: /usr/bin/php5

Dear Maintainer,

This is on Debian Jessie fully updated.

This problem surfaced in using composer after installing yesterday's security
release of OpenSSL.

  libssl1.0.0/stable,now 1.0.1t-1+deb8u4 amd64 [geïnstalleerd,automatisch]

Transcript to show the problem:

$ wget https://getcomposer.org/composer.phar
--2016-09-23 12:34:45--  https://getcomposer.org/composer.phar
[...]

$ gdb /usr/bin/php

(gdb) r composer.phar self-update
Starting program: /usr/bin/php composer.phar self-update
[...]

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: Bestand of map bestaat niet.
(gdb) where
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x006f7cc8 in add_assoc_string_ex ()
#2  0x004a1f58 in zif_openssl_x509_parse ()
[...]

TL;DR: composer is unusable at the moment.



-- Package-specific info:
 Additional PHP 5 information 

 PHP 5 SAPI (php5query -S): 
apache2
cli

 PHP 5 Extensions (php5query -M -v): 
mssql (Enabled for apache2 by maintainer script)
mssql (Enabled for cli by maintainer script)
zmq (Enabled for apache2 by maintainer script)
zmq (Enabled for cli by maintainer script)
opcache (Enabled for apache2 by maintainer script)
opcache (Enabled for cli by maintainer script)
pdo (Enabled for apache2 by maintainer script)
pdo (Enabled for cli by maintainer script)
pdo_mysql (Enabled for apache2 by maintainer script)
pdo_mysql (Enabled for cli by maintainer script)
pgsql (Enabled for apache2 by maintainer script)
pgsql (Enabled for cli by maintainer script)
curl (Enabled for apache2 by maintainer script)
curl (Enabled for cli by maintainer script)
mysqli (Enabled for apache2 by maintainer script)
mysqli (Enabled for cli by maintainer script)
imap (Enabled for apache2 by maintainer script)
imap (Enabled for cli by maintainer script)
gd (Enabled for apache2 by maintainer script)
gd (Enabled for cli by maintainer script)
readline (Enabled for apache2 by maintainer script)
readline (Enabled for cli by maintainer script)
ldap (Enabled for apache2 by maintainer script)
ldap (Enabled for cli by maintainer script)
pdo_pgsql (Enabled for apache2 by maintainer script)
pdo_pgsql (Enabled for cli by maintainer script)
pdo_dblib (Enabled for apache2 by maintainer script)
pdo_dblib (Enabled for cli by maintainer script)
mcrypt (Enabled for apache2 by maintainer script)
mcrypt (Enabled for cli by maintainer script)
mysql (Enabled for apache2 by maintainer script)
mysql (Enabled for cli by maintainer script)
json (Enabled for apache2 by maintainer script)
json (Enabled for cli by maintainer script)
mediawiki (Enabled for apache2 by local administrator)
mediawiki (Enabled for cli by local administrator)
imagick (Enabled for apache2 by maintainer script)
imagick (Enabled for cli by maintainer script)
apc-rfc1867 (Enabled for apache2 by local administrator)
apc-rfc1867 (Enabled for cli by local administrator)
apcu (Enabled for apache2 by maintainer script)
apcu (Enabled for cli by maintainer script)

 Configuration files: 
[PHP]
engine = On
short_open_tag = Off
asp_tags = Off
precision = 14
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = 17
disable_functions =
disable_classes =
zend.enable_gc = On
expose_php = On
max_execution_time = 30
max_input_time = 60
memory_limit = -1
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
track_errors = Off
html_errors = On
variables_order = "GPCS"
request_order = "GP"
register_argc_argv = Off
auto_globals_jit = On
post_max_size = 8M
auto_prepend_file =
auto_append_file =
default_mimetype = "text/html"
default_charset = "UTF-8"
doc_root =
user_dir =
enable_dl = Off
file_uploads = On
upload_max_filesize = 2M
max_file_uploads = 20
allow_url_fopen = On
allow_url_include = Off
default_socket_timeout = 60
[CLI Server]
cli_server.color = On
[Date]
[filter]
[iconv]
[intl]
[sqlite3]
[Pcre]
[Pdo]
[Pdo_mysql]
pdo_mysql.cache_size = 2000
pdo_mysql.default_socket=
[Phar]
[mail function]
SMTP = localhost
smtp_port = 25
mail.add_x_header = On
[SQL]
sql.safe_mode = Off
[ODBC]
odbc.allow_persistent = On
odbc.check_persistent = On
odbc.max_persistent = -1
odbc.max_links = -1
odbc.defaultlrl = 4096
odbc.defaultbinmode = 1
[Interbase]
ibase.allow_persistent = 1
ibase.max_persistent = -1
ibase.max_links = -1
ibase.timestampformat = "%Y-%m-%d %H:%M:%S"
ibase.dateformat = "%Y-%m-%d"
ibase.timeformat = "%H:%M:%S"
[MySQL]
mysql.allow_local_infile = On
mysql.allow_persistent = On
mysql.cache_size = 2000
mysql.max_persistent = -1
mysql.max_links = -1
mysql.default_port =
mysql.default_socket =
mysql.default_host =
mysql.default_user =

Bug#834340: O: xnbd -- Network Block Device client with support for live migration

Package: wnpp
Severity: normal

I intend to orphan the xnbd package. I no longer use it with my current
employer, and do also not have any use for it privately. Hence I intend
to orphan it. Anybody is welcome to take it over.


The package description is:
 xNBD is a NBD (Network Block Device) server program, which is fully compatible
 with the NBD client driver of Linux kernel. It adds extended features to the
 traditional NBD server:
 .
  * Better performance
  * Support for distributed copy-on-write disks
  * Live storage migration for virtual machines.
  * IPv6 support.
 .
 This is the client side of the program

Bug#834339: O: xnbd -- Network Block Device client with support for live migration

Package: wnpp
Severity: normal

I intend to orphan the xnbd package. I no longer use it with my current
employer, and do also not have any use for it privately. Hence I intend
to orphan it. Anybody is welcome to take it over.

The package description is:
 xNBD is a NBD (Network Block Device) server program, which is fully compatible
 with the NBD client driver of Linux kernel. It adds extended features to the
 traditional NBD server:
 .
  * Better performance
  * Support for distributed copy-on-write disks
  * Live storage migration for virtual machines.
  * IPv6 support.
 .
 This is the client side of the program

Bug#834337: O: xnbd -- Network Block Device client with support for live migration

Package: wnpp
Severity: normal

I intend to orphan the xnbd package. I no longer use it with my current
employer, and do also not have any use for it privately. Hence I intend
to orphan it. Anybody is welcome to take it over.


The package description is:
 xNBD is a NBD (Network Block Device) server program, which is fully compatible
 with the NBD client driver of Linux kernel. It adds extended features to the
 traditional NBD server:
 .
  * Better performance
  * Support for distributed copy-on-write disks
  * Live storage migration for virtual machines.
  * IPv6 support.
 .
 This is the client side of the program

Bug#832935: Bad patch

Hi,

On Saturday 30 July 2016 15:47:20 Lester Hightower wrote:
> Earlier today, kpcli v3.1 was released and it allows
> for Math::Random::ISAAC to be optionally used in place of the built-in
> rand() function. An objective evaluation of the ways that rand() is used in
> kpcli would likely lead one to believe this is an unnecessary change, but I
> made it none the less.

I will update kpcli in Debian to 3.1. As pointed out in your discussion 
upstream, I cannot currently enable it for Debian as Math::Random::ISAAC is 
not currently packaged. 

Having that said, I will talk to the Perl team, an if they package it, I will 
recommend the package in kpcli. This allows people to use it transparently, as 
you seem to use the module at runtime when available, and recommends are 
installed.

Is that okay with all of you? 

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D

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

Bug#730073: linux-image-3.11-2-amd64: postinst fails with no_symlinks=yes

2016-06-06 Thread Arno Schuring


Hi Ben,

> this configuration is no longer supported.

Fair enough. Thanks for considering.

Does that mean /etc/kernel-img.conf will disappear completely?


Arno

From: Ben Hutchings <b...@decadent.org.uk>
Sent: Sunday, June 5, 2016 12:18:50 AM
To: 730...@bugs.debian.org; Arno
Subject: Re: linux-image-3.11-2-amd64: postinst fails with no_symlinks=yes

On Wed, 20 Nov 2013 23:22:46 +0100 Arno <aelschur...@hotmail.com> wrote:
> Package: src:linux
> Version: 3.11.8-1
> Severity: normal
> 
> Dearest maintainer,
> 
> The latest kernel upgrade fails to complete its installation on my system. If
> I remember correctly, the previous new kernel failed to install in the same
> way but I chose to work around it instead of reporting it back then.
> 
> The symptom is a failing postinst script because initrd is missing:

I recently found this bug myself while reviewing the maintainer scripts.

> If I'm reading the postinst script correctly, this error is from either
> line 383 or line 422, which is called from image_magic() if the
> destination path is neither missing nor a symlink. This is the case on
> my system, because I have set both do_symlinks=no and no_symlinks=yes in
> /etc/kernel-img.conf (what's the difference between them?).

do_symlinks = no disables creating symlinks for the 'default' kernel and initrd.
no_symlinks = yes enables copying to the default filenames.

> For new
> kernels, the initrd has not been generated yet (that happens at the end
> of the script) and cp doesn't handle that case as gracefully as ln does.

Yes.  This regression was introduced when we moved the call to update-
initramfs into a hook script (around version 2.6.38).

> Even though the failure mode is created by no_symlinks in kernel-img.conf,
> simply changing those settings does not allow the installation to
> continue. That's because the /initrd.img file still exists, and
> image_magic() is driven by the existing paths, not the config settings.
> Conversely, simply setting no_symlinks=yes in the config does not prevent
> a new kernel to be installed initially -- but as soon as a new initrd is
> generated (and the /initrd symlink is replaced with a file), the next
> kernel installation will fail regardless of the current config setting.

I'm afraid my answer to this is that this configuration is no longer
supported.  If many people were using it, I would try to fix it, but it
seems that yours was the only bug report.  Future kernel packages will
warn and will create symlinks instead of copying.

Ben.

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

Bug#796285: apache2-module-depends-on-real-apache2-package contradicts dh_apache2

2015-08-21 Thread Arno Töll

Hi,

we agreed that we should change Lintian to accommodate these changes. The fix 
would be, to raise this Lintian error only if a package depends on apache2-bin 
but not on apache2-api-MMNN. 



-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D


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

Bug#782739: web-monitoring: SSL connection error

2015-04-17 Thread Arno Schneider

Package: zabbix-server-mysql
Version: 1:2.2.5+dfsg-1~bpo70+1
Severity: important

Dear Maintainter,

I try to monitor a SSL protected web site. The web check gives the error 
failed: SSL connection error. I think the problem is described at
https://support.zabbix.com/browse/ZBX-727 an relies to the use of the
libcurl3-gnutls instead of libcurl3-openssl.

best regards, arno

-- System Information:  Debian Release: 7.

  APT prefers proposed-updates

  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages zabbix-server-mysql depends on:
ii  adduser   3.113+nmu3
ii  fping 3.2-1
ii  libc6 2.13-38+deb7u8
ii  libcurl3-gnutls   7.26.0-1+wheezy12
ii  libiksemel3   1.2-4
ii  libldap-2.4-2 2.4.31-1+nmu2
ii  libmysqlclient18  5.5.41-0+wheezy1
ii  libodbc1  2.2.14p2-5
ii  libopenipmi0  2.0.16-1.3
ii  libsnmp15 5.4.3~dfsg-2.8+deb7u1
ii  libssh2-1 1.4.2-1.1+deb7u1
ii  libxml2   2.8.0+dfsg1-7+wheezy3
ii  lsb-base  4.1+Debian8+deb7u1
ii  ucf   3.0025+nmu3

Versions of packages zabbix-server-mysql recommends:
ii  mysql-server  5.5.41-0+wheezy1
ii  snmpd 5.4.3~dfsg-2.8+deb7u1

Versions of packages zabbix-server-mysql suggests:
ii  logrotate 3.8.1-4
ii  snmp-mibs-downloader  1.1
ii  zabbix-frontend-php   1:2.2.5+dfsg-1~bpo70+1

-- Configuration Files:
/etc/default/zabbix-server changed [not included]
/etc/init.d/zabbix-server changed [not included]

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#778895: (pre-approval) unblock: trafficserver/5.0.1-1+deb8u1

2015-03-10 Thread Arno Töll

Hi,

On Tuesday 10 March 2015 17:27:04 Arnaud Fontaine wrote:
 Ok, before  uploading and filing a  proper unblock request, I  will wait
 for the maintainer ACK until Friday if that's ok with you.

I'm fine with your NMU, but please note it's only part of the problem. We never 
bothered for the (easy) fix for #778895 because of other security problems we 
cannot easily fix in particular CVE-2014-3624 and #749846 - both fixed in Sid.

However, the Release Team was uncomfortable to unblock that package (cf. 
#769689). I'm afraid, that we better ask for removal of that package in 
Testing rather than bothering with it, as we - as maintainers - cannot 
guarantee for the security of it already, even less so over the lifespan of a 
Debian Release, and upstream is moving faster than us. 

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D


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

Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2014-11-19 Thread Arno Töll

On 19.11.2014 16:49, Andreas Beckmann wrote:
 PS: do you need the apache2.2-common transitional package? would
 upgrades work if that would not exist?

Please see https://lists.debian.org/debian-devel/2014/07/msg00450.html
for all the gory details. We added it very late in the process to work
around people's laziness :/


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2014-11-11 Thread Arno Töll

Hi,

On 10.11.2014 00:11, Andreas Beckmann wrote:
 that process would have to be distributed to two packages ...

We do right that already, the best we can. cf.:

http://anonscm.debian.org/cgit/pkg-apache/apache2.git/tree/debian/apache2.preinst
http://anonscm.debian.org/cgit/pkg-apache/apache2.git/tree/debian/apache2.postinst

We can't use dpkg-maintscript helper for the reason you named, as we
renamed the package owning it. However, I believe, we cleanly
remove/take-over the conffiles in the best way dpkg allows us.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#767287: trafficserver: ftbfs on kfreebsd

2014-10-30 Thread Arno Töll

Hi,

On 30.10.2014 00:10, Steven Chamberlain wrote:
 I guess the .install file may have some kind syntax to mark that file
 [linux-any]?

Sadly not. However, we may find another way to get it build on kfreebsd.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#766413: /lib/systemd/systemd-resolved: domain and search lines missing from resolv.conf

2014-10-24 Thread Arno Schuring

forwarded 85397 https://bugs.freedesktop.org/show_bug.cgi?id=85397
--

Hi Michael,

 Therefore, I'd kindly ask you to file a bug report upstream [1] and
 report back with the bug number.

Submitted as https://bugs.freedesktop.org/show_bug.cgi?id=85397

Regards,
Arno

  

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766413: /lib/systemd/systemd-resolved: domain and search lines missing from resolv.conf

2014-10-22 Thread Arno

Package: systemd
Version: 215-5+b1
Severity: normal
File: /lib/systemd/systemd-resolved

Dear Maintainer,

It seems systemd-resolved is not writing any domain suffixes into its
resolv.conf file:

$ cat netif/leases/4:
# This is private data. Do not parse.
ADDRESS=172.22.15.58
NETMASK=255.255.255.0
ROUTER=172.22.15.5
SERVER_ADDRESS=172.22.15.5
NEXT_SERVER=0.0.0.0
DNS=172.22.21.5 172.22.21.7
NTP=172.22.21.5 172.22.21.19
DOMAINNAME=intra.loos.site
$ cat resolve/resolv.conf
# This file is managed by systemd-resolved(8). Do not edit.
#
# Third party programs must not access this file directly, but
# only through the symlink at /etc/resolv.conf. To manage
# resolv.conf(5) in a different way, replace the symlink by a
# static file or a different symlink.

nameserver 172.22.21.5
nameserver 172.22.21.7
nameserver 172.22.21.5
# Too many DNS servers configured, the following entries may be ignored
nameserver 172.22.21.7
nameserver 2a01:4f8:161:4109::6
nameserver 2001:4ba0:cafe:383::1
nameserver 2a00:1768:1005:1000:1000:1000:e621:4948

Additionally, it seems that systemd-networkd is not writing out any SEARCH
directives either, as my dhcpd.conf contains the following:

option domain-name intra.loos.site;
option domain-search loos.site;


I would like to use networkd as it is much faster in responding to a link
change on wired interfaces, but having to write out each FQDN instead of just
the hostname is annoying, and breaks some of my scripts.

Finally, it would be nice if resolved would notice duplicate nameservers on
separate interfaces (wireless and wired in my case) and not write them out
twice.


Regards,
Arno


-- Package-specific info:

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (900, 'stable'), (300, 'unstable'), (200, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-53.4
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1
ii  libblkid1   2.20.1-5.11
ii  libc6   2.19-11
ii  libcap2 1:2.24-6
ii  libcap2-bin 1:2.24-6
ii  libcryptsetup4  2:1.6.6-2
ii  libgcrypt20 1.6.2-3
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2
ii  libpam0g1.1.8-3.1
ii  libselinux1 2.3-2
ii  libsystemd0 215-5+b1
ii  sysv-rc 2.88dsf-53.4
ii  udev215-5+b1
ii  util-linux  2.20.1-5.11

Versions of packages systemd recommends:
ii  dbus1.8.8-2
ii  libpam-systemd  215-5+b1

Versions of packages systemd suggests:
pn  systemd-ui  none

/etc/systemd/resolved.conf changed:
[Resolve]
DNS=2a01:4f8:161:4109::6 2001:4ba0:cafe:383::1 
2a00:1768:1005:1000:1000:1000:e621:4948


-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765347: Disable SSLv3 in default config

2014-10-14 Thread Arno Töll

For the records, we evaluated the market share of IE6. Several sources
indicate it's in the  0.1% range so that it sounds like a safe default
to disable SSLv3.

- http://www.w3schools.com/browsers/browsers_explorer.asp says
- https://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#762584: apache2: silently changes user configuration /etc/logrotate.d/apache2

2014-09-23 Thread Arno Töll

On 23.09.2014 15:01, Vincent Lefevre wrote:
 On 2014-09-23 14:43:49 +0200, Arno Töll wrote:
 We install this file through dh_installlogrotate and it is listed as a
 conffile in the binary package of apache2. That means, it will be
 handled like any other configuration file in Debian with special care
 and it won't overwrite changes YOU made.
 
 OK, but then, is there any reason not to announce it in the NEWS file?
 This is a significant configuration change!

This is a change like the ones which happen every day in Debian during
an update. It's not newsworthy I think.

 Unfortunately it doesn't seem to be possible to hint dpkg: according
 to the dpkg(1) man page, all the conffile related options are in the
 case If a conffile is missing or If a conffile has been modified
 (while here it exists, but was not modified because the default was
 OK).

You're looking for --force-confold. See
http://raphaelhertzog.com/2010/09/21/debian-conffile-configuration-file-managed-by-dpkg/
for all details.



-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#622647: Audio recording parameter error

2014-07-31 Thread Happy Arno

DEFAULT should be default.
Parameter DEFAULT cause error message.
Parameter default will record fine.
Please see images.

Bug#664761: apache2/conf.d migration: what should webapp packagers do?

2014-07-20 Thread Arno Töll

Hi Jonathan,

On 14.07.2014 23:12, Jonathan Nieder wrote:

https://wiki.debian.org/Apache/PackagingFor24 is helpful (thanks!),
but I'm still stuck --- I really just don't know how to package gitweb
in the new setup. See also http://bugs.debian.org/669292#28:

* It's not clear when to run apache2_invoke enconf gitweb for a
package like gitweb that does not have a Depends against apache
2.4. If I run it conditionally based on the Apache version, then
gitweb will still be broken when the user upgrades apache, unless
gitweb happens to be upgraded later in the same upgrade run.

web applications aren't supposed to depend on Apache anyway. We suggest
packagers of web applications to recommend on Apache so that other web
servers can be used, too if people wish. On that matter I do not think
gitweb would be different to other packages, or is it?

Therefore, we recommend that you check if Apache 2.4 is installed at
time you execute the maintainer scripts. There is not much you or we
could do, if it isn't. We do both agree that gitweb should rather not
depend on Apache, therefore we need conditionals in maintainer scripts.
For Apache 2.4 this works like this:

if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
. /usr/share/apache2/apache2-maintscript-helper
apache2_invoke enconf gitweb.conf || exit $?
fi

This ensures that your configuration is enabled when Apache is
installed, and it will not fail if it is not. You do not need to worry
in what context to execute this, as our apache2-maintscript-helper takes
care to figure out the right thing in the right context (e.g. postinst
configure).

* It's not clear when to run apache2_invoke disconf gitweb. At
remove and purge time doesn't seem to be enough.

Likewise as for the enable part. Just call

if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
. /usr/share/apache2/apache2-maintscript-helper
apache2_invoke disconf gitweb.conf || exit $?
fi

... and apache2-maintscript-helper tries to figure out when to do what.
In particular we disable the module in postrm purge, postrm remove and
prerm remove. When else do you think it would be necessary?

For the archives: apache2-maintscript-helper is reading the maintainer
script state out of $@ supplied to your script. If you wish to call it
from a function, you must ensure the context is preserved.

If you wish, you can set APACHE2_MAINTSCRIPT_DEBUG (e.g. in
/etc/apache2/envvars) and get debug output of the
apache2-maintscript-helper at runtime to see what it does in various use
cases.

And
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=23;filename=update-apache-packaging.patch;att=1;bug=669292:

- prerm deconfigure does not clean up as much as it should
- needs triggers to reconfigure when apache is updated?

Not sure what you ask me about here?

Basically, I am stuck on understanding the state machine:

(1) What is the intended update order between webapps, apache-common,
and apache itself? What Depends, Pre-Depends, or triggers should
be used to make sure everything works okay regardless of the
update order?

Please read
http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;h=0bbb06c48d628cd7c3b6037a0118574a722f2184;hb=HEAD#l157.
Does this answer your questions? It does not talk about triggers,
because there are none (though we planned to do at some stage) ;-)

In particular, the conditional enconf and disconf invocations
seem to make it easy to get into a non-working state and never
get out of it.

Well, we need to deal with that. This is not different than before. If
Apache2 wasn't installed, you putting a conf to conf.d is not going to
work out either. If you meant to address situations when you install
your conf to conf-available and install Apache at a later stage, it is
our business (i.e. Apache maintainer's) to ensure those get enabled
then. That's a good point actually, and I need to think if we can and
should do something in that case.

(2) What is the intended uninstallation procedure?
https://wiki.debian.org/Apache/PackagingFor24 tells me I should
enconf in postinst and disconf in postrm. That's confusing
because:

* Usually in packaging, postinst is a mirror image of prerm so
when the package is in a given dpkg state, the state of
configuration matches that. Why here is postinst's mirror
image in postrm instead?

* Dependencies are not guaranteed to be present during postrm, so
the disconf is not guaranteed to happen.

It is actually preferred that disconf is called in prerm. This is also
what dh-apache2 would do if you let it. Or in both scripts. I am not
sure why this is isn't written more explicit in the wiki but I will fix
that in a minute.

--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D

signature.asc

Bug#752922: apache2 upgrade wheezy-jessie breaks certain apache2 modules

merge 752922 711925
thanks

Hi,


This is a duplicate of #711925. I will merge the isse you reported.



-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#716880: Solutions for the Apache upgrade hell

Hello,

we've got a problem with Apache that causes problems during upgrades
(e.g. #716880, #752922, #711925). In short, the issue is that Apache 2.4
changed ABIs, so that we need to ensure that dpkg properly removes
packages linking against the obsolete ABIs at upgrade time. This is the
first time this happened since Debian Etch, so this brings a problem to
the spotlight, that hasn't been one for a long time.

To summarize the bug reports: The problem is, that Apache package
maintainers at that time decided, that third party modules shall depend
on apache2.2-common, by guaranteeing ABIs remain stable as long as the
package name does not change. This is, so far policy compliant. However,
by now ABIs did change and we were forced to rename the package (we did
so, by providing a virtual API package third parties must depend on. At
time of writing this is apache2-api-20120211). Unfortunately,
apache2.2-common also contains conffiles and configuration file handling
in postinst/postrm ...

I spent a lot of time to properly transition to a new state with
conffiles/configuration separated from ABI handling, and this works well
enough for regular updates by now.

Unfortunately it turns out, that /a lot/ of people use aptitude
--purge-unused safe-upgrade, or the apt equivalent apt-get
dist-upgrade --purge which causes dpkg to purge the user's
configuration, in particular enabled modules, during the upgrade because
apache2.2-common disappears in that step. Those people end up with
effects as described in the bugs outlined above, for example with
incomplete installations because our maintainer scripts had no chance to
properly detect the state of the /etc/apache2 directory before the upgrade.

This gives us three possibilities which all have unwanted side effects
(unless you come up with an idea that all of us makes happy). I'm
writing to this list in hope that someone has a very smart idea to make
everyone happy, or express your support for either alternative to give
us some insights what people think would be the best alternative.

* Ignore the problem, and refer to the manpage of aptitude without
proper fix etc. which clearly says THIS OPTION CAN CAUSE DATA LOSS! DO
NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING. The bad news is, we
can't tell this before it's too late, such as in a NEWS file - and we
know, everybody reads release notes too, right?

* Add a apache2.2-commmon transitional package. This gives us a chance
to inspect /etc/apache2 in spite of --purge-unused and properly
transition to Apache 2.4. HOWEVER, this has the nasty side effect that
modules ABIs are considered compatible as far as dpkg is concerned.
Therefore, old module packages aren't forced to be removed and this
breaks at runtime when people try to start their upgraded web server
with incompatible modules. As a workaround we could add a versioned
Breaks for all modules in Wheezy (~ 75) in the apache2.2-common
transitional package, and in addition for packages that existed in
Squeeze or Etch only (no, really). That said, this still won't help for
third party modules outside Debian which people might use (and to my
best knowledge, they do a lot) and it's generally problematic in view of
the policy with respect to library packaging (even though we're not a
library strictly speaking)

* Treat the upgrade as new install in our maintainer scripts when
--purge-unused was used (side question: Any idea how to reliably and
properly detect that case, as the binary package name changed and it's
well possible that in Wheezy apache2.2-common is installed, but not
apache2 because of weird(tm) packaging)? This would not preserve user's
choices in regard of enabled/disabled modules and thus be a borderline
policy violation, too.


What would you do in our situation? Side note 2: We kinda expected this
situation and added a trapdoor in Wheezy [1], but it turned out, that
even that is not good enough to prevent havoc with --purge-unused.


[1]
http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/apache2.2-common.postrm;h=bbe9f740b81cf8af64412f7ba6aace119dd159ad;hb=refs/heads/wheezy#l5



-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#491547: web server policy requires /var/www, not in FHS

Hi Bill,

On 01.05.2014 22:52, Bill Allombert wrote:
 [[ I think it is possible to use subdirectories of /srv as long as we prompt
 the user for the directory structure to use, but that seems totally
 unpractical for tthe purpose of the Document Root.
 ]]

... and not good enough. For some use cases, e.g. Apache, we need to
know the Document Root at build time. Apache does statically compile the
path in for apache2-suexec for example. Other web servers might do
something similar (or not).

 I have made a first minimal draft.
 Please comment.
 
 diff --git a/policy.sgml b/policy.sgml
 index bf959f1..5661f4b 100644
 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -7043,6 +7043,11 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
   /p
 /item
 item
 +p
 +  The file/var/www/file directory is additionally 
 allowed. 
 +/p
 +   /item
 +   item
   p
 On GNU/Hurd systems, the following additional
 directories are allowed in the root
 @@ -9752,7 +9757,7 @@ http://localhost/cgi-bin/.../varcgi-bin-name/var
   packagedoc-base/package package.  If access to the
   web document root is unavoidable then use
   example compact=compact
 -/var/www
 +/var/www/html
   /example
   as the Document Root.  This might be just a symbolic
   link to the location where the system administrator

Fine with me, thanks.

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#711755: don't attempt to reload apache2 if it wasn't running before we started the upgrade

reassign 711755 debhelper
affects 711755 src:apache2
thanks

Hi,

On 09.06.2013 14:33, jida...@jidanni.org wrote:
 I'm telling you guys, not everybody runs apache2 24/7/365 days a year,
 so please double check if it was running first (before the upgrade
 started) before causing these error messages during upgrades!

technically, we do not but debhelper does.

We call dh_installinit as:

override_dh_installinit:
dh_installinit --restart-after-upgrade --error-handler=true --
defaults 91 09


which is expanded to:


# Automatically added by dh_installinit
if [ -x /etc/init.d/apache2 ]; then
update-rc.d apache2 defaults 91 09 /dev/null
if [ -n $2 ]; then
_dh_action=restart
else
_dh_action=start
fi
invoke-rc.d apache2 $_dh_action || true
fi
# End automatically added section


in postinst.

I think, debhelper should check through invoke-rc.d status - when
available - before (re-)starting a daemon unconditionally.

This is arguably a behavior which should be addressed on a higher level
for all packages that handle init scripts through dh_installinit. If
debhelper maintainers disagree, please assign back and we may workaround
that particular behavior for our package only, even though that sounds
wrong to me.



-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#743483: apache2-mpm-itk: AssignUserID is ignored in favor of file ownership.

reassign mpm-itk
thanks

Steinar,

On 05.04.2014 17:01, Steinar H. Gunderson wrote:
 This is almost certainly a configuration issue. It sounds like he is hitting
 suexec or suphp.

I'm handing this over to you now that itk is its own package.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#736809: apache2-bin needs proper Breaks: for Apache 2.4 transition

On 26.01.2014 22:30, Adrian Bunk wrote:
 Package: apache2-bin
 Version: 2.4.6-3
 Severity: serious
 
 First, I was surprised to see the many open and non-RC bugs in [1],
 shouldn't packages that e.g. use /etc/apache2/conf.d/ have an RC bug
 since they'll definitely have to get fixed for jessie?

Yes. However, the problem is, that a lot of web apps  are not all
technically release critical broken. We need to look at all of them on a
case by case basis and decide what exactly they do (or don't do). This
is on my to do, but if someone beats me on it, I won't complain. :-)


 Second, for supporting all possible upgrade and partial upgrade
 scenarios (not only between wheezy and jessie, Debian-derived
 distributions like Ubuntu might have different collections of
 packages), apache2-bin needs to have a versioned Breaks: against
 the broken versions of all of the packages in [1] and [2].

Why? Packages in [2] aren't supposed to depend on apache2.2-bin (with
some few exceptions, against which ones we /do/ have Breaks in place).
Module packages depend on apache2.2-common, where we do force removal
upon upgrade, so that in turn, obsolete dependencies without proper
replacement are removed, too.

For web apps, it's merely a definition of Breaks, a lot of web apps
continue to work just fine, just the automated integration into Apache
does not work anymore, or the example configuration needs a few fixes,
whereas the package itself just works fine. Not that they would depend
on apache2.2-bin.

 (Are there more such usertags?)

No, there are not.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#745605: apache2: ignores AddDefaultCharset

Hi,

On 16.06.2014 22:59, Arnaud de Prelle wrote:
 It seems Apache 2.4.9-2 misuses the AddDefaultCharset statement.
 By default it should be Off but the current 2.4.9-2 simply overrides the 
 value of the parameters and sets it to UTF-8.

are you sure, this isn't overridden by PHP as in Carlos' case? Apache
defaults to

#define DEFAULT_ADD_DEFAULT_CHARSET_NAME iso-8859-1


else if (!strcasecmp(arg, On)) {
   d-add_default_charset = ADD_DEFAULT_CHARSET_ON;
   d-add_default_charset_name = DEFAULT_ADD_DEFAULT_CHARSET_NAME;


when set to on, and this code hasn't changed a long time.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#754135: trafficserver: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4

Hi Breno,

thanks for your patch, but unfortunately you submitted it after I
uploaded ATS 5.0 already. That being said, by pure coincidence, I
enabled autoreconf for that upload already.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#754527: dput-ng: Please update for Ubuntu upload changes (for derived distros)

Hi Scott,

On 12.07.2014 07:45, Scott Kitterman wrote:
 Please see the attached patch.  It would be nice to get this into Debian for
 people that work on Ubuntu from Debian systems.

when we started dput-ng, we said we're hosted on collab-maint and we
mean it: Therefore, feel free to push that patch yourself to our git
head. I'm sure, you have commit access there.

Just one question: Is this the only method allowed anymore on Launchpad?
I mean, do we need to keep legacy compatibility? If we do not, your
patch is very fine.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#754134: trafficserver: add support for ppc64el

Hi Breno,

On 07.07.2014 22:50, Breno Leitao wrote:
 I would like to have this patch included in order to add support for ppc64el 
 in
 the trafficserver package. Currently it fails with this build log.
 
 http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/trafficserver_5.0.0-1_ppc64el.build

as mentioned in the other bug you filed: You submitted your patch after
I uploaded ATS 5.0 already. Could you please test your patch for the
current version? I'm not really sure how I would test ppc64el builds.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#754134: trafficserver: add support for ppc64el

One more thing I forgot: The build log you linked is for 5.0, the patch
for 4.1.2 and so seems your bug report. Could you please enlighten me?
Did you patch and test 4.1.2 or 5.0?

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#745695: Can't launch SFLphone after update.

2014-07-09 Thread Happy Arno

SFLphone worked fine before system updated.
There is no icon. (icon has disappeared after system updated)

$ uname -a
Linux O 3.14-1-amd64 #1 SMP Debian 3.14.9-1 (2014-06-30) x86_64 GNU/Linux
 

$ dpkg -l | grep  sflphone
ii  sflphone-daemon  1.3.0-1+b2    amd64    SIP and IAX2 compatible VoIP 
phone - core daemon
ii  sflphone-data    1.3.0-1   all  SIP and IAX2 compatible VoIP 
phone - common data
ii  sflphone-gnome   1.3.0-1+b2    amd64    SIP and IAX2 compatible VoIP 
phone - GNOME client
 


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745695: Solution from Ubuntu for SFLphone

2014-07-09 Thread Happy Arno

Ubuntu has fixed.
I am waiting Debian.
https://bugs.launchpad.net/ubuntu/+source/sflphone/+bug/1299967


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745695: Solution from Ubuntu for SFLphone with code

2014-07-09 Thread Happy Arno

Ubuntu has fixed.
I am waiting Debian.
https://bugs.launchpad.net/ubuntu/+source/sflphone/+bug/1299967

old code
flags, G_APPLICATION_HANDLES_COMMAND_LINE | G_APPLICATION_IS_SERVICE, NULL);

new code
flags, G_APPLICATION_HANDLES_COMMAND_LINE, NULL);

https://projects.savoirfairelinux.com/projects/sflphone/repository/revisions/390d5826f2f0db8bf7634f773ca36fb622009a06/diff/gnome/src/sflphone_client.c

Wish this works.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753851: apache2: [core:notice] [pid 22446] AH00052: child pid 22554 exit signal Segmentation fault (11)

2014-07-06 Thread Arno Töll

reassign 753851 libapache2-mod-php5
thanks


Hi Rainer,


yes - this is indeed an issue in PHP. gc_remove_zval_from_buffer sounds
like PHP tries to access a freed value. I'm reassigning to PHP, maybe
they can tell you more about.

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#749846: trafficserver: Insecure command execution and use of temporary filenames.

2014-06-02 Thread Arno Töll

Hi Steve,

On 30.05.2014 09:59, Steve Kemp wrote:
 Please do request/assign CVE identifiers.


Thanks for your report, I will coordinate this with Apache folks to get
a CVE upstream as this is not Debian specific.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#749846: trafficserver: Insecure command execution and use of temporary filenames.

2014-06-02 Thread Arno Töll

On 02.06.2014 11:29, Steve Kemp wrote:
 [ Hoping this whole file isn't needed, and can simply go away :) ]


Actually, it is. The shadow part is most likely a left-over from dead
code before ATS was open-sourced. Either way, the entire command line
utility (traffic-shell) is being dropped upstream altogether.



-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#745707: xpra: raising a window with H.264 encoding causes xpra to crash and remain stale

2014-04-25 Thread Arno Töll

On 25.04.2014 04:06, Dmitry Smirnov wrote:
 On Thu, 24 Apr 2014 10:46:23 Arno Töll wrote:
 Versions of packages xpra depends on:
 ii  libavutil52   10:2.1.3-dmo1
 ii  libswscale2   10:2.1.3-dmo1
 
 I'm pretty sure the above libraries are responsible for troubles.

*le sigh*


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#745707: xpra: raising a window with H.264 encoding causes xpra to crash and remain stale

2014-04-25 Thread Arno Töll

On 25.04.2014 09:46, Arno Töll wrote:
 On 25.04.2014 04:06, Dmitry Smirnov wrote:
 On Thu, 24 Apr 2014 10:46:23 Arno Töll wrote:
 Versions of packages xpra depends on:
 ii  libavutil52   10:2.1.3-dmo1
 ii  libswscale2   10:2.1.3-dmo1

 I'm pretty sure the above libraries are responsible for troubles.
 
 *le sigh*

Err, wait: Yes, I'm using DMO on the client side. However, what's
crashing is the server if the client wishes H.264 encoding?


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#745707: xpra: raising a window with H.264 encoding causes xpra to crash and remain stale

2014-04-24 Thread Arno Töll

Package: xpra
Version: 0.12.3+dfsg-1
Severity: important

The current version of xpra looks rather broken to me. Trying to raise a window
yields to an unrecoverable error. Symptoms are that the first window is 
displayed,
causing xpra to crash, and further windows remain black when they exist already,
or aren't displayed anymore at all, when they do not exist yet. The server 
remains
stale, accepts connections but no windows are shown. 

To reproduce, do on the server side (connect a client after the start):

$ xpra start :1
$ DISPLAY=:1 xmessage 'foo'  // works, but causes the crash
Warning: Cannot convert string vlines2 to type Pixmap
$ DISPLAY=:1 xmessage 'foo' // never shown

from the log:

2014-04-24 10:36:11,636 Handshake complete; enabling connection
2014-04-24 10:36:11,641 Python/Gtk2 Linux client version 0.12.3 connected from 
'snowball' as 'arno' ('arno')
2014-04-24 10:36:11,642 client supplied an mmap_file: /tmp/xpra.16EDpx.mmap but 
we cannot find it
2014-04-24 10:36:11,643 using h264 as primary encoding, also available: vp8, 
rgb24, rgb32
2014-04-24 10:36:11,643 client root window size is 1600x900 with 1 displays:
2014-04-24 10:36:11,643   ':0.0' (423x238 mm) workarea: 1600x850
2014-04-24 10:36:11,643 LVDS1 (310x174 mm)
2014-04-24 10:36:11,645 server virtual display now set to 1600x900
2014-04-24 10:36:11,646 setting key repeat rate from client: 300ms delay / 20ms 
interval
2014-04-24 10:36:11,647 setting keymap: rules=evdev, model=thinkpad60, 
layout=de,us
The XKEYBOARD keymap compiler (xkbcomp) reports:
 Warning:  Type ONE_LEVEL has 1 levels, but RALT has 2 symbols
   Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server
2014-04-24 10:36:11,669 setting full keymap definition from client via xkbcomp
[swscaler @ 0x7f141c005380] 0x54 - 0x54 is invalid scaling dimension
2014-04-24 10:36:16,431 setup_pipeline failed for (44, codec_spec(swscale), 
'RGB', codec_spec(x264))
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/xpra/server/window_video_source.py, 
line 1051, in setup_pipeline
enc_width, enc_height, enc_in_format, csc_speed)
  File colorspace_converter.pyx, line 316, in 
xpra.codecs.csc_swscale.colorspace_converter.ColorspaceConverter.init_context 
(xpra/codecs/csc_swscale/colorspace_converter.c:4321)
AssertionError: sws_getContext returned NULL


The problem seems to be specific to the H.264 codec (which is the default). 
Starting the client with

$ xpra attach --encoding=vp8 ...

seems to workaround the problem, however. That being said using VP8 fills the 
log
with:

2014-04-24 10:42:51,594 error processing damage data: BUG: no encoder not found 
for rgb
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/xpra/server/source.py, line 1578, in 
data_to_packet
encode_and_queue()
  File /usr/lib/python2.7/dist-packages/xpra/server/window_source.py, line 
890, in make_data_packet_cb
packet = self.make_data_packet(*data)
  File /usr/lib/python2.7/dist-packages/xpra/server/window_source.py, line 
1109, in make_data_packet
raise Exception(BUG: no encoder not found for %s % coding)
Exception: BUG: no encoder not found for rgb

... though that seems harmless.


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

Kernel: Linux 3.13-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

Versions of packages xpra depends on:
ii  libavcodec54  6:9.11-3+b2
ii  libavutil52   10:2.1.3-dmo1
ii  libc6 2.18-4
ii  libgtk2.0-0   2.24.23-1
ii  libswscale2   10:2.1.3-dmo1
ii  libvpx1   1.3.0-2
ii  libx11-6  2:1.6.2-1
ii  libx264-142   2:0.142.2389+git956c8d8-4
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-1
ii  libxext6  2:1.3.2-1
ii  libxfixes31:5.0.1-1
ii  libxrandr22:1.4.2-1
ii  libxtst6  2:1.2.2-1
ii  python2.7.5-5
ii  python-gtk2   2.24.0-3+b1
ii  x11-xserver-utils 7.7+2
ii  xserver-xorg-input-void   1:1.4.0-1+b3
ii  xserver-xorg-video-dummy  1:0.3.7-1+b2

Versions of packages xpra recommends:
ii  openssh-client1:6.6p1-3
ii  python-avahi  0.6.31-4
ii  python-gtkglext1  1.1.0-9.1
ii  python-imaging2.3.0-2
ii  python-netifaces  0.8-3+b1
ii  python-webm   0.2.2-3
ii  ssh-askpass   1:1.2.4.1-9

Versions of packages xpra suggests:
ii  gstreamer0.10-plugins-bad   0.10.23-7.2
ii  gstreamer0.10-plugins-good  0.10.31-3+nmu2
ii  openssh-server  1:6.6p1-3
pn  pulseaudio  none
pn  pulseaudio-utilsnone
ii  python-dbus 1.2.0-2+b2
pn  python-gst0.10  none
pn  python-pyopencl none

Bug#741236: lightdm-gtk-greeter: bt with debug symbols

2014-04-08 Thread Arno

Package: lightdm-gtk-greeter
Version: 1.8.3-1
Followup-For: Bug #741236

I thought I'd add one more information point to this bug, i.e. a full
backtrace with debug symbols. I can confirm that sending USR1 to the hanging
gtk-greeter (pid 2922 from the backtrace below) causes lightdm to continue
the login process and allows the session manager to start.

I'm also attaching the lightdm logs, as they look interesting to me. The
greeter.log shows gtk-critical errors for pid 2922, and lightdm.log shows
PAM authentication errors at +111, although I don't remember mistyping my
password (faulty soft-memory perhaps). At +1061 is where I sent the USR1
signal to gtk-greeter.

Just in case it's relevant: no systemd on this box, also no libpam-systemd.
There is -login0 and -journal0, just because they make dbus happy.

Full backtrace follows.
Regards,
Arno


Script started on Tue 08 Apr 2014 19:09:24 CEST
GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/sbin/lightdm-gtk-greeter...(no debugging symbols 
found)...done.
Attaching to program: /usr/sbin/lightdm-gtk-greeter, process 2922

[.. snip missing .dbg files ..]

warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x7fff6819a000
__lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
135 ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or 
directory.
(gdb) thr ap a bt

Thread 3 (Thread 0x7fbd91de7700 (LWP 2940)):
#0  0x7fbda5cdc72d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7fbda675e814 in g_main_context_poll (priority=2147483647, n_fds=3, 
fds=0x7fbd8c0010c0, timeout=-1, context=0x7fbda95c2dd0)
at /tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:4007
#2  g_main_context_iterate (context=0x7fbda95c2dd0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=optimized out)
at /tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:3708
#3  0x7fbda675eb3a in g_main_loop_run (loop=0x7fbda95c2cf0) at 
/tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:3907
#4  0x7fbda3d9dad6 in gdbus_shared_thread_func (user_data=0x7fbda95c2da0) 
at /tmp/buildd/glib2.0-2.38.2/./gio/gdbusprivate.c:278
#5  0x7fbda6783095 in g_thread_proxy (data=0x7fbda8ac0190) at 
/tmp/buildd/glib2.0-2.38.2/./glib/gthread.c:798
#6  0x7fbda5fb3062 in start_thread (arg=0x7fbd91de7700) at 
pthread_create.c:312
#7  0x7fbda5ce7a3d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7fbd90b86700 (LWP 2941)):
#0  0x7fbda5cdc72d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7fbda675e814 in g_main_context_poll (priority=2147483647, n_fds=2, 
fds=0x7fbd840008c0, timeout=-1, context=0x7fbda95c2270)
at /tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:4007
#2  g_main_context_iterate (context=context@entry=0x7fbda95c2270, 
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out)
at /tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:3708
#3  0x7fbda675e91c in g_main_context_iteration (context=0x7fbda95c2270, 
may_block=may_block@entry=1) at /tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:3774
#4  0x7fbda675e959 in glib_worker_main (data=optimized out) at 
/tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:5486
#5  0x7fbda6783095 in g_thread_proxy (data=0x7fbda94ebed0) at 
/tmp/buildd/glib2.0-2.38.2/./glib/gthread.c:798
#6  0x7fbda5fb3062 in start_thread (arg=0x7fbd90b86700) at 
pthread_create.c:312
#7  0x7fbda5ce7a3d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7fbda7d47980 (LWP 2922)):
#0  __lll_lock_wait () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x7fbda5fb549d in _L_lock_1086 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7fbda5fb5417 in __GI___pthread_mutex_lock (mutex=0x7fbda8ad65d0) at 
../nptl/pthread_mutex_lock.c:134
#3  0x7fbda679e321 in g_mutex_lock (mutex=optimized out) at 
/tmp/buildd/glib2.0-2.38.2/./glib/gthread-posix.c:213
#4  0x7fbda675ec2b in g_main_loop_quit (loop=0x7fbda95a0340) at 
/tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:3932
#5  signal handler called
#6  0x7fbda675e6a3 in g_main_dispatch (context=0x7fbda8ad6510) at 
/tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:3082
#7  g_main_context_dispatch (context=context@entry=0x7fbda8ad6510) at 
/tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:3642
#8  0x7fbda675e878 in g_main_context_iterate (context=0x7fbda8ad6510, 
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out)
at /tmp/buildd/glib2.0-2.38.2/./glib/gmain.c:3713
#9  0x7fbda675eb3a in g_main_loop_run (loop

Bug#743977: drbd8: Xen resource script fails when using the xl stack

2014-04-08 Thread Arno Töll

Source: drbd8
Severity: important

The DRBD resource script for Xen (/etc/xen/scripts/block-drbd) does not work 
when
using the xl toolstack anymore, which is exclusively available in xen 4.2 and
later (i.e. the current Testing).

First of all, it needs the patch mentioned in [1] for basic support. However, 
when
using it in conjunction with pygrub, it fails to find its boot device, whereas
this worked fine earlier.


Consider this configuration domu.cfg:

bootloader = '/usr/lib/xen-4.3/bin/pygrub'
disk= [
  'drbd:web1,xvda1,w',
  ]

it fails with:

xl create -c /etc/xen/auto/matrix-web1.cfg 
Parsing config from /etc/xen/auto/matrix-web1.cfg
libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader failed - 
consult logfile /var/log/xen/bootloader.22.log
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: bootloader 
[20386] exited with error status 1
libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot (re-)build 
domain: -3
libxl: error: libxl_dom.c:35:libxl__domain_type: unable to get domain type for 
domid=22
Unable to attach console
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] 
exited with error status 1


# cat /var/log/xen/bootloader.22.log
Traceback (most recent call last):
  File /usr/lib/xen-4.3/bin/pygrub, line 799, in module
part_offs = get_partition_offsets(file)
  File /usr/lib/xen-4.3/bin/pygrub, line 106, in get_partition_offsets
image_type = identify_disk_image(file)
  File /usr/lib/xen-4.3/bin/pygrub, line 48, in identify_disk_image
fd = os.open(file, os.O_RDONLY)
OSError: [Errno 2] No such file or directory: 'web1'

However, with the configuration:

kernel = /boot/vmlinuz-3.2.0-4-amd64
ramdisk = /boot/initrd.img-3.2.0-4-amd64
disk= [
  'drbd:web1,xvda1,w',
  ]


it works fine. I guess the resource script needs a few more tweaks to work with 
pygrub.



[1] http://lists.linbit.com/pipermail/drbd-user/2014-April/thread.html


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

Kernel: Linux 3.9-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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743483: apache2-mpm-itk: AssignUserID is ignored in favor of file ownership.

Steinar,

could you please comment on that? I have no experience with itk
whatsoever. Therefore, I do not how if this is a problem in itk or a
configuration issue.

Moreover, please reasign this bug to the itk source package, if this is
a still persisting problem.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#731074: [pkg-lighttpd] Bug#731074: Bug#731074: lighttpd: indeterminate test on kfreebsd buildds

Hi,

On 02.04.2014 02:13, Michael Gilbert wrote:
 Didn't get a message that I was accepted ;)  Will do.

That's a feature of FusionForge. While you're at it, please do also
include the security NMUs you did in Stable. Thanks!

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#743584: trafficserver 4.1.2-1.1 FTBFS on kfreebsd-*

On 05.04.2014 04:06, Aníbal Monsalve Salazar wrote:
 Please let trafficserver 4.1.2-1.2 migrate to testing. It's the result
 of the efforts of Petr, Dejan, myself and some other people who looked
 into the bugs fixed by the NMUs.

Sure thing. The MIPS patch is supposed to be included in ATS 5.0, but
the kfreebsd patch is probably a Debian specific issue. That being said,
I can also commit it upstream if you'd like.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#743338: [pkg-lighttpd] Bug#743338: lighttpd: Broken migration to /var/www/html

Hi,

On 01.04.2014 23:24, Nelson A. de Oliveira wrote:
 I see two problems here: it broke my server without any message (there
 isn't a message in NEWS, for example) and the placeholder page gives a
 wrong path too:

Good idea. I'll add a NEWS file warning users about this and fix the
documentation bug.

 I am also thinking if it should automatically change/update my
 /etc/lighttpd/lighttpd.conf file to include the new path (like happened)
 or if it should only use /var/www/html on new installs.


As you should be aware as a DD, I am not allowed to touch conffiles. It
will be updated accordingly if you did not modify the default
configuration but apart there is not much I can do. I am not sure how
the upgrade broke anything for you though. Apparently you had modified
the lighttpd.conf so that it wasn't upgraded. Thus, it further continues
to use whatever doc root you configured, and our default doc root
contains nothing but the sample index.html file you're supposed to
replace if you really want to use the default. Would you mind telling me
more about your setup?


Please note, that the default document root is not really meant to be
used by end users anyway. It's rather supposed to be the host of last
resort when no other (virtual) host matches.

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#743635: openvswitch: OVS should probably start before networking

2014-04-04 Thread Arno Töll

Source: openvswitch
Severity: important

OVS is a software switch, and as such providing primarily L2 features. Therefore
it's unfortunate that it starts after networking (i.e. ifupdown) that may be 
used
to configure bridge ports provided by OVS.

Consider this configuration:

ovs-vsctl add-br br0
ovs-vsctl add-bond br0 bond0 eth0 eth1 lacp=active

/etc/network/interfaces

auto br0
iface br0 inet static
address 10.10.100.84
netmask 255.255.255.128
network 10.10.100.0
broadcast 10.10.100.127
gateway 10.10.100.1

auto eth0
auto eth0 inet manual

auto eth1
auto eth1 inet manual


In such a setup there is no way where you ever could end up with a networking
setup that ends in remote reachable machine and is thus locking you out. This is
because ifupdown starts before openvswitch-{switch, controller}. Thus, ifupdown
does not find that interface as it isn't provided at this stage during the boot.

A possible fix would be to let openvswitch-{switch, controller} start before the
network. For example these LSB headers would do the job:

# X-Start-Before:networking
# Required-Start:$local_fs
# Required-Stop: 
# Default-Start: S
# Default-Stop:  0 6

Arguably this is a cyclic dependency as - depending on the configuration - OVS 
may
indeed rely on a working network to connect to a remote controller. In such 
setups
it is probably advised to keep things as is, although OVS may still come up and
fail to connect to the controller which isn't that bad as it keeps reconnecting 
I
guess. That being said I believe that my use case is more common for OVS and
should thus be fixed.

Alternatively OVS should provide a way to configure it's own L3 stuff itself so 
that
such cyclic dependencies could be avoided. For example, the whole problem could 
be
avoided if the IP configuration was stored in the OVS database.

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

Kernel: Linux 3.9-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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743584: trafficserver 4.1.2-1.1 FTBFS on kfreebsd-*

2014-04-03 Thread Arno Töll

Hi

On 04.04.2014 00:05, Aníbal Monsalve Salazar wrote:

 As you could guess we don't have a Debian kfreebsd machine to test
 patches.  Dejan and I are following up the NMU of trafficserver
 4.1.2-1.1 to fix bugs on mips/mipsel and we noticed it FTBFS on
 kfreebsd-*.
 

while I do not mind if you go ahead, I did not look into these build
issues as trafficserver 4.2 is to be released any day ahead and I wanted
to work on the package with the new upstream base.

That being said it's probably too late to merge your porting patches
upstream for 4.2 anyway, so it may not make a difference anyway.

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#743282: ITP: apt-get-snapshot -- Download a specific package version from snapshot.debian.org

2014-04-01 Thread Arno Töll

Hi,

On 01.04.2014 12:38, Mike Gabriel wrote:
  When using debian testing, it is not trivial to get the previous version of a
  package after it is upgraded.  [..]

debsnap (in devscripts) is your friend.



-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#731074: [pkg-lighttpd] Bug#731074: lighttpd: indeterminate test on kfreebsd buildds

2014-03-31 Thread Arno Töll

Hi Michael,

On 30.03.2014 23:42, Michael Gilbert wrote:
 I've uploaded this fix to delayed/10 since the build failure is
 blocking lighttpd from testing. Please see attached patch.

since you joined the lighttpd packaging team: Please commit your changes
to the VCS and stop doing NMUs, and just do regular maintainer uploads ;)


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#743225: RM: trafficserver [armel] -- NVIU; ARM out of date; FTBS for newer versions

2014-03-31 Thread Arno Töll

Package: ftp.debian.org
Severity: normal

Testing currently has an older version of trafficserver in Testing that blocks
migration of the trafficserver package. The package fails to build from source 
on
armel for pretty obsucre reasons so I'd prefer if it was removed for now.

Thanks!

Note: this was a request for a partial removal from testing, converted in one 
for unstable


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#491547: web server policy requires /var/www, not in FHS

2014-03-23 Thread Arno Töll

Hi,

On 22.03.2014 18:50, Bill Allombert wrote:
 Are the other HTTP engines going to also change the default document root to
 /var/www/html ?

Yes. I tried to seek consensus with maintainers of other web servers in
Debian, and I filed a mass bug to track the state of the adoption [1].

 But practically what are you sugesting ?
 Add a FHS exception for /var/www/html and change the document root in
 policy ?

Yes - either this (where the name html is an implementation detail.
With the reasoning being, that any sub directory of /var/www is needed
and html is what other distros, e.g. Red Hat use), or allow us to
use/assume a directory structure in /srv which may have a larger impact
on the FHS than /var/www.


[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-doc-root;users=debian-apa...@lists.debian.org;archive=both


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#731074: lighttpd: indeterminate test on kfreebsd buildds

2014-03-22 Thread Arno Töll

severity 731074 important
thanks

I will downgrade this bug to important for now, as long at is uncertain
if this is a bug in lighttpd or kfreebsd's libc. Either way we need to
have a newer lighttpd in Testing. If you feel like, feel free to upgrade
the severity again, once 1.4.35 hits Testing.



-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#741097: [Pkg-octave-devel] Bug#741097: octave: nox package of Octave

2014-03-22 Thread Arno Onken

On 18.03.2014 07:07, Thomas Weber wrote:
 I think you should bring up that topic on upstream's maintainer list.[1] I
 don't think we have that many machines which are constrained by the
 additional disk space, so if we as Debian maintainers complain, it is
 just not the same as a user who really has the hardware (perceived
 issue vs. real problem).

Why is this relevant for upstream at this point? I searched in the
upstream maintainers archives but I couldn't find any proposal to
abandon support for command line only compilation or compilation without
Java or LLVM altogether. I was therefore assuming that this is a
packaging and compile options only issue.

 BTW, can you give an example of one of your low ressource machines?

I was mostly referring to my SheevaPlug, FritzBox and Android device
with a Debian chroot. But then there is also my Neo Freerunner GTA02 and
Rasberry Pi. Granted, I could extend disk space for some of these
devices but that can be a pain. The GTA02, for instance, is extremely
picky about supported SD cards.

Even without any graphical feedback, I find Octave very useful in batch
mode and for extended calculator-like operation on the move. Again,
please keep in mind that this is a whishlist bug report. I would
certainly have use for a limited resource package, but maybe that's just me.

Thanks,
Arno


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741904: dma uses debconf as a registry

2014-03-22 Thread Arno Töll

tags 741904 +pending
thanks

Hi Stuart,

On 17.03.2014 06:10, Stuart Prescott wrote:
 but really, the .config file should be reading this value from dma.conf
 prior to asking the user for the new value. The value in the config file
 must override whatever happens to be in the debconf db when the user runs
 dpkg-reconfigure dma; the use of db_input without a db_set to read in the
 current setting beforehand is incorrect.

I've commited 8f12e2a36a989f0985c4b1769433f91e3cc1896d to HEAD which
should basically be doing what you suggest. Feel free to test the
changes in git.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#741097: octave: nox package of Octave

2014-03-08 Thread Arno Onken

Package: octave
Version: 3.8.0-5
Severity: wishlist

Dear Maintainer,

Starting with version 3.8, the octave package contains a GUI based on
the Qt toolkit. An `octave-cli' executable which is not linked against
Qt is provided in the package, but there is no octave package that does
not depend on Qt. Packages like emacs and gnuplot have nox alternatives.
A similar octave package would be a great asset.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741097: octave: nox package of Octave

2014-03-08 Thread Arno Onken

Thanks for your quick response.

On 08.03.2014 16:00, Mike Miller wrote:
 Can you explain specifically what you think the advantages of having a
 nox version of octave would be? I'm not refuting your request, just
 that you haven't specifically said what the problem with the current
 approach is and what specific benefits would derive from having a nox
 package, just that these others are doing it.

I have Octave running on a couple of low resource devices which don't
even have X. On these systems, unnecessary dependencies are a waste of
precious space.

 We considered this when starting work on packaging octave 3.8, please
 take a look at the discussions (thread starting at [1]) we had where we
 did look at a few different aspects and decided to keep everything in
 one package for now.

I wasn't aware of this discussion. Your comparison of required disk
space was very informative. Indeed, the Qt dependency doesn't make a big
difference when compared to the additional Java and LLVM dependencies.
But the minimum installation size more than doubles from 3.6.4 to 3.8.0.
So I think a low resources package with more dependencies striped off
would actually be very useful.

 Also keep in mind that 3.8 is a transitional period for the octave
 command-line and GUI modes, upstream may yet make changes about how
 octave is run in one mode or the other. For all we know, there may not
 be a separate octave-cli executable in the 4.0 version. I'm not saying
 this is likely or that I'm in favor of it, just that this is still a
 developmental period and things could change by 4.0.

I see. So it might make sense to reevaluate the issue when 4.0 is out.
Please keep in mind that this is a wishlist bug report. I understand
that this might be too special to be worth the additional effort. For
me, it would certainly be very useful to have an additional low
resources package. The space requirements of Octave have grown slowly in
the past, but I think this leap is unprecedented.

Thanks,
Arno


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739614: Fwd: Re: Bug#739614: [apache2] unable to execute apache2

2014-02-21 Thread Arno Töll




 Original Message 
From: marco.ri...@gmail.com  Fri Feb 21 09:50:06 2014
Return-Path: marco.ri...@gmail.com
X-Original-To: deb...@toell.net
Delivered-To: deb...@toell.net
Received: by smart.knallkopp.de (Postfix, from userid 6061) id
5362C16419A; Fri, 21 Feb 2014 09:50:06 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
smart.knallkopp.de
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=3.0
tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=disabled version=3.3.2
X-policyd-weight: using cached result; rate: -5.5
Received: from muffat.debian.org (muffat.debian.org [206.12.19.146])
(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client
certificate requested) by smart.knallkopp.de (Postfix) with ESMTPS id
B18AD164178 for deb...@toell.net; Fri, 21 Feb 2014 09:50:00 +0100 (CET)
Received: from mail-ee0-x22a.google.com ([2a00:1450:4013:c00::22a]) by
muffat.debian.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128) (Exim 4.80)
(envelope-from marco.ri...@gmail.com) id 1WGlny-0002UE-Jp for
deb...@toell.net; Fri, 21 Feb 2014 08:49:59 +
Received: by mail-ee0-f42.google.com with SMTP id b15so1451736eek.1
   for a...@debian.org; Fri, 21 Feb 2014 00:49:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=message-id:date:from:user-agent:mime-version:to:subject:references
 :in-reply-to:content-type:content-transfer-encoding;
bh=MnCfXMdLIR8yfrFpVOsC73jng1WPi2xW1MQ0+AGzT2Y=;
b=FlCUSqX90YmXIVCaTpes6szFuydunoaEmZTyIBe0w06rBj/p7fqTiFz+f6+pdtFyGs

asQeTAIph/zaIR5F/aFZM222ZWkWJvPotko/1KECj9cvzCLZmi76dIxwZOWBOVKFML2Z

+OzdQ6GnV+Yepph4qALDfwhnJzMapwbnHu+TLKKBU9bw6Y57kRK8falB0QI7eRr8VAms

SFFomsT1rM0BHI+NztKIoQReas4eyEu7Zb6ORDTG5uCK3OS5ZaRftDcz1WH0xUFcx0EW

zdCH0cyZGn3nxKW6QdXLwH05DL+bZJ1pF1zJf9wKUpjxlpDnu3k7mcg+svOWQZrr2kvt
 IFMw==
X-Received: by 10.14.175.2 with SMTP id y2mr6817847eel.75.1392972590781;
   Fri, 21 Feb 2014 00:49:50 -0800 (PST)
Received: from [146.48.81.142] (pc-thesaurus1.isti.cnr.it.
[146.48.81.142])by mx.google.com with ESMTPSA id
46sm24014582ees.4.2014.02.21.00.49.50for a...@debian.org
  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);Fri, 21
Feb 2014 00:49:50 -0800 (PST)
Message-ID: 5307132d.8030...@gmail.com
Date: Fri, 21 Feb 2014 09:49:49 +0100
From: Marco Righi marco.ri...@gmail.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Thunderbird/24.3.0
MIME-Version: 1.0
To: Arno Töll a...@debian.org
Subject: Re: Bug#739614: [apache2] unable to execute apache2
References: 53060663.7050...@gmail.com 5306157d.6020...@debian.org
In-Reply-To: 5306157d.6020...@debian.org
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

 apachectl start

Command 593 of 97 #apachectl start
sh: 0: getcwd() failed: No such file or directory
AH00558: apache2: Could not reliably determine the server's fully
qualified domain name, using 2a00:1620:c0:50:f66d:4ff:fe74:f12c. Set
the 'ServerName' directive globally to suppress this message
(98)Address already in use: AH00072: make_sock: could not bind to
address [::]:80
(98)Address already in use: AH00072: make_sock: could not bind to
address 0.0.0.0:80
no listening sockets available, shutting down
AH00015: Unable to open logs
Action 'start' failed.
The Apache error log may have more information.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#737770: Duplicate

2014-02-21 Thread Arno Töll

forcemerge 714296 737770
severity 714296 serious
thanks

#737770 is a duplicate of #714296. Moreover, I think this is a serious
problem in dia that heavily impacts is usability, next to making it
useless (how useful is a diagram drawing tool where you can't use labels
whatsoever?). Thus, I'm raising the severity.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#739614: [apache2] unable to execute apache2

2014-02-20 Thread Arno Töll

Hi Marco,

On 20.02.2014 14:42, Marco Righi wrote:
 
 Please ask to me if you need more informaitons.

Of course we do need more information. You didn't tell us anything we
could work with.

At very least you should tell us why you think Apache won't start, how
you tried, and what happens if you execute apachectl start. You know,
anything.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#739614: Fwd: Re: Bug#739614: [apache2] unable to execute apache2

2014-02-20 Thread Arno Töll




 Original Message 
From: marco.ri...@gmail.com  Thu Feb 20 16:18:52 2014
Return-Path: marco.ri...@gmail.com
X-Original-To: deb...@toell.net
Delivered-To: deb...@toell.net
Received: by smart.knallkopp.de (Postfix, from userid 6061) id
9C42516419A; Thu, 20 Feb 2014 16:18:52 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
smart.knallkopp.de
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=3.0
tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=disabled version=3.3.2
X-policyd-weight: using cached result; rate: -5.5
Received: from muffat.debian.org (muffat.debian.org [206.12.19.146])
(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client
certificate requested) by smart.knallkopp.de (Postfix) with ESMTPS id
AF2D9164178 for deb...@toell.net; Thu, 20 Feb 2014 16:18:46 +0100 (CET)
Received: from mail-ea0-x231.google.com ([2a00:1450:4013:c01::231]) by
muffat.debian.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128) (Exim 4.80)
(envelope-from marco.ri...@gmail.com) id 1WGVOe-F6-Qc for
deb...@toell.net; Thu, 20 Feb 2014 15:18:45 +
Received: by mail-ea0-f177.google.com with SMTP id h14so965338eaj.36
for a...@debian.org; Thu, 20 Feb 2014 07:18:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=message-id:date:from:user-agent:mime-version:to:subject:references
 :in-reply-to:content-type:content-transfer-encoding;
bh=KCVsdwZl/eWZiXqUrvvp1mY+bJdhHi4DUGiCgkttRX4=;
b=a5lP10JdD+rr+mInYKC4E2uh6alFfk0YOLszGp7ykzrQN191K9Ho81hATU9vjd3Kvz

ia2jeBmW4YJ9O8pqswIepGLi2L1FvzDu30cFf8YWSNQFT1Tp1xfu7jSJVzlII1WCcDnf

R+hhu6RmZj/P0Hxph2mHNB3QAnMSlcEPC5Ui9hL/T+Vzm5Yb6UMLENR5IiALigbfwAZA

fUD8lVIYpwME5mxdMWYx3K4GqKHUB+OZywCBghilXRP6Y5ryS5i+kCnMhOdfyqbCxEfI

5rj+DC3SFHJNKEmLRCEDLdOd7lE78FvKZtuY/9vOgxMetlqWHpccDKW00YT71lWo2Ra5
 AeRw==
X-Received: by 10.15.42.72 with SMTP id
t48mr2439607eev.45.1392909517030;Thu, 20 Feb 2014 07:18:37 -0800
(PST)
Received: from [146.48.81.142] (pc-thesaurus1.isti.cnr.it.
[146.48.81.142])by mx.google.com with ESMTPSA id
v6sm14914396eef.2.2014.02.20.07.18.36for a...@debian.org
  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);Thu, 20
Feb 2014 07:18:36 -0800 (PST)
Message-ID: 53061ccb.4020...@gmail.com
Date: Thu, 20 Feb 2014 16:18:35 +0100
From: Marco Righi marco.ri...@gmail.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Thunderbird/24.3.0
MIME-Version: 1.0
To: Arno Töll a...@debian.org
Subject: Re: Bug#739614: [apache2] unable to execute apache2
References: 53060663.7050...@gmail.com 5306157d.6020...@debian.org
In-Reply-To: 5306157d.6020...@debian.org
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

I have try to use /etc/inid.d/apache2 restart

The command shell is quick to execute the STOP command. It is very
slow during the start session. I have not error messages.

I am sure that apache does not run because when I try to connect to
localhost with firefox I got a timeout.

Moreover, it is strange that the log files are empty!

I have try to uninstall completely apache2 using synaptic. After the
unistallation I deleted the /etc/apache2 directory.

I have installed again apache2 (without delete the apt cache) and I
have encountered again the previous problem!

do you think that it is important try to execute directly apachectl
start?

Marco

Il 20/02/2014 15:47, Arno Töll ha scritto:
 Hi Marco,

 On 20.02.2014 14:42, Marco Righi wrote:

 Please ask to me if you need more informaitons.

 Of course we do need more information. You didn't tell us anything
 we could work with.

 At very least you should tell us why you think Apache won't start,
 how you tried, and what happens if you execute apachectl start.
 You know, anything.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728245: icinga-cgi: fails to install: subprocess installed post-installation script returned error exit status 1

2014-02-17 Thread Arno Töll

Hi,

   + APACHE2_NEED_ACTION=1
   + a2enmod -m -q cgi
   + return 1
   dpkg: error processing package icinga-cgi (--configure):


this is the actual problem. The maintscript-helper could not enable the
CGI module and thus fails out. So far that's correct behavior. Now, the
underlying question ist _why_ it fails.

I cannot reproduce this in a default installation of Apache 2.4 and a
clean chroot either. However, note that a2enmod selects cgid over cgi
when a threaded MPM was found. Thus, a2enmod cgi will actually enable
cgid when the event/worker MPM is used. Either way this is handled
correctly I think:

(work-amd64)root@build:/build/apache# a2enmod cgi ; echo $?
Your MPM seems to be threaded. Selecting cgid instead of cgi.
Enabling module cgid.
To activate the new configuration, you need to run:
  service apache2 restart
0
(work-amd64)root@build:/build/apache#
(work-amd64)root@build:/build/apache# a2query -m cgi
No module matches cgi
(work-amd64)root@build:/build/apache# a2query -m cgid
cgid (enabled by site administrator)
(work-amd64)root@build:/build/apache# a2dismod cgid
Module cgid disabled.
To activate the new configuration, you need to run:
  service apache2 restart
(work-amd64)root@build:/build/apache# a2enmod -m -q cgi ; echo $?
Your MPM seems to be threaded. Selecting cgid instead of cgi.
Enabling module cgid.
0


What's special in your environment Andreas making this fail?


-- 
mit freundlichen Grüßen,
Arno Töll
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#731074: [pkg-lighttpd] Bug#731074: lighttpd: indeterminate test on kfreebsd buildds

2014-01-28 Thread Arno Töll

Hi Steven.

On 27.01.2014 21:22, Steven Chamberlain wrote:
 I could reproduce it 8 times out of 100 here on kfreebsd-amd64.
 
 The race happens after getting Connection Refused trying to contact the
 fcgi-responder which has just exit (intentionally).
 
 The parent does a wait4() syscall, and if this returns the pid of the
 process that just exit, a new listen is set up on 1/tcp and lighttpd
 forks a new fcgi-responder.  The parent waits with select() for it to be
 ready, then sends the FCGI request which is successful:

is this a libc portability issue then? All in all this does not really
sound like a problem in the lighttpd code base, does it?


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#734865: libapache2-mpm-itk: fails to install: subprocess installed post-installation script returned error exit status 1

2014-01-16 Thread Arno Töll

Hi Steinar,

On 16.01.2014 21:22, Steinar H. Gunderson wrote:
 I think this is a separate issue; it was discussed when we split out mpm-itk
 as a separate package, and the general sentiment was that it will work for
 wheezy - jessie, but not necessarily sid - sid (the latter is not strictly
 supported).

however, we support an upgrade sid-sid - unless there is a (unrelated)
bug - in such, that the update won't error out. Sid users will be
warned, but the related postinst code is not supposed to fail in that case.

Please check if your maintainer scripts work as expected, as the issue
seems to be, that you enable the itk module, before disabling the
current (default) mpm. See [1] for properly switchting MPMs in
maintainer scripts.


On a side note, Andreas would it be possible to do piuparts checks
related to Apache and its modules with APACHE2_MAINTSCRIPT_DEBUG=true
defined in the environment? That would make the logs more useful.


[1]
http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;h=0bbb06c48d628cd7c3b6037a0118574a722f2184;hb=HEAD#l317
-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#714296: dia: pdf export broken for text elements, example attached

2014-01-15 Thread Arno Töll

forwarded 714296 https://bugzilla.gnome.org/show_bug.cgi?id=573261
thanks

As a follow-up, here are some related upstream bug reports:

https://bugzilla.gnome.org/show_bug.cgi?id=696128
https://bugzilla.gnome.org/show_bug.cgi?id=705164
https://bugzilla.gnome.org/show_bug.cgi?id=573261


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#714296: dia: pdf export broken for text elements, example attached

2014-01-02 Thread Arno Töll

Hello,

I can confirm this serious problem in dia. See the files attached which
contain a simple dia input file and the corresponding PNG/PDF exports.
Both are unreadable.


This makes dia pretty useless. The problem applies to all versions in
Testing/Unstable, (Old-)Stable however is not affected.

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D


fonts.dia
Description: application/dia-diagram


fonts.pdf
Description: Adobe PDF document
attachment: fonts.png

signature.asc
Description: OpenPGP digital signature

Bug#733377: trafficserver: FTBFS: TsConfigGrammar.hpp:3:3: error: expected identifier before '{' token

2014-01-02 Thread Arno Töll

tags 733377 pending
thanks

Hi, the issue is fixed upstream. I'm in the preparation of a new
upstream version upload fixing this issue by driving by.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#491547: web server policy requires /var/www, not in FHS

2014-01-02 Thread Arno Töll

Hi,

even more so a discussion on debian-devel [1] came to the conclusion
that /var/www as a document root is security-wise a bad default for web
servers.

Therefore, we, Apache maintainers, decided to change the default
document root to /var/www/html (#730372). This might be seen as a policy
violation as of §11.5, but we do not violate the FHS as this directory
does not exist there.

I'm not sure about the state of the FHS when this bug was filed, but to
date /srv exists per FHS as a place to put organization-local files,
e.g. document roots which is a replacement to /var/www _to users_. We,
as a maintainer cannot use /srv straight though to avoid information
leaks. Moreover, we must neither assume any organization-local directory
structure below /srv.

Please clarify this ambiguity in the policy.


[1] https://lists.debian.org/debian-devel/2012/04/msg00301.html
-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#732450: please sign new apache releases only with strong keys -- trimming the KEYS file

2013-12-27 Thread Arno Töll

Hi,

On 27.12.2013 00:18, Nick Kew wrote:
 What is Debian's view on the relative importance of key size vs breadth
 and depth of the WoT surrounding a key?  I would tend to find an ancient
 1024-bit key with 100 strong-set sigs much more reassuring than a shiny
 new 4096-bit with just 1 (let alone any number of non-strong-set keys)!

Debian /requires/ new developers to obtain a key being 2048R at least
and urges existing developers migrate to stronger keys, while aiming to
keep a solid WoT. Formal and informal keysigning parties on DebConfs and
resigning requests are a used practice to transition to stronger keys.

Full details are covered in [1][2]. Debian's best practices for a key
migration are documented in [3]

[1] http://lists.debian.org/debian-devel-announce/2010/09/msg3.html
[2] http://keyring.debian.org/creating-key.html
[3] http://keyring.debian.org/replacing_keys.html

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#732450: debian/watch: help uscan verify PGP signature automatically

Hi,

On 23.12.2013 17:48, Daniel Kahn Gillmor wrote:
 But if apache is issuing cryptographic signatures from any of the weak
 keys in KEYS, we should encourage them to stop doing so.  Apache's
 source code is a high-value target, and we should not leave the software
 distribution mechanism open to fiddling based on weak keys for
 cryptographic certifications.
[..]
 I recommend filtering KEYS by removing every key whose primary key (or
 any signing-capable subkey) is less than 3072 bits (assuming RSA or DSA
 keys here) before storing it in debian/upstream-signing-key,pgp.

I'm absolutely with you on that. I strongly agree that Apache people
should use stronger keys. However, we're a distribution - it's not our
job to define key requirements for upstreams. We can, and maybe should
talk to them on that matter but technically it's not only Jim to be
allowed to release new versions of the Apache web server.  That being
said, it's them to accept/define valid and legit keys used within their
project.

Therefore, I thought a more complete patch would be a keyring which
includes all signatures of people allowed to sign and release code on
behalf of the httpd project.

I do not mind removing weak keys again, but then I wonder if there is
an actual benefit if Jim for once doesn't sign a release.

Either way, we should move this discussion to upstream I guess.

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#731074: lighttpd: indeterminate test on kfreebsd buildds

tags 731074 help
thanks

Hi,

On 01.12.2013 18:03, Michael Gilbert wrote:
 The mod-fastcgi.t test sometimes fails and sometimes succeeds on the
 kfreebsd build daemons.  Please see latest build logs:
 https://buildd.debian.org/status/logs.php?pkg=lighttpdarch=kfreebsd-i386
 https://buildd.debian.org/status/logs.php?pkg=lighttpdarch=kfreebsd-amd64
 
 I did some testing with a real kfreebsd machine, and this test always
 passes (I uploaded those binaries), so it seems the problem is
 specific to the buildds.

could anyone with sufficient buildd-fu please provide some insight here?
In my local sbuild installation lighttpd builds fine on kfreebsd, as it
seems to do for Michael's.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#713860: [PATCH] work around bug #712727 (systemd-tmpfiles --create uses non-absolute path)

Hi Michael,

On 23.06.2013 12:31, Michael Stapelberg wrote:
 Package: lighttpd
 Version: 1.4.31-3
 Severity: normal
 Tags: patch
 
 Quote from the commit message:
 
 work around bug #712727 (systemd-tmpfiles --create uses non-absolute path)
 
 These lines can be reverted once a new debhelper version is uploaded.
 Note that the Build-Dependency needs to be bumped to make sure that
 debhelper version is used.
 
 This problem results in lighttpd not starting up properly until you
 either run systemd-tmpfiles --create or reboot your machine. All
 machines running systemd-44 (currently in Debian stable and sid) are
 affected.
 

sorry for the dealy. For some reason I missed your patch. It looks
#712727 is fixed now, so that we can close this bug without any further
action. Do you agree?

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#731074: lighttpd: indeterminate test on kfreebsd buildds

Hi Christoph,

On 24.12.2013 14:15, Christoph Egger wrote:
 Are you both running stable kernels for the build? are you using chroots
 or not?

I use sbuild and unstable on my dev environment.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#713860: [pkg-lighttpd] Bug#713860: [PATCH] work around bug #712727 (systemd-tmpfiles --create uses non-absolute path)