Bug#960380: python3-xarray: Import fails if python3-sparse is also installed
Package: python3-xarray Version: 0.15.1-2 Severity: normal Hi, if python3-xarray and python3-sparse are both installed, importing xarray fails with an AttributeError, because xarray uses an unqualified "import sparse" trying to import an internal package. The internal package is shadowed by python3-sparse, which does not have the same API as xarray's internal package. The full backtrace in ipython3 is: 22:09:205:~> ipython3 Python 3.8.3rc1 (default, Apr 30 2020, 07:33:30) Type 'copyright', 'credits' or 'license' for more information IPython 7.14.0 -- An enhanced Interactive Python. Type '?' for help. In [1]: import xarray as xr --- AttributeErrorTraceback (most recent call last) in > 1 import xarray as xr /usr/lib/python3/dist-packages/xarray/__init__.py in 1 import pkg_resources 2 > 3 from . import testing, tutorial, ufuncs 4 from .backends.api import ( 5 load_dataarray, /usr/lib/python3/dist-packages/xarray/testing.py in 5 import pandas as pd 6 > 7 from xarray.core import duck_array_ops, formatting 8 from xarray.core.dataarray import DataArray 9 from xarray.core.dataset import Dataset /usr/lib/python3/dist-packages/xarray/core/duck_array_ops.py in 12 import pandas as pd 13 ---> 14 from . import dask_array_compat, dask_array_ops, dtypes, npcompat, nputils 15 from .nputils import nanfirst, nanlast 16 from .pycompat import dask_array_type /usr/lib/python3/dist-packages/xarray/core/dask_array_compat.py in 5 import numpy as np 6 > 7 from .pycompat import dask_array_type 8 9 try: /usr/lib/python3/dist-packages/xarray/core/pycompat.py in 15 import sparse 16 ---> 17 sparse_array_type = (sparse.SparseArray,) 18 except ImportError: # pragma: no cover 19 sparse_array_type = () AttributeError: module 'sparse' has no attribute 'SparseArray' Cheers, Mika -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (650, 'testing'), (450, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/8 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-xarray depends on: ii python33.8.2-3 ii python3-numpy 1:1.17.4-5 ii python3-pandas 0.25.3+dfsg2-2 ii python3-pkg-resources 46.1.3-1 Versions of packages python3-xarray recommends: ii python3-bottleneck 1.2.1+ds1-2+b2 ii python3-dask2.11.0+dfsg-1 ii python3-h5netcdf0.8.0-1 ii python3-netcdf4 1.5.3-1+b5 ii python3-zarr2.4.0+ds-1 Versions of packages python3-xarray suggests: pn python-xarray-doc pn python3-cartopy ii python3-matplotlib 3.2.1-1+b1 pn python3-pydap pn python3-rasterio ii python3-scipy 1.4.1-2 ii python3-seaborn 0.10.1-1 ii python3-toolz 0.9.0-1.1 -- no debconf information
Bug#838858: firmware-amd-graphics: missing SI/CI smc firmware files
Hi, I can confirm that James' patch fixes the issue for me as well, on 4.9.0-rc5. Without the patch, X can't start for me neither on 4.8 nor on 4.9.0-rc5, but works fine on 4.7. I'm using a pitcairn graphic card. Would be nice to get the files included soon, as it is effectively making testing/stretch systems with radeon SI/CI cards unbootable right now. Cheers + thanks, Mika -- pgpOT3VX6ZX8w.pgp Description: Digitale Signatur von OpenPGP
Bug#844618: ITP: bornagain -- Simulating and fitting X-ray and neutron small-angle scattering at grazing incidence
Hi Frederic, I was just accepted in the debian-science team on alioth, my login is mikapfl-guest. Thanks for creating the git repository on alioth, I'll commit what I've done so far (mostly some metadata like watchfile and copyright) using git-buildpackage soon. bornagain is a pretty complex program, with a C++ shared library, a qt GUI and bindings for python as well as python3. I'll first try to build one monolithic package with GUI, library and python bindings, and then see how to split it and build the python3 bindings as well. Another problem might be the bundled libraries, the upstream tarball is bundling patched versions of gtest, some fitting routines from other packages like ROOT and some themes and widgets from qt. Cheers Mika Am 2016-11-18 08:07, schrieb PICCA Frederic-Emmanuel: Hello Mika, VEry glade to hear that you decided to integrate bornagain into Debian. I created a git repository for it under ssh://git.debian.org/git/debian-science/packages/bornagain.git do you have an alioth account, and are you already member of the debian-science team ? Cheers Frederic
Bug#844618: ITP: bornagain -- Simulating and fitting X-ray and neutron small-angle scattering at grazing incidence
Package: wnpp Severity: wishlist Owner: "Mika Pflüger" <deb...@mikapflueger.de> User: debian-scie...@lists.debian.org Usertags: field..physics * Package name: bornagain Version : 1.7.0 Upstream Author : Scientific Computing Group at MLZ Garching: Jan Burle, Jonathan M. Fisher, Marina Ganeva, Gennady Pospelov, Walter Van Herck and Joachim Wuttke * URL : http://bornagainproject.org * License : GPL3 Programming Lang: C++, Python Description : Simulating and fitting X-ray and neutron small-angle scattering at grazing incidence BornAgain is a software package to simulate and fit small-angle scattering at grazing incidence. It supports analysis of both X-ray (GISAXS) and neutron (GISANS) data. Calculations are carried out in the framework of the distorted wave Born approximation (DWBA). BornAgain provides a graphical user interface for interactive use as well as a generic python and C++ framework for modeling multilayer samples with smooth or rough interfaces and with various types of embedded nanoparticles. .. BornAgain supports: .. Layers: * Multilayers without any restrictions on the number of layers * Interface roughness correlation * Magnetic materials .. Particles: * Choice between different shapes of particles (form factors) * Particles with inner structures * Assemblies of particles * Size distribution of the particles (polydispersity) .. Positions of Particles: * Decoupled implementations between vertical and planar positions * Vertical distributions: particles at specific depth in layers or on top. * Planar distributions: - fully disordered systems - short-range order distribution (paracrystals) - two- and one-dimensional lattices .. Input Beam: * Polarized or unpolarized neutrons * X-ray * Divergence of the input beam (wavelength, incident angles) following different distributions * Possible normalization of the input intensity .. Detector: * Off specular scattering * Two-dimensional intensity matrix, function of the output angles .. Use of BornAgain: * Simulation of GISAXS and GISANS from the generated sample * Fitting to reference data (experimental or numerical) * Interactions via Python scripts or Graphical User Interface .. If you use BornAgain in your work, please cite C. Durniak, M. Ganeva, G. Pospelov, W. Van Herck, J. Wuttke (2015), BornAgain — Software for simulating and fitting X-ray and neutron small-angle scattering at grazing incidence, version , http://www.bornagainproject.org I would like to maintain the package within the debian science team. It would be great to also get other widely-used free small- and wide-angle scattering systems into debian, so it would be great to work together with other interested people to package BornAgain as well as other SAS/WAS software. Cheers, Mika
Bug#799736: python-milter: statically compiled on all architectures besides arm64, ppc64el -> needs at least binNMU
Package: python-milter Version: 1.0-1 Severity: normal Hi, python-milter compilation seems to have been broken at some time during the jessie cycle, and since it hasn't been recompiled since then, it is still statically compiled against libmilter on most architectures. See: $ ldd /usr/lib/python2.7/dist-packages/milter.so linux-vdso.so.1 (0x7ffd87b9f000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7efcf3d72000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7efcf39c9000) /lib64/ld-linux-x86-64.so.2 (0x7efcf41a9000) (There should be also a libmilter.so.1.0.1 in there) The problems are: 1. python-milter would not pick up security updates of libmilter. 2. python-milter actually _did not_ pick up the last changes in libmilter, including the socket activation patch added to make systemd socket activation possible (that's how I found this). So socket activation works if you write a C program using smfi_setconn(), but does not work using a python program with milter.setconn(). However, the build problem seems to have been fixed somehow already, if I recompile in an up-to-date sid, python-milter picks up the libmilter dependency just fine, so I guess python-milter only needs a binNMU to fix the binary packages in sid (and then testing). I don't know if this warrants a fix in stable, it is quite annoying, but is most likely not a big problem (until there is a security hole in libmilter). If I recompile in an up-to-date stable chroot, it also picks up the dependency, so also in stable a binNMU should fix it. Cheers, Mika -- System Information: Debian Release: stretch/sid APT prefers testing-proposed-updates APT policy: (650, 'testing-proposed-updates'), (650, 'testing'), (450, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-milter depends on: ii libc6 2.19-20 ii python 2.7.9-1 ii python-dns 2.3.6-3 python-milter recommends no packages. Versions of packages python-milter suggests: ii postfix2.11.3-1 pn python-milter-doc -- no debconf information -- pgp3XBV9_yU1O.pgp Description: Digitale Signatur von OpenPGP
Bug#778487: s3ql: Needs python-dugong = 3.4
Hi Nikolaus,
Am Mon, 16 Feb 2015 09:42:57 -0800
schrieb Nikolaus Rath nikol...@rath.org:
So please tighten the dependencies of s3ql 2.13 to require
python3-dugong = 3.4
At least according to
https://packages.debian.org/source/unstable/s3ql, this is exactly
what the dependency is.
That shows the dependencies of the s3ql source package (I guess that's
build dependencies, but I'm not sure about that). The dependencies of
the s3ql binary packages are found at
https://packages.debian.org/sid/s3ql
and as you can see, there is no version specified for python3-dugong. I
think the ${python3:Depends} does not expand to versioned dependencies
by default. The dh_python3 man page says:
If the pydist file contains PEP386 flag or set of (uscan like) rules,
dh_python3 will make the depedency versioned (version requirements are
ignored by default).
So I guess dh_python3 needs a pydist file or a py3dist-overrides file.
Adding debian/s3ql.pydist with the contents
dugong python3-dugong; PEP386
did not do the trick for me, maybe I'm reading the manpage wrong.
However; I couldn't test building in a clean environment because
building s3ql failed for me (with and without the pydist file) in an
unstable pbuilder. I still think a proper pydist file should work.
Cheers,
Mika
--
pgpjah7f9TaT9.pgp
Description: Digitale Signatur von OpenPGP
Bug#778487: s3ql: Needs python-dugong = 3.4
Package: s3ql
Version: 2.13+dfsg-1
Severity: normal
Dear Maintainer,
s3ql version 2.13+dfsg-1 installs without problem on a jessie system, which has
python3-dugong 3.3+dfsg-3, but it actually requires python3-dugong = 3.4, as
this traceback shows:
Traceback (most recent call last):
File /usr/lib/python3/dist-packages/pkg_resources.py, line 449, in
_build_master
ws.require(__requires__)
File /usr/lib/python3/dist-packages/pkg_resources.py, line 745, in require
needed = self.resolve(parse_requirements(requirements))
File /usr/lib/python3/dist-packages/pkg_resources.py, line 644, in resolve
raise VersionConflict(dist, req)
pkg_resources.VersionConflict: (dugong 3.3 (/usr/lib/python3/dist-packages),
Requirement.parse('dugong=3.4'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File /usr/bin/fsck.s3ql, line 5, in module
from pkg_resources import load_entry_point
File /usr/lib/python3/dist-packages/pkg_resources.py, line 2876, in module
working_set = WorkingSet._build_master()
File /usr/lib/python3/dist-packages/pkg_resources.py, line 451, in
_build_master
return cls._build_from_requirements(__requires__)
File /usr/lib/python3/dist-packages/pkg_resources.py, line 464, in
_build_from_requirements
dists = ws.resolve(reqs, Environment())
File /usr/lib/python3/dist-packages/pkg_resources.py, line 639, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: dugong=3.4
So please tighten the dependencies of s3ql 2.13 to require python3-dugong = 3.4
Cheers,
Mika
-- System Information:
Debian Release: 8.0
APT prefers testing-proposed-updates
APT policy: (650, 'testing-proposed-updates'), (650, 'testing'), (450,
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages s3ql depends on:
ii fuse 2.9.3-15+b1
ii libc6 2.19-13
ii libjs-sphinxdoc1.2.3+dfsg-1
ii libsqlite3-0 3.8.7.1-1
ii psmisc 22.21-2
ii python33.4.2-2
ii python3-apsw 3.8.6-r1-1
ii python3-crypto 2.6.1-5+b2
ii python3-defusedxml 0.4.1-2
ii python3-dugong 3.3+dfsg-3
ii python3-llfuse 0.40-2+b2
ii python3-pkg-resources 5.5.1-1
ii python3-requests 2.4.3-4
s3ql recommends no packages.
s3ql suggests no packages.
-- 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#777176: Fixed version uploaded to unstable, please unblock
Hi,
the fixed version was uploaded to unstable by kobold (the maintainer),
and needs an unblock to migrate. The final debdiff between testing and
unstable is attached. Please unblock if all looks good to you:
unblock phpldapadmin/1.2.2-5.2
Cheers + thanks,
Mika
diff -Nru phpldapadmin-1.2.2/debian/changelog phpldapadmin-1.2.2/debian/changelog
--- phpldapadmin-1.2.2/debian/changelog 2014-05-02 04:30:44.0 +0200
+++ phpldapadmin-1.2.2/debian/changelog 2015-02-07 23:09:25.0 +0100
@@ -1,3 +1,11 @@
+phpldapadmin (1.2.2-5.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Update the php 5.5 compatibility patch for the password_hash_custom
+setting (Closes: #761637).
+
+ -- Mika Pflüger deb...@mikapflueger.de Thu, 05 Feb 2015 00:41:07 +0100
+
phpldapadmin (1.2.2-5.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru phpldapadmin-1.2.2/debian/NEWS phpldapadmin-1.2.2/debian/NEWS
--- phpldapadmin-1.2.2/debian/NEWS 1970-01-01 01:00:00.0 +0100
+++ phpldapadmin-1.2.2/debian/NEWS 2015-02-07 23:17:10.0 +0100
@@ -0,0 +1,9 @@
+phpldapadmin (1.2.2-5.2) unstable; urgency=medium
+
+ The setting option 'password_hash' has been renamed to 'password_hash_custom'.
+ Please fix your /etc/phpldapadmin/config.php and replace all references to
+ $servers-setValue('appearance','password_hash',
+ with
+ $servers-setValue('appearance','password_hash_custom',
+
+ -- Mika Pflüger deb...@mikapflueger.de Sat, 07 Feb 2015 23:09:07 +0100
diff -Nru phpldapadmin-1.2.2/debian/patches/php-5.5-compat.patch phpldapadmin-1.2.2/debian/patches/php-5.5-compat.patch
--- phpldapadmin-1.2.2/debian/patches/php-5.5-compat.patch 2014-05-02 04:28:13.0 +0200
+++ phpldapadmin-1.2.2/debian/patches/php-5.5-compat.patch 2015-02-05 01:13:38.0 +0100
@@ -20,9 +20,9 @@
Index: phpldapadmin-1.2.2/lib/PageRender.php
===
phpldapadmin-1.2.2.orig/lib/PageRender.php 2014-05-01 21:01:57.218441026 -0400
-+++ phpldapadmin-1.2.2/lib/PageRender.php 2014-05-01 21:01:57.210441026 -0400
-@@ -286,7 +286,7 @@
+--- phpldapadmin-1.2.2.orig/lib/PageRender.php
phpldapadmin-1.2.2/lib/PageRender.php
+@@ -286,7 +286,7 @@ class PageRender extends Visitor {
break;
default:
@@ -31,7 +31,7 @@
}
$vals = array_unique($vals);
-@@ -956,7 +956,7 @@
+@@ -956,7 +956,7 @@ class PageRender extends Visitor {
if (trim($val))
$enc_type = get_enc_type($val);
else
@@ -40,7 +40,7 @@
$obfuscate_password = obfuscate_password_display($enc_type);
-@@ -981,7 +981,7 @@
+@@ -981,7 +981,7 @@ class PageRender extends Visitor {
if (trim($val))
$enc_type = get_enc_type($val);
else
@@ -51,9 +51,9 @@
Index: phpldapadmin-1.2.2/lib/ds_ldap.php
===
phpldapadmin-1.2.2.orig/lib/ds_ldap.php 2014-05-01 21:01:57.218441026 -0400
-+++ phpldapadmin-1.2.2/lib/ds_ldap.php 2014-05-01 21:01:57.210441026 -0400
-@@ -1116,13 +1116,24 @@
+--- phpldapadmin-1.2.2.orig/lib/ds_ldap.php
phpldapadmin-1.2.2/lib/ds_ldap.php
+@@ -1116,13 +1116,24 @@ class ldap extends DS {
if (is_array($dn)) {
$a = array();
@@ -83,9 +83,9 @@
public function getRootDSE($method=null) {
Index: phpldapadmin-1.2.2/lib/ds_ldap_pla.php
===
phpldapadmin-1.2.2.orig/lib/ds_ldap_pla.php 2014-05-01 21:01:57.218441026 -0400
-+++ phpldapadmin-1.2.2/lib/ds_ldap_pla.php 2014-05-01 21:01:57.210441026 -0400
-@@ -16,7 +16,7 @@
+--- phpldapadmin-1.2.2.orig/lib/ds_ldap_pla.php
phpldapadmin-1.2.2/lib/ds_ldap_pla.php
+@@ -16,7 +16,7 @@ class ldap_pla extends ldap {
function __construct($index) {
parent::__construct($index);
@@ -96,9 +96,9 @@
Index: phpldapadmin-1.2.2/lib/functions.php
===
phpldapadmin-1.2.2.orig/lib/functions.php 2014-05-01 20:59:08.770437445 -0400
-+++ phpldapadmin-1.2.2/lib/functions.php 2014-05-01 21:04:29.302444259 -0400
-@@ -2126,7 +2126,7 @@
+--- phpldapadmin-1.2.2.orig/lib/functions.php
phpldapadmin-1.2.2/lib/functions.php
+@@ -2126,7 +2126,7 @@ function password_types() {
*crypt, ext_des, md5crypt, blowfish, md5, sha, smd5, ssha, or clear.
* @return string The hashed password.
*/
@@ -107,7 +107,7 @@
if (DEBUG_ENABLED (($fargs=func_get_args())||$fargs='NOARGS'))
debug_log('Entered (%%)',1,0,__FILE__,__LINE__,__METHOD__,$fargs);
-@@ -2307,7 +2307,7 @@
+@@ -2307,7 +2307,7 @@ function password_check($cryptedpassword
# SHA crypted passwords
case 'sha':
@@ -116,7 +116,7 @@
return true;
else
return false;
-@@ -2316,7 +2316,7 @@
+@@ -2316,7 +2316,7 @@ function password_check($cryptedpassword
# MD5 crypted passwords
case 'md5':
@@ -125,7 +125,7 @@
return true;
else
return false;
-@@ -2544,13 +2544,24 @@
Bug#761637: Fixed package
Hi, I have uploaded a package containing a fix for #761637 to mentors.debian.net: https://mentors.debian.net/package/phpldapadmin I have asked for pre-approval of the release team to include the fixed package into testing, Niels Thykier agreed that #761637 looks grave enough to justify including a fix into Jessie, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777176 As I do not have upload privileges in debian, I can't upload the fixed package myself. Could you check the fixed package and upload to unstable? I'll then file the unblock request with the release team. If you are unable to upload the package atm, I'll start searching for a sponsor from monday on. Cheers, Mika -- pgp0EkehLyetj.pgp Description: Digitale Signatur von OpenPGP
Bug#777176: pre-approval: unblock: phpldapadmin/1.2.2-5.2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi,
phpldapadmin has bug #761637, which I think is RC for phpldapadmin. The short
version is: phpldapadmin is a frontend to manage ldap directories. As a
regression from stable, the version in testing crashes if an entry in the
managed ldap directory contains a password field. As it is /very/ common to
have password fields in ldap entries, this renders the package unusable for a
large portion of the user base.
Fortunately, the fix for this is small, as the issue is already partly fixed by
version 1.2.2-5.1 which is already in testing. It was missing:
* A single line change in the code.
* An update of the config file
* A NEWS entry to explain users how to update their config.
I have prepared a package containing the fix, which can provisionally be found
at https://mentors.debian.net/package/phpldapadmin . The meat of the debdiff is:
diff -Nru phpldapadmin-1.2.2/debian/changelog
phpldapadmin-1.2.2/debian/changelog
--- phpldapadmin-1.2.2/debian/changelog 2014-05-02 04:30:44.0 +0200
+++ phpldapadmin-1.2.2/debian/changelog 2015-02-05 01:02:16.0 +0100
@@ -1,3 +1,11 @@
+phpldapadmin (1.2.2-5.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Update the php 5.5 compatibility patch for the password_hash_custom
+setting (Closes: #761637).
+
+ -- Mika Pflüger deb...@mikapflueger.de Thu, 05 Feb 2015 00:41:07 +0100
+
phpldapadmin (1.2.2-5.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru phpldapadmin-1.2.2/debian/patches/php-5.5-compat.patch
phpldapadmin-1.2.2/debian/patches/php-5.5-compat.patch
--- phpldapadmin-1.2.2/debian/patches/php-5.5-compat.patch 2014-05-02
04:28:13.0 +0200
+++ phpldapadmin-1.2.2/debian/patches/php-5.5-compat.patch 2015-02-05
01:13:38.0 +0100
+Index: phpldapadmin-1.2.2/config/config.php.example
+===
+--- phpldapadmin-1.2.2.orig/config/config.php.example
phpldapadmin-1.2.2/config/config.php.example
+@@ -379,7 +379,7 @@ $servers-setValue('server','name','My L
+
+ /* Default password hashing algorithm. One of md5, ssha, sha, md5crpyt, smd5,
+blowfish, crypt or leave blank for now default algorithm. */
+-// $servers-setValue('appearance','password_hash','md5');
++// $servers-setValue('appearance','password_hash_custom','md5');
+
+ /* If you specified 'cookie' or 'session' as the auth_type above, you can
+optionally specify here an attribute to use when logging in. If you enter
+@@ -546,7 +546,7 @@ $servers-setValue('sasl','authz_id_rege
+ $servers-setValue('sasl','authz_id_replacement','$1');
+ $servers-setValue('sasl','props',null);
+
+-$servers-setValue('appearance','password_hash','md5');
++$servers-setValue('appearance','password_hash_custom','md5');
+ $servers-setValue('login','attr','dn');
+ $servers-setValue('login','fallback_dn',false);
+ $servers-setValue('login','class',null);
+Index: phpldapadmin-1.2.2/lib/TemplateRender.php
+===
+--- phpldapadmin-1.2.2.orig/lib/TemplateRender.php
phpldapadmin-1.2.2/lib/TemplateRender.php
+@@ -2466,7 +2466,7 @@ function deleteAttribute(attrName,friend
+ if ($val = $attribute-getValue($i))
+ $default = get_enc_type($val);
+ else
+- $default =
$this-getServer()-getValue('appearance','password_hash');
++ $default =
$this-getServer()-getValue('appearance','password_hash_custom');
+
+ if (! $attribute-getPostValue())
+ printf('input type=hidden name=post_value[%s][]
value=%s /',$attribute-getName(),$i);
(the version currently at mentors has a slightly larger debdiff due to quilt
refresh'ing of the php-5.5-compat.patch, but with no further real changes).
If you pre-approve the unblock request, I will write a NEWS entry, seek a
sponsor and come back to you. I am using a fixed version at a reasonably busy
site for two weeks now.
One thing to note is that the version currently in testing deviates from the
upstream solution, possibly because it predates it. The setting which collides
with a php-internal function name ('password_hash' in debian stable) was
[incompletely, hence this bug] changed to 'password_hash_custom' in debian, but
to 'pla_password_hash' in the 1.2.3 upstream version. That is clearly a
suboptimal situation, as this will confuse users and will come back to bite us
later. However, I guess changing 'password_hash_custom' to 'pla_password_hash'
is a bit intrusive at this stage of the release cycle. If you disagree, I can
also prepare a patch which aligns with upstream's choice of bike shed colour.
Cheers,
Mika
unblock phpldapadmin/1.2.2-5.2
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (650, 'testing'), (450, 'unstable
Bug#763701: config: Check for doveconf does not work
Package: dovecot-core
Version: 1:2.2.13-5
Severity: normal
Hi,
in dovecot-core.config you use:
if [ ! -z `which doveconf /dev/null 21` ]; then
which will never be true. As you redirect stderr _and_ stdout of 'which',
the string will always be zero, so the '-z' will always be true and the '!'
will always be false. To fix that, and make stuff more readable, just use:
if which doveconf /dev/null 21; then
instead. 'which' already returns false if the program does not exist.
If you want to, I can prepare a pull request or even a package, just drop
me a line. I also read you consider redesigning the whole certificate
generation code. If you could articulate your goal of what should happen,
I could try to implement that cleanly.
Cheers,
Mika
-- Package-specific info:
dovecot configuration
-
# 2.2.13: /etc/dovecot/dovecot.conf
# OS: Linux 3.14-2-amd64 x86_64 Debian jessie/sid
lda_mailbox_autocreate = yes
lda_mailbox_autosubscribe = yes
mail_location = maildir:~/.Maildir
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox Sent Messages {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
driver = pam
}
plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}
protocols = imap
ssl = no
userdb {
driver = passwd
}
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (650, 'testing'), (450, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-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
Versions of packages dovecot-core depends on:
ii adduser3.113+nmu3
ii debconf [debconf-2.0] 1.5.53
ii libbz2-1.0 1.0.6-7
ii libc6 2.19-11
ii liblzma5 5.1.1alpha+20120614-2
ii libpam-runtime 1.1.8-3.1
ii libpam0g 1.1.8-3.1
ii libssl1.0.01.0.1i-2
ii libwrap0 7.6.q-25
ii openssl1.0.1i-2
ii ucf3.0030
ii zlib1g 1:1.2.8.dfsg-2
dovecot-core recommends no packages.
Versions of packages dovecot-core suggests:
ii dovecot-gssapi1:2.2.13-5
ii dovecot-imapd 1:2.2.13-5
ii dovecot-ldap 1:2.2.13-5
pn dovecot-lmtpd none
pn dovecot-lucenenone
pn dovecot-managesieved none
ii dovecot-mysql 1:2.2.13-5
ii dovecot-pgsql 1:2.2.13-5
pn dovecot-pop3d none
ii dovecot-sieve 1:2.2.13-5
pn dovecot-solr none
ii dovecot-sqlite1:2.2.13-5
ii ntp 1:4.2.6.p5+dfsg-3
Versions of packages dovecot-core is related to:
ii dovecot-core [dovecot-common] 1:2.2.13-5
pn dovecot-dbgnone
pn dovecot-devnone
ii dovecot-gssapi 1:2.2.13-5
ii dovecot-imapd 1:2.2.13-5
ii dovecot-ldap 1:2.2.13-5
pn dovecot-lmtpd none
pn dovecot-managesieved none
ii dovecot-mysql 1:2.2.13-5
ii dovecot-pgsql 1:2.2.13-5
pn dovecot-pop3d none
ii dovecot-sieve 1:2.2.13-5
ii dovecot-sqlite 1:2.2.13-5
-- debconf information:
* dovecot-core/create-ssl-cert: false
dovecot-core/ssl-cert-name: localhost
* dovecot-core/ssl-cert-exists:
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702030: [DSE-Dev] forbid most packages to depend on or recommend apparmor
Hi, I certainly can't speak for the whole team, but can offer my thoughts about the situation of SELinux at the moment. intrigeri intrig...@debian.org wrote: AFAIK this is inconsistent with how selinux is handled, which is only enabled via an explicit boot option. I was not aware of that, thanks for pointing it out. @SELinux maintainers: is this behavior on purpose, or is it due to the historical lack of a facility (recently added by the /etc/default/grub.d support) to easily have a package append arguments to the kernel command-line? I think both. Installing the default SELinux policy and enabling it routinely breaks all kinds of stuff (avahi-things, booting with systemd, obtaining IP addresses via dhcp, hotplugging of network interfaces etc. just to name some things that popped up in testing or stable during the last year), especially things not usually tested on servers run by the more security-aware part of the linux admin population. So for the regular user (unfortunately), enabling selinux simply by installing the policy package would certainly feel a lot like a grave bug (breaks unrelated software). Shouldn't we handle our LSMs symmetrically? Indeed, I think we should. I see several ways of keeping things consistent while reaching the aforementioned AppArmor usability goal: a) Having the SELinux equivalent of the apparmor package enable it by default too (and then, we'll need conflicts); I've no idea if this is feasible; one would need to look at the SELinux packages and their chain of reverse-dependencies. However, I think this could be pretty reasonable, given 1) it would be e.g. a selinux binary package doing this, not the library or selinux-basics/utils package. This binary package does not exist at the moment, but could be created. 2) it would ask via debconf before enabling. b) Implementing the behavior proposed by Patrick via a dedicated apparmor-$something configuration package. ftp-masters likely won't be happy with it (understandably), unless we demonstrate it's the best available solution to reach a sensible goal. The SELinux team is then free to create a corresponding package. This is basically a) for selinux, as there is no standard selinux package. c) A new package whose job is to select and enable a LSM (or none). Likely none would be the default for now. It's tempting to take benefit from debconf here. d) An apparmor-activate command, very similar to selinux-activate (from the selinux-basics package). The resulting user experience would be less friendly than just install the apparmor package, but perhaps that's acceptable for now. Other ideas? SELinux maintainers, any thoughts on this? I've no idea what's the current situation wrt. SELinux policies in Debian — are they in a shape that warrants thinking of usability matters for the target userbase described above, or do potential users anyway have to play with a terminal and text editor as root? In other words, should we work on a shared solution to this problem, or should the AppArmor folks do their bit on their side, merely being careful not to break the SELinux usecases? For the users we are currently targetting, selinux-activate is adequate, but a debconf question would certainly be easier. We are (slowly) working on getting better user experience, but yes, people still have to play with a terminal as root for jessie, I'm afraid. (Also, what happens if someone has already enabled selinux, then installs this apparmor package which is intended to automatically enable apparmor?) The *last* LSM activated on the kernel command-line is the one that's enabled in practice (tested both ways). So, installing a apparmor package, that automatically enables this LSM, would override the previous manual enabling of SELinux. The reciprocal applies when running selinux-activate (which is arguably a more explicit choice made by the administrator than installing the apparmor package). IMO, both should first check if another LSM is enabled. That sounds like a good idea. It would be nice to have some kind of standard way to tell if any other LSM is enabled, otherwise we all have to maintain some selinuxenabled | $apparmorenabled | $whateverelseenabled shell snippets on our own. Cheers, Mika -- signature.asc Description: PGP signature
Bug#758464: [DSE-Dev] Bug#758464: selinux-policy-default: Impossible to use libvirt(d) if enforcing
Hi Andreas,
Andreas Florath an...@flonatel.org wrote:
avc:
denied { execstack }
Which SELinux booleans have you set? Does allowing execstack help?
To learn about SELinux booleans, see booleans(8), to see the status of
all booleans, use getsebool -a.
To switch allow_execstack, use setsebool allow_execstack on.
Maybe this helps and it is merely a configuration/documentation issue.
Cheers,
Mika
--
signature.asc
Description: PGP signature
Bug#756729: [DSE-Dev] Bug#756729: selinux-policy-default: Setting SELinux to enforce results in not configured network interface at boot time
Hi,
Andreas Florath an...@flonatel.org wrote:
Package: selinux-policy-default
Version: 2:2.20110726-12
Severity: important
Dear Maintainer,
after enableing SELinux the eth0 network device is not longer
configured automatically during boot time.
There is a similar bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728950
but it differs in the command. Here it is 'dhclient' there the
scripts.
IMHO this is an 'important' bug, because systems using dhcp cannot
switch to enforce - or they will not work properly any more.
The eth0 device is configured as:
allow-hotplug eth0
iface eth0 inet dhcp
After booting with SELinux set to enforced the eth0 network interface
is not configured. ifconfig shows only 'lo'.
During boot, the following two AVCs are reported:
Jul 31 12:55:55 debtest kernel: [4.489454] type=1400
audit(1406804155.296:5): avc: denied { name_bind } for pid=1677
comm=dhclient src=1356
scontext=system_u:system_r:dhcpc_t:s0-s0:c0.c1023
tcontext=system_u:object_r:port_t:s0 tclass=udp_socket Jul 31
12:55:55 debtest kernel: [4.489641] type=1400
audit(1406804155.296:6): avc: denied { name_bind } for pid=1677
comm=dhclient src=14762
scontext=system_u:system_r:dhcpc_t:s0-s0:c0.c1023
tcontext=system_u:object_r:port_t:s0 tclass=udp_socket
When I use these both lines as input to 'audit2allow' and 'semodule
$ audit2allow -M localdhclient
$ semodule -i localdhclient.pp
after booting, the interface comes up, but it looks that the further
setup needs 'hostname' and 'ip':
Jul 31 13:39:41 debtest kernel: [4.954371] type=1400
audit(1406806780.651:5): avc: denied { read write } for pid=1723
comm=ip path=socket:[7251] dev=sockfs ino=7251
scontext=system_u:system_r:ifconfig_t:s0-s0:c0.c1023
tcontext=system_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=udp_socket
Jul 31 13:39:41 debtest kernel: [4.954457] type=1400
audit(1406806780.651:6): avc: denied { read write } for pid=1723
comm=ip path=socket:[7252] dev=sockfs ino=7252
scontext=system_u:system_r:ifconfig_t:s0-s0:c0.c1023
tcontext=system_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=udp_socket
Jul 31 13:39:41 debtest kernel: [5.005695] type=1400
audit(1406806780.703:7): avc: denied { read write } for pid=1751
comm=hostname path=socket:[7251] dev=sockfs ino=7251
scontext=system_u:system_r:hostname_t:s0-s0:c0.c1023
tcontext=system_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=udp_socket
Jul 31 13:39:41 debtest kernel: [5.005781] type=1400
audit(1406806780.703:8): avc: denied { read write } for pid=1751
comm=hostname path=socket:[7252] dev=sockfs ino=7252
scontext=system_u:system_r:hostname_t:s0-s0:c0.c1023
tcontext=system_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=udp_socket
Jul 31 13:39:41 debtest kernel: [5.007904] type=1400
audit(1406806780.703:9): avc: denied { read write } for pid=1752
comm=ip path=socket:[7251] dev=sockfs ino=7251
scontext=system_u:system_r:ifconfig_t:s0-s0:c0.c1023
tcontext=system_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=udp_socket
Jul 31 13:39:41 debtest kernel: [5.007988] type=1400
audit(1406806780.703:10): avc: denied { read write } for pid=1752
comm=ip path=socket:[7252] dev=sockfs ino=7252
scontext=system_u:system_r:ifconfig_t:s0-s0:c0.c1023
tcontext=system_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=udp_socket
After another 'autid2allow' and 'semodule' there are no further AVCs
in the log after a reboot and the interface works fine.
Could you provide the output of
# sestatus
# semodule -l
and also which init system you are using?
Cheers,
Mika
--
signature.asc
Description: PGP signature
Bug#756731: [DSE-Dev] Bug#756731: selinux-policy-default: Setting SELinux to enforce when using systemd some AVCs are logged during boot
Hi Andre, as you can see I set the severity of the cosmetic bug reports, where AVCs are logged but apparently no functional degradation happens to minor. Often programs will use different codepaths (or do not actually care) when something is denied (think of the equivalent of ls -la|grep etc [or something along the lines which actually makes sense] where stat'ing /dev will be prohibited. It will log an AVC, but the program doesn't actually care). Therefore, in policy we have dontaudit rules, which do deny access, but don't log AVCs. So if functionality is not degraded, this actually looks like a missing dontaudit rule, which is arguably only a minor error. Also please note that updates to Debian stable are only done for at least important bugs, so it is not really worth reporting minor bugs against versions in stable (other than for documentation purposes), we most likely will not actually fix them. If someone finds time, we will however try to test if they persist in testing/unstable to try to fix them in testing, such that the next stable release will have fewer bugs. If you could test minor/normal bugs you find in stable in testing/unstable (e.g. in a VM), that would actually help us a lot! If you need some help in setting up a test environment for that, I can help you with it (or even provide a vm to you which you can use for testing if you do not have necessary hardware). Cheers, Mika -- signature.asc Description: PGP signature
Bug#756729: [DSE-Dev] Bug#756729: selinux-policy-default: Setting SELinux to enforce results in not configured network interface at boot time
Hi Andre, most interesting is the output of semodule -l. SELinux refpolicy is modular, so that you only have to load the policy for the programs you actually use. Note that in your case you have loaded only some select modules, pretty much a minimal set of modules, which will provide only very basic functionality. Upon installation, the selinux-policy-default package in stable tries to guess which modules you could need and installs those. If you then install other software afterwards, you have to enable other modules yourself. To enable the dhcp module (which hopefully will fix your problem), use: # semodule -i /usr/share/selinux/default/dhcp.pp you will find all available modules in /usr/share/selinux/default/, just check which one sounds like you need it. You can also install all of them and then selectively disable some using # semodule -d dhcp (or equivalent for other module names, see semodule(8)), which is often easier. Note that having loaded too many modules usually only means selinux is not as effective in preventing acceses (if e.g. you don't have an ftp server installed, there is no need to allow ftp access), but it usually will not do much harm. We recognise that this situation (minimal set of default modules enable upon installation) is confusing for many users, which is why we changed this already in debian unstable, such that by default a much larger set (also including dhcp) of modules is installed. I hope this helps you to get up and running with selinux. Unfortunately, there is only very basic documentation about selinux on debian (the best I know is http://debian-handbook.info/browse/stable/sect.selinux.html from the debian administrator's handbook), but it is mostly analogous to how it works on RHEL and Fedora, so you can also read https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/index.html Cheers, Mika -- signature.asc Description: PGP signature
Bug#756468: [DSE-Dev] Bug#756468: Please think about fixing this bug in stable
Hi, Andreas Florath an...@flonatel.org wrote: IMHO this bug should be fixed in stable, because it prevents installing packages that use addgroup when SELinux is set to enforcing. I haven't found time to investigate the issue, but if you have loaded the unconfined module and use normal apt-get (not se_apt-get etc.) commands as unconfined root, everything should work. You could at least use this as a workaround for the time being. Cheers, Mika -- signature.asc Description: PGP signature
Bug#756542: [DSE-Dev] Bug#756542: selinux-policy-default: Installation of systemd from wheezy-backports results in many AVCs
Hi, Andreas Florath an...@flonatel.org wrote: using systemd from backports (version see below) many AVCs appear in the logging. The system is (partially) unusable - e.g. eth0 works not reliable. Using software from backports usually is not supported by the refpolicy in stable (we can't see the future, after all), and it is very unlikely we'll be able to fix that in stable. Cheers, Mika -- signature.asc Description: PGP signature
Bug#747111: [DSE-Dev] Bug#747111: selinux-basics: MCS mode is missing in /etc/selinux/config
Hi, Victor Porton por...@narod.ru wrote: From /etc/selinux/config: # SELINUXTYPE= can take one of these two values: # default - equivalent to the old strict and targeted policies # mls - Multi-Level Security (for military and educational use) # src - Custom policy built from source SELINUXTYPE=default MCS mode is missing in the comments and I am not sure whether it is supported at all. Personally I need MCS (but not MLS) support for my project. The default policy (from selinux-policy-default) is a mcs policy. It might be a good idea to reword the documentation to clearly state this like this: # default - equivalent to the old strict and targeted policies (includes multi category security) on the other hand that would change the config file, triggering dpkg-questions for users who modified the file for only a small benefit. Note that the fact that selinux-policy-default uses mcs is already documented in the package description. I personally don't think we should update the comments in /etc/selinux/config unless we are changing that file anyway. Cheers, Mika signature.asc Description: PGP signature
Bug#719743: selinux-policy-default: GDM3 doesn't load in permissive mode
Hi Kees, could you post the output of: # semodule -l # sestatus # cat /var/log/gdm3/:0.log # cat /var/log/gdm3/:0-greeter.log # cat /var/log/gdm3/:0-slave.log I am running testing (with the same policy as 7/wheezy) in permissive mode without problems, so we need to figure out what is different in your setup. Cheers, Mika -- signature.asc Description: PGP signature
Bug#503565: [DSE-Dev] Bug#503565: closed by Mika Pflüger deb...@mikapflueger.de (Old and unreproducible)
Hi, Am Thu, 8 Aug 2013 23:41:06 +0200 schrieb Julien Cristau jul...@cristau.org: With resolvconf installed and the bind hook configured? With resolvconf installed but without bind hook – the bind hook was removed some time ago (see #697435). Now, you /can/ of course write your own hook for bind or copy the one from resolvconf's doc repository; however, I think than you have to write the relevant parts of policy yourself (possibly using audit2allow). Cheers, Mika -- signature.asc Description: PGP signature
Bug#690087: Can't reproduce with -13
Hi, I can't reproduce this bug. What I did: * Install a fresh wheezy with task standard and openssh-server. * apt-get install selinux-basics auditd * selinux-activate; reboot; selinux-config-enforcing; reboot * adduser unconf * adduser conf * semanage login -a -s user_u conf Then semanage login -l shows: Login Name SELinux User MLS/MCS Range __default__unconfined_u SystemLow-SystemHigh conf user_u SystemLow root unconfined_u SystemLow-SystemHigh system_u system_u SystemLow-SystemHigh Also, ps -eZ|grep sshd shows that sshd actually has categories: LABEL PID TTY TIME CMD system_u:system_r:sshd_t:s0-s0:c0.c1023 2585 ? 00:00:00 sshd I can log in via ssh for both users, unconf and conf: conf@setest:~$ id -Z user_u:user_r:user_t:SystemLow unconf@setest:~$ id -Z unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh Either the bug was fixed in the meantime or I don't understand where the bug actually is. Cheers, Mika -- signature.asc Description: PGP signature
Bug#716753: Not an important bug
Severity 716753 normal Thanks As far as I can see the effect of the missing setsched is only that the regeneration of ssl dh parameters cannot be nice'd and therefore runs with higher priority than would be necessary, possibly congesting the system. As the core functionality (regenerate ssl dh parameters) is not affected, this is not an important bug. And the spurious AVC denial is annoying, but not important either. Cheers, Mika -- signature.asc Description: PGP signature
Bug#707243: Does anything break?
Hi, does anything break, or is it just a spurious AVC denial? If no important functionality of irqbalance is lost, it may not be worth fixing this in stable, we could just forward a fix upstream and wait until it trickles back to debian. Cheers, Mika -- signature.asc Description: PGP signature
Bug#707293: default (chrooted) configuration of postfix is not supported by selinux policy; won't be
Hi, as mentioned in the wiki, the debian default configuration of postfix (chrooted) is not supported by selinux policy. Please use the script postfix-nochroot to unchroot your configuration. Cheers, Mika -- signature.asc Description: PGP signature
Bug#702877: Uploaded to unstable; please unblock
Hi release team,
Thomas Goirand was so nice to upload the fixed package to unstable. He
added a small change to fix building twice in a row, such that the full
changelog now reads:
[ Mika Pflüger ]
* Team upload.
* debian/patches/05_ssl.patch: Add upstream patch to force building
SSL support with newer MySQL client libraries. Thanks to Eldon Koyle
for isolating the fix in the upstream VCS. (Closes: #678169)
* Delete now obsolete debian/patches/README.source which referred to
dpatch.
[ Thomas Goirand ]
* Added a debian/rules clean: rm MySQL_python.egg-info/PKG-INFO, so
it is possible to build the package twice.
The debdiff between the version in testing and stable is attached,
it would be very nice if you could unblock it.
Cheers,
Mika
unblock python-mysqldb/1.2.3-2
--
diff -Nru python-mysqldb-1.2.3/debian/changelog python-mysqldb-1.2.3/debian/changelog
--- python-mysqldb-1.2.3/debian/changelog 2011-10-18 12:46:05.0 +0200
+++ python-mysqldb-1.2.3/debian/changelog 2013-03-15 07:02:21.0 +0100
@@ -1,3 +1,19 @@
+python-mysqldb (1.2.3-2) unstable; urgency=low
+
+ [ Mika Pflüger ]
+ * Team upload.
+ * debian/patches/05_ssl.patch: Add upstream patch to force building
+SSL support with newer MySQL client libraries. Thanks to Eldon Koyle
+for isolating the fix in the upstream VCS. (Closes: #678169)
+ * Delete now obsolete debian/patches/README.source which referred to
+dpatch.
+
+ [ Thomas Goirand ]
+ * Added a debian/rules clean: rm MySQL_python.egg-info/PKG-INFO, so it is
+possible to build the package twice.
+
+ -- Mika Pflüger deb...@mikapflueger.de Mon, 11 Mar 2013 18:03:06 +0100
+
python-mysqldb (1.2.3-1) unstable; urgency=low
* Merge with package from Ubuntu, thanks to Mario Limonciello.
diff -Nru python-mysqldb-1.2.3/debian/patches/05_ssl.patch python-mysqldb-1.2.3/debian/patches/05_ssl.patch
--- python-mysqldb-1.2.3/debian/patches/05_ssl.patch 1970-01-01 01:00:00.0 +0100
+++ python-mysqldb-1.2.3/debian/patches/05_ssl.patch 2013-03-15 06:51:49.0 +0100
@@ -0,0 +1,21 @@
+Description: Force HAVE_OPENSSL if the client library is 5.5 or newer.
+Origin: http://sourceforge.net/p/mysql-python/svn/656/tree//branches/MySQLdb-1.2/MySQLdb/_mysql.c?diff=5059d1f5bfc09e26e1a66617:655
+Bug: http://sourceforge.net/p/mysql-python/bugs/323/
+Reviewed-by: Eldon Koyle eko...@gmail.com
+Last-Update: 2013-03-11
+
+Index: python-mysqldb-argh/_mysql.c
+===
+--- python-mysqldb-argh.orig/_mysql.c 2010-06-17 09:21:56.0 +0200
python-mysqldb-argh/_mysql.c 2013-03-11 18:30:38.839269635 +0100
+@@ -102,6 +102,10 @@
+ #define check_server_init(x) if (!_mysql_server_init_done) _mysql_server_init_done = 1
+ #endif
+
++#if MYSQL_VERSION_ID = 50500
++#define HAVE_OPENSSL 1
++#endif
++
+ PyObject *
+ _mysql_Exception(_mysql_ConnectionObject *c)
+ {
diff -Nru python-mysqldb-1.2.3/debian/patches/series python-mysqldb-1.2.3/debian/patches/series
--- python-mysqldb-1.2.3/debian/patches/series 2011-10-18 11:38:40.0 +0200
+++ python-mysqldb-1.2.3/debian/patches/series 2013-03-15 06:51:49.0 +0100
@@ -1,2 +1,3 @@
01_converters_boolean.patch
03_converters_set2str.patch
+05_ssl.patch
diff -Nru python-mysqldb-1.2.3/debian/rules python-mysqldb-1.2.3/debian/rules
--- python-mysqldb-1.2.3/debian/rules 2011-10-18 12:53:10.0 +0200
+++ python-mysqldb-1.2.3/debian/rules 2013-03-15 07:02:45.0 +0100
@@ -17,7 +17,7 @@
python$* setup.py clean
find . -name *.py[co] -exec rm -f {} \;
dh_testroot
- rm -fr build build-python$*
+ rm -fr build build-python$* MySQL_python.egg-info/PKG-INFO
dh_clean
build: $(PYVERS:%=build-python%)
signature.asc
Description: PGP signature
Bug#678169: even more corrected debdiff
Hi,
The corrected debdiff still had a bogus changelog whitespace-only
change, thanks to Julien Cristau for noticing it. So here is an even
more corrected version. (-;
Cheers,
Mika
--
diff -Nru python-mysqldb-1.2.3/debian/changelog
python-mysqldb-1.2.3/debian/changelog
--- python-mysqldb-1.2.3/debian/changelog 2011-10-18 12:46:05.0
+0200
+++ python-mysqldb-1.2.3/debian/changelog 2013-03-12 13:51:34.0
+0100
@@ -1,3 +1,14 @@
+python-mysqldb (1.2.3-2) unstable; urgency=low
+
+ * Team upload.
+ * debian/patches/05_ssl.patch: Add upstream patch to force building
+SSL support with newer MySQL client libraries. Thanks to Eldon Koyle
+for isolating the fix in the upstream VCS. (Closes: #678169)
+ * Delete now obsolete debian/patches/README.source which referred to
+dpatch.
+
+ -- Mika Pflüger deb...@mikapflueger.de Mon, 11 Mar 2013 18:03:06 +0100
+
python-mysqldb (1.2.3-1) unstable; urgency=low
* Merge with package from Ubuntu, thanks to Mario Limonciello.
diff -Nru python-mysqldb-1.2.3/debian/patches/05_ssl.patch
python-mysqldb-1.2.3/debian/patches/05_ssl.patch
--- python-mysqldb-1.2.3/debian/patches/05_ssl.patch1970-01-01
01:00:00.0 +0100
+++ python-mysqldb-1.2.3/debian/patches/05_ssl.patch2013-03-11
18:32:15.0 +0100
@@ -0,0 +1,21 @@
+Description: Force HAVE_OPENSSL if the client library is 5.5 or newer.
+Origin:
http://sourceforge.net/p/mysql-python/svn/656/tree//branches/MySQLdb-1.2/MySQLdb/_mysql.c?diff=5059d1f5bfc09e26e1a66617:655
+Bug: http://sourceforge.net/p/mysql-python/bugs/323/
+Reviewed-by: Eldon Koyle eko...@gmail.com
+Last-Update: 2013-03-11
+
+Index: python-mysqldb-argh/_mysql.c
+===
+--- python-mysqldb-argh.orig/_mysql.c 2010-06-17 09:21:56.0 +0200
python-mysqldb-argh/_mysql.c 2013-03-11 18:30:38.839269635 +0100
+@@ -102,6 +102,10 @@
+ #define check_server_init(x) if (!_mysql_server_init_done)
_mysql_server_init_done = 1
+ #endif
+
++#if MYSQL_VERSION_ID = 50500
++#define HAVE_OPENSSL 1
++#endif
++
+ PyObject *
+ _mysql_Exception(_mysql_ConnectionObject *c)
+ {
diff -Nru python-mysqldb-1.2.3/debian/patches/series
python-mysqldb-1.2.3/debian/patches/series
--- python-mysqldb-1.2.3/debian/patches/series 2011-10-18 11:38:40.0
+0200
+++ python-mysqldb-1.2.3/debian/patches/series 2013-03-11 18:19:24.0
+0100
@@ -1,2 +1,3 @@
01_converters_boolean.patch
03_converters_set2str.patch
+05_ssl.patch
diff -Nru python-mysqldb-1.2.3/debian/README.source
python-mysqldb-1.2.3/debian/README.source
--- python-mysqldb-1.2.3/debian/README.source 2011-09-19 12:48:38.0
+0200
+++ python-mysqldb-1.2.3/debian/README.source 1970-01-01 01:00:00.0
+0100
@@ -1,2 +0,0 @@
-This package uses dpatch for its patch management, see
-/usr/share/doc/dpatch/README.source.gz if you are unfamiliar with it.
signature.asc
Description: PGP signature
Bug#678169: debdiff for a version -2 fixing this bug
Hi, I turned the patch by Eldon Koyle into an update for the debian package. Attached is the debdiff. I chose to include a small documentation fix as I was initially confused by the misleading documentation. If someone could commit this to the DPMT svn and then upload it to unstable, I'm volunteering to file an unblock request. Cheers, Mika -- python-mysqldb-fix-678169.debdiff Description: Binary data signature.asc Description: PGP signature
Bug#678169: corrected debdiff
Hi,
my last debdiff did not include an appropriate (Closes: #)-Tag, this
one is corrected. Sorry for the noise.
Cheers,
Mika
--
diff -Nru python-mysqldb-1.2.3/debian/changelog
python-mysqldb-1.2.3/debian/changelog
--- python-mysqldb-1.2.3/debian/changelog 2011-10-18 12:46:05.0
+0200
+++ python-mysqldb-1.2.3/debian/changelog 2013-03-12 03:11:11.0
+0100
@@ -1,3 +1,14 @@
+python-mysqldb (1.2.3-2) unstable; urgency=low
+
+ * Team upload.
+ * debian/patches/05_ssl.patch: Add upstream patch to force building
+SSL support with newer MySQL client libraries. Thanks to Eldon Koyle
+for isolating the fix in the upstream VCS. (Closes: #678169)
+ * Delete now obsolete debian/patches/README.source which referred to
+dpatch.
+
+ -- Mika Pflüger deb...@mikapflueger.de Mon, 11 Mar 2013 18:03:06 +0100
+
python-mysqldb (1.2.3-1) unstable; urgency=low
* Merge with package from Ubuntu, thanks to Mario Limonciello.
@@ -54,7 +65,6 @@
* Add 02_python_2.6.dpatch to fix python 2.6 related warnings. Thanks to
Mario Limonciello supe...@ubuntu.com for the patch. (closes: #541719)
* bump standards-version to 3.8.3, no changes required.
-
-- Jonas Meurer m...@debian.org Wed, 26 Aug 2009 01:50:35 +0200
python-mysqldb (1.2.2-8) unstable; urgency=low
diff -Nru python-mysqldb-1.2.3/debian/patches/05_ssl.patch
python-mysqldb-1.2.3/debian/patches/05_ssl.patch
--- python-mysqldb-1.2.3/debian/patches/05_ssl.patch1970-01-01
01:00:00.0 +0100
+++ python-mysqldb-1.2.3/debian/patches/05_ssl.patch2013-03-11
18:32:15.0 +0100
@@ -0,0 +1,21 @@
+Description: Force HAVE_OPENSSL if the client library is 5.5 or newer.
+Origin:
http://sourceforge.net/p/mysql-python/svn/656/tree//branches/MySQLdb-1.2/MySQLdb/_mysql.c?diff=5059d1f5bfc09e26e1a66617:655
+Bug: http://sourceforge.net/p/mysql-python/bugs/323/
+Reviewed-by: Eldon Koyle eko...@gmail.com
+Last-Update: 2013-03-11
+
+Index: python-mysqldb-argh/_mysql.c
+===
+--- python-mysqldb-argh.orig/_mysql.c 2010-06-17 09:21:56.0 +0200
python-mysqldb-argh/_mysql.c 2013-03-11 18:30:38.839269635 +0100
+@@ -102,6 +102,10 @@
+ #define check_server_init(x) if (!_mysql_server_init_done)
_mysql_server_init_done = 1
+ #endif
+
++#if MYSQL_VERSION_ID = 50500
++#define HAVE_OPENSSL 1
++#endif
++
+ PyObject *
+ _mysql_Exception(_mysql_ConnectionObject *c)
+ {
diff -Nru python-mysqldb-1.2.3/debian/patches/series
python-mysqldb-1.2.3/debian/patches/series
--- python-mysqldb-1.2.3/debian/patches/series 2011-10-18 11:38:40.0
+0200
+++ python-mysqldb-1.2.3/debian/patches/series 2013-03-11 18:19:24.0
+0100
@@ -1,2 +1,3 @@
01_converters_boolean.patch
03_converters_set2str.patch
+05_ssl.patch
diff -Nru python-mysqldb-1.2.3/debian/README.source
python-mysqldb-1.2.3/debian/README.source
--- python-mysqldb-1.2.3/debian/README.source 2011-09-19 12:48:38.0
+0200
+++ python-mysqldb-1.2.3/debian/README.source 1970-01-01 01:00:00.0
+0100
@@ -1,2 +0,0 @@
-This package uses dpatch for its patch management, see
-/usr/share/doc/dpatch/README.source.gz if you are unfamiliar with it.
signature.asc
Description: PGP signature
Bug#697814: [DSE-Dev] Bug#697814: selinux-policy-default: exim4 and bitlbee want access to sysctl_crypto_t
Hi, Am Thu, 10 Jan 2013 00:11:17 +0200 schrieb Marius Gavrilescu mar...@ieval.ro: For some reason exim4 and bitlbee are trying to read /proc/sys/crypto/fips_enabled and SELinux doesn't let them. Seems to me they are using libgcrypt which tries to read /proc/sys/crypto/fips_enabled to determine if it should enable fips mode. Most applications are however not allowed to do so, in debian atm only chkpwd_t, rpm_t, rpm_script_t, puppet_t, puppetmaster_t are allowed access via the kernel_read_crypto_sysctls interface (defined in kernel.if). In latest upstream git there are quite some additional types which are allowed access, but exim4 and bitlbee are not among those. fedora adds kernel_read_crypto_sysctls(domain) which will allow this for a /lot/ of other programs, basically everybody (for example bitlbee and exim, which are init_daemon_domain). As (at least on my system) there is only the fips_enabled file in /proc/sys/crypto, the possible harm from allowing this for everybody seems very small. It is only the information if the system is in fips mode. How should we proceed? Add kernel_read_crypto_sysctls for everyone who needs it (which could be quite some list considering that libgrypt11 has about 200 reverse dependencies…) or follow the fedora way and allow it for everybody? However, this only breaks fips mode for the affected programs so maybe the impact is so low that we don't fix it for wheezy and therefore only work for a solution upstream. How many people use system wide fips mode? Cheers, Mika -- signature.asc Description: PGP signature
Bug#695622: unblock: refpolicy/2:2.20110726-12
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear Release Team, Please unblock package refpolicy version 2:2.20110726-12, changes since version -11 (which is in testing atm) are: File label fixes: * Label ~/.adobe(/.*)? as mozilla_home_t for flash * Label /usr/sbin/opendkim as dkim_milter_exec_t * Label postalias as postfix_master_exec_t for newaliases * Label port 5546 as dhcpc_port_t and allow dhcpc_t to bind to TCP for client control * Label /usr/lib/kde4/libexec/* and /usr/lib/gvfs/* as bin_t for desktops * Label /run/pm-utils(/.*)? as devicekit_var_run_t not hald_var_run_t * Label /sbin/xtables-multi (the new iptables) * Label /usr/lib/dovecot/auth as dovecot_auth_exec_t. Label /usr/lib/dovecot/dovecot-lda as lda_exec_t Label /usr/lib/dovecot/libdovecot.*\.so.* as lib_t Closes: #690225 All the labelling corrections fix bugs which lead to some important functionality of the respective program not working if selinux is installed enabled. No code/policy is changed, it is only about labelling the debian locations of files correctly. * Allow user roles access to mozilla_t classes shm and sem for sharing the sound device * Allow user roles access to mozilla_tmp_t Without this, a confined iceweasel won't be able to use sound properly, or it won't work at all, respectively. * Make postfix.pp not depend on unconfined.pp for strict configurations This fixes loading the postfix policy in strict configurations, which simply failed previously. * Allow lvm_t (systemd-cryptsetup) systemd_manage_passwd_run() access * Allow systemd_passwd_agent_t access to search selinuxfs and write to the console for getting a password for encrypted filesystems These fix booting with systemd and selinux enabled on dm-crypt root filesystems. * Allow watchdog_t to read syslog pid files for process watching Fixing one of the core functionalities of watchdog on selinux-enabled systems. Diffstat of the sources (patches applied) ignoring d/changelog and d/patches: policy/modules/apps/mozilla.fc |1 + policy/modules/apps/mozilla.if | 21 - policy/modules/kernel/corecommands.fc |2 ++ policy/modules/kernel/corenetwork.te.in |2 +- policy/modules/services/devicekit.fc|1 + policy/modules/services/dkim.fc |2 ++ policy/modules/services/dovecot.fc |2 +- policy/modules/services/hal.fc |1 - policy/modules/services/lda.fc |1 + policy/modules/services/postfix.fc |1 + policy/modules/services/postfix.if |4 +++- policy/modules/services/watchdog.te |4 policy/modules/system/iptables.fc |1 + policy/modules/system/libraries.fc |1 + policy/modules/system/logging.if| 18 ++ policy/modules/system/lvm.te|4 policy/modules/system/sysnetwork.te |1 + policy/modules/system/systemd.te|8 +++- 18 files changed, 57 insertions(+), 18 deletions(-) The debdiff is attached. unblock refpolicy/2:2.20110726-12 Thanks for your work + cheers, Mika refpolicy_2.20110726-11,12.debdiff Description: Binary data signature.asc Description: PGP signature
Bug#687848: Currently, only the symlink is removed
Hi, Am Tue, 4 Dec 2012 19:57:46 +0100 schrieb Ivo De Decker ivo.dedec...@ugent.be: On Wed, Sep 26, 2012 at 11:51:55PM +0200, Mika Pflüger wrote: Steps to reproduce: 1. Fresh wheezy install 2. apt-get install extlinux 3. extlinux-update extlinux-install first-hd (4. try reboot: doesn't boot; redo 1.-3. to get working setup again) 5. add unstable to sources.list and apt-get -t unstable install syslinux-themes-debian-wheezy or just download the most recent syslinux-themes-debian-wheezy_*.deb from an unstable mirror of your choice and dpkg -i it 6. extlinux-update 7. try reboot: doesn't boot. This problem can be reproduced easily with these steps. The problem should go away for fresh installs if syslinux-themes-debian-wheezy migrates to testing, but it will still be there for older installs. You are right, now it is not easily reproducible anymore - it probably is only a problem right now for old installs. And of course it will again be a problem if syslinux-themes-debian-wheezy has to be fixed for another problem (if ever). I don't know if my proposed patch is a very elegant solution (I actually suspect it's not), but I tested that it solves the problem. Removing the directories first isn't very elegant. The following patch shoud fix the problem by forcing cp to use the right path (adding the -T option): Yes, that is a much more elegant solution! Thanks a lot for finding the needed cp option I did not find! Cheers, Mika -- signature.asc Description: PGP signature
Bug#689952: More info
tags 689952 +moreinfo thanks Hi, could you post the output of # semodule -l and # check-selinux-installation ? This will hint at common problems and will show your installed selinux modules. Maybe we can spot the missing one. Cheers, Mika -- Own your own computer. Don't use Windows 7. http://windows7sins.org signature.asc Description: PGP signature
Bug#689264: unblock: refpolicy/2:2.20110726-11
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear Release Team, Please unblock package refpolicy version 2:2.20110726-11, changes since version -9 (which is in testing atm) are: * Fix #683756 (selinux in permissive mode breaks gdm and X) The problem arouse due to debian specific gdm3 locations. In version 2:2.20110726-10 a patch to fix this was introduced, but it was incomplete (fixed only some contexts, not all) and therefore in version -11 it was replaced by a correct patch, which is also already accepted upstream. The bug is only severity: normal in the BTS, but as installing and enabling selinux in permissive mode completely breaks the ability to log in via gdm I'd consider it important, at least. Regressions are very unlikely as this patch only touches file context definitions, no code. * Update the Vcs-* fields The Vcs-* fields in d/control were pointing to an old location, which doesn't work anymore. * Fix #686670 (Cannot load alsa.pp module) debian/patches/0048-Alsa-debian-locations.patch had been merged upstream but weren't dropped, leading to duplication and breaking the alsa module loading. Dropping the patch fixes this. * Drop debian/patches/0079-Allow-iptables_t-to-do-module_request.patch As in the previous fix, the code present in this one-line patch had already been introduced upstream. Dropping the patch removes duplicates and thereby avoids problems. * Fix watch file uversionmangle in debian/watch. Diffstat of the sources (patches applied) ignoring d/changelog: debian/control|4 ++-- debian/patches/series |3 +-- debian/watch |5 + policy/modules/admin/alsa.fc | 14 -- policy/modules/kernel/corecommands.fc |1 + policy/modules/services/xserver.fc| 20 +++- policy/modules/system/iptables.te |1 - 7 files changed, 20 insertions(+), 28 deletions(-) The debdiff is attached. unblock refpolicy/2.20110726-11 Thanks for your work + cheers, Mika diff -Nru refpolicy-2.20110726/debian/changelog refpolicy-2.20110726/debian/changelog --- refpolicy-2.20110726/debian/changelog 2012-06-30 11:42:53.0 +0200 +++ refpolicy-2.20110726/debian/changelog 2012-09-30 22:47:31.0 +0200 @@ -1,3 +1,30 @@ +refpolicy (2:2.20110726-11) unstable; urgency=low + + * Team upload + [ Mika Pflüger ] + * Drop incomplete patch adding debian specific gdm3 locations and +cherry-pick Laurent's complete patch from upstream instead. Slightly +edit the patch to work around an issue in file context ordering. + + -- Laurent Bigonville bi...@debian.org Sun, 30 Sep 2012 22:43:12 +0200 + +refpolicy (2:2.20110726-10) unstable; urgency=low + + * Team upload. + [ Mika Pflüger ] + * xserver.fc: Add debian specific /usr/sbin/gdm3 as a location for gdm3. +Closes: #683756 + * debian/control: Update Vcs-* fields. + + [ Laurent Bigonville ] + * d/p/0079-Allow-iptables_t-to-do-module_request.patch: Dropped, the code +present in this patch was already present later in the code. + * d/p/0048-Alsa-debian-locations.patch: Dropped, changes merged upstream, +and was breaking module loading due to duplicate paths (Closes: #686670) + * debian/watch: Fix watch file uversionmangle + + -- Laurent Bigonville bi...@debian.org Fri, 07 Sep 2012 17:51:13 +0200 + refpolicy (2:2.20110726-9) unstable; urgency=high * Enable UBAC as roles aren't useful. I recommend using only roles user_r @@ -10,8 +37,8 @@ * Change readahead policy to support memlockd. * Allow devicekit_power_t, devicekit_disk_t, kerneloops_t, and policykit_t to send dbus messages to users. - * Grant systemd utilities access to selinuxfs so they can correctly label directories -Closes: #678392 + * Grant systemd utilities access to selinuxfs so they can correctly label +directories. Closes: #678392 * Assigned type consolekit_var_run_t to /var/run/console(/.*)? because it's created and managed by consolekit nowadays. * Created tunable allow_ssh_connect_reserved_ports to allow ssh client to @@ -41,7 +68,7 @@ * Add tcsd.pp (for trousers) to the policy packages * Add nut.pp for the nut-server package to the policy packages * Load irqbalance.pp if irqbalance Debian package is installed, same for -kerneloops, tcsd.pp/trousers, nut.pp/nut-server, +kerneloops, tcsd.pp/trousers, nut.pp/nut-server, and smartmon.pp/smartmontools. * High urgency because the support for tcsd and nut really needs to be tested (and it's broken badly for those people) and portslave.pp is also diff -Nru refpolicy-2.20110726/debian/control refpolicy-2.20110726/debian/control --- refpolicy-2.20110726/debian/control 2012-06-11 14:32:03.0 +0200 +++ refpolicy-2.20110726/debian/control 2012-09-30 22:47:31.0 +0200 @@ -1,6 +1,6 @@ Source: refpolicy -VCS-Git:
Bug#687848: Currently, only the symlink is removed
reopen 687848
thanks
Hi,
Looking at the code and especially the rm -rf you are referring to, I
see that only the symlink is removed:
Layout before:
/boot/extlinux/themes/debian - debian-wheezy
/boot/extlinux/themes/debian-wheezy: the old theme
the extlinux configuration has the standard values, namely:
/etc/default/extlinux: EXTLINUX_THEME=debian.
So the rm -rf ${_EXTLINUX_DIRECTORY}/themes/${EXTLINUX_THEME}
deletes /boot/extlinux/themes/debian, which is only the symlink. Then
EXTLINUX_THEME_ORIG is populated and the subsequent cp -al (and
regeneration of the symlink) leads to this layout:
/boot/extlinux/themes/debian - debian-wheezy
/boot/extlinux/themes/debian-wheezy: the old theme
/boot/extlinux/themes/debian-wheezy/extlinux: the new theme.
Of course, only the old theme is found when booting, leading to no boot
at all.
Steps to reproduce:
1. Fresh wheezy install
2. apt-get install extlinux
3. extlinux-update extlinux-install first-hd
(4. try reboot: doesn't boot; redo 1.-3. to get working setup again)
5. add unstable to sources.list and apt-get -t unstable install
syslinux-themes-debian-wheezy or just download the most recent
syslinux-themes-debian-wheezy_*.deb from an unstable mirror of your
choice and dpkg -i it
6. extlinux-update
7. try reboot: doesn't boot.
Note this is completely standard behaviour for anyone actually
installing extlinux in a wheezy right now and following the
README.Debian, finding it doesn't work, switching back to grub, waiting
for the fixes in syslinux-themes-debian hitting testing or installing
it from unstable, and trying again.
I don't know if my proposed patch is a very elegant solution (I
actually suspect it's not), but I tested that it solves the problem.
Cheers,
Mika
--
Own your own computer. Don't use Windows 7. http://windows7sins.org
signature.asc
Description: PGP signature
Bug#687848: extlinux-update: fails to correctly update changed syslinux debian themes
Package: extlinux
Version: 2:4.05+dfsg-6
Severity: grave
Tags: patch
Justification: leaves system in unbootable state if updating in wheezy
Hi,
when preparing a patch for #681426 I noticed that after updating
the debian wheezy extlinux theme (by installing an updated version of
syslinux-themes-debian-wheezy) running extlinux-update does not
update the theme in /boot/extlinux/themes/debian-wheezy but instead
copies the new theme to /boot/extlinux/themes/debian-wheezy/extlinux .
Therefore, the old theme is then used.
This means that systems which had the broken theme (as described in
#681426) installed and upgrade to a newer theme and run extlinux-update
still won't boot.
The problem can be fixed by removing the old theme before copying
the new one:
diff -Nru syslinux-4.05+dfsg/debian/local/extlinux-update
syslinux-4.05+dfsg/debian/local/extlinux-update
--- syslinux-4.05+dfsg/debian/local/extlinux-update 2012-06-30
14:00:10.0 +0200
+++ syslinux-4.05+dfsg/debian/local/extlinux-update 2012-09-16
17:07:40.0 +0200
@@ -403,9 +403,11 @@
if [ -n ${EXTLINUX_THEME_ORIG} ]
then
+ rm -rf
${_EXTLINUX_DIRECTORY}/themes/${EXTLINUX_THEME_ORIG}
cp -aL
/usr/share/syslinux/themes/${EXTLINUX_THEME_ORIG}/extlinux
${_EXTLINUX_DIRECTORY}/themes/${EXTLINUX_THEME_ORIG}
ln -sf ${EXTLINUX_THEME_ORIG}
${_EXTLINUX_DIRECTORY}/themes/${EXTLINUX_THEME}
else
+ rm -rf ${_EXTLINUX_DIRECTORY}/themes/${EXTLINUX_THEME}
cp -aL
/usr/share/syslinux/themes/${EXTLINUX_THEME}/extlinux
${_EXTLINUX_DIRECTORY}/themes/${EXTLINUX_THEME}
fi
Cheers,
Mika
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681426: Uploaded to mentors
Hi, I uploaded a version of syslinux-debian-themes with the fix for this bug and the updated artwork for debian wheezy to mentors: http://mentors.debian.net/package/syslinux-themes-debian Cheers, Mika -- Own your own computer. Don't use Windows 7. http://windows7sins.org signature.asc Description: PGP signature
Bug#686298: RFS: obnam/1.1-1.1 [NMU] [RC]
Package: sponsorship-requests
Severity: important
Dear mentors,
I am looking for a sponsor for an NMU fxing an RC bug
in the package obnam. The RC bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680670
I reported myself is open and has a patch for two weeks now.
Although I tested the resulting package pretty
thoroughly (and obnam itself has a rather extensive test suite),
I would be glad if someone could review the patch. As this RC
bug fix naturally aims for wheezy, I changed only the absolute
minimum. Therefore, no new lintian tags are introduced, but also
no old ones are fixed.
As outlined in the bug report, users who added new encryption keys
to their backup repository need to re-add these keys in order for
them to be properly added. As this can't be automized (or at least
I can't figure out a save way to do it), I added a NEWS entry
including a proposal for a shell command to re-add all keys.
I hope the NEWS entry is comprehensible and properly worded.
* Package name: obnam
Version : 1.1-1.1
Maintainer : Lars Wirzenius l...@liw.fi
* URL : http://packages.debian.org/wheezy/obnam
Section : python
It builds those binary packages:
obnam - online and disk-based backup application
To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/obnam
Alternatively, one can download the package with dget using this command:
dget -x http://mentors.debian.net/debian/pool/main/o/obnam/obnam_1.1-1.1.dsc
Changes in this version:
obnam (1.1-1.1) unstable; urgency=low
* Non-maintainer upload for RC bug.
* obnamlib/plugins/encryption_plugin.py: Reencrypt symmetric key with
added GPG keys when using add-key command line option (Closes: #680670)
Also adds a NEWS entry for this.
-- Mika Pflüger deb...@mikapflueger.de Wed, 29 Aug 2012 22:11:16 +0200
The full debdiff is:
$ debdiff obnam_1.1-1.dsc obnam_1.1-1.1.dsc
only in patch2:
unchanged:
--- obnam-1.1.orig/debian/changelog
+++ obnam-1.1/debian/changelog
@@ -1,3 +1,12 @@
+obnam (1.1-1.1) unstable; urgency=low
+
+ * Non-maintainer upload for RC bug.
+ * obnamlib/plugins/encryption_plugin.py: Reencrypt symmetric key with
+added GPG keys when using add-key command line option (Closes: #680670)
+Also adds a NEWS entry for this.
+
+ -- Mika Pflüger deb...@mikapflueger.de Wed, 29 Aug 2012 22:11:16 +0200
+
obnam (1.1-1) unstable; urgency=low
* New upstream version.
only in patch2:
unchanged:
--- obnam-1.1.orig/debian/NEWS
+++ obnam-1.1/debian/NEWS
@@ -0,0 +1,19 @@
+obnam (1.1-1.1) unstable; urgency=low
+
+ This release fixes a bug in the behaviour of the add-key subcommand.
+ In previous versions, obnam add-key --keyid KEYID did not
+ reencrypt the internal symmetric key with the new key. Therefore,
+ backups could only be restored with the first key, not with any
+ keys added via obnam add-key.
+ This version fixes this, but all keys added with obnam add-key
+ have to be re-added in order to be able to restore from backup
+ using them.
+ To re-add all keys that were previously added to a given CLIENT,
+ use a shell loop like this:
+ $ for key in $(obnam list-keys|grep key|awk '{ print $2 }')
+ do obnam add-key --keyid=${key} CLIENT
+ done
+ It is always a good idea to afterwards test restoring from a machine
+ or user with access to the new keys only.
+
+ -- Mika Pflüger deb...@mikapflueger.de Wed, 29 Aug 2012 22:11:16 +0200
only in patch2:
unchanged:
--- obnam-1.1.orig/obnamlib/plugins/encryption_plugin.py
+++ obnam-1.1/obnamlib/plugins/encryption_plugin.py
@@ -145,6 +145,10 @@
encrypted = self.filter_write(encoded, repo, toplevel)
pathname = os.path.join(toplevel, 'userkeys')
self._overwrite_file(repo, pathname, encrypted)
+symmetric_key = self.get_symmetric_key(repo, toplevel)
+encrypted_symmetric_key = obnamlib.encrypt_with_keyring(symmetric_key,
keyring)
+pathname = os.path.join(toplevel, 'key')
+self._overwrite_file(repo, pathname, encrypted_symmetric_key)
def add_to_userkeys(self, repo, toplevel, public_key):
userkeys = self.read_keyring(repo, toplevel)
Cheers,
Mika Pflüger
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683756: [DSE-Dev] Bug#683756: selinux in permissive mode breaks gdm and X
Hi, Am Wed, 29 Aug 2012 14:23:29 +0200 schrieb Laurent Bigonville bi...@debian.org: Le Wed, 29 Aug 2012 16:45:02 +0530, piruthiviraj natarajan piruthivi...@gmail.com a écrit : You want us to change the type bin_t into what? I assumed that you want to relabel the type and I tried relabelling #chcon -t xdm_exec_t /usr/sbin/gdm3 but it didn't work. Still stuck with a black screen. I had to disable the selinux at boot to login to X. Now I am at #ls -Z /usr/sbin/gdm3 system_u:object_r:xdm_exec_t:s0 /usr/sbin/gdm3 That should fix the described issue if selinux is in permissive mode, not enforcing mode. We are still far to have GNOME working in enforcing mode. Yes, you found the culprit. Thanks a lot! I just couldn't imagine the label having any influence on the functionality in permissive mode. Well, I still don't really understand, but it works. (-: Cheers + thanks, Mika signature.asc Description: PGP signature
Bug#683756: I have this error, too
Hi, I have this problem, too. Also, I was able to reproduce it in a fresh install in a virtual machine: 1. Install debian wheezy with d-i current, select graphical desktop task. 2. Install selinux-basics 3. run selinux-activate 4. reboot 5. watch gdm3 break. If I then use service gdm3 stop to kill gdm3 and thereafter service gdm3 start, gdm goes into a restart-loop, spawning endless gdm3 instances (which after short while don't get VTs anymore...). As for debugging, I am a bit clueless how to proceed - I'm not even sure it is a bug in the policy. It could be that gdm3 is buggy somehow. Cheers, Mika -- Own your own computer. Don't use Windows 7. http://windows7sins.org signature.asc Description: PGP signature
Bug#683756: selinux in permissive mode breaks gdm and X
Hi, Am Tue, 28 Aug 2012 19:00:46 +0200 schrieb Laurent Bigonville bi...@debian.org: Could you please check if you have the selinux-policy-default package installed? yes, it is recommended by selinux-basics, thus I have it installed. Also, what is the semanage login -l command giving you? On my real machine running testing for years: $ LANG=C sudo semanage login -l Login Name SELinux User MLS/MCS Range __default__unconfined_u s0-s0:c0.c1023 root unconfined_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023 On my freshly installed virtual machine: $ LANG=C sudo semanage login -l Login Name SELinux User MLS/MCS Range __default__unconfined_u SystemLow-SystemHigh root unconfined_u SystemLow-SystemHigh system_u system_u SystemLow-SystemHigh Cheers, Mika -- Own your own computer. Don't use Windows 7. http://windows7sins.org signature.asc Description: PGP signature
Bug#680670: patch
Hei, I wrote a small patch adding this to write_keyring, which is as unobtrusive as possible. I tested this and it works as I expect it, but I'm still unsure if I get the obnam encryption scheme completely right. I am not quite sure how to write a test case for this one, though - client-keys only ever lists one key (maybe this is a bug, too?). Maybe an even better black box test would be to encrypt with one key, add another key via add-key and then try to restore with the new one. However, I didn't have the time to figure out how to use a second GNUPGHOME during a test. Hopefully I find the time during this week. I don't have an idea how to implement a one-time reencryption of the symmetric key for people who update. So maybe a NEWS entry has to suffice? Terveiset, Mika -- Own your own computer. Don't use Windows 7. http://windows7sins.org === modified file 'obnamlib/plugins/encryption_plugin.py' --- obnamlib/plugins/encryption_plugin.py 2012-06-17 15:17:44 + +++ obnamlib/plugins/encryption_plugin.py 2012-07-16 22:16:55 + @@ -145,6 +145,10 @@ encrypted = self.filter_write(encoded, repo, toplevel) pathname = os.path.join(toplevel, 'userkeys') self._overwrite_file(repo, pathname, encrypted) +symmetric_key = self.get_symmetric_key(repo, toplevel) +encrypted_symmetric_key = obnamlib.encrypt_with_keyring(symmetric_key, keyring) +pathname = os.path.join(toplevel, 'key') +self._overwrite_file(repo, pathname, encrypted_symmetric_key) def add_to_userkeys(self, repo, toplevel, public_key): userkeys = self.read_keyring(repo, toplevel) signature.asc Description: PGP signature
Bug#680670: severity of 680670 is grave
severity 680670 grave thanks Justification: May cause unexpected unability to restore from backups leading to data loss signature.asc Description: PGP signature
Bug#680670: obnam: add_key doesn't encrypt symmetric key with new key
Package: obnam
Version: 1.1-1
Severity: normal
Hei,
in encryption_plugin.py:
add_key calls add_to_userkeys for the shared toplevel and all
listed clients, but add_to_userkeys only calls write_keyring
whicht in turn only calls filter_write (which encrypts symmetrically)
and then writes the new 'userkeys'. The symmetric key used to
encrypt userkeys ('key') is never written, and indeed it remains
encrypted only with the old key. Therefore, add-key effectively
doesn't add a new key. For that, it had to somehow call
obnamlib.encryption.encrypt_with_keyring, which it never does.
It could of course also be possible, that I completely misunderstood
the operation of add-key. Comparing to liw.fi/obnam/encryption, I think
that I got it right in principle - 'key' should be encrypted with all
keys in 'userkeys'. But obnam --keyid=NEWKEY add-key [client …] only
updates the 'userkeys' without reencrypting 'key'. Maybe we need a new
function in encryption_plugin.py as class function of EncryptionPlugin:
def rewrite_symmetric_key(self, repo, toplevel):
pubkeys = self.read_keyring(repo, toplevel)
symmetric_key = self.get_symmetric_key(self, repo, toplevel)
encrypted_symmetric_key = obnamlib.encrypt_with_keyring(symmetric_key,
pubkeys)
pathname = os.path.join(toplevel, 'key')
self._overwrite_file(repo, pathname, encrypted_symmetric_key)
which then needs to be called from add_key after self.add_to_userkeys.
Another approach would be adding that work directly to write_keyring,
as it is not really useful to add/remove a key from 'userkeys' without
reencrypting the symmetric key.
If you agree with my analysis, I could write a patch implementing
either method (and maybe I can cook up a test, too).
When this gets fixed existing repos should get their 'key' reencrypted, too,
I guess.
Terveiset,
Mika
-- System Information:
Debian Release: wheezy/sid
APT prefers testing-proposed-updates
APT policy: (650, 'testing-proposed-updates'), (650, 'testing'), (450,
'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages obnam depends on:
ii libc6 2.13-33
ii python2.7.3~rc2-1
ii python-cliapp 1.20120630-1
ii python-larch 1.20120527-1
ii python-paramiko 1.7.7.1-2
ii python-tracing0.6-2
ii python-ttystatus 0.19-1
ii python2.6 2.6.8-0.2
ii python2.7 2.7.3~rc2-2.1
obnam recommends no packages.
obnam suggests no packages.
-- 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#676852: selinux-policy-src: Ships byte-compiled python file pyplate.pyc in tarball
Package: selinux-policy-src Version: 2:2.20110726-3 Severity: minor Hi, in the tarball /usr/src/selinux-policy-src.tar which is shipped by this package there is a file selinux-policy-src/support/pyplate.pyc which is a byte-compiled python file. byte-compiled python files should not be shipped by packages in debian. Instead, usually they should use some helper to byte-compile at install time or they shouldn't ship byte-compiled files at all. I think, for this package, which mainly is for reference, it would be correct to not ship the byte-compiled file. Cheers, Mika -- System Information: Debian Release: wheezy/sid APT prefers testing-proposed-updates APT policy: (650, 'testing-proposed-updates'), (650, 'testing'), (450, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages selinux-policy-src depends on: ii checkpolicy 2.1.8-2 ii gawk 1:4.0.1+dfsg-2 ii policycoreutils 2.1.10-1 ii python 2.7.2-10 Versions of packages selinux-policy-src recommends: ii setools 3.3.7-2 Versions of packages selinux-policy-src suggests: pn logchecknone pn syslog-summary 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#660293: [thinkfan] Please package new upstream-version 0.8~alpha2
Package: thinkfan Version: 0.7.3-1 Severity: wishlist Tags: patch --- Please enter the report below this line. --- Hi Evgeni, a new upstream version 0.8~alpha2 is out and brings interesting new features (namely per-sensor temperature limit and level strings like level auto). The author says he named it alpha because he wants some more testing because of the new features. I packaged the new version based on your git packaging, there were only minimal changes necessary. Note however I imported the new upstream tarball instead of trying to get it from the new upstream git. It would be cool if you could look if the new version can go into debian (maybe only experimental as it is so alpha). I tested it with both an old-style config file as well as a new complex config file for several days and it all seams to work, although it is rather hard to debug a new-style config file (I messed up one limit where the UPPER limit was lower than the LOWER limit and didn't notice - cost me some hours). My preliminary packaging of the new version can be found in the master, pristine-tar and upstream branches of http://git.hemio.de/git/thinkfan (gitweb at http://git.hemio.de/gitweb/?p=thinkfan;a=summary). Note that it doesn't build out of the box because there is no real trailer line in debian/changelog; you need to add one in order to build it. Cheers, Mika --- System information. --- Architecture: amd64 Kernel: Linux 3.2.0-1-amd64 Debian Release: wheezy/sid 650 testing-proposed-updates ftp.de.debian.org 650 testing security.debian.org 650 testing ftp.de.debian.org 450 unstableftp.de.debian.org --- Package information. --- Depends (Version) | Installed ==-+-=== libc6 (= 2.2.5) | 2.13-26 Package's Recommends field is empty. Package's Suggests field is empty. -- Own your own computer. Don't use Windows 7. http://windows7sins.org signature.asc Description: PGP signature
Bug#635550: pmw: piuparts: fails to install (update-gsfontmap again)
Package: pmw Version: 4.22-3 Severity: serious Tags: patch Justification: Policy 6.1 User: debian...@lists.debian.org Usertags: piuparts piuparts.d.o Hi, during piuparts tests your package failed to install. Your patch to test for update-gsfontmap in 4.22-3 is not enough, as false true evaluates to false, so that [ -x /usr/sbin/update-gsfontmap ] /usr/sbin/update-gsfontmap fails if update-gsfontmap is not available and executable, so that the postinst will still exit with nonzero exit status. A possible way to solve the problem would be to expand the if: if [ -x /usr/sbin/update-gsfontmap ]; then /usr/sbin/update-gsfontmap fi which (I suppose) does what you want, that is, runs update-gsfontmap if it exists and exits 0 otherwise. The relevant lines from the piuparts logs: dpkg: error processing pmw (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: pmw E: Sub-process /usr/bin/dpkg returned an error code (1) The whole log can be found at http://piuparts.debian.org/sid/bugged/pmw_4.22-3.log Cheers, Mika -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620842: description: the imapsync package doesn't exist anymore
Package: imapcopy Version: 1.04-1 Severity: minor Hi, the imapcopy description says The package imapsync serves a similar purpose., but the imapsync package doesn't exist in any of the relases (squeeze, testing, sid) in which imapcopy is found. So I think the description should be altered, either just don't mention imapsync anymore, mention offlineimap instead or say something like It can be used instead of the old imapsync package. if you wish that users can find imapcopy when seraching for imapsync. Cheers, Mika -- System Information: Debian Release: wheezy/sid APT prefers testing-proposed-updates APT policy: (650, 'testing-proposed-updates'), (650, 'testing'), (450, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-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/bash Versions of packages imapcopy depends on: ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib imapcopy recommends no packages. imapcopy suggests no packages. -- 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#612042: /etc/quassel might be more appropriate for config
Hi Tony, Am Thu, 24 Mar 2011 16:35:35 -0500 schrieb Tony Gies tony.g...@gmail.com: 1. quasselcore.conf is not a user-editable configuration file and arguably isn't a configuration file at all. It stores basically some serialized objects representing the state of the core and changes frequently at runtime. Yes, you're right, I don't think quasselcore.conf is a configuration file. We both agree that /var/cache is wrong, though. Additionally I was thinking about quasselCert.pem, which definitively is a configuration file and should be in /etc, at least I would expect it in /etc. 2. The data directory is a build option and the database along with quasselcore.conf is stored in that directory. To change this behavior you would have to actually patch quasselcore. This is not, of course, a definitive reason not to do it, but does complicate matters. I see how this complicates matters, but I think in order to actually be able to claim support for encryption, we must support easily changing the certificate for a proper one and as this is a local configuration option it should reside in /etc. Maybe a symlink in the quasselcore data directory pointing to the actual /etc/quasselcore/quasselCert.pem might solve the problem without patching. If we agree on quasselCert.pem being a configuration file and the others being Variable state information and thus belonging into /var/lib I could try to prepare patches to the packaging to change the locations. We would have to think about a means of converting old installations of quasselcore, I don't know how tricky this is, I guess we can write appropriate postinstall et al scripts. Cheers, Mika -- Own your own computer. Don't use Windows 7. http://windows7sins.org signature.asc Description: PGP signature
Bug#619393: ITP: paw -- Physics Analysis Workstation
Hi, Am Wed, 23 Mar 2011 22:42:44 +0800 schrieb Lifeng Sun lifong...@gmail.com: Package: wnpp Severity: wishlist Owner: Lifeng Sun lifong...@gmail.com * Package name: paw Version : 2.14.04 Upstream Author : CERN - European Laboratory for Particle Physics * URL : http://paw.web.cern.ch/paw/ * License : GPL-2+ Programming Lang: Fortran, C Description : Physics Analysis Workstation PAW is an interactive program providing interactive graphical presentation and statistical and mathematical analysis tools. It is designed to work on objects familiar to physicists such as histograms, event files (Ntuples), vectors, etc. It seems that PAW is upstream dead (last activity on the website was in 2006, the last release of PAW was in 2002, the cernlib site states in red: 'The development and support for CERNLIB has been discontinued. Libraries will be continued to be provided as is'), additionally I don't see it being GPL-2+ licensed, at least I couldn't find any file stating this (I searched in the 2006 tarball obtained from http://cernlib.web.cern.ch/cernlib/version.html, maybe there is another version?). Additionally, in the tarball are quite a lot of files that are definitively not GPL-2+, although they arguably don't belong to PAW. An example would be the file 2006/src/packlib/fatmen/scripts/unix/ctab_root.dat which contains: # (C) COPYRIGHT International Business Machines Corp. 1989,1991 # All Rights Reserved # Licensed Materials - Property of IBM # # US Government Users Restricted Rights - Use, duplication or # disclosure restricted by GSA ADP Schedule Contract with IBM Corp. with no further licenses. This doesn't sound like GPL-2+ Additionally, it seems to be utterly undocumented - I wanted to test if PAWs is useful at all nowadays but couldn't figure out how to build it. Maybe I missed the right tarball or am just to thick, but to me it looks rather unclear if this software is worth the hassle. Cheers, Mika -- Own your own computer. Don't use Windows 7. http://windows7sins.org signature.asc Description: PGP signature
Bug#619396: ITP: geant321 -- Particle detector description and simulation tool
Hi, Am Wed, 23 Mar 2011 23:01:28 +0800 schrieb Lifeng Sun lifong...@gmail.com: Package: wnpp Severity: wishlist Owner: Lifeng Sun lifong...@gmail.com * Package name: geant321 Version : 3.21.14 Upstream Author : CERN - European Laboratory for Particle Physics * URL : http://wwwasd.web.cern.ch/wwwasd/geant/index.html * License : GPL-2+ Programming Lang: Fortran, C Description : Particle detector description and simulation tool GEANT is a framework for simulating the passage of subatomic particles through matter, for instance, particle detectors. For maximum flexibility, GEANT simulations are performed by linking FORTRAN code supplied by the user with the GEANT library, then running the resulting executable. Additionally to my concerns towards cernlib in general (see answer to #619393), I think that GEANT is not free software. At http://cernlib.web.cern.ch/cernlib/conditions.html it says: (C) Copyright CERN except where explicitly stated otherwise. Permission to use and/or redistribute this work is granted under the terms of the GNU General Public License. FLUKA routines included in GEANT3 are joint copyright of INFN and CERN and are not licensed under the GPL: permission to use and/or redistribute outside GEANT3 should be negotiated. The software and documentation made available under the terms of this license are provided with no warranty. If necessary libraries for the use of GEANT are not licensed under the GPL and are explicitly forbidden to redistribute and use outside of GEANT (should be negotiated sounds like is not allowed in my ears) this can only maybe pass into non-free, but I am not even sure redistribution is allowed, the only license-related thing I could find about fluka is in 2005/src/geant321/examples/gexam4/guphad.F: (C) Copyright of the authors [...] * - All the rights concerning FLUKA or parts of it are only of the * * authors and are independent from those of the GEANT code * with no further permissions. Seems as if this is not redistributable. Cheers, Mika -- Own your own computer. Don't use Windows 7. http://windows7sins.org signature.asc Description: PGP signature
Bug#612042: /etc/quassel might be more appropriate for config
Hi, I guess /var/lib/quassel is appropriate for the data, maybe even /srv/quassel, but the configuration should definitely be in /etc/quassel or /etc/quasselcore. According to the FSH (see hier(7)), /etc contains Contains configuration files which are local to the machine., I was actually rather confused not to find(8) any configuration for quassel besides /etc/default/quasselcore in etc. Thanks, Mika -- Own your own computer. Don't use Windows 7. http://windows7sins.org signature.asc Description: PGP signature
Bug#606872: castle-combat: Should insert private module path at beginning of sys.path, not at the end
Package: castle-combat
Version: 0.8.1.dfsg.1-3
Severity: important
Tags: patch
Hi,
In /usr/games/castle-combat it says:
import sys
sys.path.append('/usr/share/games/castle-combat/scripts')
Unfortunately, other packages or the system administrator or even the user might
have added other directories to the path before, in my case this was done by the
python-openturns package. Then, the 'import main' (or another import, in my case
the 'import common' in /usr/share/games/castle-combat/scripts/main.py) will not
import castle-combat's 'common.py', but some other. A bullet-proof way to add
private modules is to use
sys.path.insert(0, '/usr/share/games/castle-combat/scripts')
instead of
sys.path.append('/usr/share/games/castle-combat/scripts')
Like this, the castle-combat private module directory will always be searched
first and there is no problem anymore.
At the moment the bug triggers if python-openturns is installed on the same
system as castle-combat. In this case, castle-combat will not start up:
$ castle-combat
Castle-Combat requires pygame and twisted. If the game doesn't start up
correctly, please verify that these are installed.
Traceback (most recent call last):
File /usr/games/castle-combat, line 8, in module
main.main()
File /usr/share/games/castle-combat/scripts/main.py, line 33, in main
init()
File /usr/share/games/castle-combat/scripts/main.py, line 7, in init
common.init()
AttributeError: 'module' object has no attribute 'init'
Changing the sys.path line like suggested above fixes the bug.
Cheers,
Mika
-- System Information:
Debian Release: squeeze/sid
APT prefers testing-proposed-updates
APT policy: (650, 'testing-proposed-updates'), (650, 'testing'), (450,
'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-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/bash
Versions of packages castle-combat depends on:
ii python 2.6.6-3+squeeze2 interactive high-level object-orie
ii python-central 0.6.16+nmu1 register and build utility for Pyt
ii python-numpy 1:1.4.1-5 Numerical Python adds a fast array
ii python-pygame 1.8.1release-2+b1 SDL bindings for games development
ii python-twisted 10.1.0-3 Event-based framework for internet
ii ttf-dejavu-core2.31-1Vera font family derivate with add
castle-combat recommends no packages.
castle-combat suggests no packages.
-- 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#570685: New python-protobuf in testing works, versioned dependency?
retitle 570685 Versioned dependency for protobuf needed? severity 570685 minor thanks Hi, With the version 2.3.0-3 of (python-)protobuf now in testing, I can't reproduce the bug anymore. Maybe everybody who has experienced the issue in the past could try to reproduce it? So at the moment the bug doesn't affect the usability at all, especially the squeeze release is not affected. However it might be nice to have a versioned dependency, so that this bug doesn't strike again later. Cheers, Mika -- Own your own computer. Don't use Windows 7. http://windows7sins.org signature.asc Description: PGP signature
Bug#587115: packaged new version
tags 587115 + patch block 587115 by 587227 thanks I packaged the new version, maybe somebody could check if I got it all right. I was advised to wait for #587227 to be solved, but I will not be able to follow #587227 for at least one week and in order to avoid duplication of work I uploaded the source to mentors.debian.net [1]. So, when #587227 is done, it would be nice if somebody could review the package and upload it if appropriate. If I messed something up, I would be glad if you'd tell me what so I can correct it. Cheers, Mika [1] dget http://mentors.debian.net/debian/pool/main/p/pythonmagick/pythonmagick_0.9.2-1.dsc -- Own your own computer. Don't use Windows 7. http://windows7sins.org signature.asc Description: PGP signature
Bug#589997: selinux-policy-default: /dev/vd* (virtio disks) labelled incorrectly
Package: selinux-policy-default Version: 2:0.0.20080702-6 Severity: important Tags: patch Hi, If you use for example kvm to virtualize a lenny guest, you are encouraged to use virtio-disks for improved performance. But if you do so, installing selinux (and enabling it via selinux-activate and selinux-config-enforcing) renders the system unbootable, as early on in the boot process selinux denys mounting the root fs r/w. This is because /dev/vd-devices are not properly labelled, that is, they are not labelled like /dev/[hsmx]d-devices. I think this is a bug in refpolicy and will try to submit it upstream as well. I could fix the problem by applying this patch, rebuilding and installing the new version (afterwards, the system boots and /dev/vd-devices are labelled correctly): --- a/policy/modules/kernel/storage.fc +++ b/policy/modules/kernel/storage.fc @@ -5,7 +5,7 @@ /dev/n?osst[0-3].* -c gen_context(system_u:object_r:tape_device_t,s0) /dev/n?pt[0-9]+-c gen_context(system_u:object_r:tape_device_t,s0) /dev/n?tpqic[12].* -c gen_context(system_u:object_r:tape_device_t,s0) -/dev/[shmx]d[^/]* -b gen_context(system_u:object_r:fixed_disk_device_t,mls_systemhigh) +/dev/[shmxv]d[^/]* -b gen_context(system_u:object_r:fixed_disk_device_t,mls_systemhigh) /dev/aztcd -b gen_context(system_u:object_r:removable_device_t,s0) /dev/bpcd -b gen_context(system_u:object_r:removable_device_t,s0) /dev/bsg/.+-c gen_context(system_u:object_r:scsi_generic_device_t,s0) It would be nice, if this could be included in a stable update, as it happens to everybody who wants to deploy kvm-virtualized lenny-guests using the default options virt-manager and the like offer. Cheers, Mika Pflüger -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages selinux-policy-default depends on: ii libpam-modules1.0.1-5+lenny1 Pluggable Authentication Modules f ii libselinux1 2.0.65-5 SELinux shared libraries ii libsepol1 2.0.30-2 Security Enhanced Linux policy lib ii policycoreutils 2.0.49-8 SELinux core policy utilities ii python2.5.2-3An interactive high-level object-o Versions of packages selinux-policy-default recommends: ii checkpolicy 2.0.16-1 SELinux policy compiler pn setools none (no description available) Versions of packages selinux-policy-default suggests: pn logcheck none (no description available) pn syslog-summarynone (no description available) -- 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#565211: [claws-mail-python-plugin] Crashes claws-mail if python2.5-dev is not installed
Hi Ricardo,
Am Thu, 14 Jan 2010 09:47:50 +0100
schrieb Ricardo Mones mo...@debian.org:
Packages lacked ${misc:Depends}, which has been solved in 3.7.4 and
may be fixing this problem. Unfortunately for this case, 3.7.4
version also includes a new plugin so, it's still waiting on NEW
queue [0] to be processed manually. Once it gets accepted, please
upgrade and check if this gets fixed by 3.7.4, otherwise we'll look
further to solve it by other means.
I upgraded the package claws-mail-extra-plugins to 4.7.4 from
unstable/sid (I did not upgrade any other package from unstable, only
claws-mail-extra-plugins and its Dependencies).
The error produced when loading the package is still the same:
pluginwindow.c:298:Creating plugins window...
pluginwindow.c:427:called inc_lock (lock count 1)
procmime.c:1029:got type application/x-sharedlib for so
procmime.c:1029:got type application/x-sharedlib for so
plugin.c:339:trying to load
`/usr/lib/claws-mail/plugins/python_plugin.so' hooks.c:70:registed new
hook for 'compose_created' as id 1
** ERROR **: libpython2.5.so: Kann die Shared-Object-Datei nicht
öffnen: Datei oder Verzeichnis nicht gefunden
aborting...
Abgebrochen
Thank you,
Mika Pflüger
--
Own your own computer. Don't use Windows 7. http://windows7sins.org
signature.asc
Description: PGP signature
Bug#565211: [claws-mail-python-plugin] Crashes claws-mail if python2.5-dev is not installed
Package: claws-mail-python-plugin Version: 3.7.3-1 Severity: important --- Please enter the report below this line. --- Hi, if you try to load the claws-mail-python-plugin in claws-mail without python2.5-dev installed claws-mail terminates without further notice. You can solve the problem by symlinking /usr/lib/libpython2.5.so.1.0 to /usr/lib/libpython2.5.so (which, I guess, python2.5-dev does - I haven't installed python2.5-dev to test it, but apt-file says python2.5-dev contains /usr/lib/libpython2.5.so). This renders the package unusable by anybody without the python2.5-dev package installed. The last words of claws-mail before terminating with exit status 134: pluginwindow.c:298:Creating plugins window... pluginwindow.c:427:called inc_lock (lock count 1) procmime.c:1029:got type application/x-sharedlib for so procmime.c:1029:got type application/x-sharedlib for so plugin.c:339:trying to load `/usr/lib/claws-mail/plugins/python_plugin.so' ** ERROR **: libpython2.5.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden aborting... Abgebrochen Translation of the German parts: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden Couldn't open shared-object file: file or directory not found. Investigation of the issue shows: $ locate libpython2.5.so /usr/lib/libpython2.5.so.1 /usr/lib/libpython2.5.so.1.0 After creating the symlink it works flawlessly: $ ln -s /usr/lib/libpython2.5.so.1.0 /usr/lib/libpython2.5.so The missing file is in python2.5-dev: $ apt-file search libpython2.5.so python2.5: /usr/lib/libpython2.5.so.1 python2.5: /usr/lib/libpython2.5.so.1.0 python2.5-dbg: /usr/lib/debug/usr/lib/libpython2.5.so.1.0 python2.5-dev: /usr/lib/libpython2.5.so python2.5-dev: /usr/lib/python2.5/config/libpython2.5.so Thank you, Mika Pflüger --- System information. --- Architecture: amd64 Kernel: Linux 2.6.30-2-amd64 Debian Release: squeeze/sid 500 testing security.debian.org 500 testing ftp.de.debian.org --- Package information. --- Depends (Version) | Installed ==-+- libatk1.0-0(= 1.20.0) | 1.28.0-1 libc6 (= 2.2.5) | 2.10.2-2 libcairo2 (= 1.2.4) | 1.8.8-2 libfontconfig1 (= 2.4.0) | 2.8.0-2 libfreetype6(= 2.2.1) | 2.3.11-1 libglib2.0-0 (= 2.16.0) | 2.22.3-1 libgtk2.0-0 (= 2.8.0) | 2.18.3-1 libpango1.0-0 (= 1.14.0) | 1.26.2-1 python2.5 (= 2.5) | 2.5.4-3 python | 2.5.4-5 Package's Recommends field is empty. Package's Suggests field is empty. -- Own your own computer. Don't use Windows 7. http://windows7sins.org signature.asc Description: PGP signature
Bug#532912: system-config-lvm: Typo in error: mod_e_probe
Package: system-config-lvm Version: 1.1.4-2 Severity: minor Hi, If you try to make a snapshot of a logical valume and it throws an error, the error text reads: [...]try modeprobe dm-snapshot[...] But it should read: [...]try modprobe dm-snapshot[...] This might be an issue in the german translation, I am using the german translation. Greets, Mika Pfluger -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.29-2-686 (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 system-config-lvm depends on: ii gettext 0.17-4 GNU Internationalization utilities ii gsfonts 1:8.11+urwcyr1.0.7~pre44-3 Fonts for the Ghostscript interpre ii lvm2 2.02.39-7 The Linux Logical Volume Manager ii menu 2.1.41 generates programs menu for all me ii python2.5.2-3An interactive high-level object-o ii python-glade2 2.12.1-6 GTK+ bindings: Glade support ii python-gnome2 2.22.0-1 Python bindings for the GNOME desk ii python-gtk2 2.12.1-6 Python bindings for the GTK+ widge ii python-suppor 1.0.3 automated rebuilding support for P system-config-lvm recommends no packages. system-config-lvm suggests no packages. -- 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#526522: ldaptor-utils: ldaptor-ldap2passwd --help throws exception
Package: ldaptor-utils Version: 0.0.43-3 Severity: normal ldaptor-ldap2passwd throws an exception if you use it with the --help switch. $ ldaptor-ldap2passwd --help Usage: ldaptor-ldap2passwd [options] Options: --base= LDAP base dn --service-location= Service location, in the form BASEDN:HOST[:PORT] --version --help Display this help and exit. Traceback (most recent call last): File /usr/bin/ldaptor-ldap2passwd, line 80, in module except usage.UsageError, ue: AttributeError: 'module' object has no attribute 'UsageError' $ Thanks, Mika Pflüger -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.29-1-686 (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/bash Versions of packages ldaptor-utils depends on: ii python2.5.2-3An interactive high-level object-o ii python-ldaptor0.0.43-2 Pure-Python library for LDAP ldaptor-utils recommends no packages. ldaptor-utils suggests no packages. -- 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#526522: Just checked the problem with python-ldaptor from unstable
I just noticed that I had installed the stable version of python-ldaptor and installed 0.0.43-3 from unstable. The problem did not change. signature.asc Description: PGP signature
Bug#525732: apmd: package descripton wrong
Package: apmd Version: 3.2.2-12 Severity: minor From http://packages.debian.org/en/lenny/apmd: Debian kernels are built with APM support but it is disabled by default. You need to boot the kernel with the apm=on option if you want to enable the driver. (You may need to add this option to your lilo command line.) So the package description states that debian kernels are built with APM support, and you only have to give apm=on at boot to enable the APM subsystem. But at recent debian kernels (tested it now on 2.6.29-1-686, but as far as I can remember it was the same with 2.6.28 and 2.6.26) APM support is /not/ compiled in: $ cat /proc/cmdline root=/dev/mapper/lvm-root ro pci=irqmask=0x0e98 apm=on vga=0x318 splash quiet $ sudo apm -v No APM support in kernel I guess there are good reasons not to ship kernels with apm support, given that apm is a technology from the 90s, but the package description of apmd should give hints how to get apm support enabled anyway (I guess you have to compile your own kernel, do you?). So maybe the paragraph should be: Since lenny Debian kernels are not built with APM support anymore. You need to compile a kernel with apm support enabled to use this package. Or something similar. If there is any official Debian-HowTo for compiling an own kernel, maybe give the link or package name. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.29-1-686 (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/bash Versions of packages apmd depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii libapm1 3.2.2-12 Library for interacting with APM d ii libc6 2.9-4 GNU C Library: Shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii powermgmt-base1.30+nmu1 Common utils and configs for power apmd recommends no packages. Versions of packages apmd suggests: pn xapm none (no description available) -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515759: bugs.debian.org: Mail adresses starting with mail@ silently dropped
Package: bugs.debian.org Severity: normal *** Please type your report below this line *** My main Email address starts with mail@ and so I tried to report bugs to the bts with this address in From: . I never got my bugreports into the bts and I really tried to figure out, why. Reading all the stuff at http://www.debian.org/Bugs/Reporting however did not point me to the issue. Only recently I discovered, that apparently debian's mailing list system rejects applications from addresses starting with mail@ - actually, it complains back and states, it wouldn't accept such addresses. So I wondered, if this is the reason, why my mails to the bts did not make it through - and submitted this bug with another From: header. I understand the reasoning behind the measure of filtering addresses mail@ out, but it would be nice, if the bts would sent out a bounce like the mailing list system - or if the mails sent out by daemons are just too much to bounce them all, state this filtering practice at http://www.debian.org/Bugs/Reporting. Cheers, Mika -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
