Bug#1066821: apr-util: FTBFS on arm{el,hf}: /bin/bash: line 3: 3132384 Segmentation fault LD_LIBRARY_PATH="`echo "../crypto/.libs:../dbm/.libs:../dbd/.libs:../ldap/.libs:$LD_LIBRARY_PATH" | sed -e 's/
Am 18.03.24 um 19:30 schrieb Stefan Fritsch: Am 13.03.24 um 22:32 schrieb Sebastian Ramacher: Source: apr-util Version: 1.6.3-1.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/fetch.php?pkg=apr-util=armhf=1.6.3-1.1=1709086833=0 It looks to me like it tried to use a non 64bit time_t libapr1 during build, which does not work because libapr1 changes abi with the time_t transition. Adding a versioned build-depends should help. I will check later. Unfortunately, apr-util build-deps are uninstallable on armhf/armel right now due to postgres not being built for 64bit time_t. So, there is no easy way to test this. I will upload anyway.
Bug#1066821: apr-util: FTBFS on arm{el,hf}: /bin/bash: line 3: 3132384 Segmentation fault LD_LIBRARY_PATH="`echo "../crypto/.libs:../dbm/.libs:../dbd/.libs:../ldap/.libs:$LD_LIBRARY_PATH" | sed -e 's/
Am 13.03.24 um 22:32 schrieb Sebastian Ramacher: Source: apr-util Version: 1.6.3-1.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/fetch.php?pkg=apr-util=armhf=1.6.3-1.1=1709086833=0 It looks to me like it tried to use a non 64bit time_t libapr1 during build, which does not work because libapr1 changes abi with the time_t transition. Adding a versioned build-depends should help. I will check later. testldap: SUCCESS testdbd : SUCCESS testdate: SUCCESS testmemcache: Error 111 occurred attempting to reach memcached on localhost:11211. Skipping apr_memcache tests... SUCCESS testredis : Error 111 occurred attempting to reach Redis on localhost:6379. Skipping apr_redis tests... SUCCESS testxml : SUCCESS testxlate : SUCCESS testrmm : SUCCESS testdbm : BDB1565 DB->put: method not permitted before handle's open method /bin/bash: line 3: 3132384 Segmentation fault LD_LIBRARY_PATH="`echo "../crypto/.libs:../dbm/.libs:../dbd/.libs:../ldap/.libs:$LD_LIBRARY_PATH" | sed -e 's/::*$//'`" ./$prog -v Programs failed: testall make[2]: *** [Makefile:60: check] Error 139 Cheers
Bug#988310: ssl-cert: make-ssl-cert uses same filename for template and output
I won't be able to deal with this for at least 1-2 weeks. It would be nice if someone could look at it and downgrade or NMU+unblock. Am 06.06.21 um 13:14 schrieb Stefan Bühler: Hi, On Mon, 10 May 2021 11:09:58 +0200 Parodper wrote: Package: ssl-cert Version: 1.1.0 Severity: grave Tags: patch Justification: renders package unusable Given ssl-cert is installed on many systems probably just for the snakeoil self-signed certificate I think the severity isn't justified, or at least the Justification is wrong. "Only" creating other certificates seems to be impacted by this. Is there any data which packages are affected by this issue? I don't know for sure, but I expect that this mode is only used manually, not by any postinst script. The suggested patch shifts the arguments, like it is done on other parts of the script. The patch is not in "unified diff" format, which makes it hard to read / apply in a safe way. Apart from that it looks like a simple change though. cheers, Stefan
Bug#954311: libgl1-mesa-dri: Makes KDE konsole unusable
Hi Timo, Am 20.03.20 um 09:55 schrieb Timo Aaltonen: > Please file it upstream, this is caused by the new 'iris' driver. In the > meantime, you can force the previous driver with this in a ~/.drirc: > > > > > > > > > Or run the app with the driver to verify it actually helps: > > dri_driver=i965 ./app That did not help. It seems Xorg itself also loads the iris driver and that causes the drawing errors. But putting the config into /etc/drirc did help. Cheers, Stefan
Bug#947729: radicale: broken after upgrade from stretch
Package: radicale Version: 2.1.11-6 Severity: grave Justification: renders package unusable Hi, I have upgraded my system from stretch. After some head scratching due to the new disk format, I have installed the package listen in NEWS.debian, did radicale --export-storage /var/tmp/radicale Then moved /var/tmp/radicale/collection-root to /var/lib/radicale/collections and did a chown. Is this the correct path? This should be described much more verbosely in NEWS.Debian, for example including the exact commands and directory names. After that and re-installing radicale 2.1.11-6, radicale --verify-storage did run without error. But now, all requests to radicale return a 500 internal server error. radicale does not log any information despite log level debug: # journalctl -u radicale Dec 29 16:04:01 manul systemd[1]: Starting LSB: Radicale CalDAV and CardDAV server... Dec 29 16:04:01 manul radicale[16324]: Starting Radicale CalDAV server : radicale[7f555ae2f740] INFO: Starting Radicale Dec 29 16:04:01 manul radicale[16324]: [7f555ae2f740] INFO: Authentication type is 'htpasswd' Dec 29 16:04:01 manul radicale[16324]: [7f555ae2f740] DEBUG: registered 'apr_md5_crypt' handler: Dec 29 16:04:01 manul radicale[16324]: [7f555ae2f740] INFO: Storage type is 'multifilesystem' Dec 29 16:04:01 manul radicale[16324]: [7f555ae2f740] INFO: Rights type is 'owner_only' Dec 29 16:04:01 manul radicale[16324]: [7f555ae2f740] INFO: Web type is 'internal' Dec 29 16:04:01 manul radicale[16324]: [7f555ae2f740] INFO: Listening to 'localhost' on port 5232 Dec 29 16:04:01 manul radicale[16324]: . Dec 29 16:04:01 manul systemd[1]: Started LSB: Radicale CalDAV and CardDAV server. How does one make radicale log what is wrong? BTW, I run radicale behind an apache reverse proxy and did the x-script-name config changes. Cheers, Stefan -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages radicale depends on: ii adduser 3.118 ii init-system-helpers 1.56+nmu1 ii lsb-base 10.2019051400 ii python3 3.7.3-1 ii python3-radicale 2.1.11-6 Versions of packages radicale recommends: ii ssl-cert 1.0.39 Versions of packages radicale suggests: ii apache2 2.4.38-3+deb10u3 ii apache2-utils 2.4.38-3+deb10u3 pn libapache2-mod-proxy-uwsgi pn python3-bcrypt ii python3-passlib 1.7.1-1 pn uwsgi pn uwsgi-plugin-python3 -- Configuration Files: /etc/radicale/config changed: [server] hosts = 127.0.0.1:5232 certificate = /etc/ssl/certs/ssl-cert-snakeoil.pem key = /etc/ssl/private/ssl-cert-snakeoil.key [encoding] [auth] type = htpasswd htpasswd_encryption = md5 [rights] type = owner_only [storage] [web] [logging] config = /etc/radicale/logging debug = true [headers] /etc/radicale/logging changed: [loggers] keys = root [handlers] keys = console [formatters] keys = simple [logger_root] level = DEBUG handlers = console [handler_console] class = StreamHandler args = (sys.stderr,) formatter = simple [formatter_simple] format = [%(thread)x] %(levelname)s: %(message)s -- no debconf information
Bug#923661: tt-rss: PHP Fatal error: Uncaught PDOException: SQLSTATE[22001]: String data, right truncated
Hi Helmut, Am 08.05.19 um 19:23 schrieb Helmut Grohne: Thank you for the detailed analysis. The actual failure we see here is secondary. It tries to log an error and fails. Changing the LOG_DESTINATION fixes the secondary error. The primary cause seems to live in JShrink though and I guess that this commit fixes it: https://github.com/tedious/JShrink/pull/78/commits/91105810dafedba0390608d7465abd602beb6410 JShrink is a vendored library and is installed to /usr/share/tt-rss/www/vendor/JShrink/Minifier.php. You can apply the above commit to a live installation without rebuilding the package. Can any of the reporters try applying it and tell whether it fixes tt-rss? Yes, using the Minifier.php from the above commit fixes the issue (and another php warning that appeared in apache error log). In order to test it, one needs to delete the files from /var/cache/tt-rss/js/* first, or the minifier won't be called again. Cheers, Stefan
Bug#900821: linux-image-4.9.0-6-amd64: apache reads wrong data over cifs filesystems served by samba
Hi, by default, apache uses mmap, so probably mmap is broken on cifs. An alternate workaround should be to set EnableMMAP off in the apache config. Cheers, Stefan
Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout
reassign 914297 systemd affects 914297 apache2 thanks On Saturday, 15 December 2018 02:24:54 CET Alexander E. Patrakov wrote: > Stefan Fritsch : > > The rng should be initialized after the seed is loaded from disk. > > This is false according to systemd developers. Its state is changed, > but it is still not initialized, because they think that the seed > might come from a gold master image. That's broken, then. It turns out there was a similar bug against openssh which was closed as wontfix [1]. I don't see how apache can do anything about this, either. But I disagree with the systemd maintainers that there is nothing that systemd can do about this. They should credit the entropy loaded from the seed but save a new seed immediately after reading it during startup, to avoid that the same seed is used more than once. A second (but worse) alternative would be to provide something that waits for the RNG to be initialized that other services can depend on. Cheers, Stefan [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087
Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout
On Friday, 14 December 2018 12:43:29 CET Adrian Bunk wrote: > On Sun, Nov 25, 2018 at 11:35:37PM +0100, Stefan Fritsch wrote: > >... > > > > I don't see why it should take so > > long for the random number generator to initialize. > > > >... > > On embedded systems without hwrng "10 minutes" or "2 hours" are > real-life observations for the time it takes. > > Note that this became more problematic due to the CVE-2018-1108[1] > fix (reverted in stretch, but in buster/unstable). Is systemd-random-seed.service broken there? The rng should be initialized after the seed is loaded from disk. Adrian, please send the output of journalctl -b UNIT=apache2.service + UNIT=systemd-random-seed.service + _TRANSPORT=kernel|grep -i -e apache -e random if apache2 fails to start.
Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout
How long is the timeout after which it is killed? What is the status of systemd-random-seed.service in that case? I don't see why it should take so long for the random number generator to initialize. But maybe apache2 needs to add a dependency. Please provide the output of journalctl -b UNIT=apache2.service + UNIT=systemd-random-seed.service + _TRANSPORT=kernel|grep -i -e apache -e random when apache2 has failed to start.
Bug#902657: Segfault is caused by libcap-ng0 0.7.9
retitle 902657 graceful/restart results in segfault if libcap-ng0 is loaded severity 902657 important block 902657 by 904808 thanks The problem is caused by libcap-ng0 0.7.9 . This is usually pulled in by php extensions. There is nothing apache can do. Unfortunately, downgrading to 0.7.7 from stretch is not possible due to dependencies.
Bug#904808: libcap-ng0: libcap-ng's use of pthread_atfork causes segfaults
Package: libcap-ng0 Version: 0.7.9-1 Severity: grave Justification: renders package unusable Hi, apache httpd loads and unloads modules during a reload of the server configuration. This causes the pthread_atfork entry that is installed by libcap-ng0 to point to code that is no longer in the process, causing a segfault at the next fork. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902657 There is already an upstream bug report about this: https://github.com/stevegrubb/libcap-ng/issues/5 Since there is no interface to undo a pthread_atfork() call, there is no way a shared library can call pthread_atfork() in a safe way. libcap-ng0 should not do it. Cheers, Stefan -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: armhf, i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcap-ng0 depends on: ii libc6 2.27-5 libcap-ng0 recommends no packages. libcap-ng0 suggests no packages. -- no debconf information
Bug#902658: apache2: apachectl graceful/restart results in segfault
On Tuesday, 17 July 2018 21:12:48 CEST gregor herrmann wrote:
> On Tue, 17 Jul 2018 20:54:02 +0200, Stefan Fritsch wrote:
> > Can one of you please check how libcap-ng is pulled into the process.
> > Something like this should do the trick (replace XXX with the pid of one
> > of
> > your apache processes, you need to be root to do this) :
> >
> > pid=XXX; for i in $(awk '{ print $6 }' < /proc/$pid/maps|sort -u|grep /) ;
> > do readelf -d $i|grep libcap && echo $i ; done
>
> # pid=6855; for i in $(awk '{ print $6 }' < /proc/$pid/maps|sort -u|grep /)
> ; do readelf -d $i|grep libcap && echo $i ; done readelf: Error:
> '/dev/zero' is not an ordinary file
> 0x0001 (NEEDED) Shared library: [libcap-ng.so.0]
> /lib/x86_64-linux-gnu/libaudit.so.1.0.0
> 0x000e (SONAME) Library soname: [libcap-ng.so.0]
> /lib/x86_64-linux-gnu/libcap-ng.so.0.0.0
> readelf: Error: '/SYSV645e': No such file
> readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
Thanks, Gregor. Unfortunately, that is not helpful, yet. Please try again with
ldd instead of readelf -d.
Bug#902658: apache2: apachectl graceful/restart results in segfault
On Friday, 29 June 2018 10:35:32 CEST mer.at wrote:
> when i do an "apachectl graceful" or "apachectl restart", i get
> segfaults.
I don't think this is a bug in apache, at least not directly.
> if i then do a /etc/init.d/apache2 restart, it works normally
> /etc/init.d/apache2 restart and systemctl restart apache2 do NOT result
> in a segfault.
> Stack trace of thread 20261:
> #0 0x7fa235131677 n/a (libcap-ng.so.0)
Can one of you please check how libcap-ng is pulled into the process.
Something like this should do the trick (replace XXX with the pid of one of
your apache processes, you need to be root to do this) :
pid=XXX; for i in $(awk '{ print $6 }' < /proc/$pid/maps|sort -u|grep /) ; do
readelf -d $i|grep libcap && echo $i ; done
It's not pulled in by mod_fcgid.
Maybe there is a desctructor in libcap-ng that causes the segfault while
libcap-ng is unloaded during graceful restart. Then it could be possible that
it crashes or not depending on the load order or exact list of modules.
Bug#889170: apr-util: build failure with new gdbm
On Friday, 2 February 2018 23:32:35 CET Gianfranco Costamagna wrote: > Hello, before uploading new gdbm in unstable, I tested all the > reverse-dependencies, except for the packages that were already broken/not > building. > > This sounds to be the case for this one, and now I don't know how to debug > this package. It seems apr-util assumed that gdbm would always reset gdbm_errno if there has not been an error and the new gdbm version does not do that any more. I have fixed that upstream in apr-util: https://svn.apache.org/viewvc?view=revision=1825312
Bug#870831: Broken symbols file creates broken dependencies
Package: libbrotli0.6.0 Version: 0.6.0-2~exp0 Severity: serious I have tried to build apache2's mod_brotli with libbrotli0.6.0 / libbrotli-dev from experimental But the resulting packages gets a dependency on the non-existing libbrotli0 (>= 0.6.0). I think the reason for this is that /var/lib/dpkg/info/libbrotli0.6.0:amd64.symbols contains libbrotlidec.so.0.6.0 libbrotli0 #MINVER# This should be libbrotli0.6.0 instead of libbrotli0.
Bug#861994: live-wrapper: Lacks dependency on python-pycurl
Package: live-wrapper
Version: 0.6
Severity: serious
lwr seems to require pycurl:
$ lwr --help
Traceback (most recent call last):
File "/usr/bin/lwr", line 11, in
load_entry_point('live-wrapper==0.6', 'console_scripts', 'lwr')()
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 561,
in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2631,
in load_entry_point
return ep.load()
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2291,
in load
return self.resolve()
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2297,
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/usr/lib/python2.7/dist-packages/lwr/run.py", line 18, in
import pycurl
ImportError: No module named pycurl
But it lacks the proper dependency on python-pycurl. With python-pycurl
installed, it works.
-- System Information:
Debian Release: 9.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64
(x86_64)
Foreign Architectures: armhf, i386
Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages live-wrapper depends on:
ii debian-archive-keyring 2014.3
ii isolinux3:6.03+dfsg-14.1
ii python-apt 1.4.0~beta3
ii python-cliapp 1.20160724-2
ii python-distro-info 0.15
ii python-requests 2.12.4-1
pn python:any
ii vmdebootstrap 1.7-1
ii xorriso 1.4.6-1+b1
live-wrapper recommends no packages.
Versions of packages live-wrapper suggests:
pn cmdtest
-- no debconf information
Bug#849082: libapache2-mod-perl2: FTBFS: test failures with Apache 2.4.25
On Friday, 23 December 2016 18:56:54 CET Niko Tyni wrote:
> This passage in RFC 7230, section 9.4., seems relevant:
>
>A more effective mitigation is to prevent anything other than the
>server's core protocol libraries from sending a CR or LF within the
>header section, which means restricting the output of header fields to
>APIs that filter for bad octets and not allowing application servers
>to write directly to the protocol stream.
>
> I would expect mod_perl to be classified as a 'core protocol library' in
> this sense, but I have no idea yet if it's just doing something wrong.
>
> Patch attached to revert to the old "unsafe" behaviour in the virtual
> host specific to this test.
The problem is that the injected header lines only have a LF and no CR. I
suggest the attached patch.
rfc7230 3.5 says:
Although the line terminator for the start-line and header fields is
the sequence CRLF, a recipient MAY recognize a single LF as a line
terminator and ignore any preceding CR.
Apache with strict enabled chooses not to implement the MAY. I am not 100%
sure that this is a good idea, but that is a different question. In any case,
mod_perl's test should send a compliant HTTP request.
Cheers,
Stefan--- ./t/filter/TestFilter/in_bbs_inject_header.pm.orig 2016-10-27 22:11:16.0 +0200
+++ ./t/filter/TestFilter/in_bbs_inject_header.pm 2016-12-24 06:55:19.049606491 +0100
@@ -181,7 +181,7 @@
if ($data and $data =~ /^POST/) {
# demonstrate how to add a header while processing other headers
-my $header = "$header1_key: $header1_val\n";
+my $header = "$header1_key: $header1_val\r\n";
push @{ $ctx->{buckets} }, APR::Bucket->new($c->bucket_alloc, $header);
debug "queued header [$header]";
}
@@ -199,7 +199,7 @@
# we hit the headers and body separator, which is a good
# time to add extra headers:
for my $key (keys %headers) {
-my $header = "$key: $headers{$key}\n";
+my $header = "$key: $headers{$key}\r\n";
push @{ $ctx->{buckets} }, APR::Bucket->new($c->bucket_alloc, $header);
debug "queued header [$header]";
}
Bug#828231: alpine: FTBFS with openssl 1.1.0
Since the maintainer is on the LowThresholdNmu list, I intend to NMU alpine to switch to openssl 1.0.x in a few days.
Bug#828258: canl-c/gridsite: FTBFS with openssl 1.1.0
On Friday, 2 December 2016 00:16:24 CET Sebastian Andrzej Siewior wrote: > is there a reason for gridsite not to go for 3.0 (or backport the > change) and libssl-dev? Apache stays 1.0 but does not expose anything > SSL related (unless I read #828236 too quick). (assuming you meant 1.1 instead of 3.0). Unfortunately, gridsites uses apache private structures to get to the SSL related stuff and then uses openssl functions on it. So gridsite absolutely must use the same openssl version as apache.
Bug#844160: Bug#828236: [Pkg-openssl-devel] Bug#844160: openssl 1.1 and apache2
On Friday, 18 November 2016 19:20:15 CET Adrian Bunk wrote: > On Fri, Nov 18, 2016 at 06:10:31AM +0100, Stefan Fritsch wrote: > > On Friday, 18 November 2016 01:09:53 CET Adrian Bunk wrote: > > > What does create the dependency in > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828330#16 > > > > > > ? > > > > By including its own copy of ssl_private.h from the apache source (not > > installed in apache2-dev). Urgh. > > > Are there other packages that are doing similar things? I did some grep among the modules in sid but found no other. [1] > And unrelated to the problem in this bug: > Now that there is a proper header, it should be used in GridSite? In principle, yes. But it's quite possible that the APIs exposed in mod_ssl_openssl.h are not sufficient for gridsite. But then gridsite upstream should work with apache2 upstream to get the required APIs added. > > But putting it into a separate apache2-mod_ssl-dev package with the proper > > mod_ssl dependency would still work. gridsite would then need to build-dep > > on that package and (AFAICS) php does not do the same ugly tricks and > > would be unaffected by the dependency on libssl1.0-dev. > > This is the build-dependency side. > > But this would still allow installing GridSite and Apache compiled with > different OpenSSL versions. > > Creating a dependency on apache-abi-openssl-1-0-2 for every user of the > affected symbols and providing that (similar to qtbase-abi-5-6-1) would > be the proper solution. We already have a apache2-api-20120211 virtual package that apache2-bin provides and that all modules should depend on. We could stop providing that and switch to apache2-api-20120211-openssl1.1 when we upgrade apache2 to openssl 1.1. This would at least require a binNMU off all apache2 modules. Modules that don't use dh_apache2 to generate the dependency would need a sourceful update. On the other hand, since there seem to be so few modules that do this, adding some "breaks:" may be the better solution. The grep I did would then need to be re-done for modules that are in jessie but not in sid. Cheers, Stefan [1] Assuming the module-packages are extracted in the current dir: for f in $(find . -name \*.so) ; do strings $f |grep -qw -e ssl_module -e init_server -e pre_handshake -e proxy_post_handshake && echo $f ; done
Bug#844160: Bug#828236: [Pkg-openssl-devel] Bug#844160: openssl 1.1 and apache2
On Friday, 18 November 2016 01:09:53 CET Adrian Bunk wrote: > On Thu, Nov 17, 2016 at 11:18:57PM +0100, Stefan Fritsch wrote: > > On Thursday, 17 November 2016 21:39:19 CET Kurt Roeckx wrote: > > > > That header was created for mod_ssl_ct which provides support for > > > > certificate transparency. It's quite new and likely that nothing else > > > > uses the header. It would probably be acceptable to remove the > > > > dependency > > > > in apache2-dev on libssl-dev and add a caveat to the README.Debian. I > > > > could also not install the header, or put it into a separate new > > > > package > > > > that depends on libssl-dev. > > > > > > So can you confirm that the only reason for the libssl-dev > > > depedency is that file? > > > > Yes. > > What does create the dependency in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828330#16 > ? By including its own copy of ssl_private.h from the apache source (not installed in apache2-dev). Urgh. /* * After 2.0.49, Apache mod_ssl has most of the mod_ssl structures defined * in ssl_private.h, which is not installed along with httpd-devel (eg in * the FC2 RPM.) This include file provides SIMPLIFIED structures for use * by mod_gridsite: for example, pointers to unused structures are replaced * by void * and some of the structures are truncated when only the early * members are used. * * CLEARLY, THIS WILL BREAK IF THERE ARE MAJOR CHANGES TO ssl_private.h!!! */ That's very ugly. So, not installing mod_ssl_openssl.h or a caveat in README.Debian would not help. But putting it into a separate apache2-mod_ssl-dev package with the proper mod_ssl dependency would still work. gridsite would then need to build-dep on that package and (AFAICS) php does not do the same ugly tricks and would be unaffected by the dependency on libssl1.0-dev.
Bug#844160: Bug#828236: [Pkg-openssl-devel] Bug#844160: openssl 1.1 and apache2
On Thursday, 17 November 2016 21:39:19 CET Kurt Roeckx wrote: > > That header was created for mod_ssl_ct which provides support for > > certificate transparency. It's quite new and likely that nothing else > > uses the header. It would probably be acceptable to remove the dependency > > in apache2-dev on libssl-dev and add a caveat to the README.Debian. I > > could also not install the header, or put it into a separate new package > > that depends on libssl-dev. > So can you confirm that the only reason for the libssl-dev > depedency is that file? Yes.
Bug#844160: Bug#828236: [Pkg-openssl-devel] Bug#844160: openssl 1.1 and apache2
Hi, [I have trimmed the cc list a bit] On Wednesday, 16 November 2016 20:36:49 CET Kurt Roeckx wrote: > On Mon, Nov 14, 2016 at 03:06:44PM -0800, Russ Allbery wrote: > > Stefan Fritsch <s...@debian.org> writes: > > > I must admit that I did not think of php when doing that change, sorry. > > > > > > On the other hand, shibboleth-sp2 also build-depends on apache2-dev and > > > there have been some indications that shibboleth won't be switching to > > > openssl 1.1 for stretch. See > > > https://lists.debian.org/debian-release/2016/11/msg00024.html> > > It turns out that Shibboleth will be okay if Apache goes to 1.1. The > > Shibboleth code that goes into Apache is isolated from the OpenSSL use > > inside Shibboleth, so we can keep building Shibboleth against 1.0 and > > Apache can go to 1.1 and all the pieces are happy. (The OpenSSL work is > > done in a separate daemon, shibd, that the Apache module talks to.) > > So I looked at apache2-dev to see why it depends on libssl-dev. > The only thing I can find is that mod_ssl_openssl.h provides some > hooks, and you actually get SSL_CTX * and SSL * in there. But > nothing in Debian seems to include that file. That header was created for mod_ssl_ct which provides support for certificate transparency. It's quite new and likely that nothing else uses the header. It would probably be acceptable to remove the dependency in apache2-dev on libssl-dev and add a caveat to the README.Debian. I could also not install the header, or put it into a separate new package that depends on libssl-dev. That would be one alternative. Another would be to switch apache2 to openssl 1.1. I have explained why I don't want to this. But it's not impossible. The release team has announced that they will decide soon if they want the transition to go ahead or not. I will reconsider depending on what they write. BTW, I am pretty sure that support for enhanced master secret and chacha20 will appear for openssl 1.0.2 before the release of stretch+1, if only because redhat needs it for its long support cycles. Back-porting that to stretch in a year or so in a stable-point-release would IMHO be the best option. When Apache httpd 2.4 came out, I was also quite disappointed that it could not be included in squeeze, but mod_perl was not ready at the time and it would not have made any sense to include an inofficial forward-port of mod_perl to 2.4 in Debian. In the same way, I don't think it is a good idea to include lots of patches for openssl 1.1, with little testing. Cheers, Stefan
Bug#828258: canl-c/gridsite: FTBFS with openssl 1.1.0
Hi again, On Saturday, 12 November 2016 07:51:40 CET Stefan Fritsch wrote: > If these two packages cannot transition to openssl 1.1.0 before apache2 > does, I suggest that you build with openssl 1.0.2 explicitly and then > downgrade the bugs and unlink them from the transition bug. I don't have > much hope that apache2 will transition in time for stretch release. since there is now some discussion about this on debian-devel and debian- release, maybe you should wait a bit with any actions. Cheers, Stefan
Bug#844160: openssl 1.1 and apache2
On Monday, 14 November 2016 05:03:45 CET Ondřej Surý wrote: > > Looking at mod_ssl_openssl.h and the comment in #828330, > > I'd suggest the change below to add a dependency on libssl1.0-dev > > to apache2-dev. > > And that exactly happens meaning that PHP 7.0 can no longer be built > unless all it's build-depends (including PHP 7.0) and rdepends move to > libssl1.0-dev as well. > > So a nice deadlock, right? To be honest I would rather have a slightly > less tested apache2 with OpenSSL 1.1.0 and iron out the bugs as we go > than revert all the work I have done. I must admit that I did not think of php when doing that change, sorry. On the other hand, shibboleth-sp2 also build-depends on apache2-dev and there have been some indications that shibboleth won't be switching to openssl 1.1 for stretch. See https://lists.debian.org/debian-release/2016/11/msg00024.html I agree with Ondřej that this will get very entangled. There will be one big dependency-blob that contains most complex packages and can only be transitioned together. And a few leaf packages that can be transitioned easily. For example, subversion also build-depends on apache, and kde build- depends on subversion. Though libsvn-dev does not depend on apache2-dev, so maybe this is not actually a problem. > I reviewed the patch Kurt has provided and I don't see any strong reason > why anything should break. With Kurt's patch, apache2 crashes on startup with an invalid free. On the other hand, the patch from the upstream 2.4.x-openssl-1.1.0-compat branch seems to work at first glance and does not cause any regression in the test suite. So if we are going to have apache with openssl 1.1, it's going to be the upstream patch. But we first need to figure out what to do with shibboleth-sp2 . My preference would be to make openssl 1.0 provide libssl-dev again and only have a few simple packages opt-in to using libssl1.1-dev. Cheers, Stefan
Bug#828330: canl-c/gridsite: FTBFS with openssl 1.1.0
Hi, If these two packages cannot transition to openssl 1.1.0 before apache2 does, I suggest that you build with openssl 1.0.2 explicitly and then downgrade the bugs and unlink them from the transition bug. I don't have much hope that apache2 will transition in time for stretch release. Cheers, Stefan
Bug#828236: Processed: tagging 828236
Hi Kurt, On Sunday, 25 September 2016 19:51:08 CET Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > > tags 828236 + patch > > Bug #828236 [src:apache2] apache2: FTBFS with openssl 1.1.0 > Added tag(s) patch. I am sorry, but I don't feel qualified to review that patch (or the upstream branch 2.4.x-openssl-1.1.0-compat which has a different implementation). In apache, there is lots of subtle interaction between TLS-renegotiation and access control. Therefore I want to have the patch reviewed by someone who knows mod_ssl well before I include it in Debian. Also, having openssl 1.1 support only in testing/unstable won't give apache enough exposure to ensure that nothing is broken in complex configurations. Currently there is no movement upstream to finish the openssl 1.1 support any time soon. This means that it is very unlikely that apache2 will get fixed in time for stretch. Cheers, Stefan
Bug#841763: unattended-upgrades: Breaks hard when apt is upgraded
Hi, On Sun, 23 Oct 2016, Alexandre Detiste wrote: > I think that adding this snippet to apt's debian/rules would fix this problem, > not tested tough. > > > > override_dh_systemd_start: > dh_systemd_start apt-daily.timer > Not restarting it would be one way to fix it. I don't know if apt-daily does other things that need a restart when upgrading. A different idea may be to use systemd-run to start apt (or the whole unattended-upgrades script) as a transient scope unit. AIUI, this should prevent systemd from killing apt, even if the parent process is terminated. Cheers, Stefan
Bug#841763: unattended-upgrades: Breaks hard when apt is upgraded
Package: unattended-upgrades
Version: 0.92
Severity: grave
Dear Maintainer,
When unattended-upgrades has to upgrade apt itself, it will be
terminated and leaves the system in a state that requires manual
intervention, like
dpkg --reconfigure --pending
apt-get -f install
A second bug is that this broken state does not lead to any mails being
sent to root, and it may take a long time until it is discovered that
updates do not work.
Possibly, apt is killed because systemd is killing all processes
belonging to a service when that service is stopped/restarted and maybe
apt restarts the daily apt service.
Cheers,
Stefan
Log file extract:
unattended-upgrades-dpkg.log
Log started: 2016-10-10 15:35:41
apt-listchanges warning: Cannot reopen /dev/tty for stdin: [Errno 6] No
such device or address: '/dev/tty'
apt-listchanges: Reading changelogs...
apt-listchanges: Mailing root: apt-listchanges: news for XXX
(Reading database ... ^M(Reading database ... 5%^M(Reading database ...
10%^M(Reading database ... 15%^M(Reading database ... 20%^M(Reading
database ... 25%^M(Reading database ... 30%^M(Reading database ...
35%^M(Reading database ... 40%^M(Reading database ... 45%^M(Reading
database ... 50%^M(Reading database ... 55%^M(Reading database ...
60%^M(Reading database ... 65%^M(Reading database ... 70%^M(Reading
database ... 75%^M(Reading database ... 80%^M(Reading database ...
85%^M(Reading database ... 90%^M(Reading database ... 95%^M(Reading
database ... 100%^M(Reading database ... 55308 files and directories
currently installed.)
Preparing to unpack .../libapt-pkg5.0_1.3.1_amd64.deb ...
Unpacking libapt-pkg5.0:amd64 (1.3.1) over (1.3) ...
Setting up libapt-pkg5.0:amd64 (1.3.1) ...
(Reading database ... ^M(Reading database ... 5%^M(Reading database ...
10%^M(Reading database ... 15%^M(Reading database ... 20%^M(Reading
database ... 25%^M(Reading database ... 30%^M(Reading database ...
35%^M(Reading database ... 40%^M(Reading database ... 45%^M(Reading
database ... 50%^M(Reading database ... 55%^M(Reading database ...
60%^M(Reading database ... 65%^M(Reading database ... 70%^M(Reading
database ... 75%^M(Reading database ... 80%^M(Reading database ...
85%^M(Reading database ... 90%^M(Reading database ... 95%^M(Reading
database ... 100%^M(Reading database ... 55308 files and directories
currently installed.)
Preparing to unpack .../0-libapt-inst2.0_1.3.1_amd64.deb ...
Unpacking libapt-inst2.0:amd64 (1.3.1) over (1.3) ...
Preparing to unpack .../1-apt_1.3.1_amd64.deb ...
Unpacking apt (1.3.1) over (1.3) ...
Setting up apt (1.3.1) ...
Log started: 2016-10-22 04:37:01
unattended-upgrades.log
2016-10-10 15:35:34,852 INFO Initial blacklisted packages:
2016-10-10 15:35:34,852 INFO Initial whitelisted packages:
2016-10-10 15:35:34,852 INFO Starting unattended upgrades script
2016-10-10 15:35:34,852 INFO Allowed origins are:
['origin=Debian,codename=stretch']
2016-10-10 15:35:41,215 INFO Packages that will be upgraded: apache2
apache2-bin apache2-data apache2-utils apt apt-utils libapt-inst2.0
libapt-pkg5.0 libreadline6 libslang2 readline-common vim vim-common
vim-runtime xxd
2016-10-10 15:35:41,215 INFO Writing dpkg log to
'/var/log/unattended-upgrades/unattended-upgrades-dpkg.log'
2016-10-21 08:08:47,884 INFO Initial blacklisted packages:
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.7.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages unattended-upgrades depends on:
ii apt1.3.1
ii apt-utils 1.3.1
ii debconf [debconf-2.0] 1.5.59
ii init-system-helpers1.45
ii lsb-base 9.20160629
ii lsb-release9.20160629
ii python33.5.1-4
ii python3-apt1.1.0~beta5
ii ucf3.0036
ii xz-utils 5.2.2-1.2
Versions of packages unattended-upgrades recommends:
ii cron [cron-daemon] 3.0pl1-128
Versions of packages unattended-upgrades suggests:
ii bsd-mailx 8.1.2-0.20160123cvs-3
ii exim4-daemon-light [mail-transport-agent] 4.87-3+b1
-- debconf information:
* unattended-upgrades/enable_auto_updates: true
* unattended-upgrades/origins_pattern: origin=Debian,codename=${distro_codename}
Bug#838544: ext4: ext4_iget:4476: inode #8: comm mount: checksum invalid
Package: src:linux Version: 4.7.4-2 Severity: grave Justification: renders package unusable When booting with linux-image-4.7.0-1-amd64 4.7.4-2, one of my filesystems fails to mount with: ext4_iget:4476: inode #8: comm mount: checksum invalid A fsck does not find any errors, though, and the mount problem persists. After rebooting with 4.6, it works. It seems this is a known problem: http://www.spinics.net/lists/linux-fsdevel/msg101888.html Not sure about the severity, but I thought I should prevent it from migrating to testing until you have looked at it.
Bug#829088: ccache may silently miscompile symlinked source files
found 829088 3.2.5-1 thanks Version 3.2.5-1 is also affected by this issue. Attached is a log file from that version. Since the path names are rather complicated in the examples: The dir with the symlinked source files is (note the obj in the 3rd component): /changes/L4.fritsch/obj/l4re/amd64/pkg/l4re-core/uclibc-minimal/libc/src/libc/stdlib/malloc-standard/free.c The path to the source file with all symlinks resolved is (there is no obj/ and no amd64/ in this path): /changes/L4.fritsch/l4re/src/l4/pkg/l4re-core/uclibc/lib/contrib/uclibc/libc/stdlib/malloc-standard/free.c ccache-log.3.2.5-1.fail Description: Binary data
Bug#829088: ccache may silently miscompile symlinked source files
Package: ccache Version: 3.1.10-1 Severity: grave Hi, the ccache in jessie has a serious regression vs. wheezy. When passing files to the preprocessor, ccache in jessie resolves symlinks and passes the path of the resulting filename on the preprocessor command line. This does however change the compiled source code, because the preprocessor resolves paths for headers included with #include "foo.h" from the directory that the source file is located in. So, if the directory of the real source file contains a header that is included in that file, this one will be used instead of a header that is located in the directory where the symlink is located. Interestingly, if the directory with the real source file does not contain a file the the name of the included header, the preprocessor will fail and ccache will silently re-try using the correct compiler invocations. In this case no corruption occurs. I think therefore this bug is not hit very often and may not have been noticed before. I don't know yet if the version of ccache in stretch/sid also has this problem, but I will try to find out. In any case, I think this should be fixed in jessie in a stable point release. I have attached a ccache log files that exhibit the wrong preprocessor command line, and the corresponding log file with ccache 3.1.7-1 from wheezy that instead use the unmodified file name "../src/libc/stdlib/malloc-standard/free.c". The examples use CCACHE_BASEDIR=/changes/L4.fritsch . I don't know if the bug happens without CCACHE_BASEDIR. Using direct mode or not does not make a difference. Cheers, Stefan [2016-06-30T09:28:43.627166 9278 ] === CCACHE STARTED = [2016-06-30T09:28:43.627277 9278 ] Command line: gcc -c -MD -MP -MF libc/stdlib/malloc-standard/.free.s.o.d -nostdinc -include /changes/L4.fritsch/l4re/src/l4/pkg/l4re-core/uclibc/lib/uclibc/../contrib/uclibc/include/libc-symbols.h -DL4SYS_USE_UTCB_WRAP=1 -DL4_THREAD_SAFE -DL4_NO_RTTI=1 -DNDEBUG -D_LIBC -D__UCLIBC_CTOR_DTOR__ -D__UCLIBC_HAS_SSP__=1 -DUSE_TLS=1 -DSYSTEM_amd64_K8_l4f -DARCH_amd64 -DCPUTYPE_K8 -DL4API_l4f -D_GNU_SOURCE -I/changes/L4.fritsch/l4re/src/l4/pkg/l4re-core/uclibc/lib/uclibc/../contrib/uclibc/libc/sysdeps/linux/x86_64 -I/changes/L4.fritsch/l4re/src/l4/pkg/l4re-core/uclibc/lib/uclibc/../contrib/uclibc/libc/sysdeps/linux -I/changes/L4.fritsch/obj/l4re/amd64/pkg/l4re-core/uclibc/lib/uclibc/src/libc -I/changes/L4.fritsch/l4re/src/l4/pkg/l4re-core/uclibc/lib/uclibc/../libpthread/src/sysdeps/x86_64 -I/changes/L4.fritsch/l4re/src/l4/pkg/l4re-core/uclibc/lib/uclibc/../libpthread/src -I/changes/L4.fritsch/obj/l4re/amd64/include/amd64/l4f -I/changes/L4.fritsch/obj/l4re/a md64/include/amd64 -I/changes/L4.fritsch/obj/l4re/amd64/include -isystem /changes/L4.fritsch/obj/l4re/amd64/include/sys/amd64/l4f -isystem /changes/L4.fritsch/obj/l4re/amd64/include/sys/l4f -isystem /changes/L4.fritsch/obj/l4re/amd64/include/sys/amd64 -isystem /changes/L4.fritsch/obj/l4re/amd64/include/sys -nostdinc -I/changes/L4.fritsch/obj/l4re/amd64/include/uclibc -I/changes/L4.fritsch/obj/l4re/amd64/include/contrib/libstdc++-v3 -isystem /usr/lib/gcc/x86_64-linux-gnu/4.9/include -isystem /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed -fno-builtin -fno-stack-protector -DUCLIBC_INTERNAL -fno-omit-frame-pointer -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes -fno-common -std=gnu99 -m64 -mno-red-zone -march=k8 -fno-stack-protector -DSHARED=1 -fPIC -U__PIC__ -D__PIC__=1 /changes/L4.fritsch/obj/l4re/amd64/pkg/l4re-core/uclibc/lib/uclibc/src/libc/stdlib/malloc-standard/free.c -o libc/stdlib/malloc-standard/free.s.o [2016-06-30T09:28:43.627301 9278 ] Hostname: dev [2016-06-30T09:28:43.627323 9278 ] Working directory: /changes/L4.fritsch/obj/l4re/amd64/pkg/l4re-core/uclibc/lib/uclibc/OBJ-amd64_K8-l4f [2016-06-30T09:28:43.627328 9278 ] Base directory: /changes/L4.fritsch [2016-06-30T09:28:43.627671 9278 ] Source file: ../../../../../../../../../l4re/src/l4/pkg/l4re-core/uclibc/lib/contrib/uclibc/libc/stdlib/malloc-standard/free.c [2016-06-30T09:28:43.627678 9278 ] Dependency file: libc/stdlib/malloc-standard/.free.s.o.d [2016-06-30T09:28:43.627683 9278 ] Object file: libc/stdlib/malloc-standard/free.s.o [2016-06-30T09:28:43.627693 9278 ] Trying direct lookup [2016-06-30T09:28:43.627796 9278 ] Looking for object file hash in /scratch/ccache/fritsch/c/4/4b04d0df7befa9efbb1dec61a04cba-7973.manifest [2016-06-30T09:28:43.627812 9278 ] No such manifest file [2016-06-30T09:28:43.627818 9278 ] Did not find object file hash in manifest [2016-06-30T09:28:43.627830 9278 ] Running preprocessor [2016-06-30T09:28:43.627859 9278 ] Executing /usr/bin/gcc -c -nostdinc -include ../../../../../../../../../l4re/src/l4/pkg/l4re-core/uclibc/lib/contrib/uclibc/include/libc-symbols.h -DL4SYS_USE_UTCB_WRAP=1 -DL4_THREAD_SAFE -DL4_NO_RTTI=1 -DNDEBUG -D_LIBC -D__UCLIBC_CTOR_DTOR__ -D__UCLIBC_HAS_SSP__=1 -DUSE_TLS=1
Bug#794933: apache2-suexec-custom: prompting due to modified conffiles which were not modified by the user: /etc/apache2/conf-available/security.conf
Hi Andreas, sorry this took so long. I was rather busy in June. On Sunday 29 May 2016 19:00:59, Andreas Beckmann wrote: > On 2016-05-28 22:21, Stefan Fritsch wrote: > > I think I have a patch that does this correctly. > > Sounds promising. Be Is it generic enough s.t. it could be reused by > other packages with similar problems? (right now I remember squid > and libreoffice, but I think there were more) It's still a long way to a dh_fixbrokenconffiles, but I could imagine that people with the same problem may want to get inspired by the code. > > > Is it possible with piuparts to test these upgrade paths: > > > > wheezy -> jessie 8.0 -> stretch > > wheezy -> jessie 8.recent -> stretch > > wheezy -> jessie 8.0 -> jessie 8.recent -> stretch > > > > It may be a bit complicated because 8.0 is not on the mirrors > > anymore. > we could use archive.d.org > > > If yes, would you have time to do the testing? Thanks in advance. > > If you help me a bit :-) It will require some scripting ... and > maybe some new piuparts features to be coded - on my side. > > Do you have only one set of new packages for stretch to be tested or > are there new packages targeting jessie as well? I am only planning for a fix in stretch. Puting the same complicated logic into jessie seems too risky to me. > > So the upgrade path will actually be > > wheezy -> jessie X.Y -> stretch+new yes > (or up to wheezy -> jessie X.Y -> jessie X.Z(+new) -> stretch -> > stetch+new) > > (with a "reference" ending in plain stretch, to see if you actually > fixed something) > > Build the packages for amd64 and put them together with a > Packages.gz on some webspace. If it's more than one source package > for a distro - no problem, throw them all into one repo. Version > must be higher than the version in stretch, s.t. I can use stretch > + your repo and have apt do the right thing. I have put them here: deb http://www.sfritsch.de/~stf/794933/2.4.20-3~test1/ ./ Signed with my gpg key (or use https). > Can you find the sources.list entry needed to install jessie 8.0 > from archive.d.org? (Full jessie 8.0, not just a few packages.) With these release dates 2015-04-26 8.0 2015-06-06 8.1 2015-09-05 8.2 I have found: http://snapshot.debian.org/archive/debian/20150601T041739Z/ You will need to set Acquire::Check-Valid-Until=false in the apt config. > > Then I need a list of packages (indivudal ones or sets, from wheezy) > to be tested on these upgrade paths. And there is the option > --with-recommends, if needed. Installing only apache2.2-common on wheezy should do the trick and pull in apache2 when upgrading to jessie. > You'll get some logfiles to analyze in return. Thanks again for your help :) > > Sounds not too complicated :-) > > > Andreas > > PS: Do you want to do tests with user-modified conffiles as well? > These should probably get prompts and "fail". Requires a recipe for > modification. Let's try the unmodified case first. Cheers, Stefan
Bug#794933: apache2-suexec-custom: prompting due to modified conffiles which were not modified by the user: /etc/apache2/conf-available/security.conf
Here is a status update. In 2.4.10-10+deb8u2 in the Debian 8.2 point release, I have included this fix: * Fix upgrade logic: When upgrading from wheezy with apache2.2-common but without apache2 installed to jessie, part of the conffile handling logic would not run, causing outdated conffile content to be kept. This is part of the solution for bug #794933. The other part will be included in the upgrade to Debian 9 (stretch). This means that systems that were upgraded from wheezy direcly to jessie 8.2 or newer won't encounter the bug. But those systems that were upgraded to an early version of jessie now have some conffiles with old contents from wheezy instead of the new content from jessie. And dpkg thinks that the user changed the conffiles, which will cause conffile questions during the next upgrade that changes the affected conffiles. To avoid these questions, I intend to * include the correct content of the conffiles base64 encoded in the preinst. This is very ugly but there seems to be no other way. In preinst, the files of the new package are not unpacked, yet. * check in preinst if the conffiles on disk match the wheezy versions * if yes, replace them with the correct version (and save backup copies) * let dpkg do the upgrade. dpkg will not ask questions about the affected conffiles because they already have exactly the same content as in the new package. * in postinst, delete the saved copies of the old content I think I have a patch that does this correctly. Is it possible with piuparts to test these upgrade paths: wheezy -> jessie 8.0 -> stretch wheezy -> jessie 8.recent -> stretch wheezy -> jessie 8.0 -> jessie 8.recent -> stretch It may be a bit complicated because 8.0 is not on the mirrors anymore. If yes, would you have time to do the testing? Thanks in advance. Cheers, Stefan
Bug#820824: libapache2-mod-perl2: FTBFS: t/protocol/pseudo_http.t failure
On Tue, 10 May 2016, Niko Tyni wrote: > On Mon, May 09, 2016 at 09:49:13PM +0300, Niko Tyni wrote: > > > I intend to disable the test in libapache2-mod-perl2 for now until > > a better solution is found. > > Done in 2.0.9-5 which I just uploaded. > > > Do you want to track the apache2 crash > > with this bug, Yes, I will do that. Thanks.
Bug#820824: libapache2-mod-perl2: FTBFS: t/protocol/pseudo_http.t failure
reassign 820824 apache2 found 820824 2.4.20-1 affects 820824 libapache2-mod-perl2 thanks Thanks for the report. On Tuesday 12 April 2016 23:04:42, Niko Tyni wrote: > Looking at the CI results at > > https://ci.debian.net/packages/liba/libapache2-mod-perl2/unstable/a > md64/ this started happening between 2016-04-09 and 2016-04-10, > probably with the apache2 2.4.18 -> 2.4.20 upgrade. > > I can get this to happen with just > # ./t/TEST -verbose -httpd_conf $(pwd)/debian/apache2.conf > t/protocol/pseudo_http.t > > and I see the Apache server process dies with SIGSEGV. Backtrace > below. > > Cc'ing the Apache maintainers, seems to be a regression there? Seems likely. Reassigning to keep 2.4.20-1 from migrating to testing for now.
Bug#805737: libembperl-perl: FTBFS: apache2 crash during test suite
reassign 805737 apache2 found 805737 2.4.17-2 affects 805737 libembperl-perl retitle 805737 apache2 crash when started with -X thanks On Saturday 21 November 2015 22:42:00, Niko Tyni wrote: > The test apache2 process is crashing with this backtrace: > Core was generated by `/usr/sbin/apache2 -X -f > /home/niko/tmp/libembperl-perl-2.5.0/test/conf/httpd.co'. Program > terminated with signal SIGSEGV, Segmentation fault. #0 > ap_mpm_pod_check (pod=0x0) at mpm_unix.c:459 > 459 mpm_unix.c: No such file or directory. > (gdb) bt > #0 ap_mpm_pod_check (pod=0x0) at mpm_unix.c:459 > #1 0x7f280ff3cb17 in child_main > (child_num_arg=child_num_arg@entry=0, > child_bucket=child_bucket@entry=0) at prefork.c:732 sounds like it should be fixed by this commit: https://svn.apache.org/viewvc?view=revision=r1711479 "Fix crash in ap_mpm_pod_check call caused by NULL dereference of its parameter when starting httpd as single process (httpd -X)." > This regressed with apache2 upgrade from 2.4.16-3 to 2.4.17-2, so > I'm cc'ing the apache2 maintainers in case they have ideas. The crash is easily reproduced on the command line with: apache2ctl stop apache2ctl -X # different shell curl http://localhost/
Bug#794933: apache2-suexec-custom: prompting due to modified conffiles which were not modified by the user: /etc/apache2/conf-available/security.conf
AFAICS, this happens when one upgrades from wheezy from a state where only apache2.2-common is installed but not apache2. There is a bug in apache2's preinst in jessie that makes it not recognize this case and not execute the conffile handling. While I think I have a fix, I am not not sure that I want to change the upgrade logic in a stable point release. FTR, attached is the diff I meant (redone from memory and not re-tested).diff --git a/debian/apache2.preinst b/debian/apache2.preinst index ed5a382..1adc647 100644 --- a/debian/apache2.preinst +++ b/debian/apache2.preinst @@ -49,8 +49,9 @@ obsolete_conffile_exists() fi done - for CONFFILE in $MOVED_CONFFILES_IN ; do - if [ -e /etc/apache2/conf.d/$CONFFILE ] ; then + for CONFFILE in $MOVED_CONFFILES ; do + CONFFILE=$( echo $CONFFILE | cut -d: -f1 ) + if [ -e $CONFFILE ] ; then return 0 fi done
Bug#794933: apache2-suexec-custom: prompting due to modified conffiles which were not modified by the user: /etc/apache2/conf-available/security.conf
On Saturday 08 August 2015 11:38:14, Andreas Beckmann wrote: during a test with piuparts I noticed your package failed the piuparts upgrade test because dpkg detected a conffile as being modified and then prompted the user for an action. As there is no user input, this fails. But this is not the real problem, the real problem is that this prompt shows up in the first place, as there was nobody modifying this conffile at all, the package has just been installed and upgraded... This was observed while doing a wheezy - jessie - stretch upgrade test. I did not see such behavior while testing the other apache packages. AFAICS, this happens when one upgrades from wheezy from a state where only apache2.2-common is installed but not apache2. There is a bug in apache2's preinst in jessie that makes it not recognize this case and not execute the conffile handling. While I think I have a fix, I am not not sure that I want to change the upgrade logic in a stable point release. I will have to think about it. If you are at debconf, maybe we can talk about it there. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789914: apache2: fails to install: ERROR: Module mpm_event is enabled - cannot proceed due to conflicts. It needs to be disabled first!
On Monday 20 July 2015 13:33:04, Jean-Michel Vourgère wrote: We want to backport that to jessie, don't we? I mean a minimal fix. Yes, we do. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789914: apache2: fails to install: ERROR: Module mpm_event is enabled - cannot proceed due to conflicts. It needs to be disabled first!
reassign 789914 apache2 found 789914 2.4.10-3 thanks This also affects jessie + stretch. On Thursday 25 June 2015 10:27:59, Andreas Beckmann wrote: Enabling conf serve-cgi-bin. Enabling site 000-default. info: mpm_prefork: No action required This is wrong. There seems to be a ! that does not belong there in the postinst at elif [ ! -e /etc/apache2/mods-enabled/$MPM.load ] ; then msg info $MPM: No action required -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666826: Will request removal of mod-auth-mysql soon
This module has been broken for 2 years. A replacement exists in the form of mod_auth[nz]_dbd in the apache2 package. We will request its removal very soon now. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755722: systemd must sync systemclock to RTC on shutdown
On Wednesday 04 February 2015 01:41:14, Michael Biebl wrote: Am 31.01.2015 um 10:19 schrieb Stefan Fritsch: severity 755722 serious retitle 755722 systemd must sync systemclock to RTC on shutdown thanks Systemd must make sure that the system clock does not go backwards, which causes all kinds of problems, with file systems and with other software. To achieve that, systemd has to sync the system time to RTC on shutdown. Upstream's argument that the system time may not be more accurate is completely unrelated to this issue. Upstream argues, that whoever changes the clock, should also make sure to sync that to the RTC if so desired. E.g. if you change the time using the builtin timedatectl command, it will make sure the RTC is synced. There is also natural drift between the system clock and the RTC. Who is supposed to account for that? On a system with an uptime of several months, the drift may be large enough to cause the time to go backwards at a reboot. NB: Upstream should try not to break existing software. The sysv init script compatibility is mostly moot if the init scripts need to be adjusted because of semantic changes. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767850: apache2: unhandled symlink to directory conversion: /usr/share/doc/apache2
Thanks for the report. The doc symlinks will be fixed in the next upload. But the errors about conf files seem to be false positives. The upgraded apache2.2-common package does not contain any of those files anymore. Therefore it is correct that they are missing. On Sunday 02 November 2014 23:55:11, Andreas Beckmann wrote: And there are more problems but I didn't have time to look at them in detail: 1m36.2s ERROR: FAIL: debsums reports modifications inside the chroot: debsums: missing file /etc/apache2/mods-available/imagemap.load (from apache2.2-common package) debsums: missing file /etc/apache2/mods-available/cern_meta.load (from apache2.2-common package) debsums: missing file /etc/apache2/mods-available/authz_default.load (from apache2.2-common package) debsums: missing file /etc/apache2/sites-available/default-ssl (from apache2.2-common package) debsums: missing file /etc/apache2/mods-available/disk_cache.load (from apache2.2-common package) debsums: missing file /etc/apache2/mods-available/disk_cache.conf (from apache2.2-common package) debsums: missing file /etc/apache2/conf.d/charset (from apache2.2-common package) debsums: missing file /etc/apache2/sites-available/default (from apache2.2-common package) debsums: missing file /etc/apache2/mods-available/authn_default.load (from apache2.2-common package) debsums: missing file /etc/bash_completion.d/apache2.2-common (from apache2.2-common package) debsums: missing file /etc/apache2/conf.d/security (from apache2.2-common package) debsums: missing file /etc/apache2/conf.d/other-vhosts-access-log (from apache2.2-common package) debsums: missing file /etc/apache2/mods-available/mem_cache.conf (from apache2.2-common package) debsums: missing file /etc/apache2/mods-available/authn_alias.load (from apache2.2-common package) debsums: missing file /etc/apache2/mods-available/mem_cache.load (from apache2.2-common package) debsums: missing file /etc/apache2/conf.d/localized-error-pages (from apache2.2-common package) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736809: apache2-bin needs proper Breaks: for Apache 2.4 transition
serverity 736809 important thanks On Wednesday 30 July 2014 23:22:25, Adrian Bunk wrote: I do not claim to fully understand the Debian apache packaging, and after a quick test it seems you are right that you already have that covered. I am downgrading this for now until it has been proven to be a real problem. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752872: libapr1: file locking is broken, leading to file corruption in e.g. libapache2-mod-auth-cas session files
severity 752872 important found 752872 1.4.6-3 thanks On Friday 27 June 2014 11:37:18, Joost van Baal-Ilić wrote: While libapr1 defaults to fcntl() locking it also supports flock(), which does not have the problems outlined above. A patch is attached which makes libapr1 use flock() even if fcntl() locking is available. flock does not support locking on NFS (at least according to its man page), while fcntl does. I am undecided which is worse. Since there does not seem to be a good solution, I am downgrading the severity of this bug. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751294: chromium: Does not display any web page or settings (Aw, Snap)
Package: chromium Version: 35.0.1916.153-1 Severity: grave Justification: renders package unusable Upgrading chromium chromium-inspector to 35.0.1916.153-1 makes it break completely for me. Every page (including the settings and the startup page) yields the above error message and some sub-process segfaults. Some stack trace is attached. Downgrading to 35.0.1916.114-2 from jessie fixes the problem. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.14-1-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 Versions of packages chromium depends on: ii chromium-inspector 35.0.1916.153-1 ii gconf-service3.2.6-2 ii libasound2 1.0.27.2-4 ii libc62.19-1 ii libcairo21.12.16-2 ii libcap2 1:2.22-1.2 ii libcups2 1.7.3-3 ii libdbus-1-3 1.8.4-1 ii libexpat12.1.0-6 ii libfontconfig1 2.11.0-5 ii libfreetype6 2.5.2-1 ii libgcc1 1:4.9.0-6 ii libgconf-2-4 3.2.6-2 ii libgcrypt11 1.5.3-4 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgnome-keyring03.8.0-2 ii libgtk2.0-0 2.24.23-1 ii libharfbuzz0b0.9.28-2 ii libjpeg8 8d-2 ii libnspr4 2:4.10.6-1 ii libnss3 2:3.16.1-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libspeechd2 0.8-6 ii libspeex11.2~rc1.1-1 ii libstdc++6 4.9.0-6 ii libudev1 204-10 ii libx11-6 2:1.6.2-2 ii libxcomposite1 1:0.4.4-1 ii libxcursor1 1:1.1.14-1 ii libxdamage1 1:1.1.4-1 ii libxext6 2:1.3.2-1 ii libxfixes3 1:5.0.1-1 ii libxi6 2:1.7.2-1 ii libxml2 2.9.1+dfsg1-3 ii libxrandr2 2:1.4.2-1 ii libxrender1 1:0.9.8-1 ii libxslt1.1 1.1.28-2 ii libxss1 1:1.2.2-1 ii libxtst6 2:1.2.2-1 ii xdg-utils1.1.0~rc1+git20111210-7.1 chromium recommends no packages. Versions of packages chromium suggests: pn chromium-l10n none pn mozplugger none -- no debconf information # Env: # LD_LIBRARY_PATH=/usr/lib/chromium:/usr/lib/xulrunner-1.9.1 # PATH=/usr/lib/chromium:/home/stf/bin:/home/stf/bin/:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games #GTK_PATH= # CHROMIUM_USER_FLAGS= # CHROMIUM_FLAGS=--password-store=detect /usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.MKCEVZ GNU gdb (Debian 7.7.1-1) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from /usr/lib/chromium/chromium...Reading symbols from /usr/lib/debug//usr/lib/chromium/chromium...done. done. (gdb) thr[K[K[Krun Starting program: /usr/lib/chromium/chromium --password-store=detect --single-process [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/i386-linux-gnu/i686/cmov/libthread_db.so.1. [New Thread 0xf3384b40 (LWP 29043)] [New Thread 0xf27cab40 (LWP 29044)] [New Thread 0xf1dffb40 (LWP 29045)] [New Thread 0xf1fc9b40 (LWP 29046)] [New Thread 0xf1fa8b40 (LWP 29047)] [New Thread 0xf11ffb40 (LWP 29048)] [New Thread 0xf0686b40 (LWP 29049)] [New Thread 0xf1f7db40 (LWP 29050)] [New Thread 0xeaedeb40 (LWP 29051)] [New Thread 0xea6ddb40 (LWP 29052)] [New Thread 0xe9cffb40 (LWP 29053)] [New Thread 0xe92ffb40 (LWP 29054)] [New Thread 0xe88ffb40 (LWP 29055)] [New Thread 0xe7effb40 (LWP 29056)] [New Thread 0xe74ffb40 (LWP 29057)] [New Thread 0xe6affb40 (LWP 29058)] [29030:29030:0611/212732:ERROR:component_loader.cc(138)] Failed to parse extension manifest. [29030:29056:0611/212732:ERROR:proxy_service_factory.cc(105)] Cannot use V8 Proxy resolver in single process mode. [29030:29056:0611/212732:ERROR:proxy_service_factory.cc(105)] Cannot use V8 Proxy resolver in single process mode. [New Thread 0xe62feb40 (LWP 29064)] [New Thread 0xe5afdb40 (LWP 29065)] [New Thread 0xe52fcb40 (LWP 29066)] [New Thread 0xe4afbb40 (LWP 29067)] [New Thread 0xe3effb40 (LWP 29068)] [New Thread 0xe33ffb40 (LWP 29069)] [New Thread 0xe2bfeb40 (LWP 29070)] Program
Bug#734865: libapache2-mpm-itk: fails to install
Hi Steinar, I have finally removed the obsolete conflict of the mpms with mpm_itk in 2.4.9-2. But in order for libapache2-mpm-itk to install cleanly, it seems you also have to add apache2_switch_mpm prefork to your postinst before you call enmod. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748369: apr-util: diff for NMU version 1.5.3-1.1
On Friday 16 May 2014 18:39:42, Hector Oron wrote: I've prepared an NMU for apr-util (versioned as 1.5.3-1.1) and did _not_ uploaded it. Please feel free to tell me if you want me to upload it. Thanks for the patch. If you feel that it's urgent, go ahead. Otherwise i will include it in the next upload. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711167: Bug#711213: libapache2-mod-perl2: occasional core dumps after the test suite
On Friday 14 June 2013, Niko Tyni wrote: On Sun, Jun 09, 2013 at 11:23:01PM +0300, Niko Tyni wrote: On Fri, Jun 07, 2013 at 02:23:43PM +0300, Niko Tyni wrote: I can reproduce the SIGSEGV at the end of the main test suite (#711213) on amd64. The armel problem might well be related, as the log ends at the same point. I'm somewhat further now: what happens is that register_auth_provider() in modperl_util.c calls apr_pool_pre_cleanup_register(pool, NULL, cleanup_perl_global_providers); once in the parent process, then another time in a child. For some reason that I do not understand yet, the cleanup_perl_global_providers() function resides at a different memory location (with a 0x2c000 offset or so) on the second time. The first location has at that point become an invalid memory address, resulting in a SIGSEGV when libapr calls the registered cleanup functions and jumps into the old location. Another progress report. I now mostly understand what's happening. Contrary to the above, all the interesting stuff happens inside the parent process. Cc'ing the apache2 maintainers; any ideas? See below. (The jump to an invalid address is crashing armel buildds so it's a rather big problem ATM. See #711167, where this has diverged.) First, apache2 main() calls read_config() (from main.c:624), which loads all the modules. Loading mod_perl installs the pre_cleanup hook cleanup_perl_global_providers() as above. Then, there's a loop starting at main.c:704 that has this comment: /* This is a hack until we finish the code so that it only reads * the config file once and just operates on the tree already in * memory. rbb */ and calls apr_pool_clear(pconf), which unloads the modules and should do all the cleanup AIUI. A bit later, at main.c:724, ap_read_config() is called again, and under some conditions (when stack limit is 'unlimited' and the number of modules is suitable?), mod_perl gets loaded at a different place than the first time. However, the earlier installed pre_cleanup hook is still in place, so we jump into an out-of-bounds location (where cleanup_perl_global_providers() used to reside) in the end when the cleanups are actually called. The problem is that MP_CMD_SRV_DECLARE2(authz_provider) and MP_CMD_SRV_DECLARE2(authn_provider) register the cleanup against parms-server-process-pool which lives longer than the pconf pool and therefore the load time of the mod-perl shared object. It should probably use parms-pool (which is pconf) instead. In general, everything mod_perl does should be undone by the clearing/destruction of pconf, because the the .so will be unloaded after that. server-process-pool can be used to store things that need to be preserved beyond the unloading/loading of the .so, however there is now also a higher level api for that (ap_retained_data_create). Registering a cleanup with server-process- pool is always bad from a module because the code may move. Now, if there is a good reason that the above functions use server- process-pool, we need to figure out a way to fix that. But the original commit of that code has no comment with respect to the pool requirement. Therefore I think it may be simply a bug and you should test it with a cleanup against pconf, first. So I suppose mod_perl should somehow register a module uninstall hook that calls apr_pool_cleanup_run(..., cleanup_perl_global_providers, ...) [or apr_pool_cleanup_kill(), not sure] to remove the to-be-unloaded pre_cleanup hook. I haven't found a way to do that yet. If you register a pool cleanup with pconf, it will be called before the .so is unloaded. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703313: nvidia-kernel-dkms: Upgrade breaks VT text consoles
Package: nvidia-kernel-dkms Version: 304.84-1 Severity: grave Upgrading the nvidia packages from 304.64-4 to 304.84-1 breaks text consoles for me. If I switch VT with ctrl-alt-Fx, the display switches itself off (switching back to the X session works, though). The same happens after the xserver is shut down, i.e. I can't see the system's messages on the console when I shut down the computer. Downgrading the following packages to 304.64-4 fixes the problem: libgl1-nvidia-alternatives libglx-nvidia-alternatives libgl1-nvidia-glx libxvmcnvidia1 nvidia-alternative nvidia-glx nvidia-kernel-dkms nvidia-kernel-source nvidia-settings nvidia-vdpau-driver xserver-xorg-video-nvidia As I have already seen the unblock request, I have filed this at severity grave to avoid testing migration without loo. But I leave it up to the maintainers to decide which bug is less severe, this one or the ones fixed by 304.84-1. -- Package-specific info: uname -a: Linux k 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux /proc/version: Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-15) ) #1 SMP Debian 3.2.39-2 /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 304.84 Wed Feb 27 04:58:49 PST 2013 GCC version: gcc version 4.6.3 (Debian 4.6.3-15) lspci 'VGA compatible controller [0300]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller]) Subsystem: CardExpert Technology Device [10b0:1401] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at f900 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at d000 (64-bit, prefetchable) [size=256M] Region 3: Memory at ee00 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at cf00 [size=128] [virtual] Expansion ROM at e000 [disabled] [size=512K] Capabilities: access denied Kernel driver in use: nvidia dmesg: [0.00] No AGP bridge found [0.00] No AGP bridge found [0.00] Console: colour VGA+ 80x25 [0.976914] vgaarb: device added: PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none [0.976982] vgaarb: loaded [0.977028] vgaarb: bridge control possible :01:00.0 [1.468962] Linux agpgart interface v0.103 [6.131203] nvidia: module license 'NVIDIA' taints kernel. [7.173447] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input8 [7.173792] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input9 [7.174125] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input10 [7.174487] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:03.0/:01:00.1/sound/card1/input11 [7.176581] nvidia :01:00.0: setting latency timer to 64 [7.176589] vgaarb: device changed decodes: PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem [7.176866] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 304.84 Wed Feb 27 04:58:49 PST 2013 OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Dec 21 17:35 /etc/alternatives/glx - /usr/lib/nvidia lrwxrwxrwx 1 root root 46 Jul 20 2011 /etc/alternatives/glx--libGL.so-i386-linux-gnu - /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so lrwxrwxrwx 1 root root 46 Jul 20 2011 /etc/alternatives/glx--libGL.so-i386-linux-gnu - /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so lrwxrwxrwx 1 root root 41 Dec 21 17:35 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 41 Dec 21 17:35 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 49 Dec 21 17:35 /etc/alternatives/glx--libXvMCNVIDIA.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libXvMCNVIDIA.so.1 lrwxrwxrwx 1 root root 57 Dec 21 17:35 /etc/alternatives/glx--libXvMCNVIDIA_dynamic.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libXvMCNVIDIA_dynamic.so.1 lrwxrwxrwx 1 root root 49 Dec 21 17:35 /etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 25 Dec 21 17:35 /etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 36 Dec 21 17:35 /etc/alternatives/glx--nvidia-bug-report.sh - /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 29 Dec 21 17:35 /etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 22 Jul 20 2011
Bug#702475: apache2: the itk MPM is underlinked: sys/capability.h symbols are not resolved
On Saturday 09 March 2013, Steinar H. Gunderson wrote: However, my long-term plan is definitely to build mpm-itk out-of-tree and a separate source package; if the Debian Apache maintainers want to include the patches needed, I think this would make the lives easier for all of us :-) Yes. Until then, adding LoadFile libcap.so to mpm-itk.load could be a workaround. Anyone has time to test this? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697465: apache2.2-common: initial install fails: Could not read /etc/apache2/envvars
severity 697465 normal thanks On Tue, 8 Jan 2013, Jonas Smedegaard wrote: I think you are right that what I experience might be unrelated to apache packaging - I suspect however that it is not multistrap but fakechroot. I will reassing accordingly. I am downgrading this until then. No idea what severity this should have in Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697465: apache2.2-common: initial install fails: Could not read /etc/apache2/envvars
On Mon, 7 Jan 2013, Jonas Smedegaard wrote: Quoting Jean-Michel Vourgère (2013-01-07 16:58:08) On Sunday 06 January 2013 11:29:55 Arno Töll wrote: (...) Seems that error comes from a2ensite call, so I suspect the cause might be some dependency of that script has not yet been configured. a2ensite does not call a shell to read /etc/apache2/envvars. Your output makes me suspect this is rather coming from the init script which is invoked from postinst. What makes you think a2ensite is the problem? Arno: a2ensite reads /etc/apache2/envvars in function read_env_file on line 331: env - sh -c '. /etc/apache2/envvars env' Thanks, Jean-Michel. Sorry if I was unclear earlier: I am talking about postinst too: postinst calls a2ensite calls perl loads modules. Since those modules are not yet configured, postinst fails. Are you sure? Perl modules usually don't need the package to be configured in order to be usable. An exception may be if ld.config needs to be called. And even so, according to policy 7.2, the dependencies *will* be configured when postinst is run: In the case of `postinst configure', the depended-on packages will be unpacked and configured first. (If both packages are involved in a dependency loop, this might not work as expected; see the explanation a few paragraphs back.) Clearly perl-modules is not in a dependency loop with apache2.2-common. Perl-modules is priority standard, apache2.2-common is optional. Package needs to pre-depend on perl, not just depend on it. Below test indicates that this bug is independent from that lack of predependency on perl - so do you guys want me to file a separate bug about the perl predependency? If you still think there is a bug, yes please. But include the exact error message. Jonas: What does the command line above yield? What is the result code ? ($?) What shell do you use? dash? (ls -l /bin/sh) Can you send us your envvars file? As I wrote before, it occurs using multistrap. Multistrap is like debootstrap but postpones all postinst calls till later. Therefore envvars file is the file shipped with the package itself. /etc/apache2/envvars is included in apache2.2-common. Therefore apache2.2-common may assume that it is present in postinst. + env - sh -c '. /etc/apache2/envvars env' sh: 1: .: Can't open /etc/apache2/envvars + echo 2 2 + ls -l /bin/sh lrwxrwxrwx 1 root root 4 Jan 7 18:53 /bin/sh - bash + cat /etc/apache2/envvars # envvars - default environment variables for apache2ctl This is rather weird. The shell can't source the file but immediately afterwards the cat succeeds. Does multistrap do things in parallel? Or do you do this on NFS or some other strange file system? Maybe you should run strace -f -tt on the whole multistrap process to see what is happening with respect to /etc/apache2/envvars. Another possible issue I could imagine (but your log does not really look like it): If removed apache2.2-common in your chroot without purging it, and then deleted /etc/apache2/* by hand. In this case dpkg will not re-create /etc/apache2/envvars during the next installation because it is a conffile.
Bug#694473: apache2: segmentation fault after reload, maybe PHP
This seems to be related, but it does not have a definite fix, either: https://bugs.php.net/bug.php?id=62129 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670945: Re: About the media types text/x-php and text/x-php-source
* The fix for second bug #670945 (e.g. http://localhost/file not caught by mod_negotiation) was fixed in mime-support 3.52-1.1. The two bug reporters, the apache maintainer and me are all saying that this bug should be fixed in apache or PHP, not in mime-support. As pointed out elsewhere, that was a different bug. And I was not aware of this bug at that time. It does not matter which other unregistered types are currently distributed in /etc/mime.types. If you want all the Debian systems to have this media type by default, it is better to justify it by the needs of more than one package. It's completely sensible for webservers that do not interpret php scripts themselves, to serve *.php files as application/x-php or text/x-php. At least it is more consistent with the handling of python, perl, etc. But if you don't want to do that, e.g. because you intend to remove the perl/java/... types, too, adding them to Apache's config is IMHO completely acceptable, too. The mod_negotiation problem is after all an Apache only problem. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: Possible release note for systems running PHP through CGI.
On Monday 20 August 2012, Ondřej Surý wrote: Ah, I see; it gets executed when there is no know handler or mime-type for second extension. E.g. index.php.jpeg works as expected (e.g. returning PHP source code), index.php.blubb but gets executed. I don't think there's any harm in disabling php.foobar and php.blubb files. There is also the case that the extensions after .php are known to Apache but are not associated with mime types or handlers. For example, there are extensions like .de and .en which cause the Content-Language header to be set, extensions for setting the charset (e.g. .utf8) and extensions for setting the content-encoding (none configured by default). I don't know how often this is actually used together with php. Setting the Content-* headers in the php script seems saner to me. Good to see that we are heading towards a solution anyway. What shall I do with #674089 ? I can reassign it to php5-cgi so that your next upload closes it, or do we still need release notes ? I think we still might need release notes, but it needs to be updated based on final impact of changes we have done. I am not sure if the information about filename.php.unknown-mime-type is worth release notes or just NEWS file in PHP. My guess would be latter, but opinions may vary. Maybe add just a small paragraph that the configuration of the extensions has changed and php users should read the NEWS file? Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684824: apr: FTBFS: rm: cannot remove `libtoolT': No such file or directory
Hi Lucas, On Tuesday 14 August 2012, Lucas Nussbaum wrote: WARNING: This is Linux but configure did not detect POSIX semaphores. ERROR: POSIX semaphores not usable and /dev/shm not mounted. ERROR: Aborting. HINT: If you are using pbuilder or cowbuilder, add /dev/shm to BINDMOUNTS HINT: in pbuilderrc Please verify that your build setup has /dev/shm correctly mounted as tmpfs. if [ = ] ;\ Strangely, stat -c %d /dev/shm returns an empty string on your system. The check in the apr rules file may be broken now that /dev/shm is a symbolic link, but the check only triggers if posix semaphores are not usable, which points to a problem in your build setup. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670945: libapache2-mod-php5: Bug #589384 breaks default behaviour for MultiViews
FWIW, this bug has been open for 4 months. It would have been nice if you (or the php maintainers) could have sent a note to debian- apache@l.d.o a bit earlier. If mod_negotiation requires some mime-type for .php to work, then the obvious solution would be to add a non-magic type, for example application/x-php. IMHO, in order to have the whole php config in one place, this should be done with AddType in /etc/apache2/mods-available/php5.conf. Maybe like this: # mod_negotiation's MultiViews needs php scripts to have a mime # type to make negotiation work. These types are added for this # purpose, but differently from the magic application/x-httpd-* types, # they do not cause php scripts to be executed. That is done by the # SetHandler directives above. AddType application/x-php php phtml php3 AddType application/x-php-source phps -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
Thanks for coming up with some wording. On Wednesday 15 August 2012, Ondřej Surý wrote: In order to avoid any problems when not using Apache PHP5 module, and if you relied on MIME type definitions, read the README.Debian from the php5-common package on how to correctly configure PHP 5 running as a CGI or FastCGI (examples are provided for the Apache HTTPD Server) and take care, that and PHP files intended to be interpreted are recognised as such (typically by adding MIME-Type or handler definitions in the webserver configuration). Since we have gone to great pains to not use the magic MIME types anymore, I think we should not recommend them here. Or at least not as the first option. Also, there is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670945 to take into account. Is the wording still ok if the solution I suggested is implemented? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
On Wednesday 15 August 2012, Christoph Anton Mitterer wrote: On Wed, 2012-08-15 at 21:07 +0200, Stefan Fritsch wrote: Since we have gone to great pains to not use the magic MIME types anymore, I think we should not recommend them here. Or at least not as the first option. Stefan, can you please elaborate on what you mean with magic MIME types? (you're talking about MIME type discovery via libmagic or similar? That would be not what's suggested above!) The mime types that are also handler names and cause mod_php to execute scripts, i.e. application/x-httpd-php and application/x-httpd- php-source. Using these as mime types is dangerous because they may also cause things named like foo.php.bar to be executed. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682401: dbmmanage: please use Digest::SHA instead of Digest::SHA1
On Sunday 22 July 2012, Arno Töll wrote: Evidently not too many people are using dbmmanage, even less with SHA1 encryption since it is not the default option but nobody noticed so far. Nonetheless the removal of Digest::SHA1 breaks the application in a fatal way when SHA-1 encryption is explicitly desired. Thus, I am raising the bug severity to serious and I will prepare a patch. AFAICS, dbmmanage has not seen a single code commit upstream since the C variant, htdbm, has been introduced in 2001. Maybe we should get rid of dbmmanage in the 2.4 packages. But unbreaking it for wheezy by using Digest::SHA instead of Digest::SHA1 is still a good idea. Having that said, the root issue is upstream and they probably still plan to support older Perl versions as well. Thus, simply replacing the modules used will not suffice, but that does not sound like a big problem either as a simple Perl version dependent branch will do it. Stefan, shouldn't apache2-utils recommend the required perl libraries as well, instead of letting dbmmanage suggest the use of CPAN (e.g. for SHA1 in the past, or still in use for MD5)? Digest::MD5 seems to be part of the perl package in wheezy, too. No recommends needed. And I wouldn't change dependencies for squeeze unless some user actually complains. And even then, a suggests may be more appropriate in the case of Digest::SHA1, because the sha1 password hashing variant supported in apache is very insecure (no salt). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668663: backtrace
a backtrace is attached
Starting program: /usr/bin/gtimer
[Thread debugging using libthread_db enabled]
Using host libthread_db library
/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1.
** Message: Building menu Failed: (null)
(gtimer:5748): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT
(object)' failed
Program received signal SIGSEGV, Segmentation fault.
0xf7ad80f3 in gdk_x11_gc_values_to_xvalues (values=0xbbb8,
mask=GDK_GC_CLIP_MASK, xvalues=0xbaf0,
xvalues_mask=0xbb4c)
at
/build/buildd-gtk+2.0_2.24.10-1-i386-kBWRW9/gtk+2.0-2.24.10/gdk/x11/gdkgc-x11.c:511
511
/build/buildd-gtk+2.0_2.24.10-1-i386-kBWRW9/gtk+2.0-2.24.10/gdk/x11/gdkgc-x11.c:
Datei oder Verzeichnis nicht gefunden.
(gdb) bt full
#0 0xf7ad80f3 in gdk_x11_gc_values_to_xvalues (values=0xbbb8,
mask=GDK_GC_CLIP_MASK,
xvalues=0xbaf0, xvalues_mask=0xbb4c)
at
/build/buildd-gtk+2.0_2.24.10-1-i386-kBWRW9/gtk+2.0-2.24.10/gdk/x11/gdkgc-x11.c:511
No locals.
#1 0xf7ad8520 in gdk_x11_gc_values_to_xvalues (xvalues_mask=0xbb4c,
xvalues=0xbaf0,
mask=optimized out, values=0xbbb8)
at
/build/buildd-gtk+2.0_2.24.10-1-i386-kBWRW9/gtk+2.0-2.24.10/gdk/x11/gdkgc-x11.c:398
No locals.
#2 gdk_x11_gc_set_values (gc=0x80d7420, values=0xbbb8,
values_mask=optimized out)
at
/build/buildd-gtk+2.0_2.24.10-1-i386-kBWRW9/gtk+2.0-2.24.10/gdk/x11/gdkgc-x11.c:370
x11_gc = 0x80d7420
xvalues = {function = 134738000, plane_mask = 4294949816, foreground =
135099472,
background = 4149461187, line_width = -144486965, line_style = 8,
cap_style = -145224606,
join_style = -17620, fill_style = 1, fill_rule = -144706964, arc_mode
= -144805900,
tile = 4149461261, stipple = 4150480331, ts_x_origin = 8, ts_y_origin
= -145224606,
font = 4150494238, subwindow_mode = -144478032, graphics_exposures =
-134268480,
clip_x_origin = 20, clip_y_origin = -145506096, clip_mask =
4150480331,
dash_offset = -143530560, dashes = -12 '\364'}
xvalues_mask = 0
#3 0xf7a9d11e in IA__gdk_gc_set_values (gc=0x80d7420, values=0xbbb8,
values_mask=GDK_GC_CLIP_MASK)
at
/build/buildd-gtk+2.0_2.24.10-1-i386-kBWRW9/gtk+2.0-2.24.10/gdk/gdkgc.c:372
priv = 0x80d7450
__PRETTY_FUNCTION__ = IA__gdk_gc_set_values
#4 0xf7a9d1e3 in IA__gdk_gc_set_clip_mask (gc=0x80d7420, mask=0x807f050)
at
/build/buildd-gtk+2.0_2.24.10-1-i386-kBWRW9/gtk+2.0-2.24.10/gdk/gdkgc.c:632
values = {foreground = {pixel = 4160737268, red = 61384, green = 63413,
blue = 1}, background = {
pixel = 4294949888, red = 56342, green = 63486, blue = 440}, font =
0x0,
function = GDK_INVERT, fill = GDK_TILED, tile = 0x0, stipple = 0x1,
clip_mask = 0x807f050,
subwindow_mode = 4657816, ts_x_origin = -139276288, ts_y_origin =
-139968900,
clip_x_origin = -134624784, clip_y_origin = 135156752,
graphics_exposures = 6, line_width = 6,
line_style = 4160698816, cap_style = 1919, join_style = 4155101520}
#5 0xf7e0eda3 in gtk_pixmap_expose (widget=0x80e5410, event=optimized out)
at
/build/buildd-gtk+2.0_2.24.10-1-i386-kBWRW9/gtk+2.0-2.24.10/gtk/gtkpixmap.c:201
misc = 0x80e5410
y = 6
pixmap = 0x80e5410
x = 6
xalign = optimized out
#6 gtk_pixmap_expose (widget=0x80e5410, event=0x80a91f8)
at
/build/buildd-gtk+2.0_2.24.10-1-i386-kBWRW9/gtk+2.0-2.24.10/gtk/gtkpixmap.c:173
No locals.
#7 0xf7c6f662 in _gtk_marshal_BOOLEAN__BOXED (closure=0x80c1a20,
return_value=0xbe20,
n_param_values=2, param_values=0xbe90, invocation_hint=0xbe3c,
marshal_data=0xf7e0ec40)
at
/build/buildd-gtk+2.0_2.24.10-1-i386-kBWRW9/gtk+2.0-2.24.10/gtk/gtkmarshalers.c:86
callback = 0xf7e0ec40 gtk_pixmap_expose
cc = 0x80c1a20
data1 = optimized out
data2 = optimized out
v_return = optimized out
__PRETTY_FUNCTION__ = _gtk_marshal_BOOLEAN__BOXED
#8 0xf7607ced in g_type_class_meta_marshal (closure=closure@entry=0x80c1a20,
return_value=return_value@entry=0xbe20,
n_param_values=n_param_values@entry=2,
param_values=param_values@entry=0xbe90,
invocation_hint=invocation_hint@entry=0xbe3c,
marshal_data=marshal_data@entry=0xc8)
at
/build/buildd-glib2.0_2.32.3-1-i386-987P8N/glib2.0-2.32.3/./gobject/gclosure.c:970
class = optimized out
callback = optimized out
offset = 200
#9 0xf7608da2 in g_closure_invoke (closure=closure@entry=0x80c1a20,
return_value=return_value@entry=0xbe20, n_param_values=2,
param_values=param_values@entry=0xbe90,
invocation_hint=invocation_hint@entry=0xbe3c)
at
/build/buildd-glib2.0_2.32.3-1-i386-987P8N/glib2.0-2.32.3/./gobject/gclosure.c:777
marshal = 0xf7607c90 g_type_class_meta_marshal
marshal_data = 0xc8
in_marshal = 1
real_closure = 0x80c1a10
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
On Friday 01 June 2012, Christoph Anton Mitterer wrote: Release notes is a good idea, Stefan, Brian... can anyone of you take care of this or should I (but I'm on vacation starting next Tue, so that would take some time). There is still plenty of time. If you get to it first please cc: debian-apa...@lists.debian.org so that we may comment on the wording. either apache2 or mod_php NEWS file. It seems exessive to have it in the mime-support NEWS file since it is just noise to all non-apache2 users. I'm not sure whether I can agree... At least mod_php is not enough,... people seem to always forget that it's totally ok (and IMHO from a security point of view even much better) to run PHP as CGI. OK, make that mod_php and php-cgi. AFAICS the type is not relevant for FCGI. Neither am I sure, whether Apache is enough, there may be other webservers in Debian that could use mime.types (though I haven't checked this). I haven't found any hint that that type is relevant for either lighttpd or nginx. And the change has been quite some time ago and nobody has complained so far. see below. Stefan, you haven't commented on this... I've already opened #674205, where I ask the php people to include what I'd consider the safest/best way to handle PHP mime-type in Apache. Except for the RemoveType php your suggestion is not very different from what is in mod_php's config already. And I disagree about mime- type versus handler: This is exactly what handlers are for. The fact that mime-types also work is only for backward compatibility. IF mime.types will really ship no further definitions for PHP AND if that change is accordingly documented in release-notes/NEWS file(s) than I think there should be no definitions for PHP in Apache's default configs at all. Hu? Apache's default config has only minimal php relevant elements (SSLOptions +StdEnvVars, DirectoryIndex index.php). But mod_php should certainly include everything in it config that is necessary to make it work. But we should perhaps check (how?) whether any other packages have started to use that mime type (things like nautilus/file/etc.) I can see no reason that other apps may handle it specially and none has complained so far. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
On Thursday 31 May 2012, Christoph Anton Mitterer wrote: So from my side I'd say the following: 1) IF a change like this happens,.. it definitely must go to the NEWS file, as - in the case of Apache HTTPD Server - it can even have security relevant outcomes. So Brian, as long as this change stays, could you please add such information? Documenting this in a prominent place is a good idea. I would vote for the release notes plus either apache2 or mod_php NEWS file. It seems exessive to have it in the mime-support NEWS file since it is just noise to all non-apache2 users. 2) I Agree with Thijs (IIRC it was him) comment, that there are security implications in apache, i.e. that the mime.types file _alone_ would also have files like foo.php.jpeg marked as application/x-httpd-php and therefore possibly interpreted as PHP code (which is well known, but stupid and dangerous anyway. But that's easy to solve, see below. 3) Given that mime.types may be used by many programs, which may want to know about PHP files as well... it's a bad idea to fix Apache HTTPD's stupidity (well at least difficult extension handling) by removing types from mime.types. The x-httpd- types are really historic ballast from the time there was no separate way to configure the handler (Apache 1.3.x or even 1.2.x). Because of their special properties, they are called magic MIME types in apache httpd. Therefore I think they should be considered an internal (and deprecated) implementation detail of apache httpd and should not be used as real MIME types anywhere else. As #589384 explained, declaring them globally is bad for security. And it would be really strange to set these magic types globally just to remove them with RemoveType php again in the default apache2 configuration. But adding a different type for .php to /etc/mime.types is fine with me. There is some discussion at http://cweiske.de/tagebuch/php- mimetype.htm which type may be best. Both text/x-php and application/x-php seem ok to me. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666828: Apache2 2.4 transition postponed until after Wheezy
Hi, we have decided to postpone the transition to apache2 2.4. The main blocker is that mod_perl needs a major new upstream release which very likely won't be ready in time for Wheezy and we don't want to release Wheezy without mod_perl. The transition will probably happen shortly after the release of Wheezy. We are sorry for any inconvenience this may have caused. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666865: bug mail bounces
Hi, I think the problem is that you can't match on the Sender or From headers, because those remain unmodified for BTS mail. But BTS mail seems to have X-Loop: ow...@bugs.debian.org and X-Debian-PR-Source: name-of-source-package Maybe you can match on either of those. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670633: Bug#670572: [xml/sgml-pkgs] Bug#670572: libxml2: missing link from /usr/lib
On Monday 30 April 2012, Stefan Fritsch wrote:
On Sun, 29 Apr 2012, Julien Cristau wrote:
On Sun, Apr 29, 2012 at 13:10:05 +0200, Stefan Fritsch wrote:
LoadFile /usr/lib/${DEB_HOST_MULTIARCH}/libxml2.so.2. This
would break with non-multiarch versions of libxml2, but that's
acceptable.
A simple LoadFile libxml2.so.2 doesn't work? Or any other way
to make it obey the normal dlopen search path?
Unfortunately, Apache treats all non-absolute pathnames as relative
to the server root directory. It will never pass a non-absoulute
path to dlopen(). But we could change it to only do this if the
relative pathname contains at least one slash.
Implemented that slightly differently: If the lib is not found in the
server-root and the pathname has no slash, re-try with dlopen-search
path. I have just uploaded apache 2.2.22-5. With it, a simple
LoadFile libxml2.so.2 should do the trick. I think this is now the
preferred solution.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670633: Bug#670572: [xml/sgml-pkgs] Bug#670572: libxml2: missing link from /usr/lib
On Sun, 29 Apr 2012, Julien Cristau wrote:
On Sun, Apr 29, 2012 at 13:10:05 +0200, Stefan Fritsch wrote:
LoadFile /usr/lib/${DEB_HOST_MULTIARCH}/libxml2.so.2. This would
break with non-multiarch versions of libxml2, but that's acceptable.
A simple LoadFile libxml2.so.2 doesn't work? Or any other way to make
it obey the normal dlopen search path?
Unfortunately, Apache treats all non-absolute pathnames as relative to the
server root directory. It will never pass a non-absoulute path to
dlopen(). But we could change it to only do this if the relative pathname
contains at least one slash.
I will ask the other upstream developers what they think of such a change.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670633: [xml/sgml-pkgs] Bug#670572: libxml2: missing link from /usr/lib
On Friday 27 April 2012, Aron Xu wrote:
clone 670572 -1
retitle -1 not usable because libxml2.so.* are moved to Multi-Arch
path severity -1 serious
reassign -1 src:mod-proxy-html
block 670572 by -1
thanks
On Thu, Apr 26, 2012 at 21:39, Francesco Potortì
poto...@isti.cnr.it wrote:
Package: libxml2
Version: 2.7.8.dfsg-9
Severity: normal
In order to have Apache module proxy_html work, I had to do
# ln -s /usr/lib/x86_64-linux-gnu/libxml2.so.2
/usr/lib/libxml2.so.2
Cloned the bug and reassigned to mod-proxy-html and CC'ed Apache
maintainers to the thread. I'm wondering if this is a single case
of problem in mod-proxy-html or a more general one for other
Apache modules.
This may hit more modules. Ubuntu has a similar bug report for
mod_security (LP 988819).
I'm not convinced to add such a link, as it could be harmful for
other applications when you have more than one architectures
installed.
I agree, such a link should be avoided.
I see two possible solutions:
- Make the result of dpkg-architecture -qDEB_HOST_MULTIARCH
available as envvar, so that modules can use it in their config. E.g.
LoadFile /usr/lib/${DEB_HOST_MULTIARCH}/libxml2.so.2. This would
break with non-multiarch versions of libxml2, but that's acceptable.
- Make the module actually link against the libraries that it uses.
This can cause havoc if different versions of the same library are
pulled, but I think this should normally not happen in Debian. FWIW,
this is the approach taken with the mod_proxy_html included in apache2
2.4.
I prefer the second option but if some module maintainers want to use
the first option, that's ok with me, too.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624148: Please fix this bug in stable
tags squeeze thanks There was a similar issue with the recent apache2 DSA and I expect that it is the same bug. I have unattended-upgrades 0.62.2 installed. Please fix this in the next stable point release. Cheers, Stefan Unattended upgrade returned: False Packages that are upgraded: apache2-dbg apache2-mpm-prefork apache2-prefork-dev apache2-utils apache2.2-bin apache2.2-common Packages with upgradable origin but kept back: apache2 Package installation log: nothing to commit (working directory clean) git-snapshot-script: nothing to be done (Reading database ... 61258 files and directories currently installed.) Preparing to replace apache2-prefork-dev 2.2.16-6+squeeze6 (using .../apache2-prefork-dev_2.2.16-6+squeeze7_amd64.deb) ... Unpacking replacement apache2-prefork-dev ... Preparing to replace apache2-dbg 2.2.16-6+squeeze6 (using .../apache2- dbg_2.2.16-6+squeeze7_amd64.deb) ... Unpacking replacement apache2-dbg ... Preparing to replace apache2 2.2.16-6+squeeze6 (using .../apache2_2.2.16-6+squeeze7_amd64.deb) ... Unpacking replacement apache2 ... Preparing to replace apache2-mpm-prefork 2.2.16-6+squeeze6 (using .../apache2-mpm-prefork_2.2.16-6+squeeze7_amd64.deb) ... Stopping web server: apache2 ... waiting . Unpacking replacement apache2-mpm-prefork ... Preparing to replace apache2.2-common 2.2.16-6+squeeze6 (using .../apache2.2-common_2.2.16-6+squeeze7_amd64.deb) ... Unpacking replacement apache2.2-common ... Preparing to replace apache2.2-bin 2.2.16-6+squeeze6 (using .../apache2.2-bin_2.2.16-6+squeeze7_amd64.deb) ... Unpacking replacement apache2.2-bin ... Preparing to replace apache2-utils 2.2.16-6+squeeze6 (using .../apache2-utils_2.2.16-6+squeeze7_amd64.deb) ... Unpacking replacement apache2-utils ... Processing triggers for man-db ... Setting up apache2.2-bin (2.2.16-6+squeeze7) ... Setting up apache2-utils (2.2.16-6+squeeze7) ... Setting up apache2.2-common (2.2.16-6+squeeze7) ... Configuration file `/etc/apache2/sites-available/default-ssl' == Modified (by you or by a script) since installation. == Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** default-ssl (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing apache2.2-common (--configure): EOF on stdin at conffile prompt dpkg: dependency problems prevent configuration of apache2-prefork- dev: apache2-prefork-dev depends on apache2.2-common (= 2.2.16-6+squeeze7); however: Package apache2.2-common is not configured yet. dpkg: error processing apache2-prefork-dev (--configure): dependency problems - leaving unconfigured Setting up apache2-dbg (2.2.16-6+squeeze7) ... configured to not write apport reports dpkg: dependency problems prevent configuration of apache2-mpm- prefork: apache2-mpm-prefork depends on apache2.2-common (= 2.2.16-6+squeeze7); however: Package apache2.2-common is not configured yet. dpkg: error processing apache2-mpm-prefork (--configure): dependency problems - leaving unconfigured configured to not write apport reports dpkg: error processing apache2 (--configure): dependency problems - leaving unconfigured configured to not write apport reports Errors were encountered while processing: apache2.2-common apache2-prefork-dev apache2-mpm-prefork apache2 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663723: Critical memory leak with mod_rewrite in apache2 using german umlauts
severity 663723 wishlist tags 663723 -security retitle 663723 apache2 does not prevent DoS through .htaccess files thanks On Tuesday 13 March 2012, Patrick Matthäi wrote: I noticed on a customers server, that apache periodical crashes the whole system by using the whole available memory until it swaps away. RewriteEngine on RewriteBase / RewriteRule ^(.*)\xC3\x84(.*)$ $1Ä$2 [N,E=utf8_fixed:1] The problem is not the special character but that this regular expression has quadratic complexity in the string length. Using (.*?) instead of (.*) everywhere will likely fix it. This is a general problem when using regular expressions. And being allowed to use .htaccess means having access to regular expressions. Now the server runs out of memory very fast! This is especialy a big problem for shared hosters with mod_rewrite enabled (most vhosts require them today) where users could put their own .htaccess to the documentroot While I don't deny that this is a problem for some use cases, it is a fact that the .htaccess mechanism has not been designed with limiting local DoS attacks in mind. There are many ways to cause a DoS with crafted .htaccess files. Some of these cannot be fixed without breaking compatibility, i.e. not within 2.2.x or 2.4.x. Therefore, picking out a few of these issues and fixing them in Debian does not make any sense. If you use prefork, you can work around this by adding suitable ulimit calls in /etc/apache2/envvars. Upstream does not consider these issues security relevant, either: http://mail-archives.apache.org/mod_mbox/httpd- dev/20.mbox/%3c4ec6de56.9020...@rowe-clan.net%3E -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663528: libkio5: kmail crashes since upgrade to KDE 4.7.4
Package: libkio5 Version: 4:4.7.4-3 Severity: grave Justification: renders package unusable Since upgrading the kde libraries to version 4.7.4, kmail crashes on start before displaying any window. The crash happens in libkio5, therefore I file the bug against this package. Feel free to re-assign. The crash handler says: Application: KMail (kmail), signal: Segmentation fault Using host libthread_db library /lib/i386-linux-gnu/i686/cmov/libthread_db.so.1. [KCrash Handler] #7 detach (this=0xa448f38) at /usr/include/qt4/QtCore/qhash.h:299 #8 operator[] (akey=..., this=0xa448f38) at /usr/include/qt4/QtCore/qhash.h:738 #9 KIO::ProtoQueue::removeJob (this=0xa448ee8, job=0x0) at ../../kio/kio/scheduler.cpp:483 #10 0x in ?? () -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages libkio5 depends on: ii libacl1 2.2.51-5 ii libattr11:2.4.46-5 ii libc6 2.13-27 ii libgcc1 1:4.6.3-1 ii libkdecore5 4:4.7.4-3 ii libkdeui5 4:4.7.4-3 ii libnepomuk4 4:4.7.4-3 ii libqt4-dbus 4:4.7.4-2 ii libqt4-network 4:4.7.4-2 ii libqt4-svg 4:4.7.4-2 ii libqt4-xml 4:4.7.4-2 ii libqtcore4 4:4.7.4-2 ii libqtgui4 4:4.7.4-2 ii libsolid4 4:4.7.4-3 ii libstdc++6 4.6.3-1 ii libstreamanalyzer0 0.7.7-1.1 ii libx11-62:1.4.4-4 ii libxrender1 1:0.9.6-2 Versions of packages libkio5 recommends: ii kdelibs5-plugins 4:4.7.4-3 libkio5 suggests no packages. -- no debconf information Here is the reportbug info for kmail: Package: kmail Version: 4:4.4.11.1+l10n-1 Versions of packages kmail depends on: ii kdebase-runtime 4:4.7.4-2 ii kdepim-runtime 4:4.4.11.1-3 ii kdepimlibs-kio-plugins 4:4.7.4-2 ii libakonadi-contact4 4:4.7.4-2 ii libakonadi-kde4 4:4.7.4-2 ii libc6 2.13-27 ii libgcc1 1:4.6.3-1 ii libgpgme++2 4:4.7.4-2 ii libkabc44:4.7.4-2 ii libkcal44:4.7.4-2 ii libkcmutils44:4.7.4-3 ii libkde3support4 4:4.7.4-3 ii libkdecore5 4:4.7.4-3 ii libkdepim4 4:4.4.11.1+l10n-1 ii libkdeui5 4:4.7.4-3 ii libkhtml5 4:4.7.4-3 ii libkimap4 4:4.7.4-2 ii libkio5 4:4.7.4-3 ii libkldap4 4:4.7.4-2 ii libkleo44:4.4.11.1+l10n-1 ii libkmime4 4:4.7.4-2 ii libknotifyconfig4 4:4.7.4-3 ii libkontactinterface44:4.7.4-2 ii libkparts4 4:4.7.4-3 ii libkpgp44:4.4.11.1+l10n-1 ii libkpimidentities4 4:4.7.4-2 ii libkpimtextedit44:4.7.4-2 ii libkpimutils4 4:4.7.4-2 ii libkresources4 4:4.7.4-2 ii libksieve4 4:4.4.11.1+l10n-1 ii libktnef4 4:4.7.4-2 ii libmailtransport4 4:4.7.4-2 ii libmessagecore4 4:4.4.11.1+l10n-1 ii libmessagelist4 4:4.4.11.1+l10n-1 ii libmimelib4 4:4.4.11.1+l10n-1 ii libnepomuk4 4:4.7.4-3 ii libphonon4 4:4.6.0.0-1 ii libqt4-dbus 4:4.7.4-2 ii libqt4-network 4:4.7.4-2 ii libqt4-qt3support 4:4.7.4-2 ii libqt4-xml 4:4.7.4-2 ii libqtcore4 4:4.7.4-2 ii libqtgui4 4:4.7.4-2 ii libstdc++6 4.6.3-1 ii libthreadweaver44:4.7.4-3 ii perl5.14.2-9 ii phonon 4:4.6.0really4.5.1-1 Versions of packages kmail recommends: ii gnupg-agent 2.0.18-2 ii gnupg2 2.0.18-2 ii pinentry-qt [pinentry-x11] 0.8.0-1 ii pinentry-qt4 [pinentry-x11] 0.8.1-1 Versions of packages kmail suggests: pn clamav0.97.3+dfsg-2.1 pn kaddressbook 4:4.4.11.1+l10n-1 pn kleopatra none pn procmail none pn spamassassin | bogofilter | annoyance-filter | spambayes none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663528: libkio5: kmail crashes since upgrade to KDE 4.7.4
On Monday 12 March 2012, Pino Toscano wrote: Alle lunedì 12 marzo 2012, Stefan Fritsch ha scritto: Since upgrading the kde libraries to version 4.7.4, kmail crashes on start before displaying any window. Are you using a network proxy? If so, does kmail open if you unset it? Yes and yes. If I change kde's configuration to direct connection to the internet, kmail seems to work OK. Thanks for your quick response. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616323: [php-maint] Bug#616323: segfaults when serving HTTP requests
On Sunday 12 June 2011, Robert Millan wrote: Btw, as for #616323, could you consider uploading the same fix to squeeze-proposed-updates Oh, I forgot about that one. Done: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630356 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629896: segfault while simply get()ing a value from squeeze memcached
On Thursday 09 June 2011, Josip Rodin wrote: select(3147, [1024 1223 1224 1227 1230 1231 1235 1241 1242 1243 Hah, I found the apparent problem. The number of fds in those select() calls tipped me off to reexamine a change I recently did as part of the squeeze upgrade - I enabled a large number of virtual hosts which forced me to call 'ulimit -n 4096' in the apache2 init script. When I disabled 1500 virtual hosts and reduced their number to just 3, everything was just fine again. Please reassign the bug elsewhere if this is not actually specific to memcache.so - this is happening with: * libapache2-mod-php5 Version: 5.3.3-7+squeeze1 * apache2-mpm-prefork Version: 2.2.16-6+squeeze1 I haven't looked at the code, but my guess is that php5-memcache uses the FD_SET macro and friends. This only works up to 1024 open fds. From select(2): An fd_set is a fixed size buffer. Executing FD_CLR() or FD_SET() with a value of fd that is negative or is equal to or larger than FD_SETSIZE will result in undefined behavior. php5-memcache should probably use a different API (maybe poll()). An alternative work-around would be to use php in fcgi mode. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619036: [php-maint] Bug#619036: php5: Build-Depends uninstallable
On Monday 21 March 2011, Peter Samuelson wrote: Since only a single libdb*-dev can be installed at a time, and since libaprutil1-dev Depends on one of them, any apr-util reverse dep is forced to use the same bdb version. Even though, in Subversion's case, we don't use the apr-util frontend to libdb* at all. My preferred solution is to decouple apr-util and libdb, by not having the Depends in libaprutil1-dev. I note that (at least for Subversion) this should not pose any problems at runtime: libdb uses symbol versioning, and libsvn1 picks up the correct Depends: libdb4.8 via dpkg-shlibdeps. The only reason I can see for libaprutil1-dev to depend on libdb*-dev is /usr/include/apr-1.0/apu_want.h, a feature where an application can request an include of db.h. I wonder if any of its reverse deps are actually using this very minor feature. Subversion can optionally find the right db.h that way, but we don't use it in Debian. Anyway, I wonder if any other reverse deps of apr-util would break if it stopped depending on libdb*-dev. Even if so, adding some Build-Depends: libdb4.8-dev or similar to a few packages seems reasonable to me. Some googling hasn't revealed any user of apu_want.h outside of apr- util itself. I agree that removing the dependency looks like the best idea. To answer your original question, I have not tested Subversion with libdb 5.1. I will try to remember to do that soon. There are upstream indications that it is compatible. As subversion itself has a build-dep on libdb4.8-dev, it should be possible to remove libaprutil1-dev's dep without breaking subversion. I will do that with the next upload. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619036: [php-maint] Bug#619036: php5: Build-Depends uninstallable
On Sunday 20 March 2011, Raphael Geissert wrote: On Sunday 20 March 2011 11:15:54 Kurt Roeckx wrote: Your build-depends are uninstallable because you build-depend on libdb-dev, which depends on libdb5.1-dev, and apache2-prefork-dev which depends on libaprutil1-dev, which depends on libdb4.8-dev. And libdb5.1-dev and libdb4.8-dev of course conflict with each other. For apache: Stefan et al, Do you have any objection to switch to libdb5.1-dev (and bd on libdb-dev)? Switching libdb version in apr-util has to be coordinated with subversion. I am not sure we want that to happen automatically when the libdb maintainers change the default version, but I could be wrong. In the past, Peter Samuelson always did manual tests before switching. Peter, can you comment? Based on a few tests via php, databases from 4.8 and 5.1 seem to be compatible. In the long term, something needs to be decided and done. The former maintainer of db uploaded the latest version and orphaned the packages. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613083: libreoffice-common: Deletes /share and /user in preinst
Package: libreoffice-common Version: 1:3a3.3.1~rc1-1 Severity: critical Justification: causes serious data loss from preinst: if dpkg --compare-versions $2 lt 1:3.3.0-3; then rm -rf /share rm -rf /user fi Are you mad? You must nod delete arbitrary directories! Some people store important information there. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613083: libreoffice-common: Deletes /share and /user in preinst
On Saturday 12 February 2011, you wrote: And what do people store in /share and /user? /share is a common name for additional file systems (e.g. remote NFS shares). You cannot assume that just because a dir is not in the FHS, people don't use it. And you hopefully suggest an alternative way to me how to clean up those broken directories? Delete the files and directories you have created one by one, without -r. Or look if something exists there and warn the user that he should clean up by hand. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613083: libreoffice-common: Deletes /share and /user in preinst
On Saturday 12 February 2011, Rene Engelhard wrote: On Sat, Feb 12, 2011 at 06:54:22PM +0100, Stefan Fritsch wrote: On Saturday 12 February 2011, you wrote: And what do people store in /share and /user? /share is a common name for additional file systems (e.g. remote NFS shares). You cannot assume that just because a dir is not in the FHS, people don't use it. Ah, yeah, that. We use someting else, so I ddidn't think that /share is that commonly used. Sorry for that. Having to restore 30GB from backup is annoying, but at least I have a backup :-/ And you hopefully suggest an alternative way to me how to clean up those broken directories? Delete the files and directories you have created one by one, without -r. Probably feasible for /share/config/javasettingsunopkginstall.xml but that's the content of the broken /user: (sid)root@frodo:/user# tree . ├── extensions │ ├── shared │ │ ├── extensions.db │ │ ├── lastsynchronized │ │ ├── log.txt │ │ └── registry │ │ ├── com.sun.star.comp.deployment.bundle.PackageRegistryBackend │ │ ├── com.sun.star.comp.deployment.component.PackageRegistryBackend │ │ ├── com.sun.star.comp.deployment.configuration.PackageRegistryBackend │ │ │ ├── backenddb.xml │ │ │ └── registered_packages.db │ │ ├── com.sun.star.comp.deployment.executable.PackageRegistryBackend │ │ ├── com.sun.star.comp.deployment.help.PackageRegistryBackend │ │ │ └── backenddb.xml │ │ ├── com.sun.star.comp.deployment.script.PackageRegistryBackend │ │ └── com.sun.star.comp.deployment.sfwk.PackageRegistryBackend │ └── tmp │ ├── extensions │ ├── extensions.db │ └── registry │ ├── com.sun.star.comp.deployment.bundle.PackageRegistryBackend │ ├── com.sun.star.comp.deployment.component.PackageRegistryBackend │ ├── com.sun.star.comp.deployment.configuration.PackageRegistryBackend │ │ ├── backenddb.xml │ │ └── registered_packages.db │ ├── com.sun.star.comp.deployment.executable.PackageRegistryBackend │ ├── com.sun.star.comp.deployment.help.PackageRegistryBackend │ │ └── backenddb.xml │ ├── com.sun.star.comp.deployment.script.PackageRegistryBackend │ └── com.sun.star.comp.deployment.sfwk.PackageRegistryBackend └── uno_packages └── cache ├── log.txt ├── registry │ ├── com.sun.star.comp.deployment.bundle.PackageRegistryBackend │ ├── com.sun.star.comp.deployment.component.PackageRegistryBackend │ ├── com.sun.star.comp.deployment.configuration.PackageRegistryBackend │ │ ├── backenddb.xml │ │ └── registered_packages.db │ ├── com.sun.star.comp.deployment.executable.PackageRegistryBackend │ ├── com.sun.star.comp.deployment.help.PackageRegistryBackend │ │ └── backenddb.xml │ ├── com.sun.star.comp.deployment.script.PackageRegistryBackend │ └── com.sun.star.comp.deployment.sfwk.PackageRegistryBackend ├── uno_packages └── uno_packages.db 31 directories, 15 files If you know that this is the complete list, including 15 lines of rm -f and 31 lines of rmdir ... 2 /dev/null || true in depth-first order would seem best to me. Or do find /user -name 'com.sun.star*PackageRegistryBackend' -print0 | xargs -0 --no-run-if-empty rm -rf and then delete the rest by hand. But this is already more fragile. Or look if something exists there and warn the user that he should clean up by hand. That could be done, yes... If you can't limit the list of files, that's the only reasonable solution, IMHO. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613083: libreoffice-common: Deletes /share and /user in preinst
On Saturday 12 February 2011, Rene Engelhard wrote: if dpkg --compare-versions $2 lt 1:3.3.0-3; then BTW, it would be good if you limited the cleanup to the cases where the problematic version was actually installed, i.e. don't clean up if $2 is . (Or have a lower bound for $2 if that is appropriate). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613083: libreoffice-common: Deletes /share and /user in preinst
On Saturday 12 February 2011, Rene Engelhard wrote: On Sat, Feb 12, 2011 at 07:21:41PM +0100, Stefan Fritsch wrote: If you know that this is the complete list, including 15 lines of rm -f and 31 lines of rmdir ... 2 /dev/null || true in depth-first order would seem best to me. Or do I dont, it's the one I just got, though when re-simulating the condition which lead to the dirs in the first place.. I just ended up with this one: Looks sane to me. Thanks. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611461: iceweasel still does insecure ssl renegotiation?!
On Saturday 29 January 2011, Christoph Anton Mitterer wrote: It seems that iceweasel still is vulnerable to the SSL renegotiation attack, as simply is configured per default to allow the vulnerable renegotiation: This has to be balanced between compatibility and security. Currently less than 50% of the servers on the internet are patched. So it is sensible to not deny renegotiation for unpatched servers. Patched servers usually won't allow insecure renegotiation, anyway. There are also many servers that don't allow renegotiation at all. So the problem is mostly about the browser knowing if the remote server is secure. security.ssl.require_safe_negotiation;true FWIW, this setting is about negotiation, not about _re_negotiation. You probably want to change security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref instead. It will take a lot longer until security.ssl.require_safe_negotiation can be switched on by default. Look at how long it took for SSLv2 to disappear. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610984: aegis: Can't close a branch if files have been renamed in particular ways
package: aegis version: 4.24.3-2 severity: grave thanks This is the first bug in http://sourceforge.net/mailarchive/message.php?msg_id=26848688 where aede fails with aegis: project bug1.1: change 2: file file1 in the baseline has changed since the last 'aegis -DIFFerence' command, you need to do a merge The bug can be worked around by creating a dummy change, merge with aed -only_merge -GrandParent and then undo all the changes done by this merge. But I still think this is a grave bug. -- Forwarded message -- Date: Wed, 05 Jan 2011 11:49:09 +0100 From: Walter Franzini walter.franz...@gmail.com To: Stefan Fritsch s...@sfritsch.de Cc: aegis-develop...@lists.sourceforge.net, aegis-us...@auug.org.au Subject: Re: [Aegis-developers] aegis gets confused when renaming files [cc-ing aegis-users since it may be helpful for others] Stefan Fritsch s...@sfritsch.de writes: Hi, Hi, I have some more problems with aecp -ind -delta and renamed/removed files. I have created a reproducer which is attached. Thanks for the report and for the scripts. [...] Maybe this one is related http://sourceforge.net/tracker/?func=detailaid=1712779group_id=224atid=100224 but I am not sure. Yes it is possible, it seems a UUID clash. Let me try to explain my *suspects*: 1. in 1.1.C010 new_file f1 (with UUID1) new_file f3 (with UUID3) 2. close branch 1.1, now the baseline for 1 contains f1 with UUID1 f3 with UUID3 3. in 1.2.C010 remove_file f1 3. in 1.2.C011 the tricky part: rename f3 as f1 When you close 1.2.C011 the baseline for 1.2 will contain f1 with UUID3. Closing the 1.2 branch will result in the out-of date error since the uuid for f1 is UUID1 in 1.baseline and UUID3 in 1.2.baseline. Does it seems right to you? I'll try to figure how to solve the problem. ciao -- Walter Franzini http://aegis.stepbuild.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610985: Can't checkout old versions correctly
package: aegis
severity: grave
version: 4.24-5
thanks
Aegis fails to checkout old versions with aecp -ind correctly if files have
been moved around in interesting ways. Details are below. The full thread
starts at http://sourceforge.net/mailarchive/message.php?msg_id=26848688
I have marked the bug as found in the lenny version, too. But with the lenny
version, this is only reproducible if the segfault
http://sourceforge.net/tracker/?func=detailaid=3066593group_id=224atid=100224
would be fixed first.
-- Forwarded message --
Date: Mon, 24 Jan 2011 17:33:36 +0100 (CET)
From: Stefan Fritsch s...@sfritsch.de
To: Walter Franzini walter.franz...@gmail.com
Cc: aegis-develop...@lists.sourceforge.net
Subject: Re: [Aegis-developers] aegis gets confused when renaming files
Hi Walter,
thanks for your help and sorry for the late response.
On Fri, 14 Jan 2011, Walter Franzini wrote:
The aecp -ind bug is fixed, you can get a compressed patch from
http://aegis.stepbuild.org/cgi-bin/aeget/aegis.4.24.C665/?aepatch+compat=4.16
This fixes some aecp -ind problems, but I found other problems that are not
fixed. Again, the attached reprod4 script creates the repository and the
verify4 script shows that aecp -ind produces wrong output.
If I'm not wrong you are a DD, so you can probably give me some advice
about the best/proper way to have these fixes in squeeze. Actually only
RC bugs and translation updates are allowed to migrate to testing, so a
new upload in unstable will be blocked and not eligible for unblocking.
I think the inability of a revision control system to checkout old versions
correctly is a grave bug and is therefore RC. I will open a bug report in the
debian BTS.
The fix will likely be too late for Squeeze 6.0.0, but I am sure it is eligible
for the first point release 6.0.1. To get an update into 6.0.1, you need to
upload a package that fixes this bug but makes no other changes. Then ask
debian-rele...@lists.debian.org for inclusion. If the fix is uploaded before
6.0.0, it can likely be propagated from unstable. If not, a separate upload to
stable-proposed-updates will be necessary. If you need a sponsor for the
upload, just ask.
Cheers,
Stefan#!/bin/bash
. /usr/share/aegis/profile
set -eux
P=${1:-bug4}
U=$LOGNAME
TF=$(mktemp)
trap rm -f $TF EXIT
SNAPSHOTDIR=$(pwd)/snapshots.$P
if [ -e $SNAPSHOTDIR ] ; then
echo $SNAPSHOTDIR already exists
exit 1
else
mkdir $SNAPSHOTDIR
fi
setup_devs () {
aegis -new_developer $U || true
aegis -new_integrator $U || true
aegis -new_reviewer $U || true
}
snapshot () {
DIR=$SNAPSHOTDIR/$AEGIS_PROJECT.C$AEGIS_CHANGE
if [ -e $DIR ] ; then
echo snapshot $DIR already exists
exit 1
fi
aecd
cp -rL . $DIR
}
nc () {
EDITOR=true aegis -v -nc -p $AEGIS_PROJECT $TF 21
cat $TF
export AEGIS_CHANGE=$(grep aegis.*created $TF|perl -p -e 's/.*change
([0-9]+):.*/$1/')
aedb -p $AEGIS_PROJECT $AEGIS_CHANGE
aecd
}
ec () {
aecd
sleep 1
aed
aeb
snapshot
sleep 1
aede
aeib
sleep 1
aecd
aeb
aed
cd
aeipass
}
nbr () {
EDITOR=true aegis -v -nbr -p $AEGIS_PROJECT $TF 21
cat $TF
BR=$(grep aegis.*created $TF|perl -p -e 's/.*(\S+): created.*/$1/')
BR=${BR#$AEGIS_PROJECT.}
export AEGIS_PROJECT=$AEGIS_PROJECT.$BR
setup_devs
}
ebr () {
export AEGIS_PROJECT=${AEGIS_PROJECT%.$BR}
export AEGIS_CHANGE=$BR
aecd
sleep 1
aede
aeib
sleep 1
aecd
aeb
aed
sleep 1
cd
aeipass
}
setup_proj () {
EDITOR=true aenpr $P.1
export AEGIS_PROJECT=$P.1
setup_devs
PA=$(mktemp)
cat $PA 'EOF'
description = The \$P\ program, branch 1.;
developer_may_review = true;
developer_may_integrate = true;
reviewer_may_integrate = true;
developers_may_create_changes = true;
umask = 022;
default_test_exemption = true;
default_test_regression_exemption = true;
minimum_change_number = 10;
reuse_change_numbers = true;
minimum_branch_number = 1;
skip_unlucky = false;
compress_database = false;
develop_end_action = goto_awaiting_integration;
protect_development_directory = false;
EOF
aepa -file $PA
rm -f $PA
nc
aenf aegis.conf
cat aegis.conf 'EOF'
build_command = true;
development_directory_style = {
source_file_symlink = true;
};
merge_command =
set +e; \
merge -p -L baseline -L C$c ${quote $mostrecent} ${quote $original} \
${quote $input} ${quote $output}; \
test $? -le 1;
diff_command =
diff -pU10 ${quote $original} ${quote $input} ${quote $output} \
|| [ $? -eq 1 ] || grep \^Binary files\ ${quote $output};
architecture
Bug#605484: libapache2-mod-fcgid in lenny vulnerable to hole for weeks
On Tuesday 21 December 2010, John Goerzen wrote: I reported bug #605484 regarding a security hole in lenny. I believe the security team was CC'd. Prior to my report, http://security-tracker.debian.org/tracker/CVE-2010-3872 said that Debian/stable was not vulnerable. I also notified them to correct this issue. My question here is: who's got the ball on security issues? It seems that this issue didn't trigger any bugs being created or any bugs being filed in Debian when it came out. When I did what I thought was appropriate, it also didn't trigger much. The maintainer was interested in it, but AFAICT there are, as yet, no new packages. This is not an attack on any person/team, just a question about whether we have an organizational problem we need to correct. The problem is a combination of several security team members being inactive because of work/thesis/... and the other members being kept busy by things which had higher priority. For example fixing the recent exim remote root vulnerability and sorting out infrastructure breakage due to the dak upgrade on security-master. The upgrade was was necessary to support squeeze. My understanding is that the mod_fcgid issue cannot be triggered by browsers but only if there is a malicious fcgi app on the server, which is not a very common setup. Therefore this seemed like a not-so- high priority issue. I am sorry that nobody found the time to mail this to you. FWIW, it seems the infrastructure has been finally fixed today, so I hope things will improve now. But I do think that there are currently to few active members in the security team. I am pretty sure we will send out a request for new volunteers soon. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594711: slapd: Migration of DB format fails during upgrade
Package: slapd Version: 2.4.23-4 Severity: grave When upgrading from 2.4.23-2 to 2.4.23-4, I get a debconf message that tells me that slapcat failed during upgrade. dpkg then aborts with a failure. Also, contrary to the debconf message, the database files are not moved into /var/backup. I am guessing that the problem could have to do with slapd not being started on boot on my system. #593550 has some info about how to resolve the problem, but I think this information should be in slapd's README.Debian. Here is the log from the attempted upgrade: Preconfiguring packages ... (Reading database ... 261556 files and directories currently installed.) Preparing to replace slapd 2.4.23-2 (using .../slapd_2.4.23-4_i386.deb) ... Stopping OpenLDAP: slapd. Dumping to /var/backups/slapd-2.4.23-2: - directory dc=loglevel,dc=info... bdb(dc=loglevel,dc=info): Program version 4.8 doesn't match environment version 4.7 hdb_db_open: database dc=loglevel,dc=info cannot be opened, err -30971. Restore from backup! backend_startup_one (type=hdb, suffix=dc=loglevel,dc=info): bi_db_open failed! (-30971) slap_startup failed failed. dpkg: error processing /var/cache/apt/archives/slapd_2.4.23-4_i386.deb (--unpack): subprocess new pre-installation script returned error exit status 1 configured to not write apport reports Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.4.23-4... done. insserv: warning: current start runlevel(s) (3 4 5) of script `slapd' overwrites defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 6) of script `slapd' overwrites defaults (0 1 6). Errors were encountered while processing: /var/cache/apt/archives/slapd_2.4.23-4_i386.deb nothing to commit (working directory clean) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages slapd depends on: ii adduser 3.112 add and remove users and groups ii coreutils 8.5-1 GNU core utilities ii debconf [debconf-2.0] 1.5.35 Debian configuration management sy ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libdb4.8 4.8.30-1 Berkeley v4.8 Database Libraries [ ii libgnutls26 2.8.6-1the GNU TLS library - runtime libr ii libldap-2.4-2 2.4.23-4 OpenLDAP libraries ii libltdl7 2.2.6b-2 A system independent dlopen wrappe ii libperl5.10 5.10.1-14 shared Perl library ii libsasl2-22.1.23.dfsg1-6 Cyrus SASL - authentication abstra ii libslp1 1.2.1-7.8 OpenSLP libraries ii libwrap0 7.6.q-19 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-23.1 Linux Standard Base 3.2 init scrip ii perl [libmime-base64-perl 5.10.1-14 Larry Wall's Practical Extraction ii psmisc22.12-1utilities that use the proc file s ii unixodbc 2.2.14p2-2 ODBC tools libraries Versions of packages slapd recommends: ii libsasl2-modules 2.1.23.dfsg1-6 Cyrus SASL - pluggable authenticat Versions of packages slapd suggests: ii ldap-utils2.4.23-4 OpenLDAP utilities -- debconf information: slapd/tlsciphersuite: * shared/organization: lan * slapd/upgrade_slapcat_failure: slapd/backend: HDB * slapd/allow_ldap_v2: false * slapd/no_configuration: false slapd/move_old_database: true slapd/suffix_change: false * slapd/dump_database_destdir: /var/backups/slapd-VERSION * slapd/domain: loglevel.info slapd/password_mismatch: slapd/invalid_config: true slapd/slurpd_obsolete: * slapd/dump_database: when needed slapd/purge_database: false -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591286: libapr1: upgrade breaks apache
On Sunday 01 August 2010, Adrian Bridgett wrote: However, if I downgrade _just_ libapr1 to 1.2.12-5+lenny1 then posixsem (and sem) work just fine. Which architecture are you using? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591286: libapr1: upgrade breaks apache
On Sunday 01 August 2010, Adrian Bridgett wrote: i386 (but it's a KVM guest, sorry - I should have said). I found out why posixsem does not work: A bug in pbuilder/cowbuilder causes posix shared mem/posix semaphores to not work in the build chroot and this causes apr's configure to disable it. Since I always use cowbuilder to build the packages, all i386 libapr1 packages of the last few years had non-working posixsem. The only exception was 1.2.12-5+lenny1 which was not uploaded by me but by Peter Samuelson. You were simply lucky that you upgraded to lenny after version 1.2.12-5+lenny1 was released. With 1.2.12-5 it would not have worked either. If you need it, you can fix it by rebuilding libapr1. It should work if you either don't use pbuilder, or use pbuilder and put /dev/shm in the BINDMOUNTS variable in /etc/pbuilderrc. I haven't yet looked into the issue of sem trying to use posixsem even if it is not available. This really does look like a bug in apr or apache. Out of interest: Have you noticed any performance difference with sslmutex sem instead of the default 'file'? The description of the types on http://httpd.apache.org/docs/2.2/misc/perf-tuning.html says that the semaphore mutex types are somewhat less robust. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583435: NMU diff
Hi,
I have uploaded an NMU that changes the state file dir to
/var/run/rpcbind. Diff is attached.
Cheers,
Stefandiff -Nru rpcbind-0.2.0/debian/changelog rpcbind-0.2.0/debian/changelog
--- rpcbind-0.2.0/debian/changelog 2010-01-09 04:03:44.0 +0100
+++ rpcbind-0.2.0/debian/changelog 2010-07-17 21:49:33.0 +0200
@@ -1,3 +1,11 @@
+rpcbind (0.2.0-4.1) unstable; urgency=high
+
+ * Non-maintainer upload by the security team.
+ * CVE-2010-2061: Store state files in /var/run/rpcbind instead of /tmp.
+Closes: #583435
+
+ -- Stefan Fritsch s...@debian.org Sat, 17 Jul 2010 21:47:56 +0200
+
rpcbind (0.2.0-4) unstable; urgency=low
* -w is the default option
diff -Nru rpcbind-0.2.0/debian/init.d rpcbind-0.2.0/debian/init.d
--- rpcbind-0.2.0/debian/init.d 2010-01-09 04:24:00.0 +0100
+++ rpcbind-0.2.0/debian/init.d 2010-07-17 22:13:33.0 +0200
@@ -4,8 +4,8 @@
### BEGIN INIT INFO
# Provides: rpcbind
-# Required-Start:$network
-# Required-Stop: $network
+# Required-Start:$network $local_fs
+# Required-Stop: $network $local_fs
# Default-Start: S 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: RPC portmapper replacement
@@ -21,6 +21,7 @@
. /lib/lsb/init-functions
OPTIONS=-w
+STATEDIR=/var/run/rpcbind
if [ -f /etc/default/rpcbind ]
then
. /etc/default/rpcbind
@@ -31,6 +32,14 @@
start ()
{
+if [ ! -d $STATEDIR ] ; then
+mkdir $STATEDIR
+fi
+if [ ! -O $STATEDIR ] ; then
+log_begin_msg $STATEDIR not owned by root
+log_end_msg 1
+exit 1
+fi
log_begin_msg Starting rpcbind daemon...
ps=$( ps aux | grep /sbin/rpcbind | grep -v grep )
if [ -n $ps ]
diff -Nru rpcbind-0.2.0/debian/postrm rpcbind-0.2.0/debian/postrm
--- rpcbind-0.2.0/debian/postrm 1970-01-01 01:00:00.0 +0100
+++ rpcbind-0.2.0/debian/postrm 2010-07-17 22:09:34.0 +0200
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+set -e
+
+if [ $1 = purge ] ; then
+ rm -rf /var/run/rpcbind /var/run/rpcbind.lock /var/run/rpcbind.sock
+fi
+
+#DEBHELPER#
diff -Nru rpcbind-0.2.0/debian/rules rpcbind-0.2.0/debian/rules
--- rpcbind-0.2.0/debian/rules 2010-01-09 04:14:00.0 +0100
+++ rpcbind-0.2.0/debian/rules 2010-07-17 21:43:54.0 +0200
@@ -18,7 +18,7 @@
dh_testdir
# Add here commands to configure the package.
cp -f /usr/share/misc/config.sub /usr/share/misc/config.guess .
- ./configure $(CROSS) --prefix=/usr --mandir=\$${prefix}/share/man
--infodir=\$${prefix}/share/info CFLAGS=$(CFLAGS) LDFLAGS=-Wl,-z,defs
--enable-warmstarts --enable-libwrap
+ ./configure $(CROSS) --prefix=/usr --mandir=\$${prefix}/share/man
--infodir=\$${prefix}/share/info CFLAGS=$(CFLAGS) LDFLAGS=-Wl,-z,defs
--enable-warmstarts --enable-libwrap --with-statedir=/var/run/rpcbind
build: build-stamp
Bug#586480: openssh-server: chroot directive is not working when using FISH (File transfer of shell with midnight commander)
On Saturday 19 June 2010, you wrote: However, if I use the fish protocol [1] included in midnight commander, I can see the full filesystem hierarchy, and even transfer files from the etc folder, etc... Subsystem sftp internal-sftp Match group sftponly ChrootDirectory /home/%u X11Forwarding no AllowTcpForwarding no AllowAgentForwarding no ForceCommand internal-sftp fish does not work at all with ForceCommand and it won't work with ChrootDirectory unless you copy lots of things into the chroot (/lib /bin ...). Have you used the same user for your fish and sftp tests? Please verify in /var/log/auth.log that you really did. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583858: libc6-i686: causes segfaults
Hi, I can reproduce this. I have attached a stacktrace and part of the update log which shows that the segfaults start while configuring locales (though probably that this is just the first package with a postinstall after configuring libc6-i686). If you have ideas how I could help further, just ask. Cheers, Stefan Setting up libc6-i686 (2.11.1-1) ... Setting up libc-dev-bin (2.11.1-1) ... Setting up libc6-amd64 (2.11.1-1) ... Setting up linux-libc-dev (2.6.32-14) ... Setting up libc6-dev (2.11.1-1) ... Setting up libc6-dev-amd64 (2.11.1-1) ... Setting up libc6-dbg (2.11.1-1) ... Setting up locales (2.11.1-1) ... dpkg: error processing locales (--configure): subprocess installed post-installation script killed by signal (Segmentation fault) Setting up libperl5.10 (5.10.1-13) ... Setting up linux-base (2.6.32-14) ... dpkg: error processing linux-base (--configure): subprocess installed post-installation script killed by signal (Segmentation fault) Setting up initramfs-tools (0.95.1) ... Installing new version of config file /etc/initramfs-tools/initramfs.conf ... Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault /boot/initrd.img-2.6.18-4-amd64 does not exist. Cannot update. dpkg: dependency problems prevent configuration of linux-image-2.6.32-5-amd64: linux-image-2.6.32-5-amd64 depends on linux-base (= 2.6.32-14); however: Package linux-base is not configured yet. dpkg: error processing linux-image-2.6.32-5-amd64 (--configure): dependency problems - leaving unconfigured Setting up libsqlite3-0 (3.6.23.1-4) ... Setting up libsqlite3-dev (3.6.23.1-4) ... Setting up libx264-96 (1:0.svn20100531-0.0) ... Setting up avidemux-common (1:2.5.3-0.1) ... Setting up binutils (2.20.1-10) ... Setting up cpp (4:4.4.4-1) ... processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz stepping: 5 cpu MHz : 1197.000 cache size : 8192 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid bogomips: 5596.19 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz stepping: 5 cpu MHz : 1197.000 cache size : 8192 KB physical id : 0 siblings: 8 core id : 1 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse
Bug#582876: gdc-4.3 needs tighter versioned dependency on gcc-4.3-base
On Tuesday 25 May 2010, Iain Buclaw wrote: On 24 May 2010 19:21, Stefan Fritsch s...@sfritsch.de wrote: On Monday 24 May 2010, Matthias Klose wrote: On 24.05.2010 12:35, Stefan Fritsch wrote: Package: gdc-4.3 Version: 1:1.046-4.3.4-5 Severity: serious gdc 4.3.4 does not work with gcc-4.3-base 4.3.5: I think you forgot to give an explanation why you closed this bug. Or was the closing done by accident? The upgrade to 4.3.5 has only been done this weekend, and gcc has to be compiled and uploaded first before gdc can be built against it. As for the bumping of gdc, has only been recently done, see link for current status. https://buildd.debian.org/pkg.cgi?pkg=gdc-4.3https://buildd.debian .org/pkg.cgi?pkg=gdc-4.3 When it is uploaded for your architecture, update the package, then try again. If problems persist, don't hesitate to reply back. With the update, gdc works again. But the problem will re-appear with gcc-4.3-base 4.3.6, unless you either change the dependencies or ship the old symlink (4.3.5 - 4.3), too. Therefore I think this bug is still valid. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582876: gdc-4.3 needs tighter versioned dependency on gcc-4.3-base
Package: gdc-4.3 Version: 1:1.046-4.3.4-5 Severity: serious gdc 4.3.4 does not work with gcc-4.3-base 4.3.5: $ gdc -c test_md5.d gdc: error trying to exec 'cc1d': execvp: No such file or directory The problem is that it looks for cc1d in /usr/lib/gcc/i486-linux-gnu/4.3.4/ but gcc-4.3-base 4.3.5 only contains the symlink /usr/lib/gcc/i486-linux-gnu/4.3.5 - 4.3 gdc-4.3 should probably depend on: gcc-4.3-base (= current upstream minor version), gcc-4.3-base ( next upstream minor version) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages gdc-4.3 depends on: ii g++-4.3 4.3.5-1 The GNU C++ compiler ii gcc-4.3-base 4.3.5-1 The GNU Compiler Collection (base ii libc62.10.2-9Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.4-2 GCC support library ii libgmp3c22:4.3.2+dfsg-1 Multiprecision arithmetic library ii libmpfr1ldbl 2.4.2-3 multiple precision floating-point ii libphobos-4.3-dev1:1.046-4.3.4-5 The phobos D standard library ii libstdc++6 4.4.4-2 The GNU Standard C++ Library v3 gdc-4.3 recommends no packages. gdc-4.3 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582876: gdc-4.3 needs tighter versioned dependency on gcc-4.3-base
On Monday 24 May 2010, Matthias Klose wrote: On 24.05.2010 12:35, Stefan Fritsch wrote: Package: gdc-4.3 Version: 1:1.046-4.3.4-5 Severity: serious gdc 4.3.4 does not work with gcc-4.3-base 4.3.5: I think you forgot to give an explanation why you closed this bug. Or was the closing done by accident? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576399: libao4: Fails to install if libao2 is installed
Package: libao4 Version: 1.0.0-2 Severity: serious dpkg: error processing /var/cache/apt/archives/libao4_1.0.0-2_i386.deb (--unpack): trying to overwrite '/etc/libao.conf', which is also in package libao2 0:0.8.8-5.1 Errors were encountered while processing: /var/cache/apt/archives/libao4_1.0.0-2_i386.deb I guess either libao4 must conflicts/replaces libao2 or the libao.conf must be moved into a separate package. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages libao4 depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib libao4 recommends no packages. Versions of packages libao4 suggests: ii libasound21.0.22-2 shared library for ALSA applicatio ii libaudio2 1.9.2-3Network Audio System - shared libr ii libesd0 0.2.41-7 Enlightened Sound Daemon - Shared ii libpulse0 0.9.21-1.1 PulseAudio client libraries -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573163: apache2.2-common - mod_proxy_http reports stray timeouts
On Wednesday 10 March 2010, Bastian Blank wrote: It checks for POLLIN (aka for readable things) before writing the request, which makes no sense at all. Yes, the bug is that mod_reqtimeout handles the backend connection at all. It should be restricted to the client connection. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570245: Processed: severity of 570245 is grave
On Mon, 1 Mar 2010, Michael Tokarev wrote: Stefen, can you please, this and next time you merely increases severity, give at least some hint about your justification? I thought from the original report it was obvious that this makes kvm unusable, therefore this bug is not only important. I cannot successfully start kvm at all, except when using the -no-kvm switch. But with that, kvm is just the same as qemu. I have an intel core i7, therefore the statement that this only affects intel could be correct, but that was not present in the bug report before I bumped the severity. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
