Bug#1031743: python3.11-minimal: Python 3.11 should be compiled as a PIE, but it is not

[Philipp Hahn]

Package: python3.11
Version: 3.11.2-6
Followup-For: Bug #1031743

Dear Maintainer,

PIE was enebaled for Python 3.10 by [Bug
#919134](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919134).

[b23d4ec0](https://salsa.debian.org/cpython-team/python3/-/commit/b23d4ec00357597127b8651a1f4f5e3eea388d72#8756c63497c8dc39f7773438edf53b220c773f67_84_83)
added it only for Ubuntu, so
[4faf96b5](https://salsa.debian.org/cpython-team/python3/-/commit/4faf96b52843e91c28c2e4cc2a5cbb8b88ff7ec3#8756c63497c8dc39f7773438edf53b220c773f67_88_83)
changed it to also support Debian and switched from 

Then
[03a2c395](https://salsa.debian.org/cpython-team/python3/-/commit/03a2c395781b26ecb2c6ec09a54fa3569de8ac9c#8756c63497c8dc39f7773438edf53b220c773f67_86_85)
added a work-around for 
[pypa/pip#11183](https://github.com/pypa/pip/issues/11183) and disbaled PIE:

But `debian/rules` contains this:

> 81 dpkg_buildflags = DEB_BUILD_MAINT_OPTIONS="hardening=-pie 
> $(DPKG_OPTIMIZE)" dpkg-buildflags
> 82 dpkg_pieflags = DEB_BUILD_MAINT_OPTIONS="hardening=-pie 
> $(DPKG_OPTIMIZE)"dpkg-buildflags
> 83 ifeq (,$(filter $(distrelease),stretch buster bullseye trusty xenial 
> bionic focal impish))

No "bookworm" here, so `$(filter booworm,…)` is empty and the following
gets applied:

> 84   with_nopie := yes
> 85   dpkg_pieflags = DEB_BUILD_MAINT_OPTIONS="hardening=-pie 
> $(DPKG_OPTIMIZE)" dpkg-buildflags
  ^
> 86 endif


Sadly the commit does not carry any extra information why PIE was
disabled, probably to make binary wheels compatible with Debian again?

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3.11 depends on:
ii  libpython3.11-stdlib  3.11.2-6
ii  media-types   10.0.0
ii  mime-support  3.66
ii  python3.11-minimal3.11.2-6

Versions of packages python3.11 recommends:
ii  ca-certificates  20230311

Versions of packages python3.11 suggests:
ii  binutils 2.40-2
ii  python3.11-doc   3.11.2-6
ii  python3.11-venv  3.11.2-6

-- no debconf information

Bug#1055917: mailman3-web: cron-job /etc/cron.d/mailman3-web sends mail minutely

[Philipp Hahn]

Package: mailman3-web
Version: 0+20200530-2.1
Severity: important

Dear Maintainer,

There's a cron job running ever miniute:
> # cat /etc/cron.d/mailman3-web
> * * * * *  www-data [ -f /usr/bin/django-admin ] && flock -n 
> /var/run/mailman3-web/cron.minutely /usr/share/mailman3-web/manage.py runjobs 
> minutely
> 2,17,32,47 * * * * www-data [ -f /usr/bin/django-admin ] && flock -n 
> /var/run/mailman3-web/cron.quarter_hourly /usr/share/mailman3-web/manage.py 
> runjobs quarter_hourly
> @hourlywww-data [ -f /usr/bin/django-admin ] && flock -n 
> /var/run/mailman3-web/cron.hourly /usr/share/mailman3-web/manage.py runjobs 
> hourly
> @daily www-data [ -f /usr/bin/django-admin ] && flock -n 
> /var/run/mailman3-web/cron.daily /usr/share/mailman3-web/manage.py runjobs 
> daily
> @weeklywww-data [ -f /usr/bin/django-admin ] && flock -n 
> /var/run/mailman3-web/cron.weekly /usr/share/mailman3-web/manage.py runjobs 
> weekly
> @monthly   www-data [ -f /usr/bin/django-admin ] && flock -n 
> /var/run/mailman3-web/cron.monthly /usr/share/mailman3-web/manage.py runjobs 
> monthly
> @yearlywww-data [ -f /usr/bin/django-admin ] && flock -n 
> /var/run/mailman3-web/cron.yearly /usr/share/mailman3-web/manage.py runjobs 
> yearly

that jobs writes to STDOUT/STDERR, which crond collects and sends via
email:

> /usr/lib/python3/dist-packages/django_q/conf.py:139: UserWarning: Retry and 
> timeout are misconfigured. Set retry larger than timeout,
> failure to do so will cause the tasks to be retriggered before 
> completion.
> See https://django-q.readthedocs.io/en/latest/configure.html#retry 
> for details.
>   warn(
> System check identified some issues:
> 
> WARNINGS:
> django_mailman3.MailDomain: (models.W042) Auto-created primary key used when 
> not defining a primary key type, by default 'django.db.models.AutoField'.
> HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
> DjangoMailman3Config.default_auto_field attribute to point to a subclass of 
> AutoField, e.g. 'django.db.models.BigAutoField'.
> django_mailman3.Profile: (models.W042) Auto-created primary key used when not 
> defining a primary key type, by default 'django.db.models.AutoField'.
> HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
> DjangoMailman3Config.default_auto_field attribute to point to a subclass of 
> AutoField, e.g. 'django.db.models.BigAutoField'.
> hyperkitty.Attachment: (models.W042) Auto-created primary key used when not 
> defining a primary key type, by default 'django.db.models.AutoField'.
> HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
> HyperKittyConfig.default_auto_field attribute to point to a subclass of 
> AutoField, e.g. 'django.db.models.BigAutoField'.
> hyperkitty.Email: (models.W042) Auto-created primary key used when not 
> defining a primary key type, by default 'django.db.models.AutoField'.
> HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
> HyperKittyConfig.default_auto_field attribute to point to a subclass of 
> AutoField, e.g. 'django.db.models.BigAutoField'.
> hyperkitty.Favorite: (models.W042) Auto-created primary key used when not 
> defining a primary key type, by default 'django.db.models.AutoField'.
> HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
> HyperKittyConfig.default_auto_field attribute to point to a subclass of 
> AutoField, e.g. 'django.db.models.BigAutoField'.
> hyperkitty.LastView: (models.W042) Auto-created primary key used when not 
> defining a primary key type, by default 'django.db.models.AutoField'.
> HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
> HyperKittyConfig.default_auto_field attribute to point to a subclass of 
> AutoField, e.g. 'django.db.models.BigAutoField'.
> hyperkitty.MailingList: (models.W042) Auto-created primary key used when not 
> defining a primary key type, by default 'django.db.models.AutoField'.
> HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
> HyperKittyConfig.default_auto_field attribute to point to a subclass of 
> AutoField, e.g. 'django.db.models.BigAutoField'.
> hyperkitty.Profile: (models.W042) Auto-created primary key used when not 
> defining a primary key type, by default 'django.db.models.AutoField'.
> HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
> HyperKittyConfig.default_auto_field attribute to point to a subclass of 
> AutoField, e.g. 'django.db.models.BigAutoField'.
> hyperkitty.Tag: (models.W042) Auto-created primary key used when not defining 
> a primary key type, by default 'django.db.models.AutoField'.
> HINT: Configure the DEFAULT_AUTO_FIELD setting or the 
> HyperKittyConfig.default_auto_field attribute to point to a subclass of 
> AutoField, e.g. 'django.db.models.BigAutoField'.
> hyperkitty.Tagging: (models.W042) Auto-created primary key used when not 
> defining a primary key type, by default 

Bug#1052154: python-debian: Make 'Package-List' a multiline field

[Philipp Hahn]

Source: python-debian
Version: 0.1.39
Severity: wishlist

Dear Maintainer,

according to 
> Package-List:
> package package-type section priority key-value-list
>   This multiline field contains a list of binary packages generated by this 
> source package.

but it is not listed as "Multivalue fields" for "class Dsc" in
<https://salsa.debian.org/python-debian-team/python-debian/-/blob/master/src/debian/deb822.py#L1907-1912>:

> _multivalued_fields = {
>   "files": ["md5sum", "size", "name"],
>   "checksums-sha1": ["sha1", "size", "name"],
>   "checksums-sha256": ["sha256", "size", "name"],
>   "checksums-sha512": ["sha512", "size", "name"],
> }

IMHO the following lines should be added:

> "package-list": ["package", "package-type", "section", "priority", 
> "key-value-list"],

This (slightly) changes the API as the returned type for
`Dsc()["package-list"]` changes, which might break existing code:
  old: str
  new: List[str]

-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable-debug'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-25-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 28601b07cb3f9a46ad989b6b1fefba00363329e5 Mon Sep 17 00:00:00 2001
Message-Id: 
<28601b07cb3f9a46ad989b6b1fefba00363329e5.1695027946.git.h...@univention.de>
From: Philipp Hahn 
Date: Mon, 18 Sep 2023 11:01:37 +0200
Subject: [PATCH] fix!: Make Dsc["Package-List"] a multiline field

according to 
> Package-List:
> package package-type section priority key-value-list
>   This multiline field contains a list of binary packages generated by this 
> source package.

Register the field `Package-List` as a multi-valued field.

BREAKING CHANGE: This changes the return type from `str` to `List[str]`.
---
 src/debian/deb822.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/debian/deb822.py b/src/debian/deb822.py
index 2c08797..a1ce4b1 100644
--- a/src/debian/deb822.py
+++ b/src/debian/deb822.py
@@ -1909,6 +1909,7 @@ class Dsc(_gpg_multivalued, _VersionAccessorMixin):
 "checksums-sha1": ["sha1", "size", "name"],
 "checksums-sha256": ["sha256", "size", "name"],
 "checksums-sha512": ["sha512", "size", "name"],
+"package-list": ["package", "package-type", "section", "priority", 
"key-value-list"],
 }
 
 
-- 
2.30.2

Bug#996892: cyrus-sasl2: consider handling as system library

[Philipp Hahn]

Hello fellow DDs,

Looking at 
[cyrus-sasl/COPYING](https://github.com/cyrusimap/cyrus-sasl/blob/master/COPYING) 
I find this text:



* 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer. 
 *

 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The name "Carnegie Mellon University" must not be used to
 *endorse or promote products derived from this software without
 *prior written permission. For permission or any other legal
 *details, please contact 

...

 * 4. Redistributions of any form whatsoever must retain the following
 *acknowledgment:
 *"This product includes software developed by …."


This looks like 
[BSD-3-Clause-Attribution](https://spdx.org/licenses/BSD-3-Clause-Attribution.html) 
to me:



1. Redistributions of source code must retain the above copyright notice, this 
list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, 
this list of conditions and the following disclaimer in the documentation 
and/or other materials provided with the distribution.
> 3. Neither the name of the copyright holder nor the names of its 
contributors may be used to endorse or promote products derived from 
this software without specific prior written permission.


4. Redistributions of any form whatsoever must retain the following 
acknowledgment: 'This product includes software developed by the ….'



Not [BSD-4-Clause](https://spdx.org/licenses/BSD-4-Clause.html) which 
differs in 3 and 4:



3. All advertising materials mentioning features or use of this software must 
display the following acknowledgement:
This product includes software developed by the organization.

4. Neither the name of the copyright holder nor the names the copyright holder 
nor the names of its contributors may be used to endorse or promote products 
derived from this software without specific prior written permission.



See 
<https://github.com/cyrusimap/cyrus-sasl/issues/594#issuecomment-1506743164> 
for a nicer comparison.


Looking at 
[popcon](https://qa.debian.org/popcon.php?package=cyrus-sasl2) I see the 
library to be install almost everywhere, which IMHO would qualify it as 
a "system library":



libsasl2-2  209141  99.40%  86


What needs to be done to get this bug move forward?

Thanks
pmhahn
--
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen

 +49-421-22232-57
 +49-421-22232-99

✉️ h...@univention.de
 https://www.univention.de/

Geschäftsführer: Peter H. Ganten, Stefan Gohmann
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Bug#1032916: ca-certificates: More expired CA certificates

[Philipp Hahn]

Package: ca-certificates
Version: 20210119
Followup-For: Bug #1032916

Dear fellow Debian Maintainer,

FYI: ca-certificates conatins many more CA certificates, which are
expired by now:

> $ for crt in /usr/share/ca-certificates/mozilla/*; do openssl x509 -in "$crt" 
> -noout -checkend 0 >/dev/null || printf "%s\t%s\n" "$(openssl x509 -noout 
> -enddate -in "$crt")" "$crt";  done
> notAfter=Dec 15 08:00:00 2021 GMT   
> /usr/share/ca-certificates/mozilla/Cybertrust_Global_Root.crt
> notAfter=Sep 30 14:01:15 2021 GMT   
> /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
> notAfter=Mar  3 12:09:48 2023 GMT   
> /usr/share/ca-certificates/mozilla/E-Tugra_Certification_Authority.crt
> notAfter=Dec 15 08:00:00 2021 GMT   
> /usr/share/ca-certificates/mozilla/GlobalSign_Root_CA_-_R2.crt
> notAfter=Mar 17 18:33:33 2021 GMT   
> /usr/share/ca-certificates/mozilla/QuoVadis_Root_CA.crt
> notAfter=Apr  6 07:29:40 2021 GMT   
> /usr/share/ca-certificates/mozilla/Sonera_Class_2_Root_CA.crt
> notAfter=Dec  8 11:10:28 2022 GMT   
> /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_EV_Root_CA.crt

Especially the "DST_Root_CA_X3" is probelmatic as they provided the
Let's encrypt cross-sign certificate:


At least `sa-update` from SpamAssassin fails to contact
https://spamassassin.apache.org/

> # curl -I https://spamassassin.apache.org/updates/MIRRORED.BY
> curl: (60) SSL certificate problem: certificate has expired

It works after removing the "DST Root CA X3":

> [ -f /etc/ca-certificates.conf/etc/ca-certificates.conf ] &&
> sed -i -e 's=^mozilla/DST_Root_CA_X3.crt=!&=' /etc/ca-certificates.conf &&
> update-ca-certificates ||
> true

1. Why are these old CAs still included?
   I know of some implementations, where the dates are not checked, so
   for them the expired trust anchors would still work.

2. Can we have an option to `update-ca-certificate` to remove/disable
   expired CAs?

-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (50, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  openssl1.1.1n-0+deb11u4

ca-certificates recommends no packages.

ca-certificates suggests no packages.

-- debconf information:
  ca-certificates/new_crts:
* ca-certificates/enable_crts: mozilla/ACCVRAIZ1.crt, 
mozilla/AC_RAIZ_FNMT-RCM.crt, mozilla/Actalis_Authentication_Root_CA.crt, 
mozilla/AffirmTrust_Commercial.crt, mozilla/AffirmTrust_Networking.crt, 
mozilla/AffirmTrust_Premium.crt, mozilla/AffirmTrust_Premium_ECC.crt, 
mozilla/Amazon_Root_CA_1.crt, mozilla/Amazon_Root_CA_2.crt, 
mozilla/Amazon_Root_CA_3.crt, mozilla/Amazon_Root_CA_4.crt, 
mozilla/Atos_TrustedRoot_2011.crt, 
mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt, 
mozilla/Baltimore_CyberTrust_Root.crt, mozilla/Buypass_Class_2_Root_CA.crt, 
mozilla/Buypass_Class_3_Root_CA.crt, mozilla/CA_Disig_Root_R2.crt, 
mozilla/Certigna.crt, mozilla/Certigna_Root_CA.crt, 
mozilla/certSIGN_ROOT_CA.crt, mozilla/certSIGN_Root_CA_G2.crt, 
mozilla/Certum_Trusted_Network_CA_2.crt, mozilla/Certum_Trusted_Network_CA.crt, 
mozilla/CFCA_EV_ROOT.crt, mozilla/Chambers_of_Commerce_Root_-_2008.crt, 
mozilla/Comodo_AAA_Services_root.crt, 
mozilla/COMODO_Certification_Authority.crt, 
mozilla/COMODO_ECC_Certification_Authority.crt, 
mozilla/COMODO_RSA_Certification_Authority.crt, 
mozilla/Cybertrust_Global_Root.crt, mozilla/DigiCert_Assured_ID_Root_CA.crt, 
mozilla/DigiCert_Assured_ID_Root_G2.crt, 
mozilla/DigiCert_Assured_ID_Root_G3.crt, mozilla/DigiCert_Global_Root_CA.crt, 
mozilla/DigiCert_Global_Root_G2.crt, mozilla/DigiCert_Global_Root_G3.crt, 
mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, 
mozilla/DigiCert_Trusted_Root_G4.crt, mozilla/DST_Root_CA_X3.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_2009.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_EV_2009.crt, mozilla/EC-ACC.crt, 
mozilla/emSign_ECC_Root_CA_-_C3.crt, mozilla/emSign_ECC_Root_CA_-_G3.crt, 
mozilla/emSign_Root_CA_-_C1.crt, mozilla/emSign_Root_CA_-_G1.crt, 
mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt, 
mozilla/Entrust_Root_Certification_Authority.crt, 
mozilla/Entrust_Root_Certification_Authority_-_EC1.crt, 
mozilla/Entrust_Root_Certification_Authority_-_G2.crt, 
mozilla/Entrust_Root_Certification_Authority_-_G4.crt, 
mozilla/ePKI_Root_Certification_Authority.crt, 
mozilla/e-Szigno_Root_CA_2017.crt, mozilla/E-Tugra_Certification_Authority.crt, 
mozilla/GDCA_TrustAUTH_R5_ROOT.crt, mozilla/Global_Chambersign_Root_-_2008.crt, 
mozilla/GlobalSign_ECC_Root_CA_-_R4.crt, 

Bug#1032594: apt: hard-coded directory permissions 0755

[Philipp Hahn]

Package: apt
Version: 2.2.4
Severity: normal

https://salsa.debian.org/apt-team/apt/-/blob/main/apt-pkg/contrib/fileutl.cc#L398
>  if (mkdir(progress.c_str(), 0755) != 0)

it would be good to make this configurabel with something similar to
`FileMode`.

We are using `apt-ftpachive` in a shared ennvironment. We are using
`umask 0002` to give group-membery rwx-access by default.
Our top-level directory has mode 02775 and group "build", so that every
path created below it is again owned by that group and has the SGID-bit
set.

But directories and files created by `apt-ftparchive` lack
write-permission for the group:
- Permissions for files can be configured via `FileMode`, which defaults
  to 0644.
- But there is nothing for directories, which is hard-coded to 0755.


-- Package-specific info:

-- /etc/apt/preferences --

Package: *
Pin: release a=testing
Pin-Priority: 50

-- (no /etc/apt/preferences.d/* present) --
-- (/etc/apt/sources.list present, but not submitted) --
-- (/etc/apt/sources.list.d/pbuilder.list present, but not submitted) --


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (50, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2021.1.1
ii  gpgv2.2.27-2+deb11u2
ii  libapt-pkg6.0   2.2.4
ii  libc6   2.31-13+deb11u5
ii  libgcc-s1   10.2.1-6
ii  libgnutls30 3.7.1-5+deb11u3
ii  libseccomp2 2.5.1-1+deb11u1
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-7+deb11u1

Versions of packages apt recommends:
ii  ca-certificates  20210119

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.13-3
ii  dpkg-dev1.20.12
ii  gnupg   2.2.27-2+deb11u2
ii  gnupg1  1.4.23-1.1
ii  gnupg2  2.2.27-2+deb11u2
ii  powermgmt-base  1.36

-- no debconf information

Bug#1023845: python-email-validator: New upstream version: 1.3.0

[Philipp Hahn]

Source: python-email-validator
Version: 1.1.2-1
Severity: normal
X-Debbugs-Cc: Dirk Wiesenthal 

Dear fellow Maintainer,

we (Univention GmbH) just noticed that there are new upstream version
available at
<https://github.com/JoshData/python-email-validator/releases>:
- v1.1.3 2022-04-24
- v1.2.1 2022-05-02
- v1.3.0 2022-09-18

Please consider updating the package as it contains some important
features for use, e.g. an option to allow otherwise reserved deomains in
test environments.

We'd like to see a newer version in
- Debian-10-Buser backports
- Debian-11-Bullseye backports
- Debian-12-Bookworm testing
- Debian-Sid unstable

I just did a `uscan --rename`, re-applied the old patches, updated
`debian/changelog` and successfully re-built the packages; my artifacts
are attached.
Feel free to pick form my work.
Getting the latest version in Sid/Bookworm would be good.
The backports are optional as we can otherwise use my bacport packages.

Philipp  Hahn

PS: If you need any help feel free to ask me.

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (50, 'testing')
Architecture: amd64 (x86_64)

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


python-email-validator_1.3.0-0~bpo10+1.debian.tar.xz
Description: application/xz


python-email-validator_1.3.0-0~bpo11+1.debian.tar.xz
Description: application/xz


python-email-validator_1.3.0-0.1.debian.tar.xz
Description: application/xz

Bug#1022756: gdbm: Open-FD-leak in reorganize()

[Philipp Hahn]

Source: gdbm
Version: 1.18.1-4
Severity: normal

Dear Maintainer,

gdbm_reorganize() leaks open file descriptors. It can be re-produces by
using the python3-gdbm binding:

  python3 -c 'import os,subprocess;import dbm.gnu;DB = "./db.gdbm";db = 
dbm.gnu.open(DB, "csu");db.reorganize();db.close();subprocess.call(f"lsof -p 
{os.getpid()}|grep {DB}", shell=True)'

> python 2119 phahn  DEL-W  REG254,0 6293029 ./db.gdbm
> python 2119 phahn  DEL-W  REG254,0 6293042 ./db.gdbm

For each call to reorganize() the DB is copied to a new file which is
then again memory-mapped. This takes one FD each time.

# dpkg -s libgdbm6
Package: libgdbm6
Source: gdbm
Version: 1.18.1-4

# dpkg -s python3-gdbm
Package: python3-gdbm
Source: python3-stdlib-extensions
Version: 3.7.3-1

Debian-9-Stretch 1.8.3-14
Debian-10-Buster 1.18.1-4 (affected)
Debian-11-Bullseye   1.19-2 (affected)
Debian-12-Bookworm   1.23-3 (fixed)


I have bisected the issue:
git bisect start '--term-new' 'fixed' '--term-old' 'broken'
# fixed: [331f05ac9c58d358806fe1bcba88a01467ab0895] Bugfix
git bisect fixed 331f05ac9c58d358806fe1bcba88a01467ab0895
# broken: [778cc81d55aecd6344d577919cec73e4e6980e2e] Version 1.18
git bisect broken 778cc81d55aecd6344d577919cec73e4e6980e2e
# broken: [611cac791f192834d49cd1bd8cfab76a190bfc40] Document new gdbmtool 
options
git bisect broken 611cac791f192834d49cd1bd8cfab76a190bfc40
# fixed: [3052f2b51eaa9ba047d43ae97581ae1fd895c131] Add missing include
git bisect fixed 3052f2b51eaa9ba047d43ae97581ae1fd895c131
# fixed: [e4089536f849644b12d9647aff12f2dac312b940] Version 1.21 released
git bisect fixed e4089536f849644b12d9647aff12f2dac312b940
# broken: [038872b1582c6b99cc352551875aba0e81f6b5f0] Minor fix
git bisect broken 038872b1582c6b99cc352551875aba0e81f6b5f0
# fixed: [a62815cdf0b60725d6445968ce3d5c39e912eb9c] Update docs
git bisect fixed a62815cdf0b60725d6445968ce3d5c39e912eb9c
# fixed: [cc7051ae2ea384863937083a3a60a5a008d511a5] gdbmshell: get rid of 
remaining globals
git bisect fixed cc7051ae2ea384863937083a3a60a5a008d511a5
# fixed: [d19407eaa4b00a724c4ff3744c2f49269183da26] gdbmtool: bugfixes
git bisect fixed d19407eaa4b00a724c4ff3744c2f49269183da26
# fixed: [f77b0273db2d1f0cc1ba2d3256acfab1bda1f584] Fix duplicated mmap in 
gdbm_recover
git bisect fixed f77b0273db2d1f0cc1ba2d3256acfab1bda1f584
# first fixed commit: [f77b0273db2d1f0cc1ba2d3256acfab1bda1f584] Fix duplicated 
mmap in gdbm_recover

Sadly that patch is not easy to backport because GDBM changes some
fundamental details, e.g. "New bucket cache" in v1.21 and "Bucket cache
switched from balanced tree to hash table" in v1.23

A similar bug was reported for Python
, which links to
 which is ALSO
required but not enough.

I have back-ported that patch and so far it works fine, but a second set
of eyes or even a review from upstream would be good.


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (50, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-18-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From ffeafe9692da956703d28f1f16c81a027a0e6869 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Sergey Poznyakoff 
Date: Mon, 8 Apr 2019 22:17:10 +0300
Subject: [PATCH 1/2] Preserve locking type during database reorganization

* src/recover.c (_gdbm_finish_transfer): Preserve locking type.
---
 src/recover.c | 1 +
 1 file changed, 1 insertion(+)

diff --git src/recover.c src/recover.c
index 7cc20a2..f1603d9 100644
--- src/recover.c
+++ src/recover.c
@@ -155,6 +155,7 @@ _gdbm_finish_transfer (GDBM_FILE dbf, GDBM_FILE new_dbf,
   free (dbf->bucket_cache);
}
 
+   dbf->lock_type = new_dbf->lock_type;
dbf->desc  = new_dbf->desc;
dbf->header= new_dbf->header;
dbf->dir   = new_dbf->dir;
-- 
2.30.2

>From 40c6da6ca9972ff0b9d7d084fe118c765808fef6 Mon Sep 17 00:00:00 2001
Message-Id: 
<40c6da6ca9972ff0b9d7d084fe118c765808fef6.185456.git.h...@univention.de>
In-Reply-To: 

References: 

From: Sergey Poznyakoff 
Date: Wed, 11 Aug 2021 23:01:37 +0300
Subject: [PATCH 2/2] Fix duplicated mmap in gdbm_recover

* src/recover.c (_gdbm_finish_transfer): Reuse memory mapping
from the intermediate dbm structure.
---
 src/recover.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git src/recover.c src/recover.c
index f1603d9..893e0a2 100644
--- src/recover.c
+++ src/recover.c
@@ -169,14 +169,14 @@ _gdbm_finish_transfer (GDBM_FILE dbf, GDBM_FILE new_dbf,
dbf->bucket_changed= new_dbf->bucket_changed;
dbf->second_changed= new_dbf->second_changed;
 
+  

Bug#1020301: mariadb-server-10.3: postinst called with unknown argument 'triggered'

[Philipp Hahn]

Package: mariadb-server-10.3
Version: 1:10.3.36-0+deb10u
Severity: important

Dear Maintainer,

I'm working for Univention GmbH and we're running our own piuparts
tests; while doing this I noticed the following error, which is similar
for all plugin packages connect, cracklib-password-check, gssapi-server,
mroongga, opgraph, rocksdb, spider, tokudb:

> Preparing to unpack 
> .../mariadb-plugin-gssapi-server_10.3.36-0+deb10u1_amd64.deb ...
> Unpacking mariadb-plugin-gssapi-server:amd64 (1:10.3.36-0+deb10u1) ...
> Setting up mariadb-plugin-gssapi-server:amd64 (1:10.3.36-0+deb10u1) ...
> Processing triggers for mariadb-server-10.3 (1:10.3.36-0+deb10u1) ...
> postinst called with unknown argument 'triggered'
> dpkg: error processing package mariadb-server-10.3 (--configure):
>  installed mariadb-server-10.3 package post-installation script subprocess 
> returned error exit status 1
> Errors were encountered while processing:
>  mariadb-server-10.3
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Looking at the installed package itself I find this:

> # cat /var/lib/dpkg/info/mariadb-server-10.3.triggers
> interest-noawait /etc/mysql
> interest-noawait /etc/systemd/system/mariadb.service.d

but `triggered` is not handled by `mariadb-server-10.3.postinst`: 
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/blob/buster/debian/mariadb-server-10.3.postinst#L148

> case "$1" in
>   configure)
…
>   ;;
>   abort-upgrade|abort-remove|abort-configure)
  ^ Add "|trigger" here
>   ;;
>   *)
> echo "postinst called with unknown argument '$1'" 1>&2
> exit 1
>   ;;
> esac

I do not (yet) know which debhelper generated `mariadb-server-10.3.triggers`
but the `debian/mariadb-server-10.3.postinst` template shipped in the Debian
source package should not block "$1 = triggered" but shold allow other
debhelper generated fragments inserted at #DEBHELPER# to handle this argument.

Philipp
-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (50, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-17-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1002732: needrestart stalled in background when performing update with KDE Discover

[Philipp Hahn]

More info from today, where again the update is stalled due to the next 
update



# xargs -0n 1 -a /proc/401446/environ echo
DPKG_FRONTEND_LOCKED=true
APT_LISTCHANGES_FRONTEND=none
LANGUAGE=de_DE.UTF-8
PACKAGEKIT_CALLER_UID=2260
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG=de_DE.UTF-8
DEBIAN_FRONTEND=noninteractive
PWD=/tmp
APT_LISTBUGS_FRONTEND=none


The message is from


# dpkg -L needrestart | xargs grep -sn --color Return
/usr/share/perl5/NeedRestart/UI/stdio.pm:42:$self->wprint(\*STDOUT, '', '', 
__x("Pending kernel upgrade!\n\nRunning kernel version:\n  {kversion}\n\nDiagnostics:\n 
 {message}\n\nRestarting the system to load the new kernel will not be handled 
automatically, so you should consider rebooting. [Return]\n",


which is the only available UI package:


env -i DPKG_FRONTEND_LOCKED=true APT_LISTCHANGES_FRONTEND=none LANGUAGE=C.UTF-8 
PACKAGEKIT_CALLER_UID=2260 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
LANG=de_DE.UTF-8 DEBIAN_FRONTEND=noninteractive PWD=/tmp 
APT_LISTBUGS_FRONTEND=none /usr/sbin/needrestart -u \?
Available UI packages:
NeedRestart::UI::stdio


Looking further into /usr/share/perl5/NeedRestart/UI/stdio.pm:


sub _announce {

...

 if (-t *STDIN && -t *STDOUT);
}


Combine that with


# lsof -p 401446 -a -d 0-2
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
needresta 401446 root0u   CHR  136,3  0t06 /dev/pts/3
needresta 401446 root1u   CHR  136,3  0t06 /dev/pts/3
needresta 401446 root2u   CHR  136,3  0t06 /dev/pts/3



STDIN and STDOUT are both '/dev/pts/3' which is a pseudo TTY, so the 
test evaluates to true and the code tries to read from that PTY; as the 
message is not displayed anywhere visible and there is no way to 
interact with needrestart from Discover the process hangs.


Philipp

Bug#996771: piuparts: fails to parse docker container ID if pulling

[Philipp Hahn]

Package: piuparts
Version: 1.1.4
Severity: normal

Dear Maintainer,

`piuparts --docker-image $img` fails if the image is not yet available
and needs to be pulled from a repote docker image repository first. In
that case the output of `docker run` contains progress information in
addition to the container ID.

The 1. attached patch fixed this by using `--cidfile`, which forces
`docker run` to write the generated container ID into that named file,
from where it is read afterwards.

The 2. patch simplifies getting the merged directory path from `docker
inspect`.

The 3. patch is optional and helps with debugging by always using log
level `DUMP` for the given log file and using `--log-level` only for
logging to STDOUT.

<https://docs.docker.com/engine/reference/run/#pid-equivalent>

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages piuparts depends on:
ii  debootstrap  1.0.123
pn  debsums  
ii  libjs-sphinxdoc  3.4.3-2
ii  lsb-release  11.1.0
ii  lsof 4.93.2+dfsg-1.1
ii  mount2.36.1-8
pn  piuparts-common  
ii  python3  3.9.2-3
ii  python3-debian   0.1.39

Versions of packages piuparts recommends:
pn  adequate  

Versions of packages piuparts suggests:
ii  docker.io  20.10.5+dfsg1-1+b5
pn  schroot
>From 74fc04769f062cc9818512d5e33755a8c42e2616 Mon Sep 17 00:00:00 2001
Message-Id: 
<74fc04769f062cc9818512d5e33755a8c42e2616.1634559960.git.h...@univention.de>
From: Philipp Hahn 
Date: Mon, 18 Oct 2021 12:59:50 +0200
Subject: [PATCH 1/3] fix[docker] getting Container ID

in case the image does not exists locally docker will pull it from any
remote registry, but will include the progress information in the
output:

> Unable to find image 'docker-registry.XXX/YYY:ZZZ' locally
> ZZZ: Pulling from YYY
...
> Digest: 
> sha256:4b9bfe7b0a6c970e3613c04f267ba6319cfceb8cc120b0435d9ee7b8037a1f06
> Status: Downloaded newer image for docker-registry.XXX/YYY:ZZZ
> 8be38c89d12937b98c8be5ab7466dd45b0e4a306862f282b58077ac7193251eb

The old code expected the output to be the container ID, which fails in that 
case.
---
 piuparts.py | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/piuparts.py b/piuparts.py
index f05db2ff..be99abf7 100644
--- a/piuparts.py
+++ b/piuparts.py
@@ -922,11 +922,16 @@ class Chroot:
 
 def setup_from_docker(self, docker_image):
 self.check_if_docker_storage_driver_is_supported()
-ret_code, output = run(['docker', 'run', '-d', '-it', docker_image, 
'bash'])
-if ret_code != 0:
-logging.error("Couldn't start the container from '%s'" % 
docker_image)
-panic()
-self.docker_container = output.strip()
+with tempfile.TemporaryDirectory() as tmpdir:
+tmp = os.path.join(tmpdir, "cid")
+ret_code, output = run(['docker', 'run', '-d', '-it', '--cidfile', 
tmp, docker_image, 'bash'])
+if ret_code != 0:
+logging.error("Couldn't start the container from '%s'" % 
docker_image)
+panic()
+
+with open(tmp, "r") as fd:
+self.docker_container = fd.read().strip()
+
 ret_code, output = run(['docker', 'inspect', self.docker_container])
 container_data = json.loads(output)[0]
 self.name = container_data['GraphDriver']['Data']['MergedDir']
-- 
2.30.2

>From 672e844798017ac35a9ac62a226f0cd8bfd932fa Mon Sep 17 00:00:00 2001
Message-Id: 
<672e844798017ac35a9ac62a226f0cd8bfd932fa.1634559960.git.h...@univention.de>
In-Reply-To: 
<74fc04769f062cc9818512d5e33755a8c42e2616.1634559960.git.h...@univention.de>
References: 
<74fc04769f062cc9818512d5e33755a8c42e2616.1634559960.git.h...@univention.de>
From: Philipp Hahn 
Date: Mon, 18 Oct 2021 14:18:25 +0200
Subject: [PATCH 2/3] refactor[docker] Let docker inspect return path

Directly use golang templating to only get the MergedDir path instead of
using json in Python.

Add path to deebug output.

Let debug output do the variable substitution.
---
 piuparts.py | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/piuparts.py b/piuparts.py
index be99abf7..e9c9934d 100644
--- a/piuparts.py
+++ b/piuparts.py
@@ -46,7 +46,6 @@ import os
 import tarfile
 import stat
 import re
-import json
 import pickle
 import subprocess
 import traceback
@@ -932,10 +931,9 @@ class Chroot:
 with open(tmp, "r") as fd:
 self.docker_container = fd.read().strip()
 
-ret_code, output = run(['docker

Bug#995368: Apache2 regression with mod_proxy_wsgi affects mailman3-web

[Philipp Hahn]

After installing the Apache2 security update yesterday Mainman3-web is 
no longe reachable:



tail /var/log/mailman3/web/mailman-web.log

…> WARNING 2021-10-14 10:13:30,753 3319 django.request Not Found: /mailman//

WARNING 2021-10-14 10:13:30,753 3319 django.request Not Found: /mailman//
[pid: 3319|app: 0|req: 8/8] REDACTED () {162 vars in 5356 bytes} [Thu Oct 14 
10:13:30 2021] GET /mailman3/ => generated 5501 bytes in 13 msecs (HTTP/1.1 
404) 5 headers in 170 bytes (2 switches on core 0)


# cat /etc/mailman3/apache.conf 

…


ProxyPass /mailman3/favicon.ico !
ProxyPass /mailman3/static !
ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/






# dpkg-query -W mailman3-web apache2
apache2 2.4.51-1~deb11u1
mailman3-web0+20200530-2


Apache2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995368#48
Mailman: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996105

Bug#996249: ublock-origin: Invalid debian/changelog file

[Philipp Hahn]

Source: ublock-origin
Version: 1.37.0+dfsg-1~deb10u1
Severity: important
X-Debbugs-Cc: debian-rele...@lists.debian.org

Dear Maintainer,

the just releases Debian 10.1 Buster contains your package, which has an 
invalid debian/changelog file:

$ wget -qO- 
http://snapshot.debian.org/archive/debian/20210908T025933Z/pool/main/u/ublock-origin/ublock-origin_1.37.0%2Bdfsg-1~deb10u1.debian.tar.xz
 | xz -d | tar xfO - debian/changelog | sed -ne '1,6p;26,34p'
> ublock-origin (1.37.0+dfsg-1~deb10u1) buster; urgency=medium
>
>   * Backport to Debian 10 "Buster".
>
>  -- Markus Koschany   Sat, 28 Aug 2021 22:29:16 +0200
>
> ublock-origin (1.32.0+dfsg-1) unstable; urgency=medium
>
>   * New upstream version 1.32.0+dfsg.
>   * Declare compliance with Debian Policy 4.5.1.
>
>  -- Markus Koschany   Sat, 26 Dec 2020 20:48:03 +0100
> >>> master
>
> ublock-origin (1.30.0+dfsg-1) unstable; urgency=medium

This breaks parsing the file using `python3-debian` and other tools like
`dpkg-parsechangelog`:

$ wget -qO- 
http://snapshot.debian.org/archive/debian/20210908T025933Z/pool/main/u/ublock-origin/ublock-origin_1.37.0%2Bdfsg-1~deb10u1.debian.tar.xz
 | xz -d | tar xfO - debian/changelog | sed -ne '1,38p' | dpkg-parsechangelog 
-l- --all
> dpkg-parsechangelog: Warnung:-(l32): ungültig formatierte 
> Kopfzeile



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

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#892105: Cherry-pick "i40e: Be much more verbose about what we can and cannot offload"

[Philipp Hahn]

bffb5ed56e5e7d1fb3fb 
on top of v4.9.273 fixes the problem and reverting it again shows the 
problem again.


Philipp
--
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen

 +49-421-22232-57
 +49-421-22232-99

✉️ h...@univention.de
 https://www.univention.de/

Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Bug#977402: packagekit: Software update hangs waiting for input

[Philipp Hahn]

Package: packagekit
Version: 1.1.12-5
Severity: important

Dear Maintainer,

   * What led up to the situation?

Performing software update from KDE.

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

Start installing updates. I already did the same some days ago *without*
restarting my desktop session or all my services - some where restarted
I guess.

   * What was the outcome of this action?

The update process is stalled now at
> Aufgaben (95%)
> Aktualisieren - Wird installiert

   * What outcome did you expect instead?

The KDE dialog should close after all updates have been installed.

Or it should show an input dialog where I can see the output of "needrestart"
and control it.  Why is it reading from "/dev/pts/7" at all? Maybe https://bugs.launchpad.net/bugs/1778359
https://bugzilla.redhat.com/show_bug.cgi?id=471792

   * Additional data:

$ ps axf
 1589 ?Sl 2:05 /usr/bin/krunner
22405 ?Sl65:07  \_ /usr/bin/plasmashell
13140 ?Sl 0:04  |   \_ /usr/bin/plasma-discover --mode update
...
13147 ?Ssl0:07 /usr/lib/packagekit/packagekitd
14050 pts/7Ss+0:00  \_ /usr/lib/packagekit/packagekitd
14126 pts/7S+ 0:00  \_ /usr/lib/packagekit/packagekitd
14134 pts/7S+ 0:00  \_ sh -c test -x 
/usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true
14135 pts/7S+ 0:00  \_ /usr/bin/perl /usr/sbin/needrestart

$ sudo -s lsof -p 14135
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFFNODE NAME
needresta 14135 root  cwdDIR  254,1 4096 1569794 /tmp
needresta 14135 root  rtdDIR  254,1 4096   2 /
needresta 14135 root  txtREG  254,1  3201864 1208293 /usr/bin/perl
needresta 14135 root  memREG  254,122800   45297 
/usr/lib/x86_64-linux-gnu/perl/5.28.1/auto/IO/IO.so
needresta 14135 root  memREG  254,131184   45291 
/usr/lib/x86_64-linux-gnu/perl/5.28.1/auto/File/Glob/Glob.so
needresta 14135 root  memREG  254,126712 213 
/usr/lib/x86_64-linux-gnu/perl5/5.28/auto/Locale/gettext_xs/gettext_xs.so
needresta 14135 root  memREG  254,1   109384   45312 
/usr/lib/x86_64-linux-gnu/perl/5.28.1/auto/Storable/Storable.so
needresta 14135 root  memREG  254,147584   45283 
/usr/lib/x86_64-linux-gnu/perl/5.28.1/auto/Encode/Encode.so
needresta 14135 root  memREG  254,1   110032   45305 
/usr/lib/x86_64-linux-gnu/perl/5.28.1/auto/POSIX/POSIX.so
needresta 14135 root  memREG  254,122704   45289 
/usr/lib/x86_64-linux-gnu/perl/5.28.1/auto/Fcntl/Fcntl.so
needresta 14135 root  memREG  254,1   585136   45323 
/usr/lib/x86_64-linux-gnu/perl/5.28.1/auto/re/re.so
needresta 14135 root  memREG  254,143328  140394 
/lib/x86_64-linux-gnu/libcrypt-2.28.so
needresta 14135 root  memREG  254,1  1824496  140393 
/lib/x86_64-linux-gnu/libc-2.28.so
needresta 14135 root  memREG  254,1   146968  140407 
/lib/x86_64-linux-gnu/libpthread-2.28.so
needresta 14135 root  memREG  254,1  1579448  140396 
/lib/x86_64-linux-gnu/libm-2.28.so
needresta 14135 root  memREG  254,114592  140395 
/lib/x86_64-linux-gnu/libdl-2.28.so
needresta 14135 root  memREG  254,122368   15422 
/usr/lib/x86_64-linux-gnu/perl5/5.28/auto/Term/ReadKey/ReadKey.so
needresta 14135 root  memREG  254,134728   11014 
/usr/lib/x86_64-linux-gnu/perl5/5.28/auto/Proc/ProcessTable/ProcessTable.so
needresta 14135 root  memREG  254,155136   12845 
/usr/lib/x86_64-linux-gnu/perl5/5.28/auto/List/Util/Util.so
needresta 14135 root  memREG  254,118624   45274 
/usr/lib/x86_64-linux-gnu/perl/5.28.1/auto/Cwd/Cwd.so
needresta 14135 root  memREG  254,1   165632  130819 
/lib/x86_64-linux-gnu/ld-2.28.so
needresta 14135 root0u   CHR  136,7  0t0  10 /dev/pts/7
needresta 14135 root1u   CHR  136,7  0t0  10 /dev/pts/7
needresta 14135 root2u   CHR  136,7  0t0  10 /dev/pts/7


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

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

Versions of packages packagekit depends on:
ii  libappstream4   0.12.5-1
ii  libapt-inst2.0  1.8.2.2
ii  libapt-pkg5.0   1.8.2.2
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libglib2.0-02.58.3-2+deb10u2
ii  libglib2.0-bin  2.58.3-2+deb10u2
ii  libgstreamer1.0-0   1.14.4-1
ii  libpackagekit-glib2-18  1.1.12-5
ii  libpolkit-gobject-1-0   0.105-25
ii  libsqlite3-03.27.2-3+deb10u1
ii  libstdc++6  8.3.0-6
ii  libsystemd0 241-7~deb10u5
ii  policykit-1 0.105-25

Versions of packages packagekit recommends:

Bug#975903: apt-get update fails to (permanently) download index files after time skew

[Philipp Hahn]

Package: apt
Version: 1.8.2.1
Severity: normal

Suspending a VM (Qemu/KVN) to disk while it is running also saves the
current time, which is restored on resume. If NTP does not work quickly
enough to fix that on resume, the VM lives in the past.
Running `apt-get update` will then print something like this:
> E: Release file for http://192.168.0.10/xxx/Release is not valid yet (invalid 
> for another 2 d 19 h 44 min 10 s). Updates for this repository will not be 
> applied

`apt` stores the file below `/var/lib/apt/lists/` using the local time.
The file itself is considered valid (correct signature, ...), but due to
the time skew the referenced `Packages*` and `Sources*` files are *NOT*
downloaded.

When next you invoke `apt-get update` again - even after fixing the time
and thus moving the VM to current wall clock - nothing gets updated.

`apt` find the valid `Release` file and checks it with the server.
If there is an updated version, everything works as expected.

But if there is no updated version, `apt` skips the following steps to
download the index files as it thinks, that they are still valid from
the *previous* download, which never happened.

This can be "fixed" by deleting the files `/var/lib/apt/lists/*Release`,
which forces `apt` to download thoses files again; the "changed"
`Release` file then triggeres the download of the changed index files,
too.


Reproducer:
  /etc/init.d/ntp stop
  date -s '2020-11-01'
  truncate -s 0 /var/lib/apt/lists/*_Packages
  touch /var/lib/apt/lists/*_*
  apt-get update -o Debug::Acquire::http=true
  > If-Modified-Since: Sat, 31 Oct 2020 23:00:10 GMT
  < HTTP/1.1 200 OK
  < Date: Thu, 26 Nov 2020 11:35:30 GMT
  < Last-Modified: Thu, 26 Nov 2020 11:16:48 GMT
  # will complain about times in the future
  ls -gGh /var/lib/apt/lists/*_*
  # will list `Packages*` files with size 0
  ntpdate 1.debian.pool.ntp.org
  apt-get update -o Debug::Acquire::http=true
  ls -gGh /var/lib/apt/lists/*_*
  # `Release` files will be downloaded again
  # `Packages*` files still has size 0

To me it looks like `apt`
1. gets an "HTTP 200 OK",
2. downloads the (unchagned) file,
3. but sees that it is the same as the locall file,
4. skips downloadthe the index files.

I haven't yet checked the code, but on first impulse `apt` should not
store the `Release` file if it is considered invalid due to time skew.

Or always try to download the referenced index files if the `Release`
file was downloaded, even when it remains unchanged to the previous
local version. Only on a "HTTP 304 Not Modified" should `apt` optimize
the index files download.


This issue can be mitigated by setting `Acquire::Max-FutureTime` to
a large value.

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/debian-backports.list present, but not submitted) --


-- (/etc/apt/sources.list.d/google-talkplugin.list present, but not submitted) 
--


-- (/etc/apt/sources.list.d/pbuilder.list present, but not submitted) --


-- (/etc/apt/sources.list.d/skype-stable.list present, but not submitted) --


-- (/etc/apt/sources.list.d/teamviewer.list present, but not submitted) --


-- (/etc/apt/sources.list.d/teamviewer.list.dpkg-dist present, but not 
submitted) --


-- (/etc/apt/sources.list.d/univention.list present, but not submitted) --


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

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

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.12-1+deb10u1
ii  libapt-pkg5.0   1.8.2.1
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libgnutls30 3.6.7-4+deb10u5
ii  libseccomp2 2.3.3-4
ii  libstdc++6  8.3.0-6

Versions of packages apt recommends:
ii  ca-certificates  20200601~deb10u1

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.11-7
ii  dpkg-dev1.19.7
ii  gnupg   2.2.12-1+deb10u1
ii  gnupg1  1.4.23-1
ii  gnupg2  2.2.12-1+deb10u1
ii  powermgmt-base  1.34

-- no debconf information

Bug#931729: apt-mirror: Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror line 829

[Philipp Hahn]

The real problem here is that process_index() assumes that "Files:" is
still used. According to Debian Policy 4.5.0.3
<https://www.debian.org/doc/debian-policy/ch-controlfields.html#debian-source-control-files-dsc>
and <https://manpages.debian.org/testing/dpkg-dev/dsc.5.en.html>
"Files:" is still "mandatory, but reality looks different:

> $ curl -s 
> http://ftp.de.debian.org/debian/dists/buster-updates/main/source/Sources.xz | 
> xz -d | grep-dctrl -S tzdata
> Package: tzdata
> Binary: tzdata
> Version: 2019c-0+deb10u1
> Maintainer: GNU Libc Maintainers 
> Uploaders: Clint Adams , Aurelien Jarno 
> , Adam Conrad 
> Build-Depends: debhelper (>= 9)
> Build-Depends-Indep: po-debconf, rdfind, symlinks
> Architecture: all
> Standards-Version: 4.2.1
> Format: 3.0 (quilt)
> Vcs-Browser: https://salsa.debian.org/glibc-team/tzdata
> Vcs-Git: https://salsa.debian.org/glibc-team/tzdata.git
> Checksums-Sha256:
>  983c27d24d78c52d8f213b1b5800aaa90a171a4f805451b0845752f97c6f924b 2264 
> tzdata_2019c-0+deb10u1.dsc
>  79c7806dab09072308da0e3d22c37d3b245015a591891ea147d3b133b60ffc7c 392087 
> tzdata_2019c.orig.tar.gz
>  cd31deaeee229d45e4f4b973441189e7619ef81679359e9c8b47b2a87aaf6a07 833 
> tzdata_2019c.orig.tar.gz.asc
>  fa8071037767a7dfa054c26621c5079809ee038eddb32a58814faf3541d52d5a 104932 
> tzdata_2019c-0+deb10u1.debian.tar.xz
> Homepage: https://www.iana.org/time-zones
> Package-List: 
>  tzdata deb localization required arch=all
> Directory: pool/main/t/tzdata
> Priority: source
> Section: localization

As this example lacks the "Files:" entry, it is not mirrored by
"apt-mirror".

The real fix is to try "Checksums-Sha256", "Checksum-Sha1" and "Files:"
in that order and use the first existing one.

Philipp
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen

 +49-421-22232-57
 +49-421-22232-99

✉️ h...@univention.de
 https://www.univention.de/

Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876
From 2988f8d91dfbd97667be4224004deea85f888e66 Mon Sep 17 00:00:00 2001
Message-Id: 
<2988f8d91dfbd97667be4224004deea85f888e66.1601439012.git.h...@univention.de>
In-Reply-To: 

References: 

From: Philipp Hahn 
Date: Tue, 29 Sep 2020 12:40:43 +0200
Subject: Support SHA{1,256,512} for Sources too (closes #931729)

The real problem here is that process_index() assumes that "Files:" still used.
According to Debian Policy 4.5.0.3
<https://www.debian.org/doc/debian-policy/ch-controlfields.html#debian-source-control-files-dsc>
and <https://manpages.debian.org/testing/dpkg-dev/dsc.5.en.html> "Files:" is
still "mandatory, but reality looks different:

> $ curl -s 
> http://ftp.de.debian.org/debian/dists/buster-updates/main/source/Sources.xz | 
> xz -d | grep-dctrl -S tzdata
> Package: tzdata
...
> Version: 2019c-0+deb10u1
...
> Standards-Version: 4.2.1
...
> Checksums-Sha256:
>  983c27d24d78c52d8f213b1b5800aaa90a171a4f805451b0845752f97c6f924b 2264 
> tzdata_2019c-0+deb10u1.dsc
>  79c7806dab09072308da0e3d22c37d3b245015a591891ea147d3b133b60ffc7c 392087 
> tzdata_2019c.orig.tar.gz
>  cd31deaeee229d45e4f4b973441189e7619ef81679359e9c8b47b2a87aaf6a07 833 
> tzdata_2019c.orig.tar.gz.asc
>  fa8071037767a7dfa054c26621c5079809ee038eddb32a58814faf3541d52d5a 104932 
> tzdata_2019c-0+deb10u1.debian.tar.xz
...

As this example lacks the "Files:" entry, it is not mirrored by "apt-mirror".

The real fix is to try "Checksums-Sha256", "Checksum-Sha1" and "Files:" in that
order and use the first existing one.
---
 apt-mirror | 76 ++
 1 file changed, 48 insertions(+), 28 deletions(-)

diff --git a/apt-mirror b/apt-mirror
index 16c2118..5d81fcf 100755
--- a/apt-mirror
+++ b/apt-mirror
@@ -720,11 +720,21 @@ foreach ( keys %urls_to_download )
 
 %urls_to_download = ();
 
-open FILES_ALL, ">" . get_variable("var_path") . "/ALL" or die("apt-mirror: 
can't write to intermediate file (ALL)");
-open FILES_NEW, ">" . get_variable("var_path") . "/NEW" or die("apt-mirror: 
can't write to intermediate file (NEW)");
-open FILES_MD5, ">" . get_variable("var_path") . "/MD5" or die("apt-mirror: 
can't write to intermediate file (MD5)");
-open FILES_SHA1, ">" . get_variable("var_path") . "/SHA1" or die("apt-mirror: 
can't write to intermediate file (SHA1)");
-open FILES_SHA256, ">" . get_variable("var_path") . "/SHA256" or 
die("apt-mirror: can't write to intermediate file (SHA256)");
+open

Bug#735197: apt-mirror: clean.sh does nothing

[Philipp Hahn]

The documentation on "clean" is poor: You have to explicitly enable it
by adding one or more lines like this to your /etc/apt/mirror.list:

> clean http://ftp.de.debian.org/debian/

The URL should match the URL used by your other "deb" statements, which
is translated by apt-mirror to a path relative to your "$mirror_path".
apt-mirror will then recursively crawl that directory recursively and
remove any file not mentioned in "$var_path/ALL".

So using something like
> clean http://ftp.de.debian.org/debian/pool/main/d
would only remove files below that starting point.

So this is "not-a-bug" as you have not enabled apt-mirror to do the
crawling.
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen

 +49-421-22232-57
 +49-421-22232-99

✉️ h...@univention.de
 https://www.univention.de/

Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Bug#963697: apt: "apt-key verify" should be documented

[Philipp Hahn]

Package: apt
Version: 1.8.2.1
Severity: wishlist

Neither `apt-key --help` nor `man apt-key` mention the `verify` command.

Please also document if that API is stable - I guess so as
`warn_on_script_usage` is not called for its path.


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

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

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.12-1+deb10u1
ii  libapt-pkg5.0   1.8.2.1
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libgnutls30 3.6.7-4+deb10u4
ii  libseccomp2 2.3.3-4
ii  libstdc++6  8.3.0-6

Versions of packages apt recommends:
ii  ca-certificates  20200601~deb10u1

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.11-7
ii  dpkg-dev1.19.7
ii  gnupg   2.2.12-1+deb10u1
ii  gnupg1  1.4.23-1
ii  gnupg2  2.2.12-1+deb10u1
ii  powermgmt-base  1.34

-- no debconf information

Bug#657401: experiment to build packages out-of-tree

[Philipp Hahn]

This weekend I has a look at this issue and mostly got it working, but
at the end failed on two issues:

1. `dpkg-source --build $path` allows absolute paths. The `.orig.tar`
files must be placed in the directory from where `dpkg-source` is
invoked from.

2. Most packages nowadays use debhelper, so `dh_builddeb` is used to
invoke `dpkg-deb`. The former has the option `--destdir` but that one
clashes with the same option being used by `dh_auto_install`, so it MUST
NOT be passed through `$DH_OPTIONS`.

3. `dpkg-genbuildinfo` and `dpkg-genchanges` both have the option `-u`
to specify a different directory for the build artifacts.

4. The last missing part is the hard-coded path for the `.changes` file:
> 593 my $chg = "../$pva.changes";
`dpkg-buildpackage` has no option to change that.

This is my summary for now as of May 2020.
More details of my experiment at
.

Bug#951252: Acknowledgement (bareos-traymonitor: Still expects /etc/bareos/tray-monitor.conf instead of tray-monitor.d/)

[Philipp Hahn]

Am 13.02.20 um 10:45 schrieb Debian Bug Tracking System:

> sed -e 's,/etc/bareos/tray-monitor.conf,/etc/bareos/tray-monitor.d,' \
>   /usr/share/applications/bareos-tray-monitor.desktop \
>   /etc/xdg/autostart/bareos-tray-monitor.desktop

Uups, correct one is:

> sed -e 's,/etc/bareos/tray-monitor.conf,/etc/bareos,' -i \
>   /usr/share/applications/bareos-tray-monitor.desktop \
>   /etc/xdg/autostart/bareos-tray-monitor.desktop

Philipp

Bug#584472: fop: Wrong package dependency on fontbox instead of fontbox2

[Philipp Hahn]

Package: fop
Version: 1:2.3-2
Followup-For: Bug #584472

Dear Maintainer,

building some PDF documents fail with a stack trace due to the use of
"fontbox.jar" instead of "fontbox2.jar":
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/fontbox/cff/CFFType1Font
> .
> at org.apache.fop.cli.Main.main(Main.java:217)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.fontbox.cff.CFFType1Font
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
> at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 40 more

The command to run FOP looks like this:
> + exec /usr/lib/jvm/java-11-openjdk-amd64/bin/java \
> -classpath /usr/share/java/commons-io.jar:\
> /usr/share/java/avalon-framework.jar:\
> /usr/share/java/serializer.jar:\
> /usr/share/java/xalan2.jar:\
> /usr/share/java/xml-apis.jar:\
> /usr/share/java/batik-all.jar:\
> /usr/share/java/commons-logging.jar:\
> /usr/share/java/xercesImpl.jar:\
> /usr/share/java/xmlgraphics-commons.jar:\
> /usr/share/java/xml-apis-ext.jar:\
> /usr/share/java/fontbox.jar:\
  ^^^
> /usr/share/fop/fop-hyph.jar:\
> /usr/share/java/fop.jar \
> -Djava.awt.headless=true \
> -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog \
> -Dorg.apache.commons.logging.simplelog.defaultlog=INFO 
> org.apache.fop.cli.Main \
> -c ../../../doc-common/fop.xconf \
> -pdf xxx.pdf -fo xxx.fo

My 'fop.xconf' looks like this, which leads to FOP finding CFFType1 fonts:
> 
> 
>   
> 
>   
> /usr/share/fonts/truetype/liberation
> 
  ^^
>   
> 
>   
> 
If I remove that link (and thus the CCFType1 fonts no longer gets
found), I'm able to build my document fine.

Looking at the package dependencies I see this:
> $ dpkg -s libfop-java
> Package: libfop-java
> Source: fop
> Version: 1:2.3-2
> Depends: ..., libfontbox2-java, ...


libfop-java does NOT depends on 'libfontbox-java', which is only
installed on my system because 'libpdfbox-java' depends on it. If I
remove the package (and recursively 'libfontbox-java', running `fop`
outputs the following warning:
> [warning] /usr/bin/fop: Unable to locate fontbox in /usr/share/java

To me this looks like the package correctly depends on fontbox2, but the
`fop` shell script wrapper is still using the previous version.

This is verified by looking at `./fop-core/pom.xml:
> 
>   org.apache.pdfbox
>   fontbox
>   2.0.16
> 

Looking at the Debian package I also see this inconsistency:
> debian/control:18: libfontbox-java,
   ^
> debian/rules:34:ant ... -lib ...:/usr/share/java/fontbox2.jar:... 
> jar-hyphenation
  ^
> debian/rules:36:ant ... -lib ...:/usr/share/java/fontbox2.jar:... 
> javadocs
  ^
> debian/maven.rules:5:org.apache.pdfbox fontbox s/jar/bundle/ s/.*/2.x/ * *
> debian/fop.sh:54:find_jars xml-apis-ext fontbox
 ^

The following command fixes the `fop` script for me:
> sed -e '/find_jars/s/\/&2/' -i /usr/bin/fop


The attached patch fixes the Buster package; package successfully
rebuild in my Buster pbuilder environment.
(Sid build failed due to some new Java issue.)

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

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

Versions of packages fop depends on:
ii  default-jre-headless [java2-runtime-headless] 2:1.11-71
ii  libfop-java   1:2.3-2
ii  openjdk-11-jre-headless [java2-runtime-headless]  11.0.5+10-1~deb10u1

Versions of packages fop recommends:
ii  libsaxon-java  1:6.5.5-12

Versions of packages fop suggests:
pn  fop-doc  

-- no debconf information
diff -urN old/debian/changelog new/debian/changelog
--- old/debian/changelog2018-11-28 09:59:21.00000 +0100
+++ new/debian/changelog2019-12-05 14:09:59.0 +0100
@@ -1,3 +1,10 @@
+fop (1:2.3-2.1) unstable; urgency=low
+
+  * NMU.
+  * Fix wrong dependeny on fontbox{'' -> 2}. Closes: #584472
+
+ -- Philipp Hahn   Thu, 05 Dec 2019 14:09:59 +0100
+
 fop (1:2.3-2) unsta

Bug#865637: pdebuild: please allow to clean the environment

[Philipp Hahn]

   1.19.7

Versions of packages pbuilder recommends:
ii  devscripts  2.19.5+deb10u1
ii  eatmydata   105-7
ii  fakeroot1.23-1
ii  iproute24.20.0-2
ii  sudo1.8.27-1

Versions of packages pbuilder suggests:
pn  cowdancer   
pn  gdebi-core  

-- debconf information excluded
>From 8b1d237f8df78fb371e02951231257cb519c5dbe Mon Sep 17 00:00:00 2001
Message-Id: 
<8b1d237f8df78fb371e02951231257cb519c5dbe.1568030448.git.h...@univention.de>
From: Philipp Hahn 
Date: Mon, 9 Sep 2019 13:29:33 +0200
Subject: [PATCH] Clean pbuilder environment
To: Debian pbuilder maintenance team 

Initialize at least the following environment variables when using `su
-p` to provide a sane environment:
- HOME
- PATH
- USER
- LOGNAME
- SHELL

Also setup shell for user `pbuser`.

As use `eval` inside the chroot environment shell instead of piping in
the command on STDIN.

<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865637>
---
 pdebuild-internal | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/pdebuild-internal b/pdebuild-internal
index b6bd601..3e0 100644
--- a/pdebuild-internal
+++ b/pdebuild-internal
@@ -33,9 +33,6 @@ set -e
 # passwd is needed as well because of useradd and groupadd calls.
 apt-get install -q -y "${APTGETOPT[@]}" pbuilder passwd
 
-# I'm not going to have the same LOGNAME as outside, I'm root.
-export LOGNAME=root
-
 cd "$1"
 shift;
 
@@ -119,7 +116,7 @@ fi
 # TODO: what about id -G output? if other groups than the designated
 # is used, we're stuffed.
 groupadd -g "${BUILDRESULTGID}" -o pbgroup
-useradd -g pbgroup -u "${BUILDRESULTUID}" -d "${HOME}" -o pbuser
+useradd -g pbgroup -u "${BUILDRESULTUID}" -d "${HOME}" -s "${SHELL}" -o pbuser
 
 executehooks "A"
 
@@ -127,13 +124,12 @@ executehooks "A"
 # $DEBBUILDOPTS is expanded here, but split inside the su, to ensure the
 # options are de-quoted (and de-escaped) like pbuilder-buildpackage.
 export DEBBUILDOPTS
-CMD="env PATH=$PATH dpkg-buildpackage -rfakeroot -us -uc $DEBBUILDOPTS"
+CMD="eval env 'PATH=$PATH' 'USER=pbuser' 'LOGNAME=pbuser' 'SHELL=$SHELL' 
'HOME=$HOME' dpkg-buildpackage -rfakeroot -us -uc $DEBBUILDOPTS"
 echo "I: Running $CMD"
 # This command should be ran with current directory as bind-mounted
 # package source directory
-if echo "$CMD" | \
-su -p pbuser; 
-then
+if su -c "$CMD" -p pbuser
+then
 # build was successful
 :
 else
-- 
2.20.1

Bug#933544: hunspell-en-us: Regression: ~13k words less in Buster compared to Stretch

[Philipp Hahn]

Package: hunspell-en-us
Version: 1:2018.04.16-1
Severity: normal

Dear Maintainer,

Stetch: [20070829-7]
$ wc -l /usr/share/hunspell/en_US.*
   466 /usr/share/hunspell/en_US.aff
 62130 /usr/share/hunspell/en_US.dic
 62596 insgesamt

Buster: [2018.04.16-1]
$ wc -l /usr/share/hunspell/en_US.*
   205 /usr/share/hunspell/en_US.aff
 49270 /usr/share/hunspell/en_US.dic
 49475 insgesamt

This results hunspell no longer accepting valid words like
amongst
cryptographic
dereferenced
scalability
scalable

Checking scowl/final/ I find most of them in
english-words.??
but not in
american-words.??

I'm not a native English speaker, but the words listed above are common
enough and should be included in the American dictionary.
Or did I miss something?

For now I installed the package version from Stretch again.

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

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

Versions of packages hunspell-en-us depends on:
ii  dictionaries-common  1.28.1

hunspell-en-us recommends no packages.

Versions of packages hunspell-en-us suggests:
ii  hunspell   1.7.0-2
pn  openoffice.org-hunspell | openoffice.org-core  

-- no debconf information

Bug#931111: linux-image-4.9.0-9: Memory "leak" caused by CGroup as used by pam_systemd

[Philipp Hahn]

Hello,

Am 24.07.19 um 16:41 schrieb Roman Gushchin:
> On Wed, Jul 24, 2019 at 09:12:50AM +0200, Philipp Hahn wrote:
>> Am 24.07.19 um 00:03 schrieb Ben Hutchings:
...
>>> I would say this is a kernel bug.  I think it's the same problem that
>>> this patch series is trying to solve:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_ml_linux-2Dkernel_20190611231813.3148843-2D1-2Dguro-40fb.com_=DwIDaQ=5VD0RTtNlTh3ycd41b3MUw=jJYgtDM7QT-W-Fz_d29HYQ=xNLFAB3gBGB1NCKmQZN-6JNEj_AXfJ3-wYK7IDWJAx4=YfWWnoW-zJdTN0hd1tzzZQlUIUtjv-iBN9Co5rNP5J0=
>>>  
>>>
>>> Does the description there seem to match what you're seeing?
>>
>> Yes, Roman Gushchin replied to me by private mail, which I will quote
>> here to get his response archived in Debian's BTS as well:
...
>>> I've spent lot of time working on this problem, and the final patchset
>>> has been merged into 5.3. It implements reparenting of the slab memory
>>> on cgroup deletion. 5.3 should be much better in reclaiming dying cgroups.
>>>
>>> Unfortunately, the patchset is quite invasive and is based on some
>>> vmstats changes from 5.2, so it's not trivial to backport it to
>>> older kernels.
>>>
>>> Also, there is no good workaround, only manually dropping kernel
>>> caches or disable the kernel memory accounting as a whole.
...
>> So should someone™ bite the bullet and try to backport Romans change to
>> 4.19 (and 4.9)? (those are the kernel versions used by Debian).
>> I'm not a kernel expert myself, especially no mm/cg expert, but have
>> done some work myself in the past, but I would happily pass on the
>> chalice to someone more experienced.
> 
> It's doable from the technical point of view, but I really doubt it's suitable
> for the official stable. The backport will consist of at least 20+ core
> mm/memcontrol patches, so it really feels excessive.
> 
> If you still want to try, you need to backport 205b20cc5a99 first (and the 
> rest
> of the patchset), but it may also depend on some other vmstat changes.

I haven't yet started on trying the backport, but is there some process
to force free those dying cgroups manually?

I have found yet another report of this issue at
<https://github.com/moby/moby/issues/29638#issuecomment-514287415> and
there a cron-job

> 6 */12 * * * root echo 3 > /proc/sys/vm/drop_caches

is recommended. I tried that manually on one of our affected systems and
the number of memory cgroups only dropped marginally from 211_620 to
210_396 after doing the `drop_caches` multiple times and waiting for 10
minutes by now. On that idle system a lot of RAM is gone:
> # free -h
>   totalusedfree  shared  buff/cache   
> available
> Mem:   141G 60G 80G 15M755M 
> 80G

Thanks again for all your help.

Philipp

Bug#931111: linux-image-4.9.0-9: Memory "leak" caused by CGroup as used by pam_systemd

[Philipp Hahn]

Hello Ben,

Am 24.07.19 um 00:03 schrieb Ben Hutchings:
> On Tue, 2019-07-23 at 15:56 +0200, Philipp Hahn wrote:
> [...]
>> - when the job / session terminates, the directory is deleted by
>> pam_systemd.
>>
>> - but the Linux kernel still uses the CGroup to track kernel internal
>> memory (SLAB objects, pending cache pages, ...?)
>>
>> - inside the kernel the CGroup is marked as "dying", but it is only
>> garbage collected very later on
> [...]
>> I do not know who is at fault here, if it is
>> - the Linux kernel for not freeing those resources earlier
>> - systemd for using CGs in a broken way
>> - someone others fault.
> [...]
> 
> I would say this is a kernel bug.  I think it's the same problem that
> this patch series is trying to solve:
> https://lwn.net/ml/linux-kernel/20190611231813.3148843-1-g...@fb.com/
> 
> Does the description there seem to match what you're seeing?

Yes, Roman Gushchin replied to me by private mail, which I will quote
here to get his response archived in Debian's BTS as well:

> Hi Philipp!
> 
> Thank you for the report!
> 
> I've spent lot of time working on this problem, and the final patchset
> has been merged into 5.3. It implements reparenting of the slab memory
> on cgroup deletion. 5.3 should be much better in reclaiming dying cgroups.
> 
> Unfortunately, the patchset is quite invasive and is based on some
> vmstats changes from 5.2, so it's not trivial to backport it to
> older kernels.
> 
> Also, there is no good workaround, only manually dropping kernel
> caches or disable the kernel memory accounting as a whole.
> 
> Thanks!


段熊春  also replied and pointed out his
patch-set <https://patchwork.kernel.org/cover/10772277/>, which solved
the problem for them. I more looks like a "hack", was never applied
upstream as Romans work solved the underlying problem.


So should someone™ bite the bullet and try to backport Romans change to
4.19 (and 4.9)? (those are the kernel versions used by Debian).
I'm not a kernel expert myself, especially no mm/cg expert, but have
done some work myself in the past, but I would happily pass on the
chalice to someone more experienced.

Thanks for all your replies - I really appreciate your help.
Philipp

Bug#931111: linux-image-4.9.0-9: Memory "leak" caused by CGroup as used by pam_systemd

[Philipp Hahn]

Hi,

I analyzed the issue and the problem seems to be CGroup related:

- we're using 'pam_systemd' in "/etc/pam.d/common-session"

- each cron-job / login then creates a new CGroup below
"/sys/fs/cgroup/systemd/user.slice/" while that job / session is running

- when the job / session terminates, the directory is deleted by
pam_systemd.

- but the Linux kernel still uses the CGroup to track kernel internal
memory (SLAB objects, pending cache pages, ...?)

- inside the kernel the CGroup is marked as "dying", but it is only
garbage collected very later on

- until then it adds to memory pressure and very slowly pushed the
system into swap.


I back-ported the patch
<https://www.spinics.net/lists/cgroups/msg20611.html> from Roman
Gushchin to add some extra debugging, which indeed shows a large number
of "dying" cgroups:

> # find /sys/fs/cgroup/memory -name cgroup.stat -exec grep 
> '^nr_dying_descendants [^0]'  {} +
>   /sys/fs/cgroup/memory/cgroup.stat:nr_dying_descendants 360
>   /sys/fs/cgroup/memory/user.slice/cgroup.stat:nr_dying_descendants 320
>   
> /sys/fs/cgroup/memory/user.slice/user-0.slice/cgroup.stat:nr_dying_descendants
>  303
>   /sys/fs/cgroup/memory/system.slice/cgroup.stat:nr_dying_descendants 40
> # grep ^memory /proc/cgroups 
>   memory  10  452 1

Removing "pam_systemd" from PAM makes the problem go away.

Later Debain kernels are compiled with "CONFIG_MEMCG_KMEM=y", which
prompted me to add "cgroup.memory=nokmem" to the kernel command line.
This also seems to reduce the problem, but I'm not 100% convinced that
it really improves the situation.


I do not have a very good reproducer, but creating a cron-job with just
> * * *  * *  root  dd if=/dev/urandom of=/var/tmp/test-$$ count=1 >/dev/null

will most often increase the number of dying CGs every minute by one.


I do not know who is at fault here, if it is
- the Linux kernel for not freeing those resources earlier
- systemd for using CGs in a broken way
- someone others fault.

Clearly this is not good and I would like to receive some feedback on
what could be done top solve this issue, as running cron jobs is user
exploitable and can be used to DoS the system.
While looking for existing bug reports I stumbled over 912411 in Debian,
which also claims that there is a CG related leak - with Linux 4.19.x.

Should "pam_systemd" maybe do something like this before deleting the CG
directory:
> echo 0 >/sys/fs/cgroup/memory/.../memory.force_empty


Some more details are available at our bug-tracker at
<https://forge.univention.org/bugzilla/show_bug.cgi?id=49614#c5>.

Debian-Bugs:
* <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=93>
* <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912411>

Sincerely
Philipp
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
h...@univention.de

https://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876
From 0679dee03c6d706d57145ea92c23d08fa10a1999 Mon Sep 17 00:00:00 2001
Message-Id: <0679dee03c6d706d57145ea92c23d08fa10a1999.1562083574.git.h...@univention.de>
From: Roman Gushchin 
Date: Wed, 2 Aug 2017 17:55:29 +0100
Subject: [PATCH] cgroup: keep track of number of descent cgroups

Keep track of the number of online and dying descent cgroups.

This data will be used later to add an ability to control cgroup
hierarchy (limit the depth and the number of descent cgroups)
and display hierarchy stats.

Signed-off-by: Roman Gushchin 
Suggested-by: Tejun Heo 
Signed-off-by: Tejun Heo 
Cc: Zefan Li 
Cc: Waiman Long 
Cc: Johannes Weiner 
Cc: kernel-t...@fb.com
Cc: cgro...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Philipp Hahn 
Url: https://www.spinics.net/lists/cgroups/msg20611.html
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4922,6 +4922,18 @@ static struct cftype cgroup_dfl_base_fil
 	{ }	/* terminate */
 };
 
+static int cgroup_stat_show(struct seq_file *seq, void *v)
+{
+	struct cgroup *cgroup = seq_css(seq)->cgroup;
+
+	seq_printf(seq, "nr_descendants %d\n",
+		   cgroup->nr_descendants);
+	seq_printf(seq, "nr_dying_descendants %d\n",
+		   cgroup->nr_dying_descendants);
+
+	return 0;
+}
+
 /* cgroup core interface files for the legacy hierarchies */
 static struct cftype cgroup_legacy_base_files[] = {
 	{
@@ -4964,6 +4976,10 @@ static struct cftype cgroup_legacy_base_
 		.write = cgroup_release_agent_write,
 		.max_write_len = PATH_MAX - 1,
 	},
+	{
+		.name = "cgroup.stat",
+		.seq_show = cgroup_stat_show,
+	},
 	{ }	/* terminate */
 };
 
@@ -5063,9 +5079,15 @@ static void css_release_work_fn(struct w
 		if (ss->css_released)
 			ss->css_released(css);
 	} else {
+		st

Bug#931111: linux-image-4.9.0-9-amd64: Memory leak - fixed with 4.9.174 (or earlier)

[Philipp Hahn]

Package: linux-image-4.9.0-9-amd64
Version: 4.9.168-1+deb9u3
Severity: important

Dear fellow DDs,

we (Univention GmbH) have several reports of a memory leak wtih 4.9.168
as shipped by Debian (and used by us):

https://help.univention.com/t/memoryleak-auf-slave-contoller/11892/8
https://forge.univention.org/bugzilla/show_bug.cgi?id=49614

I was not yet able to pin-point the area where the leak occurs, but the
bug seemd to be fixed after switching to 4.9.174.a( I hand-applied the
incremental patches on top of Debians 4.9.168 fixing the rejects and
enabled KMEMLEAK.) The fix can be earlied than 174; I chose that version
from a hint given by one of our customers, who reported 174 to be fixed.

4.9.144 was also fine (at leat no leak was observed).

Stopping all processes did NOT free the memory again.
My interpretation of this is, that the leak is not in user-space, but in
kernel-land.

 does not
show any leaks so far.

One of the affected systems is a system of us, where I can do some
limited testing, e.g. install self-compiled kernel version.
As I don't have a (simple) reproducer running `git bisect` is somehow
inefficient.
So if you have any idea on what to test or where I can help just ask.


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

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

Versions of packages linux-image-4.9.0-9-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod23-2
ii  linux-base  4.5

Versions of packages linux-image-4.9.0-9-amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2.3

Versions of packages linux-image-4.9.0-9-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta3-5+deb9u1A~4.3.3.201812061306
pn  linux-doc-4.9   

Versions of packages linux-image-4.9.0-9-amd64 is related to:
ii  firmware-amd-graphics 20161130-5
ii  firmware-atheros  20161130-5
ii  firmware-bnx2 20161130-5
ii  firmware-bnx2x20161130-5
ii  firmware-brcm8021120161130-5
ii  firmware-cavium   20161130-5
pn  firmware-intel-sound  
ii  firmware-intelwimax   20161130-5
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20161130-5
ii  firmware-libertas 20161130-5
ii  firmware-linux-nonfree20161130-5
ii  firmware-misc-nonfree 20161130-5
ii  firmware-myricom  20161130-5
ii  firmware-netxen   20161130-5
ii  firmware-qlogic   20161130-5
ii  firmware-realtek  20161130-5
pn  firmware-samsung  
pn  firmware-siano
ii  firmware-ti-connectivity  2016113

Bug#930410: scribus: Security-Update of Ghostscript 9.26a~dfsg-0+deb9u3 breaks scribus in Debian Stretch

[Philipp Hahn]

Package: scribus
Version: 1.4.6+dfsg-4
Severity: normal

Dear Maintainer,

when inserting an QR-Code rendering fails:

> $ gs  -q -dNOPAUSE -dNODISPLAY -dBATCH -dDELAYBIND -g2381x3368 -r288 
> -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -c 0 0 translate 
> -sTraceFile=/home/phahn/.scribus//ps.out /usr/lib/scribus/import.prolog 
> /home/phahn/.scribus/bcode.ps -c flush cfile closefile quit
> Error: /undefined in GS_PDF_ProcSet
> Operand stack:
>false
> Execution stack:
>%interp_exit   .runexec2   --nostringval--   --nostringval--   
> --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   
> --nostringval--   false   1   %stopped_push   2044   1   3   %oparray_pop   
> 2043   1   3   %oparray_pop   2024   1   3   %oparray_pop   1884   1   3   
> %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval-- 
>   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
> Dictionary stack:
>--dict:1235/1684(ro)(G)--   --dict:0/20(G)--   --dict:78/200(L)--
> Current allocation mode is global
> Current file position is 2202
> GPL Ghostscript 9.26: Unrecoverable error, exit code 1

'GS_PDF_ProcSet' was removed by an security update of Ghostscript:


> * Hide pdfdict and GS_PDF_ProcSet (internal stuff for the PDF interp) 
> (CVE-2019-3839)

There are already multiple issues within Scribus caused by newer GS:




But no for "GS_PDF_ProcSet" so far.
I'm no PostScript guru, but pehaps the following links help to find a fix:





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

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

Versions of packages scribus depends on:
ii  ghostscript  9.26a~dfsg-0+deb9u3
ii  libc62.24-11+deb9u4
ii  libcairo21.14.8-1
ii  libcups2 2.2.1-8+deb9u3
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libhyphen0   2.8.8-5
ii  libjpeg62-turbo  1:1.5.1-2
ii  liblcms2-2   2.8-4+deb9u1
ii  libpodofo0.9.4   0.9.4-6
ii  libpython2.7 2.7.13-2+deb9u3
ii  libqt4-network   4:4.8.7+dfsg-11
ii  libqt4-xml   4:4.8.7+dfsg-11
ii  libqtcore4   4:4.8.7+dfsg-11
ii  libqtgui44:4.8.7+dfsg-11
ii  libstdc++6   6.3.0-18+deb9u1
ii  libtiff5 4.0.8-2+deb9u4
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2
ii  python-tk2.7.13-1
ii  scribus-data 1.4.6+dfsg-4
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages scribus recommends:
ii  cups-bsd2.2.1-8+deb9u3
ii  fonts-dejavu2.37-1
ii  fonts-liberation1:1.07.4-2
ii  hyphen-pt-pt [hyphen-hyphenation-patterns]  1:5.2.5-1
ii  icc-profiles-free   2.0.1+dfsg-1
ii  xfonts-scalable 1:1.0.3-1.1

Versions of packages scribus suggests:
pn  icc-profiles   
pn  scribus-doc
pn  scribus-template   
pn  texlive-latex-recommended  

-- no debconf information

Bug#930078: ITP: utf8.h -- header files providing utf8-ready string handing

[Philipp Hahn]

Am 06.06.19 um 17:37 schrieb Steffen Moeller:
> Package: wnpp
> Severity: wishlist
> Owner: Steffen Moeller 
> 
> * Package name: utf8.h
>   Upstream Author : Neil Henning
> * URL : https://github.com/sheredom/utf8.h
> * License : Unlicense-Licensed
>   Programming Lang: C/C++
>   Description : header files providing utf8-ready string handing
   ^l?

Bug#919977: security-tracker: https://security-tracker.debian.org/tracker/data/json returns stale data

[Philipp Hahn]

Package: security-tracker
Severity: important

Dear Maintainer,

the JSON stream of the Debian Security Bug Tracker seems to report stale
data since the beginning of January 2019:

$ curl -I https://security-tracker.debian.org/tracker/data/json
HTTP/2 200
date: Mon, 21 Jan 2019 08:10:06 GMT
...
content-length: 19836218
last-modified: Wed, 02 Jan 2019 19:49:17 GMT
expires: Wed, 02 Jan 2019 20:57:34 GMT

This breaks our process to monitor the Debian Security updates by
processing the DSAs in a machine-readable format.

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

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

Bug#915636: python3-virtualenv: incompatible with python3-pip 18.1 - AttributeError pip.main - please upgrade to 16.1.0

[Philipp Hahn]

Package: python3-virtualenv
Version: 15.1.0+ds-1
Followup-For: Bug #915636

Dear Maintainer,

find attached my NMU .debian.tar using the updated 16.1.0 version.
As I found no documentation what you +ds version removed from the
upstream TAR ball, I'm using the pristine upstream TAR ball.

Upstream moved most files to the src/ sub-directory, so all 3 patches
did no longer apply and several files in debian/ need updating.

Whith that new version I'm again able to use "virtualenv".
-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages python3-virtualenv depends on:
ii  python-pip-whl 9.0.1-2
ii  python33.5.3-1
ii  python3-pkg-resources  33.1.1-1

python3-virtualenv recommends no packages.

python3-virtualenv suggests no packages.

-- no debconf information


python-virtualenv_16.1.0-0.1.debian.tar.xz
Description: application/xz

Bug#915636: python3-virtualenv: incompatible with python3-pip 18.1 - AttributeError pip.main - please upgrade to 16.1.0

[Philipp Hahn]

Package: python3-virtualenv
Version: 15.1.0+ds-1.1
Severity: important

Dear Maintainer,

mybe I miss the obvious, but running "virtualenv" no longer works for me:

# virtualenv -p /usr/bin/python3.6 ./py36 -v
...
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/virtualenv.py", line 2375, in 
> main()
>   File "/usr/lib/python3/dist-packages/virtualenv.py", line 724, in main
> symlink=options.symlink)
>   File "/usr/lib/python3/dist-packages/virtualenv.py", line 992, in 
> create_environment
> download=download,
>   File "/usr/lib/python3/dist-packages/virtualenv.py", line 922, in 
> install_wheel
> call_subprocess(cmd, show_stdout=False, extra_env=env, stdin=SCRIPT)
>   File "/usr/lib/python3/dist-packages/virtualenv.py", line 817, in 
> call_subprocess
> % (cmd_desc, proc.returncode))
> OSError: Command /home/phahn/py36/bin/python3.6 - setuptools pkg_resources 
> pip wheel failed with error code 1


/usr/lib/python3/dist-packages/virtualenv.py:876
> SCRIPT = textwrap.dedent("""
...
> import pip
...
> sys.exit(pip.main(args))


>>> import pip
>>> pip.__version__
'18.1'
>>> pip.main
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: module 'pip' has no attribute 'main'

According to  pip.main is an internal
details and should not be called as it is not part of the API.

If I add '--no-wheel --no-pip  --no-setuptools' to the command line, the
command at least does not exit with an error.

According to  version 16.1.0 fixes it:
> upgrade pip from 10.0.1 to 18.1

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

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

Versions of packages python3-virtualenv depends on:
ii  python-pip-whl 18.1-2
ii  python33.7.1-2
ii  python3-distutils  3.7.1-1
ii  python3-pkg-resources  40.6.2-1

python3-virtualenv recommends no packages.

python3-virtualenv suggests no packages.

-- no debconf information

Bug#886358: chromium: Enable Hangouts screensharing extension

[Philipp Hahn]

unarchive 886358
reopen 886358
thanks

Sorry for re-opeing this bug, but it cost me some time to find that
Debian disables the shreen sharing extention in its build of chromium.

> This is the intended default configuration.  For those that would like
> it enabled in their version, the suggested patch is correct.

Can you at least clarify *why* that feature is disabled? Neither my web
search nor looking in the Debian source package found any hint:
* Does it make the package non-free/contrib
* Is it an security issue?
* or is there some other technical reason to disable it in Debian?

After re-compiling chromium with that extension enabled I was finally
able to use the screen sharing extension with my colleges.


Also (a different issue): NEW still contains this text:
> chromium-browser (55.0.2883.75-4) unstable; urgency=medium
> 
>   * External extensions are now disabled by default.  Chromium will only load
> extensions that are explicitly specified with the --load-extension command
> line option passed into CHROMIUM_FLAGS.  See the chromium-lwn4chrome
> package for an example of how to do this.
>   * You can also use the --enable-remote-extensions command line argument to
> chromium, which will bypass this restriction.

But:
> cat /etc/chromium.d/extensions 
> # remote extensions on by default
> export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-remote-extensions"

So this looks out-of-date. Please correct me if I'm wrong.

Thanks.
Philipp
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
h...@univention.de

http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Bug#898606: piuparts: multiple conflicting versions by `apt-cache show` in piuparts-depends-dummy

[Philipp Hahn]

Source: piuparts
Version: 0.85
Severity: normal
Tags: patch

Dear Maintainer,

we're using "piuparts" to test our own packages. It sometimes happens
that out Packages files contain multiple versions of a package. Using
`apt-cache show` list all of them leading to the situation, where the
generated "piuparts-depends-dummy" has multiple dependencies on the same
package with different versions:

  Depends: pkg (= 1), pkg (= 2)

You should use `apt-cache show --no-all-versions` which only lists the
version with the highest priority.

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 71c0431c4395d8265efee551e29fae3a5635355c Mon Sep 17 00:00:00 2001
Message-Id: 
<71c0431c4395d8265efee551e29fae3a5635355c.1526279446.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Mon, 14 May 2018 08:30:39 +0200
Subject: [PATCH] piuparts: Only depend on latest version
Organization: Univention GmbH, Bremen, Germany

It may happen that the Packages files contain multiple versions of a
package. Using `apt-cache show` list all of them leading to the
situation, where the generated "piuparts-depends-dummy" has multiple
dependencies on the same package with different versions:

  Depends: pkg (= 1), pkg (= 2)

Use `apt-cache show --no-all-versions` to only lists the version with
the highest priority.
---
 piuparts.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/piuparts.py b/piuparts.py
index 7f5c0f77..6c61b07e 100644
--- a/piuparts.py
+++ b/piuparts.py
@@ -1180,7 +1180,7 @@ class Chroot:
 known_packages = []
 new_packages = []
 for name in packages:
-(status, output) = self.run(["apt-cache", "show", name],
+(status, output) = self.run(["apt-cache", "show", 
"--no-all-versions", name],
 ignore_errors=True)
 # apt-cache reports status for some virtual packages and packages
 # in status config-files-remaining state without installation
@@ -2292,7 +2292,7 @@ def install_purge_test(chroot, chroot_state, 
package_files, packages, extra_pack
 else:
 # We have package names.  Use apt to get all their control
 # information.
-apt_cache_args = ["apt-cache", "show"]
+apt_cache_args = ["apt-cache", "show", "--no-all-versions"]
 if os.environ["PIUPARTS_DISTRIBUTION"] in ["lenny"]:
 # apt-cache in lenny does not accept version-qualified packages
 apt_cache_args.extend(unqualify(packages))
-- 
2.11.0

Bug#820129: grub2: Disallow booting unsigned kernels when Secure Boot is enabled

[Philipp Hahn]

Hello,

Am 15.04.2018 um 23:03 schrieb Steve McIntyre:
> On Thu, Apr 12, 2018 at 05:10:38PM +0100, Luca Boccassi wrote:
>> On Thu, 2018-04-12 at 15:58 +0100, Steve McIntyre wrote:
>>> [ Note cc to the d-efi list. SB is finally in progress after last
>>>   week's sprint! ]
>>>
>>> Very belated, it's time we discussed this.
...
>>> This looks like one way of doing this. Philipp Hahn is suggesting
>>> that
>>> we just don't include the "linux" module in our signed grub
>>> build. That's simpler, but potentially causes problems elsewhere,
>>> e.g. "it gets a bit nasty to try and dynamically switch between linux
>>> and linuxefi in live-build". So, let's discuss - we need to agree our
>>> policy and decide the best mechanism here. Go...!
>>
>> The issues I see is that until now pretty much everywhere "linux" is
>> used in grub.cfg.
>>
>> This can be solved easily, and indeed Philipp has already done it, for
>> local installations - the problems arise when building images.
>>
>> At least in live-build (not sure about debootstrap/live-wrapper?),
>> users can provide their own grub.cfg. Personally I've never seen anyone
>> use anything but "linux" in the menuentry (eg: Kali [2]).
>>
>> So I'd need to do something like this [1] in live-build:
>>
>> sed -i "s|linux\(\s\+/\w\+/vmlinuz\)|linuxefi\1|" \
>>binary/boot/grub/grub.cfg
>> sed -i "s|initrd\(\s\+/\w\+/initrd\)|initrdefi\1|" \
>>binary/boot/grub/grub.cfg
>>
>> With the risk of randomly breaking with weird user's grub.cfg :-/
>>
>> I'd really like to make the process as transparent as possible for
>> users, as there are already enough hoops to jump through as-is to get
>> secure boot working.
>>
>> I have been using the patch from this bug in production for about a
>> year as an alternative in the downstream distro at $work, and it seems
>> to work fine.

FYI: We (Univention) have been running with "linux" removed for >2 years.

>> On the other hand, I imagine it's easier to verify that nothing is
>> broken by removing the "linux" module rather than using this patch. So
>> there's the other side of the coin.

I see 2 use-cases here:

1. make it as easiest as possible to install Debian even on systems
where Secure Boot is enabled by default by providing a signed GRUB which
loads anything.

2. have a more secure setup where everything must be signed.

We chose to be on the save side and thus removed "linux". But you patch
seems to be small enough to verify and actually looks quite nice: With
it both "linux" and "linuxefi" can be used, which has an appeal.

So I'm okay to switch to your implementation.

@steve: I'm currently busy with work and family and don't have that much
time until next weekend. I havenn't yet checked back for the status of
the signing box, but how do you want to proceed with GRUB: I haven't yet
done a complete test build of my patched packages with a self-created
set of key to check that everything work as expected. Shall we continue
working on my GIT repo or how do you want to get the required changed in
your repo?

Thanks in advance and thanks to everyone working on this.
Philipp

Bug#884029: library package with conffile and SONAME?

[Philipp Hahn]

Hello,

some library packages like "libtirpc1" (just my example here) contain a
conffile like "/etc/netconfig". Naturally they must conflict with their
successor "libtirpc3" as they contain the same file name. Currently it
does not: 

1. Either I could add the "Conflicts: libtirpc1" but that would render
the rename of the package following the SONAME change useless as they
will never be co-installed anyway then.

2. Or I could add a "Replaces: libtirpc1 (<< 0.2.5-1.2)" to silence dpkg
and allow libtirpc3 to overwrite that with which still has the same
format and content. This has the drawback that anyone later on
installing 1 after 3 will get the error from dpkg as 1 is not allowed to
replace the file from 3.

3. And/or I can create an additional package "libtirpc-common" to just
contain that single conffile and make "libtirpc[13]" both depend on it.
This last option is AFAIK frowned upon as it creates yet another package
for a single file.

So whats the current best practice?

Philipp

Bug#892654: nfs-kernel-server: Mismatching [RPC]SVCGSSDOPTS defaults

[Philipp Hahn]

Package: nfs-kernel-server
Version: 1:1.3.4-2.1
Severity: normal

Dear Maintainer,

The options for rpc.svcgssd are not used:

debian/nfs-kernel-server.default:
> 18 # Options for rpc.svcgssd.
> 19 RPCSVCGSSDOPTS=""
 ^^^
systemd/nfs-config.service:
> 13 ExecStart=/usr/lib/systemd/scripts/nfs-utils_env.sh
debian/nfs-utils_env.sh:
>  7 [ -r /etc/default/nfs-kernel-server ] && . /etc/default/nfs-kernel-server
> 15 echo RPCSVCGSSDARGS=\"$RPCSVCGSSDOPTS\"
  ^^^   ^^^
> 16 } > /run/sysconfig/nfs-utils
systemd/rpc-svcgssd.service:
> 18 EnvironmentFile=-/run/sysconfig/nfs-utils
> 20 ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS
  ^^^

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

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

Bug#892323: busybox: Broken DHCP setup with multiple gateways

[Philipp Hahn]

Package: busybox
Version: 1:1.22.0-19+b3
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Trying a installation in our local network.

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

DHCP is configured to server *two* IPv4 gateways.

   * What was the outcome of this action?

Debian-Installer fails to setup IPv4 networking.
Claims that "no routers" were configured.

   * What outcome did you expect instead?

A working network configuration.

See attached patch.

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

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

Versions of packages busybox depends on:
ii  libc6  2.24-11+deb9u1

busybox recommends no packages.

busybox suggests no packages.

-- no debconf information
>From ac604eb2e37cb67a1133cc9bf78287c755fc70a4 Mon Sep 17 00:00:00 2001
Message-Id: 
<ac604eb2e37cb67a1133cc9bf78287c755fc70a4.1520505761.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Thu, 8 Mar 2018 11:27:59 +0100
Subject: [PATCH] Allow multiple routers
Organization: Univention GmbH, Bremen, Germany

According to <https://udhcp.busybox.net/README.udhcpc> "$router" is "A
*list* of routers", so do not quote it to allow IFS splitting.

Running the following command by hand shows the error:
  udhcpc -i ens3 -V d-i -T 1 -t 59 -O router -f
...
  ip: an inet address is expected rather than "192.168.10.13 192.168.10.14"

Fixes: 574355f4380bd7ede11e5110fffefb51f1294b0b
Cc: Otavio Salvador <ota...@debian.org>
---
 debian/tree/busybox-udeb/etc/udhcpc/default.script | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/debian/tree/busybox-udeb/etc/udhcpc/default.script 
b/debian/tree/busybox-udeb/etc/udhcpc/default.script
index a47bdae7e..3c33effd3 100755
--- a/debian/tree/busybox-udeb/etc/udhcpc/default.script
+++ b/debian/tree/busybox-udeb/etc/udhcpc/default.script
@@ -59,7 +59,7 @@ case "$1" in
 
bound|renew)
do_hostname
-   
+
ip -4 addr add "$ip/$subnet" dev "$interface"
 
if [ -n "$mtu" ]; then
@@ -69,8 +69,10 @@ case "$1" in
# special case for /32 subnets, use onlink when adding routes
[ ".$subnet" = .255.255.255.255 ] \
 && onlink=onlink || onlink=
-   for r in "$router"; do
-   ip -4 route add default via "$r" $onlink
+   metric=0
+   for r in $router; do
+   ip -4 route add default via "$r" $onlink metric $metric
+   metric=$((1+$metric))
done
 
do_resolv_conf
-- 
2.11.0

Bug#891328: python-debian: DebFile.changelog() fails to parse DebianVersion (in some cases)

[Philipp Hahn]

Package: python-debian
Version: 0.1.30
Severity: normal

Dear fellow Maintainer,

   * What led up to the situation?

I wrote a small Python tool to comapre the debian/changelog of two Debian
binary package files. It fails on "apache2-suexec-custom" as currently
available in Debian-Sid.

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

>apt download apache2-suexec-custom
>python -c 'from debian.debfile import DebFile
>from sys import argv
>for block in DebFile(argv[1]).changelog():
>   print(block.version)' apache2-suexec-custom_*.deb

   * What was the outcome of this action?

>2.4.29-2
...
>2.0.37-1
>Traceback (most recent call last):
>  File "", line 1, in 
>  File "/usr/lib/python2.7/dist-packages/debian/changelog.py", line 103, in 
> _get_version
>return Version(self._raw_version)
>  File "/usr/lib/python2.7/dist-packages/debian/debian_support.py", line 213, 
> in __init__
>super(AptPkgVersion, self).__init__(version)
>  File "/usr/lib/python2.7/dist-packages/debian/debian_support.py", line 111, 
> in __init__
>self.full_version = version
>  File "/usr/lib/python2.7/dist-packages/debian/debian_support.py", line 137, 
> in __setattr__
>self._set_full_version(str(value))
>  File "/usr/lib/python2.7/dist-packages/debian/debian_support.py", line 116, 
> in _set_full_version
>raise ValueError("Invalid version string %r" % version)
>ValueError: Invalid version string '2.0.37+cvs.JCW_PRE2_2037-1'

The underscore character '_' is not valid in
debian/debian_support.py:105
> 105  "(?P[A-Za-z0-9.+:~-]+?)"

   * What outcome did you expect instead?

No traceback.


Please travel back in time and fix the version number of
"apache2-suexec-custom" before it gets uploaded to Debian ;-)

Seriously: I see several options

- add a LazyVersion like
from debian.debian_support import Version
class NonConformantVersion(Version):
re_valid_version = re.compile(
r"^((?P\d+):)?"
 "(?P[A-Z_a-z0-9.+:~-]+?)"
 "(-(?P[A-Za-z0-9+.~]+))?$")
import debian.changelog
debian.changelog.Version = NonConformantVersion

- add an option to ignore invalid/unparseable changelog blocks

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

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

Versions of packages python-debian depends on:
ii  python  2.7.13-2
ii  python-chardet  2.3.0-2
ii  python-six  1.10.0-3

Versions of packages python-debian recommends:
ii  python-apt  1.4.0~beta3

Versions of packages python-debian suggests:
ii  gpgv  2.1.18-8~deb9u1

-- no debconf information
#!/usr/bin/python2.7
"""
Compare Debian package changelogs
"""

from __future__ import print_function
from optparse import OptionParser
from debian.debfile import DebFile, DebError
from debian.debian_support import Version
import debian.changelog
from difflib import unified_diff
import re


# Work-around Debian Bug allowing '_' in version string
# /usr/lib/python2.7/dist-packages/debian/debian_support.py:103
class NonConformantVersion(Version):
re_valid_version = re.compile(
r"^((?P\d+):)?"
r"(?P[A-Z_a-z0-9.+:~-]+?)"
r"(-(?P[A-Za-z0-9+.~]+))?$")


debian.changelog.Version = NonConformantVersion


class DiffError(Exception):
pass


def load(deb):
try:
debfile = DebFile(deb)
changelog = debfile.changelog()
return changelog
except (DebError, EnvironmentError):
raise DiffError(deb)


def render(changelog, common_version):
for block in changelog:
yield '{0.version} [{0.date}] {0.author}:'.format(block)
for change in block.changes():
yield change
if block.version == common_version:
break


def diff(old_deb, new_deb):
old_changelog = load(old_deb)
old_versions = set(block.version for block in old_changelog)

new_changelog = load(new_deb)
new_versions = set(block.version for block in new_changelog)

common_version = max(old_versions & new_versions)

old = list(render(old_changelog, common_version))
new = list(render(new_changelog, common_version))
return unified_diff(old, new, old_deb, new_deb, lineterm='')


def main():
usage = '%prog <1.deb> <2.deb>'
parser = OptionParser(usage=usage, description=__doc__)
opt, args = parser.parse_args()
try:
old_deb, new_deb = args
except ValueError:
parser.error('Expecting exactly 2 

Bug#890876: python-apt: Provide API for versioned provides

[Philipp Hahn]

Package: python-apt
Version: 1.4.0~beta3
Severity: whistlist

Dear Maintainer,

I'm using python-apt to analyse inter-package-dependencies and just
stumbled over "python-cffi-backend", which already uses versioned
Provdies¹ in Debian-Stretch:

import apt
cache = apt.Cache()
pkg = cache['python-cffi-backend']
cand = pkg.candidate
print(cand.provides)
# ['python-cffi-backend-api-min', 'python-cffi-backend-api-max', 
'python-cffi-backend-api-9729']
print(cand.record['Provides'])
# 'python-cffi-backend-api-9729, python-cffi-backend-api-max (= 10239), 
python-cffi-backend-api-min (= 9729)'

As a temporary work-around I'm now using

for (providesname, providesver, version) in cand._cand.provides_list:
print(providesname, providesver)
# ('python-cffi-backend-api-min', '9729')
# ('python-cffi-backend-api-max', '10239')
# ('python-cffi-backend-api-9729', None)

python-apt should have an "official" API to access the version
information.

¹: : debian-policy: 
document versioned Provides

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

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

Versions of packages python-apt depends on:
ii  dirmngr2.1.18-8~deb9u1
ii  gnupg  2.1.18-8~deb9u1
ii  libapt-inst2.0 1.4.8
ii  libapt-pkg5.0  1.4.8
ii  libc6  2.24-11+deb9u1
ii  libgcc11:6.3.0-18
ii  libstdc++6 6.3.0-18
ii  python 2.7.13-2
ii  python-apt-common  1.4.0~beta3

Versions of packages python-apt recommends:
ii  iso-codes3.75-1
ii  lsb-release  9.20161125
ii  xz-utils 5.2.2-1.2+b1

Versions of packages python-apt suggests:
ii  apt 1.4.8
pn  python-apt-dbg  
ii  python-apt-doc  1.4.0~beta3

-- no debconf information

Bug#609427: [PATCH] Bug #609427: Disable bind-mount propagation

[Philipp Hahn]

If multiple "pbuilder"s run in parallel using --bindmounts, the first
environment inherits any mounts from the second environment:

$ mount | grep --color /$BUILDTMP

> /proc on /$BUILDTMP/cow.10949/proc type proc
> tmpfs on /$BUILDTMP/cow.10949/run/shm type tmpfs
> /dev/pts on /$BUILDTMP/cow.10949/dev/pts type devpts
> /dev/md0 on /$BUILDTMP/cow.10949/tmp/apt-8804 type ext4
> /dev/md0 on /$BUILDTMP/cow.10949/$BUILDTMP type ext4
This is the first environment (PID=10949).

> /proc on /$BUILDTMP/cow.11327/proc type proc (rw,relatime)
> tmpfs on /$BUILDTMP/cow.11327/run/shm type tmpfs
> /dev/pts on /$BUILDTMP/cow.11327/dev/pts type devpts
> /dev/md0 on /$BUILDTMP/cow.11327/tmp/apt-9148 type ext4
> /dev/md0 on /$BUILDTMP/cow.11327/$BUILDTMP type ext4
This is the second environment (PID=11327), ...

> /proc on /$BUILDTMP/cow.10949/$BUILDTMP/cow.11327/proc type proc
> tmpfs on /$BUILDTMP/cow.10949/$BUILDTMP/cow.11327/run/shm type tmpfs
> /dev/pts on /$BUILDTMP/cow.10949/$BUILDTMP/cow.11327/dev/pts type devpts
> /dev/md0 on /$BUILDTMP/cow.10949/$BUILDTMP/cow.11327/tmp/apt-9148 type ext4
> /dev/md0 on /$BUILDTMP/cow.10949/$BUILDTMP/cow.11327/$BUILDTMP type ext4
..., which also got propagated into the first environment!

This is done by default with "pdebuild --use-pdebuild-internal"!

Use "mount --make-private" on Linux to prevent the propagation of later
mounts into previous environments.

This requires git:util-linux v2.23-rc1~351; Debian-Jessie has 2.25.2-6,
but Wheezy only has 2.20.1-5.3
---
 pbuilder-modules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pbuilder-modules b/pbuilder-modules
index 73e38fe..9c7e0f5 100644
--- a/pbuilder-modules
+++ b/pbuilder-modules
@@ -453,7 +453,7 @@ function mountproc () {
 mount -t firmlink /servers "$BUILDPLACE/servers" || true
 mounted[${#mounted[@]}]="$BUILDPLACE/servers"
 fi
-MOUNTPARAMS="-obind"
+MOUNTPARAMS="-obind --make-private"
 [ "$DEB_BUILD_ARCH_OS" = "kfreebsd" ] && MOUNTPARAMS="-t nullfs"
 for mnt in $BINDMOUNTS; do
 mntpoint=${mnt#*:}
-- 
2.11.0

Bug#863724: python-debian: Fix codename for Debian 1.2 'Rex'

[Philipp Hahn]

Package: python-debian
Version: 0.1.27
Severity: minor
Tags: patch

Dear Maintainer,

According to
<https://www.debian.org/doc/manuals/debian-faq/ch-ftparchives#s-sourceforcodenames>
the codename of Debian 1.2 was 'Rex'

$ python -c 'from debian.debian_support import intern_release;print 
intern_release("rex")'
None

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

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

Versions of packages python-debian depends on:
ii  python-chardet  2.3.0-1
ii  python-six  1.10.0-3
pn  python:any  

Versions of packages python-debian recommends:
ii  python-apt  0.9.3.12

Versions of packages python-debian suggests:
ii  gpgv  1.4.18-7+deb8u3

-- no debconf information
>From a97b7883a8fdf75210087294aae7d084bad00d1d Mon Sep 17 00:00:00 2001
Message-Id: <a97b7883a8fdf75210087294aae7d084bad00d1d.1496151946.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Tue, 30 May 2017 15:44:02 +0200
Subject: [PATCH] Fix codename of 'Rex'
Organization: Univention GmbH, Bremen, Germany

According to
<https://www.debian.org/doc/manuals/debian-faq/ch-ftparchives#s-sourceforcodenames>
the codename of Debian 1.2 was 'Rex'
---
 lib/debian/debian_support.py | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/lib/debian/debian_support.py b/lib/debian/debian_support.py
index 4de36b7..fccc310 100644
--- a/lib/debian/debian_support.py
+++ b/lib/debian/debian_support.py
@@ -1,17 +1,17 @@
 # debian_support.py -- Python module for Debian metadata
 # Copyright (C) 2005 Florian Weimer <f...@deneb.enyo.de>
 # Copyright (C) 2010 John Wright <j...@debian.org>
-# 
+#
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
 # the Free Software Foundation; either version 2 of the License, or
 # (at your option) any later version.
-# 
+#
 # This program is distributed in the hope that it will be useful,
 # but WITHOUT ANY WARRANTY; without even the implied warranty of
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 # GNU General Public License for more details.
-# 
+#
 # You should have received a copy of the GNU General Public License
 # along with this program; if not, write to the Free Software
 # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
@@ -62,7 +62,7 @@ class ParseError(Exception):
 msg - error message
 
 """
-
+
 def __init__(self, filename, lineno, msg):
 assert type(lineno) == types.IntType
 self.filename = filename
@@ -355,7 +355,7 @@ class PackageFile:
 line = self.file.readline()
 self.lineno += 1
 continue
-
+
 match = self.re_field.match(line)
 if not match:
 self.raise_syntax_error("expected package field")
@@ -415,7 +415,7 @@ class Release(PseudoEnum): pass
 def list_releases():
 releases = {}
 rels = ("buzz",
-"rez",
+"rex",
 "bo",
 "hamm",
 "slink",
@@ -472,7 +472,7 @@ def patches_from_ed_script(source,
 """
 
 i = iter(source)
-
+
 for line in i:
 match = re_cmd.match(line)
 if match is None:
@@ -566,7 +566,7 @@ def download_file(remote, local):
 remote - URL, without the .gz suffix
 local - name of the local file
 """
-
+
 lines = download_gunzip_lines(remote + '.gz')
 replace_file(lines, local)
 return lines
@@ -591,7 +591,7 @@ def update_file(remote, local, verbose=None):
 local_hash = read_lines_sha1(lines)
 patches_to_apply = []
 patch_hashes = {}
-
+
 import urllib
 index_name = remote + '.diff/Index'
 
@@ -632,9 +632,9 @@ def update_file(remote, local, verbose=None):
 # remaining patches.
 if patches_to_apply or  hist_hash == local_hash:
 patches_to_apply.append(patch_name)
-
+
 continue
-
+
 if field == 'SHA1-Patches':
 for entry in value.splitlines():
 if entry == '':
@@ -643,10 +643,10 @@ def update_file(remote, local, verbose=None):
  = re_whitespace.split(entry)
 patch_hashes[patch_name] = patch_hash
 continue
-
+
 if verbose:
 print("update_file: field %r ignored" % field)
-
+
   

Bug#740893: libjs-jquery-hotkeys: Incompatible ABI change

[Philipp Hahn]

Package: libjs-jquery-hotkeys
Version: 0~20130707+git2d51e3a9+dfsg-2
Followup-For: Bug #740893
X-Debbugs-CC: Debian Haskell Group 
<pkg-haskell-maintain...@lists.alioth.debian.org>
X-Debbugs-CC: Debian Go Packaging Team 
<pkg-go-maintain...@lists.alioth.debian.org>
X-Debbugs-CC: Ben Finney <ben+deb...@benfinney.id.au>
X-Debbugs-CC: Federico Ceratto <federico.cera...@gmail.com>
X-Debbugs-CC: Thomi Richards <thomi.richa...@canonical.com>
Severity: serious
Control: severity -1 serious

Dear Maintainer,

today I spent some time on investigating this issue, as
python-pytest-cov currently is unusable: Every key press makes the
browser window jump back to the top as *all* registered handlers fire
and the last one is "coverage.to_first_chunk" from "coverage_html.js".

<https://github.com/tzuryby/jquery.hotkeys/commit/321e02b98be973d1ea09eb97ceb921411ffb3415>
introduced an incompatible ABI change how events are registered:

jeresig <https://github.com/jeresig/jquery.hotkeys>:
  $(...).bind('keydown', 'j', function (e) {...})

tzuryby <https://github.com/tzuryby/jquery.hotkeys>:
  $(...).bind('keydown.j', function (e) {...})

So "coverage_html.js" uses the 'jeresig' API to pass the hotkey via
"data", while the 'tzuryby' API "jquery.hotkeys.js" expects is via
'namespace'.

libjs-jquery-hotkeys currently is used by 3 packages in Debian:
- libghc-gitit-data
- prometheus
- python-pytest-cov

Doing some source code `grep -n -r "[.]bind([\"']key"`:

gitit-0.10.4/data/templates/expire.st:5: \$(document).bind("keydown", 
"ctrl+r", function() {
python-coverage-3.7.1+dfsg.1/tests/farm/html/src/htmlcov/coverage_html.js:12:   
 $(document).bind('keydown', c.substr(9), function () {
python-coverage-3.7.1+dfsg.1/tests/farm/html/src/htmlcov/coverage_html.js:119:  
  .bind('keydown', 'j', coverage.to_next_chunk_nicely)
python-coverage-3.7.1+dfsg.1/tests/farm/html/src/htmlcov/coverage_html.js:120:  
  .bind('keydown', 'k', coverage.to_prev_chunk_nicely)
python-coverage-3.7.1+dfsg.1/tests/farm/html/src/htmlcov/coverage_html.js:121:  
  .bind('keydown', '0', coverage.to_top)
python-coverage-3.7.1+dfsg.1/tests/farm/html/src/htmlcov/coverage_html.js:122:  
  .bind('keydown', '1', coverage.to_first_chunk)
python-coverage-3.7.1+dfsg.1/coverage/htmlfiles/coverage_html.js:12:
$(document).bind('keydown', c.substr(9), function () {
python-coverage-3.7.1+dfsg.1/coverage/htmlfiles/coverage_html.js:119:
.bind('keydown', 'j', coverage.to_next_chunk_nicely)
python-coverage-3.7.1+dfsg.1/coverage/htmlfiles/coverage_html.js:120:
.bind('keydown', 'k', coverage.to_prev_chunk_nicely)
python-coverage-3.7.1+dfsg.1/coverage/htmlfiles/coverage_html.js:121:
.bind('keydown', '0', coverage.to_top)
python-coverage-3.7.1+dfsg.1/coverage/htmlfiles/coverage_html.js:122:
.bind('keydown', '1', coverage.to_first_chunk)
prometheus-1.5.2+ds/web/ui/static/js/graph.js:97:  
self.insertMetric.bind("keydown", "return", function(e) {

So all of them use the "jeresig" API, but 'libjs-jquery-hotkeys'
packages the "tzuryby" API.

Please switch to the "jeresig" jeresig as all current users in Debian
expect that.


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

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

Versions of packages libjs-jquery-hotkeys depends on:
ii  dpkg  1.17.27
ii  libjs-jquery  1.11.3+dfsg-4~bpo8+1

Versions of packages libjs-jquery-hotkeys recommends:
ii  javascript-common  11

libjs-jquery-hotkeys suggests no packages.

-- no debconf information

-- 
Philipp Hahn   Open Source Software Engineer  h...@univention.de
Univention GmbHbe open.   fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen fax: +49 421 22 232-99
   http://www.univention.de/
Director:Peter H. Ganten   HRB 20755 Amtsgericht Bremen   UID:DE 220 051 310

Bug#858982: isc-dhcp: dhcp-lease-list

[Philipp Hahn]

Source: isc-dhcp
Version: 4.3.5-3
Severity: normal

Dear Maintainer,

   * What led up to the situation?

> # dhcp-lease-list 
> To get manufacturer names please download 
> http://standards.ieee.org/regauth/oui/oui.txt to /usr/local/etc/oui.txt
> Cannot open /var/db/dhcpd.leases: Datei oder Verzeichnis nicht gefunden at 
> /usr/sbin/dhcp-lease-list line 69.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

Should use '/var/lib/dhcp/dhcpd.leases' instead on Debian.

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

FYI: On <https://packages.debian.org/source/sid/isc-dhcp> the link to
GIT repository no longer works.


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From b0c1bd21416c059009de13fc8abaa5bb2591a682 Mon Sep 17 00:00:00 2001
Message-Id: <b0c1bd21416c059009de13fc8abaa5bb2591a682.1490780634.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Wed, 29 Mar 2017 11:26:03 +0200
Subject: [PATCH] Use IEEE data as packaged by Debian
Organization: Univention GmbH, Bremen, Germany

Debian already has the "oui.txt" data in the package "ieee-data".

Update the manual page, too.
---
 contrib/dhcp-lease-list.pl | 4 ++--
 debian/control | 1 +
 debian/dhcp-lease-list.8   | 8 
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/contrib/dhcp-lease-list.pl b/contrib/dhcp-lease-list.pl
index aa6372d..8b0c65b 100644
--- a/contrib/dhcp-lease-list.pl
+++ b/contrib/dhcp-lease-list.pl
@@ -29,7 +29,7 @@ my @LEASES = ('/var/db/dhcpd.leases', '/var/lib/dhcp/dhcpd.leases', '/var/lib/dh
 my @all_leases;
 my @leases;
 
-my @OUIS = ('/usr/share/misc/oui.txt', '/usr/local/etc/oui.txt');
+my @OUIS = ('/usr/share/ieee-data/oui.txt', '/usr/share/misc/oui.txt', '/usr/local/etc/oui.txt');
 my $OUI_URL = 'http://standards.ieee.org/regauth/oui/oui.txt';
 my $oui;
 
@@ -65,7 +65,7 @@ sub check_oui_file() {
 
 if (not defined $oui) {
 	print(STDERR "To get manufacturer names please download $OUI_URL ");
-	print(STDERR "to /usr/local/etc/oui.txt\n");
+	print(STDERR "to " . $OUIS[$#OUIS] . "\n");
 }
 }
 
diff --git a/debian/control b/debian/control
index 8274109..7cf2fff 100644
--- a/debian/control
+++ b/debian/control
@@ -29,6 +29,7 @@ Depends:
 Recommends:
  isc-dhcp-common,
  policycoreutils,
+ ieee-data,
 Breaks:
  isc-dhcp-common (<= 4.3.3-1),
  logcheck-database (<= 1.3.17~)
diff --git a/debian/dhcp-lease-list.8 b/debian/dhcp-lease-list.8
index 18b31f5..f7f6c6a 100644
--- a/debian/dhcp-lease-list.8
+++ b/debian/dhcp-lease-list.8
@@ -15,7 +15,7 @@ dhcp\-lease\-list \- Prints active DHCP leases.
 .SH "SYNOPSIS"
 .\" The general command line
 .B dhcp\-lease\-list
-.RB [\|options \|]
+.RI [ options ]
 .SH "OPTIONS"
 .TP 
 .B \-\-help
@@ -35,11 +35,11 @@ shows the dhcpd.leases file but filters, depending on the
 specified command line options, obsolete entries.
 .SH "FILES"
 .TP 
-.I /var/lib/dhcp3/dhcpd.leases
+.IR /var/db/dhcpd.leases ,\  /var/lib/dhcp/dhcpd.leases \ or\  /var/lib/dhcp3/dhcpd.leases
 dhcpd leases
 .TP 
-.I /usr/share/misc/oui.txt or /usr/local/etc/oui.txt
+.IR /usr/share/ieee-data/oui.txt ,\  /usr/share/misc/oui.txt \ or\  /usr/local/etc/oui.txt
 optional file to map MAC addresses to manufactorer names
 .SH "SEE ALSO"
-.BR dhcpd3 (8)
+.BR dhcpd (8),
 .BR dhcpd.leases (5)
-- 
2.1.4

>From be6174f36ea59bc58436a557fe2a04f3514a99a3 Mon Sep 17 00:00:00 2001
Message-Id: <be6174f36ea59bc58436a557fe2a04f3514a99a3.1490781017.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Wed, 29 Mar 2017 11:49:47 +0200
Subject: [PATCH] d/control: Fix Vcs-Git URL
Organization: Univention GmbH, Bremen, Germany

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 7cf2fff..c021626 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: net
 Priority: important
 Maintainer: Debian ISC DHCP maintainers <pkg-dhcp-de...@lists.alioth.debian.org>
 Uploaders: Andrew Pollock <apoll...@debian.org>, Michael Gilbert <mgilb...@debian.org>
-Vcs-Git: https://anonscm.debian.org/pkg-dhcp/isc-dhcp.git
+Vcs-Git: https://anonscm.debian.org/git/pkg-dhcp/isc-dhcp.git
 Vcs-Browser: https://anonscm.debian.org/gitweb/?p=pkg-dhcp/isc-dhcp.git;a=summary
 Homepage: http://www.isc.org
 Build-Depends:
-- 
2.1.4

Bug#857059: [debian-mysql] Bug#857059: FTBFS: parallel build -j

[Philipp Hahn]

Hi.
Good if it is already fixen in Debian. For Univention Corporate Server 4.2 
we're stuck with Debian-Jessied mysql-5.5, that's why I posted the report.
I think it's okay to not prepare an updated package for Jessie, but you could 
apply the fix to the next security upload.
Thank you for your work.
Philipp Hahn <pmh...@debian.org>
-- 
Univention GmbH

Bug#857059: FTBFS: parallel build -j

[Philipp Hahn]

Source: mysql-5.5
Version: 5.5.54-0+deb8u1
Severity: normal
Tags: patch

Building mysql-5.5 with -j4 failed to build as there are 2 errors in the
debian/rules file. Patches attached.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 11f261ecf1258aa7c755e6bf27cd49571ac1179a Mon Sep 17 00:00:00 2001
Message-Id: <11f261ecf1258aa7c755e6bf27cd49571ac1179a.1488896981.git.h...@univention.de>
In-Reply-To: <cf7e5ca200c884bf017a215026a1276d8bdb10cc.1488896981.git.h...@univention.de>
References: <cf7e5ca200c884bf017a215026a1276d8bdb10cc.1488896981.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Tue, 7 Mar 2017 15:21:31 +0100
Subject: [PATCH 2/3] d/rules: Fix parallel build 2
Organization: Univention GmbH, Bremen, Germany

debian/rules contains the following Make rules:

> binary:binary-indep binary-arch

When dpkg-buildpackage runs, the following processes will run in
parallel:
> # make -f debian/rules -n binary
> dh binary-indep --parallel
> dh binary-arch --parallel
> dh binary --parallel
The all will then run the following targets in parallel:
> override_dh_auto_install: auto_install-stamp
> override_dh_install:
> 	dh_movefiles
which fails as they each move file already used by other targets.

Just remove the legacy "binary" rule as "dh" will do the right thing for
"binary", "binary-arch" and "binary-indep" internally.
---
 debian/rules | 2 --
 1 file changed, 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index 3c47f89..3f7a23a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -247,8 +247,6 @@ override_dh_makeshlibs-arch:
 override_dh_builddeb:
 	dh_builddeb -- -Zxz
 
-binary:	binary-indep binary-arch
-
 get-orig-source:
 	uscan --force-download --verbose --download-current-version
 
-- 
2.1.4

>From cf7e5ca200c884bf017a215026a1276d8bdb10cc Mon Sep 17 00:00:00 2001
Message-Id: <cf7e5ca200c884bf017a215026a1276d8bdb10cc.1488892085.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Tue, 7 Mar 2017 14:01:02 +0100
Subject: [PATCH] d/rules: Fix parallel build
Organization: Univention GmbH, Bremen, Germany

debian/rules contains the following Make rules:

> override_dh_auto_build: build-stamp build-pic-stamp
> build-stamp:
> 	@echo "RULES.$@"
> 	[ -f $(EXPORTED_SOURCE_TARBALL) ] || tar -zcf $(EXPORTED_SOURCE_TARBALL) \
> 	--exclude=debian . \
> 	--transform="s,^\./,mysql-5.5/,"
> 	cd $(builddir) && $(MAKE)
>
> build-pic-stamp:
> 	@echo "RULES.$@"
> 	cd $(builddir) && $(MAKE) -C scripts
> 	cd $(builddir) && $(MAKE) -C libmysqld
> 	touch $@

The rule "override_dh_auto_build" will build "build-stamp" and
"build-pic-stamp", but the "tar" process from "build-stamp" will fail to
create an atomic TAR file as the "build-pic-stamp" already modifies the
sub-directories in parallel.

Both jobs must only start the parallel build after the TAR has been
created.
---
 debian/rules | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/debian/rules b/debian/rules
index f696bc1..3c47f89 100755
--- a/debian/rules
+++ b/debian/rules
@@ -138,15 +138,17 @@ configure-stamp configure-pic-stamp:
 
 override_dh_auto_build: build-stamp build-pic-stamp
 
-build-stamp:
-	@echo "RULES.$@"
+build-tar $(EXPORTED_SOURCE_TARBALL):
 	[ -f $(EXPORTED_SOURCE_TARBALL) ] || tar -zcf $(EXPORTED_SOURCE_TARBALL) \
 	--exclude=debian . \
 	--transform="s,^\./,mysql-5.5/,"
+
+build-stamp: $(EXPORTED_SOURCE_TARBALL)
+	@echo "RULES.$@"
 	cd $(builddir) && $(MAKE)
 	touch $@
 
-build-pic-stamp:
+build-pic-stamp: $(EXPORTED_SOURCE_TARBALL)
 	@echo "RULES.$@"
 	cd $(builddir) && $(MAKE) -C scripts
 	cd $(builddir) && $(MAKE) -C libmysqld
-- 
2.1.4

Bug#857058: FTBFS: parallel build -j4

[Philipp Hahn]

Package: libpaper
Version: 1.1.24+nmu4
Severity: normal
Tags: patch

Dear Maintainer,

When doing a parallel build, "make config" and "make "build-stamp" run in
parallel, while the later depends on the former:
The "Makefile" is only avaiable for calling *after* configure has run.


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
When doing a parallel build, "make config" and "make "build-stamp" run in
parallel, while the later depends on the former:
The "Makefile" is only avaiable for calling *after* configure has run.

--- libpaper-1.1.24+nmu4.orig/debian/rules	2014-11-01 14:26:20.0 +0100
+++ libpaper-1.1.24+nmu4/debian/rules	2017-03-07 16:40:26.555477889 +0100
@@ -47,8 +47,8 @@
 	$(SHELL) ./configure $(config_flags)
 	touch $@
 
-build:	config build-stamp debian/libpaper1.config
-build-stamp:
+build:	build-stamp debian/libpaper1.config
+build-stamp:	config
 	$(MAKE)
 	touch $@
 

Bug#855688: lmdb: Out-of-date 0.9.19

[Philipp Hahn]

Updates patch with better tool description.
>From af79d293438e731d654443932f0a32533475d95a Mon Sep 17 00:00:00 2001
Message-Id: <af79d293438e731d654443932f0a32533475d95a.1487665779.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Tue, 21 Feb 2017 09:21:21 +0100
Subject: [PATCH] debian/control: Update description for lmdb-utils
Organization: Univention GmbH, Bremen, Germany

to include mdb_dump and mdb_load
---
 debian/control | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/control b/debian/control
index a77e31a..0675ccb 100644
--- a/debian/control
+++ b/debian/control
@@ -19,6 +19,8 @@ Description: Lightning Memory-Mapped Database Utilities
  This package provides tools for manipulating LMDB databases:
   * mdb_stat - LMDB environment status tool
   * mdb_copy - LMDB environment copy tool
+  * mdb_dump - LMDB environment export tool
+  * mdb_load - LMDB environment import tool
  .
  Lighting Memory-Mapped Database (LMDB) is an ultra-fast, ultra-compact
  key-value embedded data store developed for the OpenLDAP Project.  It uses
-- 
2.1.4

Bug#855688: lmdb: Out-of-date 0.9.19

[Philipp Hahn]

Source: lmdb
Version: 0.9.18-5
Severity: normal

Dear Maintainer,

debian/copyright:4 Source: https://gitorious.org/mdb/mdb
is stale; there is a read-only mirror on <https://github.com/LMDB/lmdb>,
but the real upstream is OpenLDAP at
<http://www.openldap.org/software/repo.html>.

There is a new 0.9.19 release with many fixs at
<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/liblmdb/CHANGES;h=c2e5ff672e3f6347a8c36d41d4da47aeac4150d2;hb=HEAD>

debian/control:Package: lmdb-utils should also mention mdb_{dump,load} -
see attached patch.


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 48cdc296a865603c32d673a246b15f0d906c6c33 Mon Sep 17 00:00:00 2001
Message-Id: <48cdc296a865603c32d673a246b15f0d906c6c33.1487665327.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Tue, 21 Feb 2017 09:21:21 +0100
Subject: [PATCH] debian/control: Update description for lmdb-utils
Organization: Univention GmbH, Bremen, Germany

to include mdb_dump and mdb_load
---
 debian/control | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/control b/debian/control
index a77e31a..fc95372 100644
--- a/debian/control
+++ b/debian/control
@@ -19,6 +19,8 @@ Description: Lightning Memory-Mapped Database Utilities
  This package provides tools for manipulating LMDB databases:
   * mdb_stat - LMDB environment status tool
   * mdb_copy - LMDB environment copy tool
+  * mdb_dump - LMDB environment dump tool
+  * mdb_load - LMDB environment load tool
  .
  Lighting Memory-Mapped Database (LMDB) is an ultra-fast, ultra-compact
  key-value embedded data store developed for the OpenLDAP Project.  It uses
-- 
2.1.4

Bug#849353: btrfs-progs: new upstream version

[Philipp Hahn]

Package: btrfs-progs
Version: 4.9-0.1
Followup-For: Bug #849353

Dear Maintainer,

find attached by NMU.

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

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

Versions of packages btrfs-progs depends on:
ii  e2fslibs1.42.12-2+b1
ii  libblkid1   2.25.2-6
ii  libc6   2.24-5
ii  libcomerr2  1.42.12-2+b1
ii  liblzo2-2   2.08-1.2
ii  libuuid12.25.2-6
ii  zlib1g  1:1.2.8.dfsg-2+b1

btrfs-progs recommends no packages.

btrfs-progs suggests no packages.

-- no debconf information


btrfs-progs_4.9.1-0.1.debian.tar.xz
Description: application/xz

Bug#853930: man: dh_python2 --namespace requires argument

[Philipp Hahn]

Package: dh_python2
Version: 2.20160218
Severity: normal

Update the manual page to make it clear, that the option --namespace
of dh_python2 requires an argument:
> parser.add_option('--namespace', action='append', dest='namespaces',
>   help='recreate __init__.py files for given namespaces at 
> install time')

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 393c36efb1a54c29a15aae1a2ba95cc4e189da35 Mon Sep 17 00:00:00 2001
Message-Id: <393c36efb1a54c29a15aae1a2ba95cc4e189da35.1486026065.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Thu, 2 Feb 2017 09:58:42 +0100
Subject: [PATCH] man: dh_python2 --namespace requires argument
Organization: Univention GmbH, Bremen, Germany

Update the manual page to make it clear, that the option --namespace
of dh_python2 requires an argument:
> parser.add_option('--namespace', action='append', dest='namespaces',
>   help='recreate __init__.py files for given namespaces at install time')
---
 dh_python2.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dh_python2.rst b/dh_python2.rst
index 593ad09..971f96d 100644
--- a/dh_python2.rst
+++ b/dh_python2.rst
@@ -197,7 +197,7 @@ OPTIONS
 --requires=FILENAME	translate requirements from given file(s) into Debian
   dependencies and add them to ${python:Depends}
 
---namespace	use this option (multiple time if necessary) if
+--namespace=NAMESPACE	use this option (multiple time if necessary) if
   namespace_packages.txt is not complete
 
 --ignore-namespace	ignore Egg's namespace declaration and
-- 
2.1.4

Bug#740208: systemd: encountered with /dev/disk/by-uuid as well

[Philipp Hahn]

Hello,

Am 19.12.2016 um 09:33 schrieb Michael Biebl:
> On Thu, 18 Sep 2014 11:46:49 -0400 Zack Weinberg  wrote:
> 
>> I've just tripped over the same bug with the latest systemd.  My 
>> configuration
>> is considerably simpler:
>>
>> # 
>>  
>> UUID="eaf36848-eadc-4138-b2a9-db3d8ce82f34"  /  ext4  
>> noatime,errors=remount-ro  0 1
>> UUID="1e04942e-c69b-4430-84f3-1622ef1afe75"  none   swap  sw 
>> 0 0
>> UUID="ec93d2c2-7937-40f8-aaa6-c20c9775d93a"  /home  btrfs subvol=/home   
>> 0 2
>>
>> The BTRFS volume spans /dev/sdb and /dev/sdc.
>>
>> # ls -l /dev/disk/by-uuid/
>> total 0
>> lrwxrwxrwx 1 root root 10 Sep 18 11:29 10C8D0B8C8D09D72 -> ../../sda4
>> lrwxrwxrwx 1 root root 10 Sep 18 11:29 1e04942e-c69b-4430-84f3-1622ef1afe75 
>> -> ../../sda2
>> lrwxrwxrwx 1 root root 10 Sep 18 11:29 eaf36848-eadc-4138-b2a9-db3d8ce82f34 
>> -> ../../sda1
>> lrwxrwxrwx 1 root root  9 Sep 18 11:29 ec93d2c2-7937-40f8-aaa6-c20c9775d93a 
>> -> ../../sdc
>>
>> root@moxana:~# udevadm info --query=all --name=/dev/sdb | grep BTRFS
>> E: ID_BTRFS_READY=1
>> root@moxana:~# udevadm info --query=all --name=/dev/sdc | grep BTRFS
>> E: ID_BTRFS_READY=0
>>
>> Manually mounting /home from the emergency shell allows boot to continue.
> 
> Is that still an issue on an up-to-date sid/stretch system?
> In that case, we should probably take this upstream.

I'm reluctant to upgrade my system at the moment, as I need it for my
daily work.

I tried to create a test scenario with Qemu, but was never able to
reproduce it there. Timing seems to be critical and I was not able to
trick Qemu into delaying the availability of a disk.

Maybe I find some time over the Christmas holidays to give it another try.

Philipp

Bug#837051: dpkg: Fix update of diverted conffile moved between packages

[Philipp Hahn]

Package: dpkg
Version: 1.17.27
Followup-For: Bug #837051

Dear Maintainer,

find attached a patch to fix the mentioned bug.
The patch still applied to master=1.18.8.

To reproducte this:
tar xf 41965_dpkg-divert.tar.xz
cd bug41965.1 && dpkg-buildpackage -uc -us -b
cd bug41965.2 && dpkg-buildpackage -uc -us -b
dpkg -i bug41965-a_1_all.deb
dpkg-divert --local --rename --divert /etc/bug41965/compat.moved --add 
/etc/bug41965/compat
dpkg -i bug41965-?_2_all.deb

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-7+b3
ii  libc62.24-5
ii  liblzma5 5.1.1alpha+20120614-2+b3
ii  libselinux1  2.3-2
ii  tar  1.27.1-2+deb8u1
ii  zlib1g   1:1.2.8.dfsg-2+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.0.9.8.3

-- no debconf information
>From 557ad2681c947515cc52f933158473f440d65ee9 Mon Sep 17 00:00:00 2001
Message-Id: 
<557ad2681c947515cc52f933158473f440d65ee9.1481286674.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Fri, 9 Dec 2016 13:11:59 +0100
Subject: [PATCH] Fix update of diverted conffile moved between packages
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Organization: Univention GmbH, Bremen, Germany

If a conffile is diverted and it gets moved from one package to another,
dpkg still considers it owned by the original package and aborts the
upgrade:
> Unpacking libpython2.7-minimal:amd64 (from 
> libpython2.7-minimal_2.7.9-2_amd64.deb) ...
> dpkg: error processing libpython2.7-minimal_2.7.9-2_amd64.deb (--install):
>  trying to overwrite '/etc/python2.7/sitecustomize.py', which is also in 
> package python2.7-minimal 2.7.9-2

Running dpkg with --debug=03773 shows this difference (using an
artificial package for testing) - left is diverted, right side not:
> tarobject ti->name='./etc/bug41965/compat' mode=100644 owner=0.0 type=48(-) 
> ti->linkname='' name…| tarobject ti->name='./etc/bug41965/compat' mode=100644 
> owner=0.0 type=48(-) ti->linkname='' namenode='/etc/b…
> namenodetouse namenode='/etc/bug41965/compat' pkg=bug41965-b:all  
>| 
> -
> namenodetouse ... useinstead=/etc/bug41965/compat.moved camefrom= 
> pkg= return /etc/b…| 
> -
>   
>|
> conffderef in='etc/bug41965/compat.moved' current 
> working='/etc/bug41965/compat.moved'   | conffderef 
> in='etc/bug41965/compat' current working='/etc/bug41965/compat'
> conffderef in='etc/bug41965/compat.moved' result='/etc/bug41965/compat.moved' 
>| conffderef in='etc/bug41965/compat' 
> result='/etc/bug41965/compat'
> tarobject fnnf_new_conff deref='etc/bug41965/compat.moved'
>| tarobject fnnf_new_conff deref='etc/bug41965/compat'
> setupvnamevbs main='/etc/bug41965/compat.moved' 
> tmp='/etc/bug41965/compat.moved.dpkg-tmp' new='/…| setupvnamevbs 
> main='/etc/bug41965/compat' tmp='/etc/bug41965/compat.dpkg-tmp' 
> new='/etc/bug41965/compat.dpkg…
> tarobject already exists  
>| tarobject already exists
> tarobject ... found in bug41965-a:all 
>| tarobject ... found in bug41965-a:all
> tarobject ... diverted, divpkgset=  
>| tarobject other's obsolete conffile

In the un-diverted case (right side) you see the message from
src/archives.c:911, which is missing in the diverted case (left side),
finally leading to the package being rejected:

>   /* Is the file an obsolete conffile in the other package
>* and a conffile in the new package? */
>   if ((nifd->namenode->flags & fnnf_new_conff) &&
>   !statr && S_ISREG(stab.st_mode)) {
> for (conff = otherpkg->installed.conffiles;
>  conff;
>  conff = conff->next) {
>   if (!conff->obsolete)
> continue;
>   if (stat(conff->name, )) {

Here conff->name='./etc/bug41965/compat' is the original fi

Bug#822575: linux-4.1: UEFI root-fb vs. cirrusfb

[Philipp Hahn]

Hello David,

Am 15.11.2016 um 15:57 schrieb David Herrmann:
> On Fri, Oct 28, 2016 at 2:24 PM, Philipp Hahn <h...@univention.de> wrote:
>> while experimenting with UEFI and secure-boot I stumbled into the issue
>> "cirrusdrmfb broken with simplefb" associated with your name:
>> <https://groups.google.com/forum/#!msg/linux.kernel/tD2UEqra-wU/u6NkZY8o5YEJ>
>>
>> I'm using a Debian based linux-4.1.38 kernel, which has
>>> # zgrep -E 'CONFIG_X86_SYSFB|CONFIG_FB_SIMPLE' /boot/config-`uname -r`
>>> CONFIG_X86_SYSFB=y
>>> CONFIG_FB_SIMPLE=y
>>
>> I found that SUSE bug
>> <https://bugzilla.novell.com/show_bug.cgi?id=855821>, where Takashi Iwai
>> finally disabled those options.
>>
>> I also checked Debians latest linux-4.7 kernel in Debian-sid, which
>> still has this setting. So my questions are:
>> 1, should Debian disable those options for x86?
>> 2. What would Debian loose?
>> 3. or is that issue fixed otherwise in newer kernels?
> 
> Right now CONFIG_X86_SYSFB should remain disabled. Once the SimpleDRM
> driver is upstream, there will be infrastructure to do the hw
> handover. Right now, it breaks if you hand over hw from one driver to
> another.

@David: Thank you for your feedback.

@Debian: Please disable CONFIG_X86_SYSFB in Debian for all next builds -
maybe except arch=arm.

Philipp Hahn

Bug#822575: fb: switching to cirrusdrmfb from simple

[Philipp Hahn]

Source: linux
Version: 4.9~rc5-1~exp1
Followup-For: Bug #822575

Dear Maintainer,

I have the same problem with cirrusfb: After that last message the
screen does not update anymore (but I can login through ssh).

After lots of research I things the problem is related to
CONFIG_X86_SYSFB being enabled in Debian by default:

$ git rev-parse HEAD # git://anonscm.debian.org/kernel/linux.git
6c0c9bcf78dfc886907d006b8cb6c2ea0f075a62
$ git grep -n -F -e CONFIG_X86_SYSFB -e CONFIG_FB_SIMPLE
config/armhf/config:1187:CONFIG_FB_SIMPLE=y
config/kernelarch-x86/config:73:CONFIG_X86_SYSFB=y
config/kernelarch-x86/config:1776:CONFIG_FB_SIMPLE=y

By default the video RAM is claimed by the boot framebbuffer:
> # cat /proc/fb
> 0 simple
> # grep 8000 /proc/iomem
> 8000-febf : PCI Bus :00
>   8000-81ff : :00:02.0
> 8000-801d4fff : BOOTFB

When cirrusdrmfb loads, it disabled the bootfb and tries to claim that
region. As it is still held by bootfb, this failes:
> # modprobe cirrus
> # dmesg
> [  263.171744] checking generic (8000 1d5000) vs hw (8000 200)
> [  263.171753] fb: switching to cirrusdrmfb from simple
> [  263.171838] Console: switching to colour dummy device 80x25
> [  263.177052] [drm:cirrus_device_init [cirrus]] *ERROR* can't reserve VRAM
> [  263.177066] cirrus :00:02.0: Fatal error during GPU init: -6
> [  263.177072] Trying to free nonexistent resource 
> <82029000-82029fff>
> [  263.177080] Trying to free nonexistent resource 
> <8000-81ff>

/proc/fb is empty afterwards, as bootfb remains disabled.

My solution was to remove cirrus.ko and cirrusfb.ko from
/lib/modules/`uname -r`/kernel/ and to re-build the initramfs. That
prevented cirrus from being loaded, leaving the simple-frame-buffer intact.
Loading the module by hand breaks the console again.

I found that SUSE bug
, where Takashi Iwai
finally disabled those options for OpenSUSE.

Ubuntu disabled the Cirrus drm driver first,

but later changed to only disable X86_SYSFB.

So probably it's best to disable X86_SYSFB:
> config X86_SYSFB
>   bool "Mark VGA/VBE/EFI FB as generic system framebuffer"
>   help
> Firmwares often provide initial graphics framebuffers so the BIOS,
> bootloader or kernel can show basic video-output during boot for
> user-guidance and debugging. Historically, x86 used the VESA BIOS
> Extensions and EFI-framebuffers for this, which are mostly limited
> to x86.
> This option, if enabled, marks VGA/VBE/EFI framebuffers as generic
> framebuffers so the new generic system-framebuffer drivers can be
> used on x86. If the framebuffer is not compatible with the generic
> modes, it is adverticed as fallback platform framebuffer so legacy
> drivers like efifb, vesafb and uvesafb can pick it up.
> If this option is not selected, all system framebuffers are always
> marked as fallback platform framebuffers as usual.
> 
> Note: Legacy fbdev drivers, including vesafb, efifb, uvesafb, will
> not be able to pick up generic system framebuffers if this option
> is selected. You are highly encouraged to enable simplefb as
> replacement if you select this option. simplefb can correctly deal
> with generic system framebuffers. But you should still keep vesafb
> and others enabled as fallback if a system framebuffer is
> incompatible with simplefb.
> 
> If unsure, say Y.

If you read  there was a
patched proposed to change it to 'N' and/or to depend on FB_SIMPLE, but
that patch never made it into linux.

Nor did  or
.

I tried to contact David Herrmann himself, but never got a reply.

So I think Debian should disable X86_SYSFB for now, too.

Thank you for your work and help
Philipp "also a Debian maintainer" Hahn
-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (90, 'testing')
Architecture: amd64 (x86_64)

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

Bug#611045: debian-installer: find a better way of detecting default GRUB bootloader install location

[Philipp Hahn]

Package: grub-installer
Version: 1.117+deb8u1
Followup-For: Bug #611045

Dear Maintainer,

   * What led up to the situation?
Installation using USB stick emulated by QEMU

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Preseed grub-installer/bootdev=default

   * What was the outcome of this action?
grub-installer tried /dev/sda = USB stick

   * What outcome did you expect instead?
grub-installer should use /dev/vda

See attached patch.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 4d37f26c2bb1030a1013ce457ce98864fda127d6 Mon Sep 17 00:00:00 2001
Message-Id: <4d37f26c2bb1030a1013ce457ce98864fda127d6.1478269339.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Fri, 4 Nov 2016 15:11:47 +0100
Subject: [PATCH 1/2] Choose better default for bootdev
Organization: Univention GmbH, Bremen, Germany

`grub-mkdevicemap` enumerates the devices in random/BIOS(?) order:
> (hd0)  /dev/disk/by-id/usb-QEMU_QEMU_HARDDISK_1-:00:07.7-2-0:0
> (hd1)  /dev/vda
The current code always selects the first drive, which in this case is
the emulated USB stick containing the Hybrid-ISO. Together with
"grub-installer/bootdev=default" the installer tries to install GRUB to
'/dev/sda', which fails.

As we know the device name of the installation before calling
`grub-mkdevicemap`, use that knowledge to filter out those devices first
and only then select the default device from the remaining devices.
---
 grub-installer | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/grub-installer b/grub-installer
index 7655408..139a910 100755
--- a/grub-installer
+++ b/grub-installer
@@ -570,15 +570,6 @@ if [ "$frdev" ]; then
 	fi
 fi
 
-# Try to avoid using (hd0) as a boot device name.  Something which can be
-# turned into a stable by-id name is better.
-default_bootdev_os="$($chroot $ROOT grub-mkdevicemap --no-floppy -m - | head -n1 | cut -f2)"
-if [ "$default_bootdev_os" ]; then
-	default_bootdev="$($chroot $ROOT readlink -f "$default_bootdev_os")"
-else
-	default_bootdev="(hd0)"
-fi
-
 # Set a sensible default boot device, so that we aren't installing GRUB to
 # installation media which may be removed later.  The disk containing /cdrom
 # is very unlikely to be a sensible default.  If we had to fall back to
@@ -593,11 +584,16 @@ hybrid=false
 if db_get cdrom-detect/hybrid; then
 	hybrid="$RET"
 fi
+# Try to avoid using (hd0) as a boot device name.  Something which can be
+# turned into a stable by-id name is better.
+default_bootdev="$(
+	$chroot "$ROOT" /bin/sh -c 'grub-mkdevicemap --no-floppy -m -|while read grub dev;do readlink -f "$dev";done' |
+	grep -F -v ${cdsrc:+-e "$(device_to_disk "$cdsrc")"} ${hdsrc:+-e "$(device_to_disk "$hdsrc")"} |
+	head -n1)"
+: ${default_bootdev:='(hd0)'}
 case $ARCH:$grub_package in
 *:grub|*:grub-pc|sparc:grub-ieee1275)
-	if [ "$(device_to_disk "$cdsrc")" = "$default_bootdev" ] || \
-	   ([ -n "$hdsrc" ] && [ "$(device_to_disk "$hdsrc")" = "$default_bootdev" ]) || \
-	   ([ "$default_bootdev" = '(hd0)' ] && \
+	if ([ "$default_bootdev" = '(hd0)' ] && \
 	(([ -n "$cdfs" ] && [ "$cdfs" != "iso9660" ]) || \
 	 [ "$hybrid" = true ])) || \
 	   ([ "$default_bootdev" != '(hd0)' ] && \
-- 
2.1.4


>From 8ed38114bb518b55cc5359f9055a9ce3b4e8df9d Mon Sep 17 00:00:00 2001
Message-Id: <8ed38114bb518b55cc5359f9055a9ce3b4e8df9d.1478269339.git.h...@univention.de>
In-Reply-To: <4d37f26c2bb1030a1013ce457ce98864fda127d6.1478269339.git.h...@univention.de>
References: <4d37f26c2bb1030a1013ce457ce98864fda127d6.1478269339.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Fri, 4 Nov 2016 14:27:12 +0100
Subject: [PATCH 2/2] Remove use-less bask-slash line continuation
Organization: Univention GmbH, Bremen, Germany

\ after && and || and | is not required.
---
 debian/postinst |  6 +++---
 grub-installer  | 38 ++---
 otheros.sh  |  2 +-
 rescue.d/81grub-efi-force-removable |  6 +++---
 4 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/debian/postinst b/debian/postinst
index 4b12027..11b4847 100755
--- a/debian/postinst
+++ b/debian/postinst
@@ -21,11 +21,11 @@ die () {
 mountvirtfs () {
 	fstype=&qu

Bug#837639: lsb-base: get_lsb_header_val() should strip leading spaces

[Philipp Hahn]

Package: lsb-base
Version: 4.1+Debian13+nmu1
Severity: minor
Tags: patch

Dear Maintainer,

most LSB headers are indented for visual readability (table format), but
get_lsb_header_val() from /lib/lsb/init-functions does not strip leading
spaces, leading to visual anomalies when later used quoted.

IMHO all leading blanks should be stripped:

--- /lib/lsb/init-functions 2016-09-13 10:26:56.34800 +0200
+++ init-functions  2016-09-13 10:26:53.86800 +0200
@@ -260,7 +260,7 @@
 fi
 LSB_S="### BEGIN INIT INFO"
 LSB_E="### END INIT INFO"
-sed -n "/$LSB_S/,/$LSB_E/ s/# $2: \(.*\)/\1/p" $1
+sed -n "/$LSB_S/,/$LSB_E/ s/# $2: \+\(.*\)/\1/p" "$1"
 }
 
 # If the currently running init daemon is upstart, return zero; if the

The patch assumes sed does eager wildcards - I verified it does.

PS: $1 should be quoted as well to support file names containings
characters in $IFS.

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

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

-- no debconf information

Bug#837051: dpkg-divert breaks package upgrade with moved conffile

[Philipp Hahn]

Package: dpkg
Version: 1.17.27
Severity: normal

Dear Maintainer,

During a dist-upgrade of python2.7 dpkg aborted the installation of the new
package libpython2.7-minimal as it claims a conffile was still owned by the old
package while being moved to the new package. The conffile was locally diverted
by me:

- python2.7-minimal 2.7.3-6 has /etc/python2.7/sitecustomize.py

- With 2.7.4-2 the conffile was moved to the new package
  libpython2.7-minimal_2.7.9-2

- dpkg aborts because of:

> Unpacking libpython2.7-minimal:amd64 (from 
> libpython2.7-minimal_2.7.9-2_amd64.deb) ...
> dpkg: error processing libpython2.7-minimal_2.7.9-2_amd64.deb (--install):
>  trying to overwrite '/etc/python2.7/sitecustomize.py', which is also in 
> package python2.7-minimal 2.7.9-2

$ apt-cache show libpython2.7-minimal
Package: libpython2.7-minimal
Replaces: libpython2.7-stdlib (<< 2.7.8-7), python2.7 (<< 2.7.4-2), 
python2.7-minimal (<< 2.7.3-10)

$ dpkg -s python2.7-minimal 
Package: python2.7-minimal
Version: 2.7.9-2
Config-Version: 2.7.3-6.7.201608291252

$ dpkg-query -W -f 
'${Package}\n${Version}\n${Config-Version}\n${Conffiles}\n\n' python2.7-minimal 
libpython2.7-minimal
libpython2.7-minimal

python2.7-minimal
2.7.9-2
2.7.3-6.7.201608291252
 /etc/python2.7/sitecustomize.py d6b276695157bde06a56ba1b2bc53670 obsolete


# dpkg-divert --list /etc/python2.7/sitecustomize.py
local diversion of /etc/python2.7/sitecustomize.py to 
/etc/python2.7/sitecustomize.py.debian


If I undo my local divert, the new package can be installed without problems:


Maybe related:
#363524  Problem diverting conffile
#595112  dpkg-maintscript-helper: new helper for moving a conffile between 
packages
#672945  dpkg should support moving a conffile between packages

As the conffile is moved from python2.7-minimal to libpython2.7-minimal,
python2.7-minimal does not use "dpkg-maintscript-helper rm_conffile".

Yes, I know :
> Do not attempt to divert a conffile, as dpkg does not handle it well.

I would have expected dpkg-divert to not having such subtile side effects.


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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-7+b3
ii  libc62.19-18+deb8u4
ii  liblzma5 5.1.1alpha+20120614-2+b3
ii  libselinux1  2.3-2
ii  tar  1.27.1-2+b1
ii  zlib1g   1:1.2.8.dfsg-2+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.0.9.8.3

-- no debconf information

Bug#817015: jessie-pu: package libvirt/1.2.9-9+deb8u1

[Philipp Hahn]

Hello,

Am 24.03.2016 um 15:00 schrieb Adam D. Barratt:
> On 2016-03-24 13:48, Philipp Hahn wrote:
>> Am 23.03.2016 um 21:55 schrieb Adam D. Barratt:
>>> On Mon, 2016-03-07 at 07:22 +0100, Philipp Hahn wrote:
>>>> Guido asked me to prepare an update for libvirt:
>>>> - CVE-2015-5313 is marked 'no-dsa', but should be fixed anyway
>>>> (#808273)
>>>>   Salvatore Bonaccorso (security team) asked me to prepare an update
>>>> via
>>>>   jessie-proposed-updates.
>>>> - the SUID bridge-helper in searched in /usr/libexec/, while it
>>>> realy is
>>>>   in /usr/lib/qemu/ (#816602)
>>>> While preparing the update I noticed that it FTBFS in my pbuilder
>>>> environment, requiring 3 more fixes.
>>>
>>> The Build-Depends change makes me unhappy, but...
>>>
>>> Please can we have an actual debdiff of the prepared (and tested)
>>> package, rather than the git patches?
>>
>> Here it is:
>>
>>> $ debdiff --from /var/cache/apt/archives/*libvirt*.deb --to
>>> *libvirt*.deb
> 
> Thanks, but I meant of the source package. :-)

Attached.

Philipp
diff -Nru libvirt-1.2.9/debian/changelog libvirt-1.2.9/debian/changelog
--- libvirt-1.2.9/debian/changelog  2015-08-26 08:34:22.0 +0200
+++ libvirt-1.2.9/debian/changelog  2016-03-05 08:18:07.0 +0100
@@ -1,3 +1,13 @@
+libvirt (1.2.9-9+deb8u2) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix CVE-2015-5313 (Closes: #808273)
+  * libvirt-daemon: Expects qemu-bridge-helper in /usr/libexec/
+(Closes: #816602)
+  * Fix several FTBFS errors
+
+ -- Philipp Matthias Hahn <pmh...@debian.org>  Fri, 04 Mar 2016 12:01:36 +0100
+
 libvirt (1.2.9-9+deb8u1) jessie; urgency=medium
 
   [ Guido Günther ]
diff -Nru libvirt-1.2.9/debian/control libvirt-1.2.9/debian/control
--- libvirt-1.2.9/debian/control2015-08-24 16:20:54.0 +0200
+++ libvirt-1.2.9/debian/control2016-03-04 13:42:30.0 +0100
@@ -5,6 +5,7 @@
 Uploaders: Guido Günther <a...@sigxcpu.org>, Laurent Léonard 
<laur...@open-minds.org>
 Build-Depends:
  debhelper (>= 7),
+ dh-autoreconf,
  dh-systemd (>= 1.18~),
  libxml2-dev,
  libncurses5-dev,
diff -Nru 
libvirt-1.2.9/debian/patches/debian/Debianize-bridge-helper-path.patch 
libvirt-1.2.9/debian/patches/debian/Debianize-bridge-helper-path.patch
--- libvirt-1.2.9/debian/patches/debian/Debianize-bridge-helper-path.patch  
1970-01-01 01:00:00.0 +0100
+++ libvirt-1.2.9/debian/patches/debian/Debianize-bridge-helper-path.patch  
2016-03-05 08:18:07.0 +0100
@@ -0,0 +1,42 @@
+libvirt-daemon: Expects qemu-bridge-helper in /usr/libexec/
+
+$ strings /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so | grep 
bridge-helper
+/usr/libexec/qemu-bridge-helper
+
+$ dpkg -S bridge-helper
+qemu-system-common: /usr/lib/qemu/qemu-bridge-helper
+
+Closes #816602
+--- a/src/qemu/qemu.conf
 b/src/qemu/qemu.conf
+@@ -357,7 +357,7 @@
+ # is used to create  interfaces when libvirtd is
+ # running unprivileged.  libvirt invokes the helper directly, instead
+ # of using "-netdev bridge", for security reasons.
+-#bridge_helper = "/usr/libexec/qemu-bridge-helper"
++#bridge_helper = "/usr/lib/qemu/qemu-bridge-helper"
+ 
+ 
+ 
+--- a/src/qemu/qemu_conf.c
 b/src/qemu/qemu_conf.c
+@@ -244,7 +244,7 @@ virQEMUDriverConfigPtr virQEMUDriverConf
+ goto error;
+ }
+ 
+-if (VIR_STRDUP(cfg->bridgeHelperName, "/usr/libexec/qemu-bridge-helper") 
< 0)
++if (VIR_STRDUP(cfg->bridgeHelperName, "/usr/lib/qemu/qemu-bridge-helper") 
< 0)
+ goto error;
+ 
+ cfg->clearEmulatorCapabilities = true;
+--- a/src/qemu/test_libvirtd_qemu.aug.in
 b/src/qemu/test_libvirtd_qemu.aug.in
+@@ -56,7 +56,7 @@ module Test_libvirtd_qemu =
+ { "auto_dump_bypass_cache" = "0" }
+ { "auto_start_bypass_cache" = "0" }
+ { "hugetlbfs_mount" = "/dev/hugepages" }
+-{ "bridge_helper" = "/usr/libexec/qemu-bridge-helper" }
++{ "bridge_helper" = "/usr/lib/qemu/qemu-bridge-helper" }
+ { "clear_emulator_capabilities" = "1" }
+ { "set_process_name" = "1" }
+ { "max_processes" = "0" }
diff -Nru libvirt-1.2.9/debian/patches/Disable-failing-virnetsockettest.patch 
libvirt-1.2.9/debian/patches/Disable-failing-virnetsockettest.patch
--- libvirt-1.2.9/debian/patches/Disable-failing-virnetsockettest.patch 
2015-08-24 16:20:54.0 +0200
+++ libvirt-1.2.9/debian/patches/Disable-failing-virnetsockettest.patch 
2016-03-04 14:47:12.0 +0100
@@ -7,11 +7,25 @@
  tests/virnetsockettest.c | 2 ++
  1 file changed, 2 insertions(+)
 
-diff --git a/tests/virnet

Bug#817015: jessie-pu: package libvirt/1.2.9-9+deb8u1

[Philipp Hahn]

Hello

Am 23.03.2016 um 21:55 schrieb Adam D. Barratt:
> Control: tags -1 + moreinfo
> 
> On Mon, 2016-03-07 at 07:22 +0100, Philipp Hahn wrote:
>> Guido asked me to prepare an update for libvirt:
>> - CVE-2015-5313 is marked 'no-dsa', but should be fixed anyway (#808273)
>>   Salvatore Bonaccorso (security team) asked me to prepare an update via
>>   jessie-proposed-updates.
>> - the SUID bridge-helper in searched in /usr/libexec/, while it realy is
>>   in /usr/lib/qemu/ (#816602)
>> While preparing the update I noticed that it FTBFS in my pbuilder
>> environment, requiring 3 more fixes.
> 
> The Build-Depends change makes me unhappy, but...
> 
> Please can we have an actual debdiff of the prepared (and tested)
> package, rather than the git patches?

Here it is:

> $ debdiff --from /var/cache/apt/archives/*libvirt*.deb --to *libvirt*.deb
> [The following lists of changes regard files as different if they have
> different names, permissions or owners.]
> 
> Files in second set of .debs but not in first
> -
> -rw-r--r--  root/root   /usr/share/doc/libvirt-bin/README.Debian.gz
> 
> Files in first set of .debs but not in second
> -
> -rw-r--r--  root/root   /usr/share/doc/libvirt-bin/README.Debian

The file is now compressed because the increase in size due to the added
paragraph.

> Control files of package libvirt-bin: lines which differ (wdiff format)
> ---
> Depends: libvirt-daemon-system (>= [-1.2.9-9+deb8u1),-] {+1.2.9-9+deb8u2),+} 
> libvirt-clients (>= [-1.2.9-9+deb8u1)-] {+1.2.9-9+deb8u2)+}
> Installed-Size: [-44-] {+74+}
> Version: [-1.2.9-9+deb8u1-] {+1.2.9-9+deb8u2+}
> 
> Control files of package libvirt-clients: lines which differ (wdiff format)
> ---
> Depends: libapparmor1 (>= 2.6~devel), [-libaudit1 (>= 1:2.2.1), 
> libavahi-client3 (>= 0.6.16), libavahi-common3 (>= 0.6.16),-] libc6 (>= 
> 2.17), [-libcap-ng0, libdbus-1-3 (>= 1.0.2), libdevmapper1.02.1 (>= 
> 2:1.02.20), libgnutls-deb0-28 (>= 3.3.0), libnl-3-200 (>= 3.2.7), 
> libnl-route-3-200 (>= 3.2.7), libnuma1,-] libreadline6 (>= 6.0), 
> [-libsasl2-2,-] libselinux1 (>= 1.32), [-libssh2-1 (>= 1.0), libsystemd0,-] 
> libvirt0 (= [-1.2.9-9+deb8u1),-] {+1.2.9-9+deb8u2),+} libxml2 (>= [-2.7.4), 
> libyajl2 (>= 2.0.4)-] {+2.7.4)+}
> Installed-Size: [-1594-] {+1637+}
> Version: [-1.2.9-9+deb8u1-] {+1.2.9-9+deb8u2+}
> 
> Control files of package libvirt-daemon: lines which differ (wdiff format)
> --
> Depends: libapparmor1 (>= 2.6~devel), libaudit1 (>= 1:2.2.1), 
> libavahi-client3 (>= 0.6.16), libavahi-common3 (>= 0.6.16), libblkid1 (>= 
> 2.17.2), libc6 (>= 2.17), libcap-ng0, libdbus-1-3 (>= 1.1.1), 
> libdevmapper1.02.1 (>= 2:1.02.90), libfuse2 (>= 2.8), libgnutls-deb0-28 (>= 
> 3.3.0), libnetcf1 (>= 1:0.2.2), libnl-3-200 (>= 3.2.7), libnl-route-3-200 (>= 
> 3.2.7), libnuma1, libparted2 (>= 3.1), libpcap0.8 (>= 1.0.0), libpciaccess0, 
> librados2 (>= 0.72.2), librbd1 (>= 0.72.2), libsasl2-2, libselinux1 (>= 
> 2.1.12), libssh2-1 (>= 1.2.8), libsystemd0, libudev1 (>= 183), libvirt0 (= 
> [-1.2.9-9+deb8u1),-] {+1.2.9-9+deb8u2),+} libxen-4.4 (>= 4.4.1), 
> libxenstore3.0 (>= 3.2.0), libxml2 (>= 2.7.4), libyajl2 (>= 2.0.4)
> Installed-Size: [-9046-] {+9242+}
> Version: [-1.2.9-9+deb8u1-] {+1.2.9-9+deb8u2+}
> 
> Control files of package libvirt-daemon-system: lines which differ (wdiff 
> format)
> -
> Depends: libapparmor1 (>= 2.6~devel), libaudit1 (>= 1:2.2.1), 
> [-libavahi-client3 (>= 0.6.16), libavahi-common3 (>= 0.6.16),-] libblkid1 (>= 
> 2.17.2), libc6 (>= 2.14), libcap-ng0, libdbus-1-3 (>= 1.0.2), 
> libdevmapper1.02.1 (>= 2:1.02.90), [-libgnutls-deb0-28 (>= 3.3.0),-] 
> libnl-3-200 (>= 3.2.7), libnl-route-3-200 (>= 3.2.7), libnuma1, librados2 (>= 
> 0.72.2), librbd1 (>= 0.72.2), [-libsasl2-2,-] libselinux1 (>= 1.32), 
> [-libssh2-1 (>= 1.0),-] libsystemd0, libvirt0 (>= 1.2.9~rc1), libxml2 (>= 
> 2.7.4), libyajl2 (>= 2.0.4), adduser, gettext-base, libvirt-clients (= 
> [-1.2.9-9+deb8u1),-] {+1.2.9-9+deb8u2),+} libvirt-daemon (= 
> [-1.2.9-9+deb8u1),-] {+1.2.9-9+deb8u2),+} logrotate, policykit-1
> Installed-Size: [-432-] {+636+}
> Version: [-1.2.9-9+deb8u1-] {+1.2.9-9+deb8u2+}

The changes in libraries are due to "ld --no-copy-dt

Bug#817015: jessie-pu: package libvirt/1.2.9-9+deb8u1

[Philipp Hahn]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Guido asked me to prepare an update for libvirt:
- CVE-2015-5313 is marked 'no-dsa', but should be fixed anyway (#808273)
  Salvatore Bonaccorso (security team) asked me to prepare an update via
  jessie-proposed-updates.
- the SUID bridge-helper in searched in /usr/libexec/, while it realy is
  in /usr/lib/qemu/ (#816602)
While preparing the update I noticed that it FTBFS in my pbuilder
environment, requiring 3 more fixes.

I'm running the binary on my amd64 system without problems: The CVE is
fixed and bridging works again.

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

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

>From fc0ddb2c5709e2b6ac4fc34fe66a275fc2388326 Mon Sep 17 00:00:00 2001
Message-Id: <fc0ddb2c5709e2b6ac4fc34fe66a275fc2388326.1457180803.git.h...@univention.de>
From: Philipp Hahn <h...@univention.de>
Date: Fri, 4 Mar 2016 11:57:52 +0100
Subject: [PATCH 1/6] Fix CVE-2015-5313
Organization: Univention GmbH, Bremen, Germany

Patches cherry-picked from upstream

Closes: #808273
---
 ...13-storage-don-t-allow-in-filesystem-volu.patch | 72 ++
 debian/patches/series  |  1 +
 2 files changed, 73 insertions(+)
 create mode 100644 debian/patches/security/CVE-2015-5313-storage-don-t-allow-in-filesystem-volu.patch

diff --git a/debian/patches/security/CVE-2015-5313-storage-don-t-allow-in-filesystem-volu.patch b/debian/patches/security/CVE-2015-5313-storage-don-t-allow-in-filesystem-volu.patch
new file mode 100644
index 000..90e9610
--- /dev/null
+++ b/debian/patches/security/CVE-2015-5313-storage-don-t-allow-in-filesystem-volu.patch
@@ -0,0 +1,72 @@
+From 034e47c338b13a95cf02106a3af912c1c5f818d7 Mon Sep 17 00:00:00 2001
+Message-Id: <034e47c338b13a95cf02106a3af912c1c5f818d7.1457088964.git.h...@univention.de>
+From: Eric Blake <ebl...@redhat.com>
+Date: Tue, 8 Dec 2015 17:46:31 -0700
+Subject: [PATCH] CVE-2015-5313: storage: don't allow '/' in filesystem volume
+ names
+Organization: Univention GmbH, Bremen, Germany
+To: libvir-l...@redhat.com
+
+The libvirt file system storage driver determines what file to
+act on by concatenating the pool location with the volume name.
+If a user is able to pick names like "../../../etc/passwd", then
+they can escape the bounds of the pool.  For that matter,
+virStoragePoolListVolumes() doesn't descend into subdirectories,
+so a user really shouldn't use a name with a slash.
+
+Normally, only privileged users can coerce libvirt into creating
+or opening existing files using the virStorageVol APIs; and such
+users already have full privilege to create any domain XML (so it
+is not an escalation of privilege).  But in the case of
+fine-grained ACLs, it is feasible that a user can be granted
+storage_vol:create but not domain:write, and it violates
+assumptions if such a user can abuse libvirt to access files
+outside of the storage pool.
+
+Therefore, prevent all use of volume names that contain "/",
+whether or not such a name is actually attempting to escape the
+pool.
+
+This changes things from:
+
+$ virsh vol-create-as default ../../../../../../etc/haha --capacity 128
+Vol ../../../../../../etc/haha created
+$ rm /etc/haha
+
+to:
+
+$ virsh vol-create-as default ../../../../../../etc/haha --capacity 128
+error: Failed to create vol ../../../../../../etc/haha
+error: Requested operation is not valid: volume name '../../../../../../etc/haha' cannot contain '/'
+
+Signed-off-by: Eric Blake <ebl...@redhat.com>
+---
+ src/storage/storage_backend_fs.c | 10 +-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/src/storage/storage_backend_fs.c
 b/src/storage/storage_backend_fs.c
+@@ -1,7 +1,7 @@
+ /*
+  * storage_backend_fs.c: storage backend for FS and directory handling
+  *
+- * Copyright (C) 2007-2014 Red Hat, Inc.
++ * Copyright (C) 2007-2015 Red Hat, Inc.
+  * Copyright (C) 2007-2008 Daniel P. Berrange
+  *
+  * This library is free software; you can redistribute it and/or
+@@ -1005,6 +1005,14 @@ virStorageBackendFileSystemVolCreate(vir
+ 
+ vol->type = VIR_STORAGE_VOL_FILE;
+ 
++/* Volumes within a directory pools are not recursive; do not
++ * allow escape to ../ or a subdir */
++if (strchr(vol->name, '/')) {
++virReportError(VIR_ERR_OPERATION_INVALID,
++   _("volume name '%s' cannot contain '/'"), vol->name);
++return -1;
++}
++
+ VIR_FREE(vol->target.path);
+ if (virAsprintf(>target.path, "%s/%s",
+ pool->def->target.path,
diff --git a/de

Bug#692803: git-pbuilder: does not allow arguments with spaces or special chars to pbuilder

[Philipp Hahn]

Hello,

Am 06.03.2016 um 10:18 schrieb Guido Günther:
> On Fri, Mar 04, 2016 at 03:59:10PM +0100, Philipp Hahn wrote:
>>> I: Running /usr/bin/dpkg-buildpackage -rfakeroot -us -uc ${DEBBUILDOPTS}
>>> dpkg-buildpackage: unknown option or argument '-sa'
>>>
>>> Use --help for program usage information.
> 
> Could you add examples how you invoke gbp to see the error. Is it just
> passing --use-pdebuild-internal as --git-pbuilder-options ?

I used "git-pbuilder -sa"

> I do think we need to skip the quoting in this case.

The quoting in pbuilder is horribly wrong.
When using --use-pdebuild-internal you must not do the quoting
git-pbuiler is now duing.
If you don't, den you need to do the extra quoting in git-pbuilder to
work around the quoting error in pbuilder.


Philipp

Bug#816602: closed by Guido Günther <g...@godiug.net> (Re: [Pkg-libvirt-maintainers] Bug#816602: libvirt-daemon: Expects qemu-bridge-helper in /usr/libexec/)

[Philipp Hahn]

Am 03.03.2016 um 17:51 schrieb Debian Bug Tracking System:
> This was already fixed in the above version so closing this (to have the
> bug information correct for the release team).

Doesn't seem to be fixed:

> $ wget 
> http://ftp.de.debian.org/debian/pool/main/libv/libvirt/libvirt-daemon_1.2.9-9+deb8u1_amd64.deb
> $ dpkg -x libvirt-daemon_1.2.9-9+deb8u1_amd64.deb tmp
> $ strings tmp/usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so | grep 
> bridge-helper
> /usr/libexec/qemu-bridge-helper

So Jessie looks still broken:

> $ apt-cache policy libvirt-daemon
> libvirt-daemon:
>   Installiert:   1.2.9-9+deb8u1
>   Installationskandidat: 1.2.9-9+deb8u1
>   Versionstabelle:
>  1.3.1-2 0
>  90 http://httpredir.debian.org/debian/ stretch/main amd64 Packages
>  *** 1.2.9-9+deb8u1 0
> 500 http://httpredir.debian.org/debian/ jessie/main amd64 Packages
> 100 /var/lib/dpkg/status

Philipp

Bug#692803: git-pbuilder: does not allow arguments with spaces or special chars to pbuilder

[Philipp Hahn]

Package: git-buildpackage
Version: 0.6.22
Followup-For: Bug #692803

Dear Maintainer,

/usr/bin/git-pbuilder contains:
> 266 # Add all of the additional arguments we got on the command line, but 
> quote
> 267 # them from the shell since they'll undergo another round of shell 
> expansion
> 268 # when the pbuilder runs debbuild.
...
> 270 for arg in "$@" ; do
...
> 274 DEBBUILDOPTS+=" $(shell_quote "$arg")"
> 275 done

This seems to be right only when *not* using --use-pdebuild-internal, as

/usr/lib/pbuilder/pdebuild-checkparams:
>  44 »···--debbuildopts)
>  45 »···DEBBUILDOPTS="${2:+$DEBBUILDOPTS $2}"
passes the argument unmodified, but then

/usr/bin/pdebuild:
>  46 if [ "${USE_PDEBUILD_INTERNAL}" = 'yes' ]; then
>  57 »···--debbuildopts "${DEBBUILDOPTS}" \
passes on the argument unmodified when using the internal pdebuild, but

>  74 else
>  78 echo "dpkg-buildpackage -S -us -uc -r${BUILDSOURCEROOTCMD} 
> $DEBBUILDOPTS" | \
>  80 »···/bin/bash
does splitting on IFS when not using it.
>  90 fi


For completeness:

/usr/lib/pbuilder/pdebuild-internal:
>  48 »···--debbuildopts)
>  50 »···DEBBUILDOPTS="${2:+${DEBBUILDOPTS:+$DEBBUILDOPTS }$2}";
un-splitted
> 123 export DEBBUILDOPTS
> 124 CMD="/usr/bin/dpkg-buildpackage -rfakeroot -us -uc "'${DEBBUILDOPTS}'
> 128 if echo "$CMD" | \
> 129 su -p pbuser;·

does *not* spit on IFS, so DEBBUILDOPTS still contains the 's from 
shell_quote() leading to the error

> I: Running /usr/bin/dpkg-buildpackage -rfakeroot -us -uc ${DEBBUILDOPTS}
> dpkg-buildpackage: unknown option or argument '-sa'
>
> Use --help for program usage information.

Philipp

PS: I still wonder why --use-pdebuild-internal is not the default, as I
don't want to pollute my development environment with all those build
dependencies. That makes running "debian/rules clean" sometimes more
complicate as I'm missing some required dependencies for that, but
still..."
-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (90, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages git-buildpackage depends on:
ii  devscripts2.15.3
ii  git   1:2.1.4-2.1+deb8u1
ii  man-db2.7.0.2-5
ii  python2.7.9-1
ii  python-dateutil   2.2-2
ii  python-pkg-resources  5.5.1-1

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.73
ii  pristine-tar  1.33

Versions of packages git-buildpackage suggests:
pn  python-notify  
ii  unzip  6.0-16+deb8u2

-- no debconf information

Bug#816602: libvirt-daemon: Expects qemu-bridge-helper in /usr/libexec/

[Philipp Hahn]

Package: libvirt-daemon
Version: 1.2.9-9+deb8u1
Severity: normal

Hi Guido,

$ strings /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so | grep 
bridge-helper
/usr/libexec/qemu-bridge-helper

# dpkg -S bridge-helper
qemu-system-common: /usr/lib/qemu/qemu-bridge-helper


As 
seems to never got applied, the helper is also missing the required
capability CAP_NET_ADMIN, which must be added by running
setcap cap_net_admin+ep /usr/lib/qemu/qemu-bridge-helper

I choose to put that information in the README.Debian.

Greeting
Philipp

PS: I hope I didn't break some test-suite - at least building the new
version in my pbuilder environment worked okay.

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

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

Versions of packages libvirt-daemon depends on:
ii  libapparmor12.9.0-3
ii  libaudit1   1:2.4-1+b1
ii  libavahi-client30.6.31-5
ii  libavahi-common30.6.31-5
ii  libblkid1   2.25.2-6
ii  libc6   2.19-18+deb8u3
ii  libcap-ng0  0.7.4-2
ii  libdbus-1-3 1.8.20-0+deb8u1
ii  libdevmapper1.02.1  2:1.02.90-2.2
ii  libfuse22.9.3-15+deb8u2
ii  libgnutls-deb0-28   3.3.8-6+deb8u3
ii  libnetcf1   1:0.2.3-4.1
ii  libnl-3-200 3.2.24-2
ii  libnl-route-3-200   3.2.24-2
ii  libnuma12.0.10-1
ii  libparted2  3.2-7
ii  libpcap0.8  1.6.2-2
ii  libpciaccess0   0.13.2-3+b1
ii  librados2   0.80.7-2+deb8u1
ii  librbd1 0.80.7-2+deb8u1
ii  libsasl2-2  2.1.26.dfsg1-13+deb8u1
ii  libselinux1 2.3-2
ii  libssh2-1   1.4.3-4.1+deb8u1
ii  libsystemd0 215-17+deb8u3
ii  libudev1215-17+deb8u3
ii  libvirt01.2.9-9+deb8u1
ii  libxen-4.4  4.4.1-9+deb8u3
ii  libxenstore3.0  4.4.1-9+deb8u3
ii  libxml2 2.9.1+dfsg1-5+deb8u1
ii  libyajl22.1.0-2

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.1+dfsg1-5+deb8u1
ii  netcat-openbsd  1.105-7
ii  qemu-kvm1:2.1+dfsg-12+deb8u5a

Versions of packages libvirt-daemon suggests:
ii  libvirt-daemon-system  1.2.9-9+deb8u1

-- no debconf information
--- a/src/qemu/qemu.conf
+++ b/src/qemu/qemu.conf
@@ -357,7 +357,7 @@
 # is used to create  interfaces when libvirtd is
 # running unprivileged.  libvirt invokes the helper directly, instead
 # of using "-netdev bridge", for security reasons.
-#bridge_helper = "/usr/libexec/qemu-bridge-helper"
+#bridge_helper = "/usr/lib/qemu/qemu-bridge-helper"
 
 
 
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -244,7 +244,7 @@ virQEMUDriverConfigPtr virQEMUDriverConf
 goto error;
 }
 
-if (VIR_STRDUP(cfg->bridgeHelperName, "/usr/libexec/qemu-bridge-helper") < 0)
+if (VIR_STRDUP(cfg->bridgeHelperName, "/usr/lib/qemu/qemu-bridge-helper") < 0)
 goto error;
 
 cfg->clearEmulatorCapabilities = true;
--- a/src/qemu/test_libvirtd_qemu.aug.in
+++ b/src/qemu/test_libvirtd_qemu.aug.in
@@ -56,7 +56,7 @@ module Test_libvirtd_qemu =
 { "auto_dump_bypass_cache" = "0" }
 { "auto_start_bypass_cache" = "0" }
 { "hugetlbfs_mount" = "/dev/hugepages" }
-{ "bridge_helper" = "/usr/libexec/qemu-bridge-helper" }
+{ "bridge_helper" = "/usr/lib/qemu/qemu-bridge-helper" }
 { "clear_emulator_capabilities" = "1" }
 { "set_process_name" = "1" }
 { "max_processes" = "0" }
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -51,6 +51,18 @@ EOF
 This makes dnsmasq only bind to the loopback interface by default so libvirtd
 can handle the virtual bridges.
 
+Bridged network
+===
+libvirt can use the qemu-bridge-helper to create bridged network interfaces for
+session domains. For this to work the helper must have the capability to create
+TUN/TAP devices or must have the SUID permission set.
+This can be done by running the following command as the user root:
+
+setcap cap_net_admin+ep /usr/lib/qemu/qemu-bridge-helper
+
+The allowed bridges must be configured in the file '/etc/qemu/bridge.conf'. For
+each bridge add a line like 'allow br0'.
+
 Access Control
 ==
 Access to the libvirt managing tasks is controlled by PolicyKit. To ease

Bug#815653: isc-dhcp: FTBFS debian/rules .NOTPARALLEL:

[Philipp Hahn]

Source: isc-dhcp
Version: 4.2.2.dfsg.1-5+deb70u8
Severity: normal

Dear Maintainer,

The package fails-to-build-from-source when using -jX, as debian/rules
has
> install-stamp: build-ldap-stamp build-non-ldap-stamp
which builds both versions in parallel in the same directory: One ./configure
run overwrites the output of the other ./configure run leading one to fail with
error like
> checking for gcc... gcc
> grep: conftest.er1: No such file or directory
> cat: conftest.er1: No such file or directory
or later on during compile like
> In file included from ../includes/omapip/isclib.h:57:0,
>  from ../includes/dhcpd.h:95,
>  from alloc.c:35:
> ../bind/include/isc/socket.h:170:21: error: field 'pktinfo' has incomplete 
> type

Please consider adding the make special target ".NOTPARALLEL:" to
debian/rules in Wheezy-Security or -LTS to force a sequential built.

Jessie/Stretch/Sid are unaffected as they were converted to "dh" and
both ./configure are invoked sequentially there in
"override_dh_auto_build".

Otherwise FYI.

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

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

Bug#808242: phantomjs: Does not run headless

[Philipp Hahn]

Package: phantomjs
Version: 2.0.0+dfsg-1
Severity: important

Dear Maintainer,

phantomjs crashes when it can't connect to X11, which is bad for a
package calling itself "minimalistic _headless_ WebKit-based with
JavaScript":

> $ LANG=C DISPLAY= phantomjs  --help
> QXcbConnection: Could not connect to display 
> PhantomJS has crashed. Please read the crash reporting guide at
>  and file a bug report at
> .
> Please attach the crash dump file:
>   /tmp/0bb4faa5-a568-ed5a-3086b306-449d0771.dmp
> Abgebrochen

Not reported upstream as Debian differs from upstream by using Debians
Qt.

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

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

Bug#802652: g15daemon: Wrong package description

[Philipp Hahn]

Package: g15daemon
Version: libg15daemon-client1
Severity: minor

Dear Maintainer,

the description for "libg15daemon-client1" is wrong and talks about 
'development files'.
I think it's a copy/paste error from "libg15daemon-client-dev".
While updating the text, please also move the words "Logitech G11/G15 
keyboards" into the short summary, as this makes the output of "dpkg -l" and 
other tools more useful for users not knowing whar "g15" is.

Find attached my updated version of debian/control.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Source: g15daemon
Section: utils
Priority: extra
Maintainer: Giacomo Catenazzi 
Build-Depends: cdbs, debhelper (>= 5), autotools-dev, libtool, chrpath,
 libg15-dev, libg15render-dev (>=1.2.0.svn250-2), libusb-dev, libfreetype6-dev
Standards-Version: 3.8.2
Homepage: http://www.g15tools.com/

Package: g15daemon
Section: utils
Architecture: any
Depends: libg15daemon-client1 (=${binary:Version}), ${shlibs:Depends}, 
${misc:Depends},
Recommends: xkb-data ( >= 0.9+cvs.20070428-1)
Description: screen multiplexer for Logitech G11/G15 keyboards
 G15daemon provides multiple virtual screens for the LCD on the Logitech
 G11 and G15 keyboards.
 .
 This package contain the daemon and a generic client to talk to the
 daemon.

Package: libg15daemon-client1
Section: libs
Priority: optional
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: library for interfacing Logitech G11/G15 keyboards
 G15daemon provides multiple virtual screens for the LCD on the Logitech
 G11 and G15 keyboards.
 .
 This package contains the shared libraries.

Package: libg15daemon-client-dev
Section: libdevel
Architecture: any
Depends: libg15daemon-client1 (= ${binary:Version}), ${misc:Depends}
Description: development package for interfacing Logitech G11/G15 keyboards
 G15daemon provides multiple virtual screens for the LCD on the Logitech
 G11 and G15 keyboards.
 .
 Includes the files needed for developing g15daemon clients.

Bug#609427: pbuilder: Shoud make --bind mounts private

[Philipp Hahn]

Package: pbuilder
Version: 0.215+nmu3
Followup-For: Bug #609427

Dear Maintainer,

I'm currently looking at a problem with jenkins-debian-glue: I build
multiple packages in parallel, as my host has multiple CPUs. I have the
strange phenomenon, that the 2nd cowbuilder environment seems to get
mounted inside the 1st and prevent cleanly unmounting it:

$ ps axfu
...
> jenkins   8544  0.0  0.0  1859636 ?SAug25   0:00 
> /usr/bin/daemon --name=jenkins --inherit --env=JENKINS_HOME=/var/lib/jenkins 
> --output=/var/log/jenkins/jenkins.log --pidfile=/var/run/jenkins/jenkins.pid 
> -- /usr/bin/java -
> jenkins   8553  0.5 12.6 2535184 507312 ?  Sl   Aug25  16:11  \_ 
> /usr/bin/java -Djava.awt.headless=true -jar /usr/share/jenkins/jenkins.war 
> --webroot=/var/cache/jenkins/war --httpPort=8080 --ajp13Port=-1
> jenkins   8804  0.0  0.0  13864  3584 ?S14:18   0:00  \_ 
> /bin/bash /usr/bin/build-and-provide-package
> root 10948  0.0  0.0  40592  3324 ?S14:18   0:00  |   \_ 
> sudo DIST= ARCH=amd64 ADT=skip cowbuilder --buildresult 
> /srv/jenkins/workspace/ucs-3.2-G00R05C02P1-master/in8-config-binaries/architecture/amd64/binaries/
>  --bui
> root 10949  0.0  0.0   4232  1308 ?S14:18   0:00  |   
> \_ cowbuilder --buildresult 
> /srv/jenkins/workspace/ucs-3.2-G00R05C02P1-master/in8-config-binaries/architecture/amd64/binaries/
>  --build /srv/jenkins/workspace/u
> root 10973  0.0  0.0  13292  2556 ?S14:18   0:00  |   
> \_ /bin/bash /usr/sbin/pbuilder build --debbuildopts -sa --hookdir 
> /usr/share/jenkins-debian-glue/pbuilder-hookdir/ --bindmounts /tmp/apt-8804 
> /var/cache/p
> root 10974  0.1  0.0  13708  3492 ?S14:18   0:00  |   
> \_ /bin/bash /usr/lib/pbuilder/pbuilder-buildpackage --debbuildopts 
> -sa --hookdir /usr/share/jenkins-debian-glue/pbuilder-hookdir/ --bindmounts 
> /tmp/ap
> root 12395  0.0  0.0  11800  2764 ?S14:18   0:00  |   
> \_ /bin/bash /usr/lib/pbuilder/pbuilder-satisfydepends --control 
> /srv/jenkins/workspace/ucs-3.2-G00R05C02P1-master/in8-config-binaries/architecture
> root 12955  5.7  1.3 173324 54948 ?Sl   14:18   0:01  |   
> \_ aptitude -y --without-recommends -o 
> APT::Install-Recommends=false -o Aptitude::ProblemResolver::StepScore=100 -o 
> Aptitude::ProblemResolver::
> root 12969  3.1  0.1  23936  7088 ?D14:18   0:00  |   
> \_ /usr/bin/dpkg --status-fd 113 --unpack 
> --auto-deconfigure 
> /var/cache/apt/archives/bsdmainutils_8.0.13.11.201104201320_amd64.deb /var/cac
> jenkins   9148  0.0  0.0  13864  3588 ?S14:18   0:00  \_ 
> /bin/bash /usr/bin/build-and-provide-package
> root 11323  0.0  0.0  40592  3440 ?S14:18   0:00  \_ 
> sudo DIST= ARCH=amd64 ADT=skip cowbuilder --buildresult 
> /srv/jenkins/workspace/ucs-3.2-G00R05C02P1-master/in8-soap-transport-binaries/architecture/amd64/binarie
> root 11327  0.0  0.0   4232  1472 ?S14:18   0:00  
> \_ cowbuilder --buildresult 
> /srv/jenkins/workspace/ucs-3.2-G00R05C02P1-master/in8-soap-transport-binaries/architecture/amd64/binaries/
>  --build /srv/jenkins/wor
> root 11618  0.0  0.0  13296  2636 ?S14:18   0:00  
> \_ /bin/bash /usr/sbin/pbuilder build --debbuildopts -sa --hookdir 
> /usr/share/jenkins-debian-glue/pbuilder-hookdir/ --bindmounts /tmp/apt-9148 
> /var/cache/p
> root 11621  0.0  0.0  13712  3432 ?S14:18   0:00  
> \_ /bin/bash /usr/lib/pbuilder/pbuilder-buildpackage --debbuildopts 
> -sa --hookdir /usr/share/jenkins-debian-glue/pbuilder-hookdir/ --bindmounts 
> /tmp/ap
> root 12873  0.0  0.0  11800  2692 ?S14:18   0:00  
> \_ /bin/bash /usr/lib/pbuilder/pbuilder-satisfydepends --control 
> /srv/jenkins/workspace/ucs-3.2-G00R05C02P1-master/in8-soap-transport-binaries/arch
> root 12960  6.1  1.3 115052 54724 ?Sl   14:18   0:01  
> \_ aptitude -y --without-recommends -o 
> APT::Install-Recommends=false -o Aptitude::ProblemResolver::StepScore=100 -o 
> Aptitude::ProblemResolver::
> root 12990  2.9  0.1  23988  7140 ?D14:18   0:00  
> \_ /usr/bin/dpkg --status-fd 113 --unpack 
> --auto-deconfigure 
> /var/cache/apt/archives/bsdmainutils_8.0.13.11.201104201320_amd64.deb /var/cac

$ pidof cowbuilder
> 11327 10949

$ mount | grep --color /var/cache/pbuilder/build
> /proc on /var/cache/pbuilder/build/cow.10949/proc type proc (rw,relatime)
> tmpfs on /var/cache/pbuilder/build/cow.10949/run/shm type tmpfs (rw,relatime)
> /dev/pts on /var/cache/pbuilder/build/cow.10949/dev/pts type devpts 
> (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
> /dev/md0 on /var/cache/pbuilder/build/cow.10949/tmp/apt-8804 type ext4 
> 

Bug#713967: Bug#790941: partman-md: RAID10 not configurable by preseeding

[Philipp Hahn]

Hi,

On 10.07.2015 00:45, Cyril Brulebois wrote:
 Philipp Hahn h...@univention.de (2015-07-03):
 Package: partman-md
...
 As partman-md/raid10layout is force-set to n2 by the script itself,
 the question is never asked for, and overwrites what is specified by
 preseeding.
 
 Thanks for the report and the patch. Out of curiosity, did you
 actually test it works fine?

Yes, the pre-seeding works, but as I learned yesterday partman-md is
only available when the installed is used interactively.
partman-auto-raid has its own hall to create the RAID, where the
leyout cannot be specified.
That is why I sent those two additional patches for partman-raid and
debian-installer (where its documentation is stored).

Philipp Hahn



signature.asc
Description: OpenPGP digital signature

Bug#790941: [PATCH] Support additional arguments to mdadm DOC

[Philipp Hahn]

Needed for --layout o2.
Spaces must be substituted by '#'.
---
 doc/devel/partman-auto-raid-recipe.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/doc/devel/partman-auto-raid-recipe.txt 
b/doc/devel/partman-auto-raid-recipe.txt
index daa7727..87d0fd1 100644
--- a/doc/devel/partman-auto-raid-recipe.txt
+++ b/doc/devel/partman-auto-raid-recipe.txt
@@ -5,12 +5,15 @@ it how to construct the RAID array(s).
 The preseedable parameter partman-auto-raid/recipe should consist of
 recipes separated by periods (.). The recipes are of the form:
 
-raidtype devcount sparecount fstype mountpoint devices 
sparedevices
+raidtype devcount sparecount fstype mountpoint devices 
sparedevices extra-args
 
 where devices is a list of the devices to make up the RAID and
 sparedevices is a list of the spare devices in the array; devices are
 separated by hashes (#).
 
+extra-args can be used to pass extra arguments to mdadm --create, like 
--layout o2.
+Blanks must be substituted by hashes (#), e.g. you have to specify 
--layout#o2.
+
 For example:
 d-i partman-auto-raid recipe string  \
   1 2 0 ext3 / /dev/sda1#/dev/sdb1 . \
-- 
1.9.1


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

Bug#790941: [PATCH] Support additional arguments to mdadm

[Philipp Hahn]

Needed for --layout o2.
Spaces must be substituted by '#'.
---
 auto-raidcfg | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/auto-raidcfg b/auto-raidcfg
index 01722c1..f0d4643 100755
--- a/auto-raidcfg
+++ b/auto-raidcfg
@@ -21,12 +21,9 @@ create_raid() {
 
FS_TYPE=$4
MOUNTPOINT=$5
-   DEVICES=$6
-   SPARE_DEVICES=$7
-
-   RAID_DEVICES=$(echo $DEVICES | sed -e s/#/ /g)
-
-   SPARE_DEVICES=$(echo $SPARE_DEVICES | sed -e s/#/ /g)
+   RAID_DEVICES=$(echo $6 | sed -e s/#/ /g)
+   SPARE_DEVICES=$(echo $7 | sed -e s/#/ /g)
+   EXTRA_ARGS=$(echo $8 | sed -e s/#/ /g)
 
NAMED_SPARES=$(echo $SPARE_DEVICES | wc -w)
 
@@ -76,7 +73,7 @@ create_raid() {
 
if ! log-output -t partman-auto-raid \
mdadm --create /dev/md$MD_NUM --auto=yes --force -R -l 
raid$RAID_TYPE \
- -n $DEV_COUNT $MDADM_PARAMS
+ -n $DEV_COUNT $MDADM_PARAMS $EXTRA_ARGS
then
logger -t partman-auto-raid Error creating array 
/dev/md$MD_NUM
exit 1
@@ -119,10 +116,10 @@ while [ -n $recipes ]; do
 
# Do the recipe!
echo $recipe /tmp/partman-auto-raid-recipe
-   read raidtype devcount sparecount fstype mountpoint devs sparedevs \
+   read raidtype devcount sparecount fstype mountpoint devs sparedevs args 
\
/tmp/partman-auto-raid-recipe
create_raid $raidtype $devcount $sparecount $fstype $mountpoint \
-   $devs $sparedevs
+   $devs $sparedevs $args
 done
 
 exit 0
-- 
1.9.1


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

Bug#790941: partman-md: RAID10 not configurable by preseeding

[Philipp Hahn]

Package: partman-md
Version: 75
Severity: normal

Dear Maintainer,

As partman-md/raid10layout is force-set to n2 by the script itself,
the question is never asked for, and overwrites what is specified by
preseeding.

diff --git a/choose_partition/md/do_option b/choose_partition/md/do_option
index b3f7c02..e29cc02 100755
--- a/choose_partition/md/do_option
+++ b/choose_partition/md/do_option
@@ -226,7 +226,6 @@ md_create_array () {
 
local layout=
if [ $level -eq 10 ]; then
-   db_set partman-md/raid10layout n2
while :; do
db_input low partman-md/raid10layout
db_go || return
diff --git a/debian/partman-md.templates b/debian/partman-md.templates
index 738e434..da1e867 100644
--- a/debian/partman-md.templates
+++ b/debian/partman-md.templates
@@ -109,6 +109,7 @@ _Description: Not enough RAID partitions available
 
 Template: partman-md/raid10layout
 Type: string
+Default: n2
 # :sl3:
 _Description: Layout of the RAID10 array:
  The layout must be n, o, or f (arrangement of the copies) followed

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

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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#713967: apache2-bin: daemon doesn't close all fds on fork - which causes postinst with debconf to hang

[Philipp Hahn]

Package: apache2
Version: 2.2.22-13+deb7u4
Followup-For: Bug #713967

I filed https://bz.apache.org/bugzilla/show_bug.cgi?id=57671 with
Apache-APR for this issue.

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

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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#753545: Fix symbolic link de_LA.dic

[Philipp Hahn]

Hi,

see attached patch to fix the link creation in debian/rules.

Sincerely
Philipp Hahn
-- 
Philipp Hahn   Open Source Software Engineer  h...@univention.de
Univention GmbHbe open.   fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen fax: +49 421 22 232-99
   http://www.univention.de/
Director:Peter H. Ganten   HRB 20755 Amtsgericht Bremen   UID:DE 220 051 310
--- igerman98-20120607/debian/rules.orig	2015-02-23 12:17:35.617421105 +
+++ igerman98-20120607/debian/rules	2015-02-23 12:17:43.653443689 +
@@ -194,7 +194,7 @@
 		ln -s de_DE.aff de_BE.aff; \
 		ln -s de_DE.dic de_BE.dic; \
 		ln -s de_DE.aff de_LU.aff; \
-		ln -s de_DE.aff de_LU.dic)
+		ln -s de_DE.dic de_LU.dic)
 	(cd $(DROOT)/hunspell-de-de/usr/share/myspell/dicts; \
 		ln -s ../../hunspell/de_DE.aff de_DE.aff; \
 		ln -s ../../hunspell/de_DE.dic de_DE.dic; \

Bug#766989: iscsitarget: FTBFS in chroot: builds for current kernel instead of kernel in chroot

[Philipp Hahn]

Package: iscsitarget
Version: 1.4.20.3+svn502-1
Severity: normal
Tags: patch

Dear Maintainer,

installing iscsitarget-dksm in a chroot environment with a different
kernel fails, because the module is built for the currently curring
kernel (uname -r) instead of the kernel available in the chroot
environment.

dh_dkms seems to have some logic to build for all (or only for the
available kernsl). As the DebHelper is not used in debian/rules, it
fails.

Use dh_dkms to patch in the current version and to add the magic to
compile for the correct kernel version.
-- System Information:
Debian Release: 7.7
  APT prefers stable
  APT policy: (900, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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


0001-Bug-35875-DKMS-iscsitarget.patch
Description: /home/phahn/.magic

Bug#742487: Update of python-ldap to upstream version 2.4.15

[Philipp Hahn]

retitle 742487 Update of python-ldap to upstream version 2.4.16
tag 742487 patch
thanks

Hello,

On 10.09.2014 14:19, Michael Ströder wrote:
 Philipp Hahn wrote:
 The attached version contains my fix for that problem, which I sent
 upstream and which is already committed to the maintainers CVS
 repository:
 http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Lib/ldap/ldapobject.py?r1=1.139r2=1.141
 
 I prefer not having to bear in mind backport fixes in distri packages.
 
 Therefore I've release 2.4.16. I would appreciate if you would package that
 (after locally testing the release).

Attached is 2.4.16.
It survived our internal nightly test run for UCS.



python-ldap_2.4.16-0.1.debian.tar.gz
Description: application/gzip
Format: 3.0 (quilt)
Source: python-ldap
Binary: python-ldap, python-ldap-dbg
Architecture: any
Version: 2.4.16-0.1
Maintainer: Matej Vela v...@debian.org
Homepage: http://www.python-ldap.org/
Standards-Version: 3.9.3
Build-Depends: debhelper (= 8), python-all-dev (= 2.6.6-3~), python-all-dbg, 
libldap2-dev, libsasl2-dev
Package-List: 
 python-ldap deb python optional
 python-ldap-dbg deb debug extra
Checksums-Sha1: 
 e25e1edda67ced26a31e8b7a68eb003c039ba21a 137873 python-ldap_2.4.16.orig.tar.gz
 3b0aef3825d7642aa62440f76b5738faecb03c79 6411 
python-ldap_2.4.16-0.1.debian.tar.gz
Checksums-Sha256: 
 524de8a99a2cf001e8d69b8e86b2bd4af18f6b9b3057bbd2ead2758ae5ac1443 137873 
python-ldap_2.4.16.orig.tar.gz
 253f6019e3c52a4bc0218d0fc920e2a37ff089ecca5fc33f16144625b0510fa0 6411 
python-ldap_2.4.16-0.1.debian.tar.gz
Files: 
 75549bad7eaaf4949f6adf80334f0acc 137873 python-ldap_2.4.16.orig.tar.gz
 9f0b95975ce2c8ceb5058b4d84a42ab1 6411 python-ldap_2.4.16-0.1.debian.tar.gz

Bug#742487: Update of python-ldap to upstream version 2.4.15

[Philipp Hahn]

Hello,

On 04.09.2014 09:45, Philipp Hahn wrote:
 find attached the Debian source files for python-ldap 2.4.15. The
 .orig.tar.gz is available from
 https://pypi.python.org/packages/source/p/python-ldap/python-ldap-2.4.15.tar.gz#md5=f12183c87579631584c4bbe2d85ad0d9
 - only debian/patches/01_setup_cfg.diff need refreshing
 
 The version still seems to be prone to dead-locks, as it stills fails
 for one of our test cases in UCS; 2.4.10 is also known to have that bug.
 I'm continuing my investigation.

The attached version contains my fix for that problem, which I sent
upstream and which is already committed to the maintainers CVS
repository:
http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Lib/ldap/ldapobject.py?r1=1.139r2=1.141

PS: We'll use that version in our Debian based distribution UCS-4.0
instead of the currently broken 2.4.10 from Debian-Wheezy.


python-ldap_2.4.15-0.1.debian.tar.gz
Description: application/gzip
Format: 3.0 (quilt)
Source: python-ldap
Binary: python-ldap, python-ldap-dbg
Architecture: any
Version: 2.4.15-0.1
Maintainer: Matej Vela v...@debian.org
Homepage: http://www.python-ldap.org/
Standards-Version: 3.9.3
Build-Depends: debhelper (= 8), python-all-dev (= 2.6.6-3~), python-all-dbg, 
libldap2-dev, libsasl2-dev
Package-List: 
 python-ldap deb python optional
 python-ldap-dbg deb debug extra
Checksums-Sha1: 
 cfd116af0c0d71d250a8cf31d32051f81e3b6310 111597 python-ldap_2.4.15.orig.tar.gz
 ab0ab33714c000221eba8646103c32a25b33ead1 6641 
python-ldap_2.4.15-0.1.debian.tar.gz
Checksums-Sha256: 
 30bcac33ded943557fbafb1b6d9c345deab34d89d63dbcee9e6b59207db11670 111597 
python-ldap_2.4.15.orig.tar.gz
 f7887b957523f7e0a8775374d30ff2d42ebfac677bec9cbc332c494e22624086 6641 
python-ldap_2.4.15-0.1.debian.tar.gz
Files: 
 f12183c87579631584c4bbe2d85ad0d9 111597 python-ldap_2.4.15.orig.tar.gz
 acc9a1bd60cc6a07d9a288c97ceceee9 6641 python-ldap_2.4.15-0.1.debian.tar.gz


signature.asc
Description: OpenPGP digital signature

Bug#742487: Update of python-ldap to upstream version 2.4.15

[Philipp Hahn]

Hello,

find attached the Debian source files for python-ldap 2.4.15. The
.orig.tar.gz is available from
https://pypi.python.org/packages/source/p/python-ldap/python-ldap-2.4.15.tar.gz#md5=f12183c87579631584c4bbe2d85ad0d9
- only debian/patches/01_setup_cfg.diff need refreshing

The version still seems to be prone to dead-locks, as it stills fails
for one of our test cases in UCS; 2.4.10 is also known to have that bug.
I'm continuing my investigation.

Sincerely
Philipp
-- 
Philipp Hahn   Open Source Software Engineer  h...@univention.de
Univention GmbHbe open.   fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen fax: +49 421 22 232-99
   http://www.univention.de/
Director:Peter H. Ganten   HRB 20755 Amtsgericht Bremen   UID:DE 220 051 310
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Wed, 03 Sep 2014 15:19:40 +
Source: python-ldap
Binary: python-ldap python-ldap-dbg
Architecture: source amd64
Version: 2.4.15-0.1
Distribution: unstable
Urgency: low
Maintainer: Matej Vela v...@debian.org
Changed-By: Philipp Matthias Hahn pmh...@debian.org
Description: 
 python-ldap - LDAP interface module for Python
 python-ldap-dbg - LDAP interface module for Python (debug extension)
Closes: 742487
Changes: 
 python-ldap (2.4.15-0.1) unstable; urgency=low
 .
   * NMU.
   * New upstream release. Closes: #742487
   * debian/patches/01_setup_cfg.diff: refresh
Checksums-Sha1: 
 728d04e58a8026d2c54ce6623584f5c8c349560d 1220 python-ldap_2.4.15-0.1.dsc
 cfd116af0c0d71d250a8cf31d32051f81e3b6310 111597 python-ldap_2.4.15.orig.tar.gz
 2579c7b0140cbd01624afaeae8628b63676f2167 6301 
python-ldap_2.4.15-0.1.debian.tar.gz
 9b9173dfd75f6387cad6dc65a52d4f11b7033570 121910 
python-ldap_2.4.15-0.1_amd64.deb
 45197a335b745a843a2f1aad38a43acdf5e8768c 266372 
python-ldap-dbg_2.4.15-0.1_amd64.deb
Checksums-Sha256: 
 95de45d00bb4a9769673c627a529cf589b1a2ac68c48e6bc137ec92a1736e80b 1220 
python-ldap_2.4.15-0.1.dsc
 30bcac33ded943557fbafb1b6d9c345deab34d89d63dbcee9e6b59207db11670 111597 
python-ldap_2.4.15.orig.tar.gz
 7ced7e05728ae8b8136397fc70442f95e8bcc4a874c40d9e06c0f839ba5fe875 6301 
python-ldap_2.4.15-0.1.debian.tar.gz
 f8fbfa1572f76fe23447c7cdedb90ed69d5cc212ca32bbbc576286ebd2941f2b 121910 
python-ldap_2.4.15-0.1_amd64.deb
 df51bd28166f7a4987c2a57975467674ae56ff6028d77d6a6b19426e05215f5b 266372 
python-ldap-dbg_2.4.15-0.1_amd64.deb
Files: 
 275b1fcf2cab7fbce2d42352720dc1fd 1220 python optional 
python-ldap_2.4.15-0.1.dsc
 f12183c87579631584c4bbe2d85ad0d9 111597 python optional 
python-ldap_2.4.15.orig.tar.gz
 25c78b74eb460826706892c05f69f794 6301 python optional 
python-ldap_2.4.15-0.1.debian.tar.gz
 7c972524c914ced98775e73dd6364b49 121910 python optional 
python-ldap_2.4.15-0.1_amd64.deb
 9f080e53c82dc9ce8be5028865b1b4fc 266372 debug extra 
python-ldap-dbg_2.4.15-0.1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlQIFyUACgkQYPlgoZpUDjnLvwCdHlrVy7Xrm78s+wC+EbH02t9Q
pO4AnA8oK14sH8hYoCokDArZYmfTowO1
=DbmU
-END PGP SIGNATURE-


python-ldap_2.4.15-0.1.debian.tar.gz
Description: Binary data
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 3.0 (quilt)
Source: python-ldap
Binary: python-ldap, python-ldap-dbg
Architecture: any
Version: 2.4.15-0.1
Maintainer: Matej Vela v...@debian.org
Homepage: http://www.python-ldap.org/
Standards-Version: 3.9.3
Build-Depends: debhelper (= 8), python-all-dev (= 2.6.6-3~), python-all-dbg, 
libldap2-dev, libsasl2-dev
Package-List: 
 python-ldap deb python optional
 python-ldap-dbg deb debug extra
Checksums-Sha1: 
 cfd116af0c0d71d250a8cf31d32051f81e3b6310 111597 python-ldap_2.4.15.orig.tar.gz
 2579c7b0140cbd01624afaeae8628b63676f2167 6301 
python-ldap_2.4.15-0.1.debian.tar.gz
Checksums-Sha256: 
 30bcac33ded943557fbafb1b6d9c345deab34d89d63dbcee9e6b59207db11670 111597 
python-ldap_2.4.15.orig.tar.gz
 7ced7e05728ae8b8136397fc70442f95e8bcc4a874c40d9e06c0f839ba5fe875 6301 
python-ldap_2.4.15-0.1.debian.tar.gz
Files: 
 f12183c87579631584c4bbe2d85ad0d9 111597 python-ldap_2.4.15.orig.tar.gz
 25c78b74eb460826706892c05f69f794 6301 python-ldap_2.4.15-0.1.debian.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlQIFyEACgkQYPlgoZpUDjle8gCgt8j3S+Tv18kLavavv1aINJRi
gaoAn3LFLfqbZp6iMKfdFKS7EDYqkpSH
=dWRZ
-END PGP SIGNATURE-


signature.asc
Description: Digital signature

Bug#759343: debian-cd: Improve correctImprove correctstatus speed

[Philipp Hahn]

Package: debian-cd
Version: 3.1.15
Severity: wishlist
Tags: d-i patch

Using dumpavail dumps all packages, while we're only interested in one
specific package. This wasts a log of cycles and time when many packages
need fixing.

Use show $pkg to directly dump only the requested package.

Use --no-all-versions to show only the candidate for installation.

This change reduces our UCS DVD build time from 9.64m down to 7.19m.
I've testes the patch on our amd64 and it did non change the content of
our DVD. More testing is appreciated.

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

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


0001-Use-apt-cache-show-show-instead-of-dumpavail.patch
Description: /home/phahn/.magic

Bug#758512: debian-cd: Wrong word splitting reg-exp for $ENV{ARCHES}

[Philipp Hahn]

Package: debian-cd
Version: 3.1.13
Severity: normal

Dear Maintainer,

the environment variable ARCHES is set to amd64, but
tools/generate_di_lists still complains about a missing i386 Packages
file:
 Missing package file for i386/local.

I think the regular expressions are wrong, since [^\s] is any character
other then a white-space while (^|\s) would match beginning of
string or white space. Same for [\s\$] to match the end of the work.

--- tools/generate_di_list.orig 2014-07-30 09:23:32.464452565 +0200
+++ tools/generate_di_list  2014-07-30 09:23:40.576662354 +0200
@@ -12,8 +12,8 @@
  my @ARCHES;
 if ( $ENV{ARCHES} ) {
-push @ARCHES, 'i386' if $ENV{ARCHES} =~ /[^\s]i386[\s\$]/;
-push @ARCHES, 'amd64' if $ENV{ARCHES} =~ /[^\s]amd64[\s\$]/;
+push @ARCHES, 'i386' if $ENV{ARCHES} =~ /(^|\s)i386(\s|$)/;
+push @ARCHES, 'amd64' if $ENV{ARCHES} =~ /(^|\s)amd64(\s|$)/;
 push @ARCHES, grep { !/^(source|i386|amd64)$/ } split /\s+/,
$ENV{ARCHES};
 }
 @ARCHES = qw{i386 amd64} unless @ARCHES;

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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#717215: dhcpd: 5 bad udp checksums in 5 packets

[Philipp Hahn]

On Wed, 18 Sep 2013 14:16:08 +0200, Bastian Blank wrote:
 Why does dhcpd check the checksum, which is already done by the kernel?

dhcpd is using RAW sockets to work with Ethernet packets. (DHCP is used
to configure IP, so it has to work on a lower level than IP.)

RAW sockets bypass the kernels IP network stack (even iptbale rules!),
so the kernel never gets a chance to check the UDP checksum.
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
h...@univention.de

http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876


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

Bug#726304: websockify: rebind.so not found by rebind

[Philipp Hahn]

Package: websockify
Version: 0.5.1+dfsg1-2
Severity: normal

Dear Maintainer,

1. /usr/bin/rebind fails similar to Bug #719889, because the shared
library is not found by the shell wrapper.
2. usage is never printed; suppot for --help is still missing in my
version below.
3. It was never checked, if the required parameters were given
4. Missing quotes.
5. You should use exec to get rid of the intermediate shell process.
6. bash is overkill.
7. The name rebind is IMHO to generic: websockify-rebind perhaps?
8. Multi-arch-support is missing.
9. The only architecture dependent files are the two rebind.*o files.
Perhaps split them with the shell wrapper into their own package and
make the websockify package Architecture: all?


#!/bin/sh

mydir=$(readlink -f $(dirname ${0}))
mylib=${mydir}/../lib/websockify/rebind.so
[ -e ${mylib} ] || { echo ${mylib} not found 2; exit 1; }

usage () {
echo Usage: $(basename $0) OLD_PORT NEW_PORT COMMAND_LINE
echo
echo Launch COMMAND_LINE, but intercept system calls to bind
echo to OLD_PORT and instead bind them to localhost:NEW_PORT
exit 2
}
[ $# -ge 3 ] || usage

# Parameter defaults

export REBIND_PORT_OLD=${1}
export REBIND_PORT_NEW=${2}
shift 2

LD_PRELOAD=${mylib} exec ${@}

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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#715494: apt-pkg: out-of-date pkgcache.bin: /var/lib/dpkg/status updated more than once in one second

[Philipp Hahn]

Package: apt
Version: 0.8.10
Severity: normal

Dear Maintainer,

we (Univention GmbH) provide a Debian based distribution called UCS.
During automatic testing we noticed a suitable bug in APT:

If /var/lib/dpkg/status is updated more than once in one second, apt-pkg
does not detect that and does not update its /var/cache/apt/pkgcache.bin
file.
dpkg-query -W and apt-cache policy then display different versions
for the currently installed version.

I tracked it down to apt-pkg/pkgcache.cc and apt-pkg/deb/debindexfile.cc
only using 'stat.mtime' without the nano-second resolution in 'tv_nsec',
which more modern Linux kernels do provide.

Would you accept a patch which adds (conditional) support for that, or
do you prefer a different solution.


The bug is more likely to happen on fast machines and in virtual
machines, where the expensive disk sync get filtered out.

The full bug information is available in our public Bugzilla at
https://forge.univention.org/bugzilla/show_bug.cgi?id=31773

Sincerely
Philipp Hahn pmh...@debian.org
-- Package-specific info:

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

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

Versions of packages apt depends on:
ii  debian-archive-keyring  2012.4
ii  gnupg   1.4.12-7
ii  libapt-pkg4.12  0.9.7.9
ii  libc6   2.13-38
ii  libgcc1 1:4.7.2-5
ii  libstdc++6  4.7.2-5

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc none
ii  aptitude0.6.8.2-1
ii  dpkg-dev1.16.10
ii  python-apt  0.8.8.2
ii  xz-utils5.1.1alpha+20120614-2

-- 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#704657: debian/rules: Inconsistent required targets

[Philipp Hahn]

Package: debian-policy
Severity: normal

Quoting from 
http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
 The following targets are required... :
   clean,
   binary,
   binary-arch,
   binary-indep,
   build.
...
 build (required)
 build-arch (required), build-indep (required)

According to the lintian description in
http://lintian.debian.org/tags/debian-rules-missing-recommended-target.html
build-arch and build-indep should be added to the paragraph
above as required targets.

 binary (required), binary-arch (required), binary-indep (required)
 clean (required)
 get-orig-source (optional)
 patch (optional)

Or remove the introducing paragraph and mention dpkg-buildpackage
further down:

- The targets are as follows:
+ The targets called by dpkg-buildpackage are as follows:

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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#673724: New Upstream

[Philipp Hahn]

New upstream source URL: https://github.com/jshint/jshint
Also see Hompage http://jshint.com/.
Current stable version is 1.1.0

Also see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559969 for the RFP 
for jslint
-- 
Philipp Hahn   Open Source Software Engineer  h...@univention.de
Univention GmbHbe open.   fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen fax: +49 421 22 232-99
   http://www.univention.de/


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

Bug#700843: qemu: snapshot error detection incomplete: raw device

[Philipp Hahn]

Package: libvirt0
Version: 0.9.12-6
Severity: normal
Tags: patch

Hello Guido,

qemu-1.0 introduced a new error message, when a snapshot is created, but
the VM uses a raw device. This is not detected by libvirt.
Patch attached.

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

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

Versions of packages libvirt0 depends on:
ii  libavahi-client30.6.31-1
ii  libavahi-common30.6.31-1
ii  libc6   2.13-37
ii  libcap-ng0  0.6.6-2
ii  libdbus-1-3 1.6.8-1
ii  libdevmapper1.02.1  2:1.02.74-4
ii  libgcrypt11 1.5.0-3
ii  libgnutls26 2.12.20-4
ii  libnetcf1   0.1.9-2
ii  libnl1  1.1-7
ii  libnuma12.0.8~rc4-1
ii  libpcap0.8  1.3.0-1
ii  libsasl2-2  2.1.25.dfsg1-6
ii  libxenstore3.0  4.1.4-2
ii  libxml2 2.8.0+dfsg1-7
ii  libyajl22.0.4-2

Versions of packages libvirt0 recommends:
ii  lvm2  2.02.95-4

libvirt0 suggests no packages.

-- no debconf information
From 7034e3285f80c3744a79a4df912d20d8b9aba7d5 Mon Sep 17 00:00:00 2001
Message-Id: 7034e3285f80c3744a79a4df912d20d8b9aba7d5.1360938805.git.h...@univention.de
From: Philipp Hahn h...@univention.de
Date: Fri, 15 Feb 2013 15:13:05 +0100
Subject: [PATCH] qemu: handle not supported writable devices
Organization: Univention GmbH, Bremen, Germany
To: libvir-l...@redhat.com

If the running VM contains a writable raw image, creating snapshot fails
internally in QEMU, but the error is not detected by libvirt. Success is
still reported to the user, who will see the snapshot in libvirt, even
they are NOT created by qemu.

virsh # qemu-monitor-command --hmp winxp-1  savevm \test\
Device 'drive-fdc0-0-0' is writable but does not support snapshots.

virsh # snapshot-create-as winxp-1 test
Domain snapshot test created

Since there is no QMP command in QEMU, libvirtd sends a HMP command to the
running QEMU and parses the returned text. There only the following 4 strings
are detected as errors:

src/qemu/qemu_monitor_text.c:2822 # qemuMonitorTextCreateSnapshot()
 Error while creating snapshot
 No block device can accept snapshots
 Could not open VM state file
 Error + while writing VM

Since none of them match the above message, libvirt thinks the command
succeeded.

Add does not support snapshots as an additional error condition.

Signed-off-by: Philipp Hahn h...@univention.de
---
 src/qemu/qemu_monitor_text.c |4 
 1 file changed, 4 insertions(+)

diff --git a/src/qemu/qemu_monitor_text.c b/src/qemu/qemu_monitor_text.c
index bc0a11d..5880ab9 100644
--- a/src/qemu/qemu_monitor_text.c
+++ b/src/qemu/qemu_monitor_text.c
@@ -3004,6 +3004,10 @@ int qemuMonitorTextCreateSnapshot(qemuMonitorPtr mon, const char *name)
 qemuReportError(VIR_ERR_OPERATION_FAILED, %s, reply);
 goto cleanup;
 }
+else if (strstr(reply, does not support snapshots) != NULL) {
+qemuReportError(VIR_ERR_OPERATION_FAILED, %s, reply);
+goto cleanup;
+}
 
 ret = 0;
 
-- 
1.7.10.4

Bug#469754: FYI: X11rdp for Debian

[Philipp Hahn]

Hello,

we (Univention) have a Debian package from xrdp-0.7.0~git20130113 for our own 
Debian Squeeze based distribution UCS-3.1, which is available through our 
AppCenter since today.

The problem with building X11rdp is that you need the source code of the X.org 
server, because X11rdp reuses large sections of that code. Sadly the Xorg 
server does not export enougth interfaces to build X11rdp against the public 
interface of Xorg server.
With that approach it's very unlikely for X11rdp to enter Debian, since 
including the Xorg source code a second time into the Debian archive would 
create additional work for the Debian Security Team, which would then have to 
fix bugs in two packages.

With Squeeze the versions of several packages are too old, so in our build I 
had to include the newer source code anyway:

xorg/X11R7.6/x11_file_list.txt
 xproto-7.0.20.tar.bz2 : xproto-7.0.20 :
 libdrm-2.4.26.tar.bz2 : libdrm-2.4.26 :
 MesaLib-7.10.3.tar.bz2 : 
Mesa-7.10.3 : --disable-gallium --with-dri-drivers=swrast 
--with-dri-driverdir='${libdir}/dri-7.10.3'
 libXfont-1.4.3.tar.bz2 :  libXfont-1.4.3 :
 xorg-server-1.9.3.tar.bz2 : 
xorg-server-1.9.3 : --with-sha1=libcrypto --disable-dmx 
--with-dri-driver-path='${libdir}/dri-7.10.3'

With Wheezy the versions of the pre-requisits are newer, so I would hope that 
only the source code of xorg-server is needed for building X11rdp.
If there's enough interest I'll have a look at that as well.

Sincerely
Philipp
-- 
Philipp Hahn   Open Source Software Engineer  h...@univention.de
Univention GmbHbe open.   fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen fax: +49 421 22 232-99
   http://www.univention.de/


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

Bug#695905: qcow2 file corruption

[Philipp Hahn]

Package: qemu-kvm
Version: 1.1.2+dfsg-2
Severity: critical
Tags: upstream

We (Univention) noticed a serious data loss problem with qemu-kvm-1.1.2
as currently shipped with Debain wheezy (and our own Debian based
distribution UCS). After finding that issue in our distribution I also
verified that it exists with a plain Debian wheezy setup.
The bug is also present in qemu-kvm-1.1.2 as compiled from git, but is not
present in qemu-kvm-1.2.0, so it's an upstream problem.

I bisected the problem down to
b7ab0fea37c15ca9e249c42c46f5c48fd1a0943c qcow2: Fix avail_sectors in cluster 
allocation code
fixing the problem.

I asked the author of said patch for his opinion, but he can't thinks of
why that patch would fix the problem.
http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg01537.html

I'm currently continuing to investigate the problem and will keep you
informed.

The bug is tracked in our German bugzilla at
https://forge.univention.org/bugzilla/show_bug.cgi?id=29355
where you can find further technical details.

The bug manifests as MD5 and unpacking errors during package install, programs
failing to start and file system corruption. It mostly happens with qcow2
files which use other qcow2 files as a backing file, but we've seen errors on
plain qcow2 installations as well.


-- Package-specific info:


/proc/cpuinfo:

processor   : 0

processor   : 7
vendor_id   : GenuineIntel
cpu family  : 6
model   : 30
model name  : Intel(R) Core(TM) i7 CPU 860  @ 2.80GHz
stepping: 5
microcode   : 0x4
cpu MHz : 1200.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 11
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm 
sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips: 5600.20
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

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

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

Versions of packages qemu-kvm depends on:
ii  adduser 3.113+nmu3
ii  ipxe-qemu   1.0.0+git-20120202.f6840ba-3
ii  libaio1 0.3.109-3
ii  libasound2  1.0.25-4
ii  libbluetooth3   4.99-2
ii  libbrlapi0.54.4-5
ii  libc6   2.13-37
ii  libcurl3-gnutls 7.26.0-1
ii  libglib2.0-02.33.12+really2.32.4-3
ii  libgnutls26 2.12.20-2
ii  libiscsi1   1.4.0-3
ii  libjpeg88d-1
ii  libncurses5 5.9-10
ii  libpng12-0  1.2.49-1
ii  libpulse0   2.0-6
ii  libsasl2-2  2.1.25.dfsg1-6
ii  libsdl1.2debian 1.2.15-5
ii  libspice-server10.11.0-1
ii  libtinfo5   5.9-10
ii  libusbredirparser0  0.4.3-2
ii  libuuid12.20.1-5.2
ii  libvdeplug2 2.3.2-4
ii  libx11-62:1.5.0-1
ii  python  2.7.3~rc2-1
ii  qemu-keymaps1.1.2+dfsg-2
ii  qemu-utils  1.1.2+dfsg-2
ii  seabios 1.7.0-1
ii  vgabios 0.7a-3
ii  zlib1g  1:1.2.7.dfsg-13

Versions of packages qemu-kvm recommends:
ii  bridge-utils  1.5-6
ii  iproute   20120521-3

Versions of packages qemu-kvm suggests:
pn  debootstrap  none
pn  sambanone
pn  vde2 none

-- 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#692846: isc-dhcp-client: /sbin/dhclient-script incorrectly handles exit codes

[Philipp Hahn]

Hello Michael,

as far as I'm aware the bug is in ./debian/dhclient-script.linux (and 
./debian/dhclient-script.kfreebsd), but not in ./client/scripts/linux.
So to me it looks like this is a bug in Debian only, because only there 
run-parts is used to source the files from /etc/dhcp/dhclient-*-hooks.d/, and 
by doing so breaks the handling of exit codes.

BYtE
Philipp
-- 
Philipp Hahn   Open Source Software Engineer  h...@univention.de
Univention GmbHbe open.   fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen fax: +49 421 22 232-99
   http://www.univention.de/


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

Bug#692846: isc-dhcp-client: /sbin/dhclient-script incorrectly handles exit codes

[Philipp Hahn]

Package: isc-dhcp-client
Version: 4.2.4-3
Severity: important

/sbin/dhclient-script contains several logic bugs, which break proper handling 
of return codes.

Reading man dhcp-scipts:
 HOOKS
   ... It also invokes all executable scripts in 
 ETCDIR/dhclient-enter-hooks.d/* in the same way.
   ... If an error occurs during the execution of the script, it can set the 
 exit_status variable to a nonzero value, and CLIENTBINDIR/dhclient-script 
 will exit with that error code  immediately after the client script exits.

/sbin/dhclient-script:128
 run_hookdir() {
 local dir
 local exit_status
 dir=$1
 shift # See run_hook
 
 if [ -d $dir ]; then
 for script in $(run-parts --list $dir); do
 run_hook $script $@ || true
By appending the || true the exit status in now alyways 0
 exit_status=$?
 done
 fi

/sbin/dhclient-script:149
if ! run_hook /etc/dhcp/dhclient-exit-hooks $@; then
exit_status=$?
exit_status will be alwys 0, since $? now contains the value of the ! runhook 
status.


Please have a look at the upstream isc-dhcp-4.1.1-P1/client/scripts/linux
file or take a look at the following patch, which (hopefully) gets it right:
--- /sbin/dhclient-script   2012-10-15 21:03:17.0 +0200
+++ /home/phahn/dhclient-scipt  2012-11-08 23:22:45.449909285 +0100
@@ -109,36 +109,31 @@
 # run given script
 run_hook() {
 local script
-local exit_status
+local prev_exit_status
 script=$1
+prev_exit_status=$exit_status
 shift  # discard the first argument, then the rest are the script's
 
 if [ -f $script ]; then
 . $script $@
 fi
 
-if [ -n $exit_status ]  [ $exit_status -ne 0 ]; then
-logger -p daemon.err $script returned non-zero exit status 
$exit_status
+if [ $exit_status -ne $prev_exit_status ]; then
+logger -p daemon.err $script returned exit status $exit_status
 fi
-
-return $exit_status
 }
 
 # run scripts in given directory
 run_hookdir() {
 local dir
-local exit_status
 dir=$1
 shift  # See run_hook
 
 if [ -d $dir ]; then
 for script in $(run-parts --list $dir); do
-run_hook $script $@ || true
-exit_status=$?
+run_hook $script $@
 done
 fi
-
-return $exit_status
 }
 
 # Must be used on exit.   Invokes the local dhcp client exit hooks, if any.
@@ -146,14 +141,10 @@
 exit_status=$1
 
 # Source the documented exit-hook script, if it exists
-if ! run_hook /etc/dhcp/dhclient-exit-hooks $@; then
-exit_status=$?
-fi
+run_hook /etc/dhcp/dhclient-exit-hooks $@
 
 # Now run scripts in the Debian-specific directory.
-if ! run_hookdir /etc/dhcp/dhclient-exit-hooks.d $@; then
-exit_status=$?
-fi
+run_hookdir /etc/dhcp/dhclient-exit-hooks.d $@
 
 exit $exit_status
 }
@@ -172,8 +163,12 @@
 # The action starts here
 
 # Invoke the local dhcp client enter hooks, if they exist.
+exit_status=0
 run_hook /etc/dhcp/dhclient-enter-hooks
 run_hookdir /etc/dhcp/dhclient-enter-hooks.d
+if [ $exit_status -ne 0 ]; then
+exit $exit_status
+fi
 
 # Execute the operation
 case $reason in

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

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

Versions of packages isc-dhcp-client depends on:
ii  debianutils  4.3.4
ii  iproute  20120521-3
ii  isc-dhcp-common  4.2.4-3
ii  libc62.13-36

isc-dhcp-client recommends no packages.

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd  none
pn  resolvconf none

-- 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#566790: [PATCH] python-tre

[Philipp Hahn]

tag 566790 + patch
thanks

Hello,

support for building the Python binding was done by us because be needed
tre for some Python project. The source file needs to be patched because
the Python binding as is expects the tre shared object library already
to be installed when building the binding. Since this is not the case
with Debians build system, change the run time paths to build time
paths.

Since our distrubution is still Squeeze based, so this is a forward port
to Wheezy/Sid. Please have a look at the patch before blindly applying
it, because I don't know if any special Multiarch handling is needed.

Sincerely
Philipp
-- 
Philipp Hahn   Open Source Software Engineer  h...@univention.de
Univention GmbHbe open.   fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen fax: +49 421 22 232-99
   http://www.univention.de/
diff -urN '--exclude=.pc' tre-0.8.0.debian/debian/control tre-0.8.0.ucs/debian/control
--- tre-0.8.0.debian/debian/control	2012-06-03 17:23:32.0 +0200
+++ tre-0.8.0.ucs/debian/control	2012-07-11 18:35:51.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Santiago Vila sanv...@debian.org
 Uploaders: Milan Zamazal p...@debian.org
 Standards-Version: 3.9.2
-Build-Depends: gettext (= 0.18.1.1-8), debhelper (= 9)
+Build-Depends: gettext (= 0.18.1.1-8), debhelper (= 9), python-all-dev (= 2.6.6-3~)
 
 Package: libtre5
 Architecture: any
@@ -34,3 +34,12 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: approximate grep utility based on the tre library
  This is an Approximate GREP utility based on the TRE regexp matching library
+
+Package: python-libtre
+Architecture: any
+Section: python
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Python binding for the tre library
+ This is an Approximate GREP utility based on the TRE regexp matching library
+ .
+ This package contains Python bindings for the libtre library
diff -urN '--exclude=.pc' tre-0.8.0.debian/debian/patches/03-build-python-binding tre-0.8.0.ucs/debian/patches/03-build-python-binding
--- tre-0.8.0.debian/debian/patches/03-build-python-binding	1970-01-01 01:00:00.0 +0100
+++ tre-0.8.0.ucs/debian/patches/03-build-python-binding	2012-07-11 18:35:51.0 +0200
@@ -0,0 +1,30 @@
+Description: Build python binding
+ Build the binding during package build requires some (hackish) path name changes.
+Origin: vendor
+Bug-Debian: http://bugs.debian.org/bugnumber
+Bug-Univention: https://forge.univention.org/bugzilla/show_bug.cgi?id=17290
+Forwarded: no
+Author: Philipp Hahn h...@univention.de
+Last-Update: 2012-07-06
+
+--- tre-0.8.0.orig/python/setup.py
 tre-0.8.0/python/setup.py
+@@ -31,6 +31,7 @@ setup(name = tre,
+sources = [tre-python.c],
+define_macros = [(HAVE_CONFIG_H, None)],
+include_dirs = include_dirs,
++   library_dirs = ['../lib/.libs'],
+libraries = libraries
+),
+  ],
+--- tre-0.8.0.orig/python/tre-python.c
 tre-0.8.0/python/tre-python.c
+@@ -13,7 +13,7 @@
+ #include Python.h
+ #include structmember.h
+ 
+-#include tre/tre.h
++#include ../lib/tre.h
+ 
+ #define	TRE_MODULE	tre
+ 
diff -urN '--exclude=.pc' tre-0.8.0.debian/debian/patches/series tre-0.8.0.ucs/debian/patches/series
--- tre-0.8.0.debian/debian/patches/series	2011-08-07 12:01:00.0 +0200
+++ tre-0.8.0.ucs/debian/patches/series	2012-07-11 18:35:51.0 +0200
@@ -1,3 +1,4 @@
 01-agrep-is-called-tre-agrep-here
 02-added-de-po-translation
+03-build-python-binding
 99-config-guess-config-sub
diff -urN '--exclude=.pc' tre-0.8.0.debian/debian/python-libtre.install tre-0.8.0.ucs/debian/python-libtre.install
--- tre-0.8.0.debian/debian/python-libtre.install	1970-01-01 01:00:00.0 +0100
+++ tre-0.8.0.ucs/debian/python-libtre.install	2012-07-11 18:35:51.0 +0200
@@ -0,0 +1 @@
+usr/lib/python*
diff -urN '--exclude=.pc' tre-0.8.0.debian/debian/rules tre-0.8.0.ucs/debian/rules
--- tre-0.8.0.debian/debian/rules	2012-06-03 17:44:24.0 +0200
+++ tre-0.8.0.ucs/debian/rules	2012-07-11 18:35:51.0 +0200
@@ -1,6 +1,10 @@
 #!/usr/bin/make -f
 %:
-	dh $@
+	dh $@ --with python2
+
+override_dh_auto_clean:
+	dh_auto_clean
+	dh_auto_clean --sourcedirectory=python --buildsystem python_distutils
 
 override_dh_clean:
 	dh_clean
@@ -10,13 +14,16 @@
 
 override_dh_auto_configure:
 	dh_auto_configure -- --enable-static
+	dh_auto_configure --sourcedirectory=python --buildsystem python_distutils
 
 override_dh_auto_build:
 	dh_auto_build
+	dh_auto_build --sourcedirectory=python --buildsystem python_distutils
 	$(MAKE) -C po update-gmo
 
 override_dh_auto_install:
 	dh_auto_install
+	dh_auto_install --sourcedirectory=python --buildsystem python_distutils
 	mv debian/tmp/usr/bin/agrep \
 	   debian/tmp/usr

Bug#666135: XenStore tdb vs. reboot

[Philipp Hahn]

Hello,

I noticed a strace delay when running virsh list on my Xen-4.1.3 test 
server. On further investigation I noticed that in XenStore there were 
multiple /vm/$UUID entries suffixed by -$VERSION, especially I hat 16 entries 
for my dom0. For each reboot of the host I get a new entry.

After disabling Xend I get the following output after a reboot:
 root@xen5:~# xenstore-ls /local/domain/0
 name = Domain-0

If I then start Xend, I get more data added:
 root@xen5:~# /etc/init.d/xend start
 Starting xen management daemon: xend.
 root@xen5:~# xenstore-ls /local/domain/0
 vm = /vm/-----2
 device = 
 control = 
  platform-feature-multiprocessor-suspend = 1
 error = 
 memory = 
  target = 3400192
 guest = 
 hvmpv = 
 data = 
 cpu = 
  1 = 
   availability = online
  0 = 
   availability = online
 description = 
 console = 
  limit = 1048576
  type = xenconsoled
 domid = 0
 name = Domain-0

Notice that I now have vm=$UUID-2.

If you just restart Xend, the problem does not show; you need to actually 
reboot to host, so that /local/domain/0/vm does not exist.

I found commit http://xenbits.xen.org/hg/xen-unstable.hg/rev/265950e3df69 
which added the suffix handling, which I never noticed before.

I found the same issue reported at 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666135.

For comparison I just installed a fresh Debian Wheezy rc1 and noticed that the 
XenStore tdb there is locates in /var/_run_/xenstore/tdb instead 
of /var/_lib_/xenstore/tdb. Since /var/run/ lives on a tempfs, it's nuked on 
every reboot and thus the problem doesn't exist there.

Is the XenStore tdb supposed to survive a reboot or must it be cleared between 
each reboot?

Sincerely
Philipp
-- 
Philipp Hahn   Open Source Software Engineer  h...@univention.de
Univention GmbHbe open.   fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen fax: +49 421 22 232-99
   http://www.univention.de/


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

Bug#666135: [PATCH] xen-xs: fix uuid of renamed domain

[Philipp Hahn]

When the XenStore tdb lives persistently and is not cleared between host
reboots, Xend (version 3.4 and 4.1) re-creates the domain information
located in XenStore below /vm/$UUID. (According to the xen-3.2-commit
hg265950e3df69 to fix a problem when locally migrating a domain to the
host itself.)

When doing so a version number is added to the UUID separated by one
dash, which confuses xenStoreDomainIntroduced(): It iterates over all
domains and tries to lookup all inactive domains using
xenStoreDomainGetUUID(), which fails if the running domain is renamed:
virUUIDParse() fails to parse the versioned UUID and the domain is
flagged as missing. When this happens the function delays .2s and
re-tries 20 times again, multiplied by the number of renamed VMs.
  14:48:38.878: 4285: debug : xenStoreDomainIntroduced:1354 : Some domains were 
missing, trying again

This adds a significant delay:
  # time virsh list /dev/null
  real0m6.529s
  # xenstore-list /vm
  ----
  -----1
  -----2
  -----3
  -----4
  -----5
  7c06121e-90c3-93d4-0126-50481d485cca
  -----6
  -----7
  144ad19d-dfb4-2f80-8045-09196bb8784f
  -----8
  144ad19d-dfb4-2f80-8045-09196bb8784f-1
  -----9
  -----10
  -----11
  -----12
  -----13
  -----14
  144ad19d-dfb4-2f80-8045-09196bb8784f-2
  -----15
  144ad19d-dfb4-2f80-8045-09196bb8784f-3
  -----16

The patch adds truncation of the UUID as read from the XenStore path
before passing it to virUUIDParse().

The same issue is reported at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666135

Signed-off-by: Philipp Hahn h...@univention.de
---
 src/xen/xs_internal.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/src/xen/xs_internal.c b/src/xen/xs_internal.c
index e56d1a4..cdaef17 100644
--- a/src/xen/xs_internal.c
+++ b/src/xen/xs_internal.c
@@ -1115,8 +1115,11 @@ int xenStoreDomainGetUUID(virConnectPtr conn,
 snprintf(prop, 199, /local/domain/%d/vm, id);
 prop[199] = 0;
 /* This will return something like
- * /vm/---- */
+ * /vm/----[-*] */
 uuidstr = xs_read(priv-xshandle, 0, prop, len);
+/* Strip optional version suffix when VM was renamed */
+if (len  40) /* strlen('/vm/') + VIR_UUID_STRING_BUFLEN - sizeof('\0') */
+uuidstr[40] = '\0';
 
 /* remove /vm/ */
 ret = virUUIDParse(uuidstr + 4, uuid);
-- 
1.7.1


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

Bug#666135: [PATCH] /etc/init.d/xencommons

[Philipp Hahn]

There's a logic bug in /etc/init.d/xencommons, which doesn't zap the tdb:

 test -z $XENSTORED_ROOTDIR || XENSTORED_ROOTDIR=/var/lib/xenstored

Fix: 
http://xenbits.xen.org/hg/xen-unstable.hg/diff/e2722b24dc09/tools/hotplug/Linux/init.d/xencommons

Sincerely
Philipp
-- 
Philipp Hahn   Open Source Software Engineer  h...@univention.de
Univention GmbHbe open.   fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen fax: +49 421 22 232-99
   http://www.univention.de/


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

Bug#669335: [2.6.32.y][PATCH] fix pgd_lock deadlock

[Philipp Hahn]

Hello,

On Wednesday 16 February 2011 15:49:47 Andrea Arcangeli wrote:
 Subject: fix pgd_lock deadlock

 From: Andrea Arcangeli aarca...@redhat.com

 It's forbidden to take the page_table_lock with the irq disabled or if
 there's contention the IPIs (for tlb flushes) sent with the page_table_lock
 held will never run leading to a deadlock.

 Apparently nobody takes the pgd_lock from irq so the _irqsave can be
 removed.

 Signed-off-by: Andrea Arcangeli aarca...@redhat.com

This patch (original commit Id for 2.6.38 
a79e53d85683c6dd9f99c90511028adc2043031f) needs to be back-ported to 2.6.32.x 
as well.
I observed a dead-lock problem when running a PAE enabled Debian 2.6.32.46+ 
kernel with 6 VCPUs as a KVM on (2.6.32, 3.2, 3.3) kernel, which showed the 
following behaviour:

1 VCPU is stuck in
  pgd_alloc() → pgd_prepopulate_pmb() →... →  flush_tlb_others_ipi()
while (!cpumask_empty(to_cpumask(f-flush_cpumask)))
cpu_relax();
(gdb) print f-flush_cpumask
$5 = {1}

while all other VCPUs are stuck in
  pgd_alloc() → spin_lock_irqsave(pgd_lock)

I tracked it down to the commit
 2.6.39-rc1: 4981d01eada5354d81c8929d5b2836829ba3df7b
 2.6.32.34: ba456fd7ec1bdc31a4ad4a6bd02802dcaa730a33
 x86: Flush TLB if PGD entry is changed in i386 PAE mode
which when reverted made the bug disappear.

Comparing 3.2 to 2.6.32.34 showed that the 'pgd-deadlock'-patch went into 
2.6.38, that is before the 'PAE correctness'-patch, so the problem was 
probably never observed in the main development branch.
But for 2.6.32 the 'pgd-deadlock' patch is still missing, so the 'PAE 
corretness'-patch made the problem worse with 2.6.32.

The Patch was also back-ported to the OpenSUSE Kernel
http://kernel.opensuse.org/cgit/kernel-source/commit/?id=ac27c01aa880c65d17043ab87249c613ac4c3635,
Since the patch didn't apply cleanly on the current Debian kernel, I had to 
backport it for us and Debian. The patch is also available from our (German) 
Bugzilla https://forge.univention.org/bugzilla/show_bug.cgi?id=26661 or 
from the Debian BTS at 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669335.

I have no easy test case, but running multiple parallel builds inside the VM 
normally triggers the bug within seconds to minutes. With the patch applied 
the VM survived a night building packages without any problem.

Signed-off-by: Philipp Hahn h...@univention.de

Sincerely
Philipp
-- 
Philipp Hahn   Open Source Software Engineer  h...@univention.de
Univention GmbHbe open.   fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen fax: +49 421 22 232-99
   http://www.univention.de/
It's forbidden to take the page_table_lock with the irq disabled
or if there's contention the IPIs (for tlb flushes) sent with
the page_table_lock held will never run leading to a deadlock.

Nobody takes the pgd_lock from irq context so the _irqsave can be
removed.

Signed-off-by: Andrea Arcangeli aarca...@redhat.com
Acked-by: Rik van Riel r...@redhat.com
Tested-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: sta...@kernel.org
LKML-Reference: 201102162345.p1gnjmjm021...@imap1.linux-foundation.org
Signed-off-by: Ingo Molnar mi...@elte.hu
Git-commit: a79e53d85683c6dd9f99c90511028adc2043031f
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -223,15 +223,14 @@ void vmalloc_sync_all(void)
 	 address = TASK_SIZE  address  FIXADDR_TOP;
 	 address += PMD_SIZE) {
 
-		unsigned long flags;
 		struct page *page;
 
-		spin_lock_irqsave(pgd_lock, flags);
+		spin_lock(pgd_lock);
 		list_for_each_entry(page, pgd_list, lru) {
 			if (!vmalloc_sync_one(page_address(page), address))
 break;
 		}
-		spin_unlock_irqrestore(pgd_lock, flags);
+		spin_unlock(pgd_lock);
 	}
 }
 
@@ -331,13 +330,12 @@ void vmalloc_sync_all(void)
 	 address += PGDIR_SIZE) {
 
 		const pgd_t *pgd_ref = pgd_offset_k(address);
-		unsigned long flags;
 		struct page *page;
 
 		if (pgd_none(*pgd_ref))
 			continue;
 
-		spin_lock_irqsave(pgd_lock, flags);
+		spin_lock(pgd_lock);
 		list_for_each_entry(page, pgd_list, lru) {
 			pgd_t *pgd;
 			pgd = (pgd_t *)page_address(page) + pgd_index(address);
@@ -346,7 +344,7 @@ void vmalloc_sync_all(void)
 			else
 BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref));
 		}
-		spin_unlock_irqrestore(pgd_lock, flags);
+		spin_unlock(pgd_lock);
 	}
 }
 
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -56,12 +56,10 @@ static unsigned long direct_pages_count[
 
 void update_page_count(int level, unsigned long pages)
 {
-	unsigned long flags;
-
 	/* Protect against CPA */
-	spin_lock_irqsave(pgd_lock, flags);
+	spin_lock(pgd_lock);
 	direct_pages_count[level] += pages;
-	spin_unlock_irqrestore(pgd_lock, flags);
+	spin_unlock(pgd_lock);
 }
 
 static void split_page_count(int level)
@@ -354,7

Bug#669335: linux-image-2.6.32-5-686-bigmem: 86-mm-Fix-pgd_lock-deadlock.patch

[Philipp Hahn]

Package: linux-image-2.6.32-5-686-bigmem
Version: 2.6.32-41squeeze2
Severity: important

We received several problem reports from our customers and also
experienced the following bug when running said kernel with =2 CPUs in
a virtualization environbment (KVM and VMWare ESX). After some time the
VM just stops (no ping, no console, no activity).

Using gdb and KVMs gdbserver capability I was able to track it down to
the following symptom: One thread would be stuck in
flush_tlb_others_ipi() waiting for all other CPUs using a specifiy mm to
signal they have flushed there TLB, while all other CPU-threads would be
waiting for the pgd_lock to be freed.

I have no easy test to reproduce the bug, but it usually happens to me
when I run several pbuilder-builds in parallel. The more virtual CPUs
the VM has, the easier to trigger: With 2 VCPUs it's hours, with 6 VCPUs
it's usually less than 5 minutes.

This got more prominent with git-commit
831d52bc153971b70e64eccfbed2b232394f22f8: x86, mm: avoid possible bogus tlb 
entries by clearing prev mm_cpumask after switching mm
(Linus tree), and even worse with
4981d01eada5354d81c8929d5b2836829ba3df7b: x86: Flush TLB if PGD entry is 
changed in i386 PAE mode

I found the issue to be fixed by
a79e53d85683c6dd9f99c90511028adc2043031f: x86/mm: Fix pgd_lock deadlock

That patch is already in the Debian patch set, but only applied for the
xen flavour: features/all/xen/x86-mm-Fix-pgd_lock-deadlock.patch

I thinks this patch should be applied to all flavours. It doesn't apply
to the non-xen-flavour as is, because it depends on some other
xen-related patch.
The Patch was also back-ported to the OpenSUSE Kernel
http://kernel.opensuse.org/cgit/kernel-source/commit/?id=ac27c01aa880c65d17043ab87249c613ac4c3635,
but since the patch is trivial to backport, I'll attach my version as
well.

The patch should be forwarded to Upstream to be included into the
upstream 2.6.32 longterm stable kernel as well.

The full issue is tracked in our (German) Bugzilla:
https://forge.univention.org/bugzilla/show_bug.cgi?id=26661

Sincerely
Philipp
-- System Information:
Debian Release: 5.0.1
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.32-ucs57-686-bigmem
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Bug #26661: 686-bigmem VM deadlock
--- /dev/null
+++ 
linux-2.6.32-2.6.32/debian/patches/bugfix/x86/x86-mm-Fix-pgd_lock-deadlock.patch
@@ -0,0 +1,217 @@
+It's forbidden to take the page_table_lock with the irq disabled
+or if there's contention the IPIs (for tlb flushes) sent with
+the page_table_lock held will never run leading to a deadlock.
+
+Nobody takes the pgd_lock from irq context so the _irqsave can be
+removed.
+
+Signed-off-by: Andrea Arcangeli aarca...@redhat.com
+Acked-by: Rik van Riel r...@redhat.com
+Tested-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
+Signed-off-by: Andrew Morton a...@linux-foundation.org
+Cc: Peter Zijlstra pet...@infradead.org
+Cc: Linus Torvalds torva...@linux-foundation.org
+Cc: sta...@kernel.org
+LKML-Reference: 201102162345.p1gnjmjm021...@imap1.linux-foundation.org
+Signed-off-by: Ingo Molnar mi...@elte.hu
+Git-commit: a79e53d85683c6dd9f99c90511028adc2043031f
+--- a/arch/x86/mm/fault.c
 b/arch/x86/mm/fault.c
+@@ -223,15 +223,14 @@ void vmalloc_sync_all(void)
+address = TASK_SIZE  address  FIXADDR_TOP;
+address += PMD_SIZE) {
+ 
+-  unsigned long flags;
+   struct page *page;
+ 
+-  spin_lock_irqsave(pgd_lock, flags);
++  spin_lock(pgd_lock);
+   list_for_each_entry(page, pgd_list, lru) {
+   if (!vmalloc_sync_one(page_address(page), address))
+   break;
+   }
+-  spin_unlock_irqrestore(pgd_lock, flags);
++  spin_unlock(pgd_lock);
+   }
+ }
+ 
+@@ -331,13 +330,12 @@ void vmalloc_sync_all(void)
+address += PGDIR_SIZE) {
+ 
+   const pgd_t *pgd_ref = pgd_offset_k(address);
+-  unsigned long flags;
+   struct page *page;
+ 
+   if (pgd_none(*pgd_ref))
+   continue;
+ 
+-  spin_lock_irqsave(pgd_lock, flags);
++  spin_lock(pgd_lock);
+   list_for_each_entry(page, pgd_list, lru) {
+   pgd_t *pgd;
+   pgd = (pgd_t *)page_address(page) + pgd_index(address);
+@@ -346,7 +344,7 @@ void vmalloc_sync_all(void)
+   else
+   BUG_ON(pgd_page_vaddr(*pgd) != 
pgd_page_vaddr(*pgd_ref));
+   }
+-  spin_unlock_irqrestore(pgd_lock, flags);
++  spin_unlock(pgd_lock);
+   }
+ }
+ 
+--- a/arch/x86/mm/pageattr.c
 b/arch/x86/mm/pageattr.c
+@@ -56,12 +56,10 @@ static unsigned long direct_pages_count[
+ 
+ void update_page_count(int level, unsigned long pages)
+ {
+-  unsigned long flags;
+-
+   /* Protect against CPA */

Bug#628828: [PATCH] Build Python-bindings for all Python versions

[Philipp Hahn]

Hello Guido,

In reference to our talk at DebConf11, here's a patch to build the Python 
bindings of libvirt for all versions of Python. This might also fix this bug.

The idea of this patch is to
1. switch to an out-of-tree build, since I have to play some symlink-tricks to 
create the python/ directory for each Python version
2. configure and build it once for the default Python version
3. build and install just the python/ directory for all Python versions

The patch to debina/control will probably not apply to Debians current 
version, so just so following change:
 sed -e '/Build-Depends:/s/python-dev/python-all-dev/' \
 -e '/XS-Python-Version:/s/current/all/' debian/control

diff -ur a/debian/control b/debian/control
--- a/debian/control2010-03-23 12:26:14.0 +0100
+++ b/debian/control2010-03-23 12:27:56.0 +0100
@@ -3,13 +3,13 @@
 Priority: optional
 Maintainer: Debian Libvirt Maintainers 
pkg-libvirt-maintain...@lists.alioth.debian.org
 Uploaders: Guido Günther a...@sigxcpu.org, Laurent Léonard 
laur...@open-minds.org
-Build-Depends: cdbs (= 0.4.43), debhelper (= 7), libxml2-dev, 
libncurses5-dev, libreadline-dev, zlib1g-dev, libgnutls-dev, python-dev (= 
2.3.5-11), python-central (= 0.5.6),
+Build-Depends: cdbs (= 0.4.43), debhelper (= 7), libxml2-dev, 
libncurses5-dev, libreadline-dev, zlib1g-dev, libgnutls-dev, python-all-dev 
(= 2.3.5-11), python-central (= 0.5.6),
  libavahi-client-dev, libsasl2-dev, xen-3.4 [i386 amd64], lvm2, qemu [amd64 
i386 powerpc sparc], open-iscsi, libparted1.8-dev (= 1.8), libdevmapper-dev, 
uuid-dev,
  libpciaccess-dev,
  module-init-tools,
  dpkg-dev ( 1.15.3) | dpkg-dev ( 1.15.3),
  libnl-dev
-XS-Python-Version: current
+XS-Python-Version: all
 Build-Conflicts: dpkg-dev (= 1.15.3)
 Vcs-Git: git://git.debian.org/git/pkg-libvirt/libvirt.git
 Vcs-Browser: http://git.debian.org/?p=pkg-libvirt/libvirt.git
diff -ur a/debian/rules b/debian/rules
--- a/debian/rules  2011-01-24 10:59:18.235952511 +0100
+++ b/debian/rules  2011-01-24 11:01:29.947448727 +0100
@@ -21,6 +21,7 @@
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/class/python-distutils.mk
 
+DEB_BUILDDIR := $(CURDIR)/debian/build
 DEB_CONFIGURE_EXTRA_FLAGS := \
--disable-rpath  \
--with-qemu  \
@@ -43,18 +44,59 @@
--without-capng  \
--without-macvtap\
--enable-debug   \
+   --srcdir=$(CURDIR)   \
$(BUILD_XEN) \
$(BUILD_VBOX)\
$(BUILD_LXC)
 
 DEB_COMPRESS_EXCLUDE = .o event-test hellolibvirt info1 suspend
 DEB_PYTHON_SETUP_CMD = /dev/null
+DEB_PYTHON_MODULE_PACKAGE = python-libvirt
 DEB_DH_MAKESHLIBS_ARGS_libvirt0 += -V 'libvirt0 (= 0.5.0)'
 DEB_DH_INSTALLINIT_ARGS = --no-restart-on-upgrade -- defaults 28 72
 DEB_DH_INSTALLLOGROTATE_ARGS = --name=libvirtd
 
 EXAMPLES_DIR = 
$(CURDIR)/debian/libvirt-doc/usr/share/doc/libvirt-doc/examples/
 
+#  Python rules 
+-include /usr/share/python/python.mk
+ifeq (,$(py_sitename))
+  py_libdir_sh = $$(_py_=$(strip $(1)); python$${_py_\#python*} -c 'from 
distutils import sysconfig; print(sysconfig.get_python_lib())')
+endif
+
+PY_DIR := $(DEB_BUILDDIR)/python
+PYDEFAULTVER := $(shell pyversions --version --default)
+PYVERSIONS := $(shell pyversions --version --installed)
+
+otherpy = \
+   set -e; for v in $(PYVERSIONS); do \
+   $(RM) $(PY_DIR); \
+   ln -sf $(PY_DIR)$$v $(PY_DIR); \
+   $(MAKE) \
+   -C $(PY_DIR) \
+   pyexecdir=$(call py_libdir_sh, $$v) \
+   PYTHON=python$$v \
+   PYTHON_VERSION=$$v \
+   PYTHON_INCLUDES=-I/usr/include/python$$v \
+   $1; \
+   $(RM) $(PY_DIR); \
+   done; \
+   ln -sf $(PY_DIR)$(PYDEFAULTVER) $(PY_DIR)
+
+configure/python-libvirt::
+   set -e; for v in $(PYVERSIONS); do \
+   cp -la $(PY_DIR) $(PY_DIR)$$v; \
+   done
+   $(RM) -r $(PY_DIR)
+   ln -sf $(PY_DIR)$(PYDEFAULTVER) $(PY_DIR)
+
+build/python-libvirt::
+   $(call otherpy, all)
+
+install/python-libvirt::
+   $(call otherpy, install DESTDIR=$(CURDIR)/debian/tmp)
+#  Python rules 
+
 binary-install/libvirt-bin::
cp $(CURDIR)/tools/libvirt-guests.init.sh 
$(CURDIR)/debian/libvirt-bin.libvirt-guests.init
cp $(CURDIR)/tools/libvirt-guests.sysconf 
$(CURDIR)/debian/libvirt-bin.libvirt-guests.default
@@ -70,3 +112,5 @@
 clean::
rm -f $(CURDIR)/debian/libvirt-bin.libvirt-guests.init
rm -f $(CURDIR)/debian/libvirt-bin.libvirt-guests.default
+   $(RM) -r $(DEB_BUILDDIR)
+# vim:set ft=make ts=4 sw=4:

Sincerely
Philipp
-- 
Philipp Hahn   Open Source Software Engineer  h...@univention.de
Univention GmbHLinux for Your Businessfon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen fax: +49 421 22

Bug#599507: KVM: SVM: Fix wrong intercept masks on 32 bit

[Philipp Hahn]

Package: linux-2.6.32
Severity: normal

When trying to reboot an ia32 guest, an ia32 kvm running on an Amd64
cpu reports the following error:
 kvm: unhandled exit 
 kvm_run returned -22

This bug was fixed for linux-2.6.34 but is still present in 2.6.32.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=061e2fd16863009c8005b4b5fdfb75c7215c0b99
 KVM: SVM: Fix wrong intercept masks on 32 bit
 
 This patch makes KVM on 32 bit SVM working again by
 correcting the masks used for iret interception. With the
 wrong masks the upper 32 bits of the intercepts are masked
 out which leaves vmrun unintercepted. This is not legal on
 svm and the vmrun fails.
 Bug was introduced by commits 95ba827313 and 3cfc3092.

It only happens on Amd cpus, Intel cpus are unaffected.

Please conside applying this patch to the 2.6.32 stable branch as well.

Sincerely
Philipp Hahn
-- System Information:
Debian Release: 5.0.1
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.32-ucs11-amd64
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
commit 061e2fd16863009c8005b4b5fdfb75c7215c0b99
Author: Joerg Roedel joerg.roe...@amd.com
Date:   Wed May 5 16:04:43 2010 +0200

KVM: SVM: Fix wrong intercept masks on 32 bit

This patch makes KVM on 32 bit SVM working again by
correcting the masks used for iret interception. With the
wrong masks the upper 32 bits of the intercepts are masked
out which leaves vmrun unintercepted. This is not legal on
svm and the vmrun fails.
Bug was introduced by commits 95ba827313 and 3cfc3092.

Cc: Jan Kiszka jan.kis...@siemens.com
Cc: Gleb Natapov g...@redhat.com
Cc: sta...@kernel.org
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
Signed-off-by: Avi Kivity a...@redhat.com

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 2ba5820..737361f 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2067,7 +2067,7 @@ static int cpuid_interception(struct vcpu_svm *svm)
 static int iret_interception(struct vcpu_svm *svm)
 {
 	++svm-vcpu.stat.nmi_window_exits;
-	svm-vmcb-control.intercept = ~(1UL  INTERCEPT_IRET);
+	svm-vmcb-control.intercept = ~(1ULL  INTERCEPT_IRET);
 	svm-vcpu.arch.hflags |= HF_IRET_MASK;
 	return 1;
 }
@@ -2479,7 +2479,7 @@ static void svm_inject_nmi(struct kvm_vcpu *vcpu)
 
 	svm-vmcb-control.event_inj = SVM_EVTINJ_VALID | SVM_EVTINJ_TYPE_NMI;
 	vcpu-arch.hflags |= HF_NMI_MASK;
-	svm-vmcb-control.intercept |= (1UL  INTERCEPT_IRET);
+	svm-vmcb-control.intercept |= (1ULL  INTERCEPT_IRET);
 	++vcpu-stat.nmi_injections;
 }
 
@@ -2539,10 +2539,10 @@ static void svm_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked)
 
 	if (masked) {
 		svm-vcpu.arch.hflags |= HF_NMI_MASK;
-		svm-vmcb-control.intercept |= (1UL  INTERCEPT_IRET);
+		svm-vmcb-control.intercept |= (1ULL  INTERCEPT_IRET);
 	} else {
 		svm-vcpu.arch.hflags = ~HF_NMI_MASK;
-		svm-vmcb-control.intercept = ~(1UL  INTERCEPT_IRET);
+		svm-vmcb-control.intercept = ~(1ULL  INTERCEPT_IRET);
 	}
 }
 


signature.asc
Description: Digital signature