Bug#962208: libtrace3: diff for NMU version 3.0.22-0.1
Please go ahead. I haven't looked at your particular patches yet, but I've been trying to make time to address these bugs without success over the last few weeks. Thanks for your effort, I will do my best to follow-up with a further tidy-up version, etc in due course. Cheers On Fri, Jan 7, 2022 at 5:22 AM Adrian Bunk wrote: > Control: tags 962208 + patch > Control: tags 962208 + pending > Control: tags 965694 + patch > Control: tags 965694 + pending > > Dear maintainer, > > I've prepared an NMU for libtrace3 (versioned as 3.0.22-0.1) and > uploaded it to DELAYED/15. Please feel free to tell me if I should > cancel it. > > cu > Adrian > -- Matt Brown m a...@debian.org +64 20 4099 3329 www.mattb.net.nz
Bug#956567: libh2o-dev-common: uninstallable in Multi-Arch situation due to missing foreign declaration
Package: libh2o-dev-common Version: 2.2.5+dfsg2-2+deb10u1 Severity: serious Justification: 8 Dear Maintainer, https://wiki.debian.org/Multiarch/Implementation#Multi-Arch:_foreign_support_packages states that an architecture all package which is used a dependency for an Architecture: any package must set Multi-Arch: foreign on the depedency. libh2o-dev-common does not do this currently, and therefore it prevents the multi-arch installation of libh2o-dev as it cannot be used to satisfy the dependency that package specifies. E.g. matt@web:~$ dpkg --print-architecture amd64 matt@web:~$ sudo apt install libh2o-dev:armhf [sudo] password for matt: Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libh2o-dev:armhf : Depends: libh2o-dev-common:armhf (= 2.2.5+dfsg2-2+deb10u1) but it is not installable E: Unable to correct problems, you have held broken packages. I believe fixing this is as simple as adding Multi-Arch: foreign to the control file stanza for libh2o-dev-common. Thanks! -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libh2o-dev-common depends on: ii libh2o0.13 2.2.5+dfsg2-2+deb10u1 libh2o-dev-common recommends no packages. libh2o-dev-common suggests no packages. -- no debconf information
Bug#723957: slapd: commented olcDbDirectory config line causes unusable system and potential data loss on upgrade
Package: slapd
Version: 2.4.31-1+nmu2
Severity: critical
Justification: breaks the whole system
Additional Justification details:
- Breaks whole system: slapd is used to provide accounts - no user
accounts available - system unusable.
- Data loss: database is physically on disk, but inaccessible due to
upgraded software, slapd, slapcat, slapadd cannot use it.
The get_directory method used in several maint scripts contains a bug
that causes it to return multiple lines of output if a commented
olcDbDirectory line also exists in the configuration file. The callers
of get_directory use filesystem existence checks on the output of
get_directory to determine whether to actually backup the database,
and silently continue without backing up when multiple lines of output
are returned.
Exact failure mode:
1) Begin upgrade
2) 2.4.23-7.3 prerm script doesn't perform any backups (as expected)
3) 2.4.31-1+nmu2 preinst attempts to backup, but silently skips
backups due to above bug
4) 2.4.31-1+nmu2 is unpacked (database now inaccessible due to format mismatch)
5) 2.4.31-1+nmu2 postinst attempts to move old db directory (skips
move silently due to same bug as above)
6) 2.4.31-1+nmu2 postinst attempts to import ldif backup (fails as no
ldif backup exists)
7) dpkg exits with error, slapd is unusable and not easily
recoverable, system unusable.
Output from step 3 and 4:
Preparing to replace slapd 2.4.23-7.3 (using
.../slapd_2.4.31-1+nmu2_i386.deb) ...
Stopping OpenLDAP: slapd.
Dumping to /var/backups/slapd-2.4.23-7.3:
Unpacking replacement slapd ...
Note the expected output from line 178 of the preinst is not printed
after the Dumping... line, this is because the check on line 176 of
the preinst script returns false when presented with multi-line input
in the $dbdir variable.
Output from steps 5, 6 and 7:
Backing up /etc/ldap/slapd.d in /var/backups/slapd-2.4.23-7.3... done.
Moving old database directories to /var/backups:
Loading from /var/backups/slapd-2.4.23-7.3:
- directory dc=katalinabrown,dc=co,dc=nz... failed.
Loading the database from the LDIF dump failed with the following
error while running slapadd:
/var/backups/slapd-2.4.23-7.3/dc=katalinabrown,dc=co,dc=nz.ldif:
No such file or directory
dpkg: error processing slapd (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
slapd
E: Sub-process /usr/bin/dpkg returned an error code (1)
Again, the expected per suffix line is missing after the Moving...
line, due to the check on line 384 of postinst returning false when
presented with mutli-line input in the $databasedir variable.
I believe the bug is found on line 293 of preinst and postinst:
grep olcDbDirectory: `grep -l olcSuffix: $1
${SLAPD_CONF}/cn\=config/olcDatabase*.ldif` | cut -d: -f 2 | sed 's/^
*//g'
the first grep is not anchored, so if a file contains content like:
olcDbDirectory: /var/lib/ldap
#olcDbDirectory: /var/lib/ldap
both paths are returned, and the subsequent checks of the return value
cause the failures described above.
The following patch (anchoring the match to start of line) would be a
minimal fix for this critical issue, but a more proper fix
would be for the preinst to bail out if it is unable to actually
backup a database that it knows to exist from the config!
--- slapd.preinst.orig 2013-09-21 16:59:18.0 +0100
+++ slapd.preinst 2013-09-21 16:58:25.0 +0100
@@ -290,7 +290,7 @@
get_directory() { # {{{
# Returns the db directory for a given suffix
if [ -d ${SLAPD_CONF} ] get_suffix | grep -q $1 ; then
- grep olcDbDirectory: `grep -l olcSuffix: $1
${SLAPD_CONF}/cn\=config/olcDatabase*.ldif` | cut -d: -f 2 | sed 's/^
*//g'
+ grep ^olcDbDirectory: `grep -l olcSuffix: $1
${SLAPD_CONF}/cn\=config/olcDatabase*.ldif` | cut -d: -f 2 | sed 's/^
*//g'
elif [ -f ${SLAPD_CONF} ]; then
# Extract the directory for the given suffix ($1)
for f in `get_all_slapd_conf_files`; do
The same fix would need to be made in postinst, and wherever else this
command is used.
Luckily, I'm testing this upgrade on my dev system... :)
-- System Information:
Debian Release: 6.0.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Shell: /bin/sh linked to /bin/dash
Versions of packages slapd depends on:
ii adduser3.113+nmu3add and remove users and groups
ii coreutils 8.13-3.5 GNU core utilities
ii debconf [debconf-2 1.5.49Debian configuration management sy
ii libc6 2.13-38 Embedded GNU C Library: Shared lib
ii libdb5.1 5.1.29-5 Berkeley v5.1 Database Libraries [
ii libgcrypt111.5.0-5+deb7u1LGPL Crypto
Bug#626741: libtrace3: FTBFS: missing depends on kfreebsd-kernel-headers
On Sat, May 14, 2011 at 10:33 PM, Christoph Egger christ...@debian.org wrote: Adding a build-depend on `kfreebsd-kernel-headers [ kfreebsd-any ]` will fix the build of libtrace there. Why should a package have to depend on the kernel headers? Why does libc/some alternative package not install the kernel headers as is done by glibc for linux? Are you suggesting that there is something within the libtrac source that makes such an explicit dependency required? From the build logs I don't see anything to suggest that the problem is a missing kernel build dependency, It looks like the dot utility required by doxygen is causing the build to fail. Tail of logs for libtrace3 on kfreebsd-amd64: sh: Problems running dot: exit code=127, command='dot', arguments='/build/buildd-libtrace3_3.0.10-1-kfreebsd-amd64-UrOfF5/libtrace3-3.0.10/docs/doxygen/html/dagformat_8h__dep__incl.dot -Tpng -o /build/buildd-libtrace3_3.0.10-1-kfreebsd-amd64-UrOfF5/libtrace3-3.0.10/docs/doxygen/html/dagformat_8h__dep__incl.png -Tcmapx -o /build/buildd-libtrace3_3.0.10-1-kfreebsd-amd64-UrOfF5/libtrace3-3.0.10/docs/doxygen/html/dagformat_8h__dep__incl.map' sh: dot: not found dot: not found Problems running dot: exit code=127, command='dot', arguments='/build/buildd-libtrace3_3.0.10-1-kfreebsd-amd64-UrOfF5/libtrace3-3.0.10/docs/doxygen/html/daglegacy_8h__dep__incl.dot -Tpng -o /build/buildd-libtrace3_3.0.10-1-kfreebsd-amd64-UrOfF5/libtrace3-3.0.10/docs/doxygen/html/daglegacy_8h__dep__incl.png -Tcmapx -o /build/buildd-libtrace3_3.0.10-1-kfreebsd-amd64-UrOfF5/libtrace3-3.0.10/docs/doxygen/html/daglegacy_8h__dep__incl.map' Problems running dot: exit code=127, command='dot', arguments='/build/buildd-libtrace3_3.0.10-1-kfreebsd-amd64-UrOfF5/libtrace3-3.0.10/docs/doxygen/latex/dagformat_8h__dep__incl.dot -Tpdf -o /build/buildd-libtrace3_3.0.10-1-kfreebsd-amd64-UrOfF5/libtrace3-3.0.10/docs/doxygen/latex/dagformat_8h__dep__incl.pdf' sh: dot: not found Problems running dot: exit code=127, command='dot', arguments='/build/buildd-libtrace3_3.0.10-1-kfreebsd-amd64-UrOfF5/libtrace3-3.0.10/docs/doxygen/latex/daglegacy_8h__dep__incl.dot -Tpdf -o /build/buildd-libtrace3_3.0.10-1-kfreebsd-amd64-UrOfF5/libtrace3-3.0.10/docs/doxygen/latex/daglegacy_8h__dep__incl.pdf' /bin/bash: line 8: 68448 Segmentation fault doxygen libtrace.doxygen make[3]: *** [doxy] Error 139 Generatinmake[3]: Leaving directory `/build/buildd-libtrace3_3.0.10-1-kfreebsd-amd64-UrOfF5/libtrace3-3.0.10/docs' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd-libtrace3_3.0.10-1-kfreebsd-amd64-UrOfF5/libtrace3-3.0.10' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd-libtrace3_3.0.10-1-kfreebsd-amd64-UrOfF5/libtrace3-3.0.10' make: *** [build-stamp] Error 2 Please provide more details to clarify why you believe I need to add a freebsd specific dependency on the kernel headers. -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592099: Grave packaging issues in PHPwiki
Hi Thomas I wasn't aware of any out of date licensing info since I last trawled the codebase and updated the copyright file - in anycase this metadata is easy enough to bring to correctness now it is noticed. The history of this package is that it has always had caretaker maintainers and while we've done our best to keep it inline with evolving policy requirements and best practices over the years the upstream codebase certainly does not make that an easy task. As you have yourself discovered. The upstream developers have promised me a new release in the next week or two to address the PHP5.3 issues so my plan was to wait for that before initiating any further action on my part. Chances are the release team is unlikely to accept a brand new version into testing at this stage so it is entirely likely that phpwiki will not be in our next release. However i'd like to have the new phpwiki release in hand before coming to a final conclusion here. With regards to the other open bugs and the package in stable. We have users depending on it so I'm not really convinced that removal is in their best interests. If there are serious security issues as you hint at then please file the appropriate bugs so we can address them through the normal processes. The embedding of software in phpwiki is certainly sub optimal. But hard to rectify without major changes from upstream. The package was accepted many years ago before we really cracked down and tightened up on such behaviour in PHP apps. I think this helps explain how the package got past the ftpmasters. The bugs to separate out the dependencies and all RFH tagged and I would gladly welcome patches - as would the upstream developers who are aware of the issue but have limited time for such work. In summary - yes there is clearly much to be improved in the package and the PHP issues will likely keep it out of the new release but I'm not connecting convinced that a full scale package removal from the archive is justified as you conclude. The issues are being worked on, but as usual more hands are needed to make it happen at the speed we desire. Cheers. On 19 Sep 2010 14:16, Thomas Goirand z...@debian.org wrote: Hi Matt, I feel already sorry that I have to send this... I was going through RCs that I could fix (as all my packages are mostly in order), and I believed this one is one that I could fix. I thought that I would just ask: Have you ever considered patching so that PHPwiki uses ~E_DEPRECATED type of error reporting, so that it wont display so many ugly messages? which would have been a work-around. But considering my findings, that wont be what I'll say. When I had a look in the package, I have found that it is embedding loads of libraries that are available in Debian, and even some that CANNOT be embedded in phpwiki, because of license restrictions. Namely (and maybe not even an exhaustive list): - php-fpdf (1.51, when even Lenny has 1.53.dfsg-6) - nusoap (old version 0.6.3 with embedded PHP 5.3 deprecation and security fixes (XSS attack) that I fixed recently in Squeeze and SID) - lib/captcha/Vera.ttf - fckeditor (old version from 2007) - php-cache (v1.2 when v1.5.5RC4 can be found in Lenny, using a php license 2.02 which use is forbidden outside PHP itself if a package is named phpSOMETHING) - ... More over, the package source embeds php-db (but it doesn't seem to be shipped in the binary packages). Even more bad: the debian/copyright file doesn't list any of the authors of the files in lib. At this point, I even wonder how this even got accepted by the ftp-masters. I really think that now, we have no other option than to remove PHPWiki from Debian, or to work really hard on it so that: 1/ The debian/copyright is written correctly with all authors listed and a full review of all files in lib/* is made 2/ Embedded libraries that are already packaged in Debian are used 3/ PHP deprecations are removed OR ~E_DEPRECATED is used 4/ Libraries that the package embeds are packaged separately 5/ A +dfsg version of the phpwiki package is created, removing what's embedded. I've done such work few times already, and I can tell that it takes really a long time to make it acceptable for Debian (see for example my extplorer package in Squeeze/SID, which took me month to make because of all this kind of issues). At this point, I wont have time to work on it either, and even if I do, that wont be enough time before Squeeze is out, with anyway, a big chance that the RT will refuse the package. I don't think I have to send more bug reports, because quite a lot have been sent against the package already (for embedding for example fpdf, nusoap). Instead, I think I had to warn the ftp-masters about all this, which is why they are Cc: to this mail. Maybe we'll have to even remove phpwiki from Lenny (this wont be my decision anyway). Cheers, Thomas Goirand (zigo)
Bug#591197: #591197: phpwiki RC bug
Yes it is in the pipes. Unfortunately my signing subkey expired so I'm waiting for a letting update before I can upload it. On 22 Sep 2010 18:41, Didier apos;OdyXapos; Raboud did...@raboud.com wrote: Hi Matt, it's been more than one month that this RC bug (#591197) is marked pending. Is your upload fixing it in the pipes towards unstable ? Thanks in advance for informing, OdyX -- Didier Raboud, proud Debian Maintainer (DM). CH-1020 Renens did...@raboud.com
Bug#592099: phpwiki: PHPwiki does not work with PHP 5.3
On Wed, Sep 8, 2010 at 6:29 PM, Kumar Appaiah a.ku...@alumni.iitm.ac.in wrote: Thanks for the update. I did see the thread; my worry is that the fix is bundled with a new upstream release. At this stage of the release, would you be able to convince the release team to let the new version in, or do you think you would be able to backport the relevant fixes to the version existing in squeeze at the moment (and support it through the squeeze cycle)? I haven't given it much thought. I suspect the release team won't love the idea of a brand new version, but the alternative is just to remove PHPwiki entirely. I don't have time to trawl through the upstream repository to determine which patches need backporting (at a quick glance a few weeks ago it was a non-trivial number). If you're willing to contribute a backport patch to make the current version work with PHP 5.3 and are willing to provide ongoing support for that patch until a new upstream version is released then I would be more than happy to consider it. Cheers -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592099: phpwiki: PHPwiki does not work with PHP 5.3
On Wed, Sep 8, 2010 at 2:19 PM, Kumar Appaiah a.ku...@alumni.iitm.ac.in wrote: Dear Matt, On Sat, Aug 07, 2010 at 03:21:32PM +0100, Matt Brown wrote: The PHPwiki 1.3.14 codebase uses a number of functions that were deprecated in PHP 5.3. As phpwiki runs with warnings equivalent to errors this renders PHPwiki completely unfunctional. Fixes for these issues are in the upstream subversion repository but there has not been a new release of phpwiki since 2007. I have filed an upstream bug to ask for a new release containing the fixes to make PHPwiki compatible with PHP 5.3 Could you please provide an update to the state of this bug? Is there a simple enough way to make PHPwiki function on PHP 5.3? See the upstream bug and the following PHP wiki discuss thread conversation http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTimd1YuS4JOOApcAP2%3Dois%2B_m21dsz0mHW7bnEp2%40mail.gmail.comforum_name=phpwiki-talk (sorry for the crappy link, blame sourceforge). Basically, as far as I can tell all of the fixes are committed to the upstream repository, but the developers haven't made a release yet. I'm not really willing to package an svn snapshot of phpwiki given the (low) level of upstream support and development speed, so we're blocked waiting for a release. -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592099: phpwiki: PHPwiki does not work with PHP 5.3
Package: phpwiki Version: 1.3.14-5 Severity: grave Tags: upstream Justification: renders package unusable The PHPwiki 1.3.14 codebase uses a number of functions that were deprecated in PHP 5.3. As phpwiki runs with warnings equivalent to errors this renders PHPwiki completely unfunctional. Fixes for these issues are in the upstream subversion repository but there has not been a new release of phpwiki since 2007. I have filed an upstream bug to ask for a new release containing the fixes to make PHPwiki compatible with PHP 5.3 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages phpwiki depends on: ii apache2 2.2.16-1 Apache HTTP Server metapackage ii apache2-mpm-prefork [httpd] 2.2.16-1 Apache HTTP Server - traditional n ii dbconfig-common 1.8.46 common framework for packaging dat ii debconf [debconf-2.0] 1.5.34 Debian configuration management sy ii libapache2-mod-php5 5.3.2-2server-side, HTML-embedded scripti ii php-db1.7.13-2 PHP PEAR Database Abstraction Laye ii php5 5.3.2-2server-side, HTML-embedded scripti ii php5-mysql5.3.2-2MySQL module for php5 ii php5-sqlite 5.3.2-2SQLite module for php5 ii ucf 3.0025 Update Configuration File: preserv Versions of packages phpwiki recommends: ii sqlite2.8.17-6 command line interface for SQLite Versions of packages phpwiki suggests: pn php5-imap none (no description available) pn php5-ldap none (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591197: phpwiki: does not build swf files from source
tag 591197 + confirmed thanks On Sun, Aug 1, 2010 at 5:06 AM, Raphael Geissert geiss...@debian.org wrote: Source: phpwiki Version: 1.3.14-5 Severity: serious Hi, phpwiki ships a swf file but doesn't build it from source. It would of course be more useful if you'd specify which file that is... and/or references to whatever mass bug filing this is part of. I'm assuming it is: m...@krypton:~/debs/phpwiki/trunk$ find . -name *.swf ./themes/Sidebar/ora.swf The best course of action here is probably just to not ship that theme in the .deb since upstream development is pretty much dead and there is no sign of any corresponding source for that swf every existing. I'll prepare a new upload over the next few days without this theme. -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#473131: dbconfig-common: database backups are world-readable
On Tue, Apr 8, 2008 at 10:53 PM, Niko Tyni [EMAIL PROTECTED] wrote: phpwiki phpwiki is not affected by this as the package installs the database with permissions 664 root:www-data There is nothing sensitive in the database, just wiki pages that are available via the http server. The admin password is kept in the config.ini file in /etc. -- Matt Brown [EMAIL PROTECTED] Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452194: invalid http11.so module (MS-DOS binary) present in package!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: mongrel Version: 1.1.1-1 Severity: grave Justification: package is unusable on most platforms mongrel_1.1.1.orig.tar.gz (md5sum 103a7a3c5580fc1002c1327fea934203) contains two invalid files that should not be in a source package: mongrel-1.1.1/lib/http11.jar mongrel-1.1.1/lib/http11.so This is doubly bad because the .so is built as an MS-DOS executable according to file! [EMAIL PROTECTED]:/home/matt # file /usr/lib/ruby/1.8/http11.so /usr/lib/ruby/1.8/http11.so: MS-DOS executable PE for MS Windows (DLL) (GUI) Intel 80386 32-bit The package fails to work after installation due to this, mongrel_rails gives the error: [EMAIL PROTECTED]:/home/matt # mongrel_rails /usr/lib/ruby/1.8/http11.so: /usr/lib/ruby/1.8/http11.so: invalid ELF header - /usr/lib/ruby/1.8/http11.so (LoadError) Deleting the two files from the source package and rebuilding results in a correct .so library and mongrel_rails then functions appropriately. - -- Matt Brown [EMAIL PROTECTED] Mob +353 86 608 7117 www.mattb.net.nz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iD8DBQFHQ07z/pqN2EBUqwgRAo8PAKCMx6rydUY2WTK29JkUHlf7cXNUKQCfZi98 dRqC1NoNiZgmXM+oVh7ydF4= =wewJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414999: File conflicts between libtrace-tools and ltt-visualizer
tag 414999 + accepted thanks The libtrace upstream maintainer has agreed to rename their tool to tracepktdump to help clarify that libtrace operates on network packets. As soon as I receive the new upstream release I will prepare a new upload. Cheers On 3/16/07, Michael Ablassmeier [EMAIL PROTECTED] wrote: both libtrace-tools and ltt-visualizer ship ['usr/bin/tracedump'] but do not conflict or add a diversion, thus fail to be installed in the same environment: -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz
Bug#398466: NMU Ready
The fix described in the third post is incorrect. The backported patches
applied in -3 have already reordered this part of the code so that it
works correctly with madwifi.
Unfortunately that backport missed the final component of the fix, which
was to all the hostapd_flush_old_stations call to fail when setting up
an interface. eg:
http://hostap.epitest.fi/cgi-bin/viewcvs.cgi/hostap/hostapd/hostapd.c.diff?r2=1.168r1=1.167diff_format=u
I will upload an NMU fixing this shortly. NMU diff is attached
--
Matt Brown
Debian Developer
[EMAIL PROTECTED]
Mob +64 21 611 544 www.mattb.net.nz
diff -u hostapd-0.5.5/debian/patches/00list hostapd-0.5.5/debian/patches/00list
--- hostapd-0.5.5/debian/patches/00list
+++ hostapd-0.5.5/debian/patches/00list
@@ -4,0 +5 @@
+22_madwifi_plaintext
diff -u hostapd-0.5.5/debian/changelog hostapd-0.5.5/debian/changelog
--- hostapd-0.5.5/debian/changelog
+++ hostapd-0.5.5/debian/changelog
@@ -1,3 +1,14 @@
+hostapd (1:0.5.5-3.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Backport hostapd.c fix from CVS: (Closes: #398466)
+- Allow hostapd_flush_old_stations to fail, otherwise configuration
+ of unencrypted modes failed with madwifi. (1.168)
+ The correct setup is handled by the backported fixes in the
+ previous revision.
+
+ -- Matt Brown [EMAIL PROTECTED] Fri, 8 Dec 2006 23:40:42 +1300
+
hostapd (1:0.5.5-3) unstable; urgency=medium
* Update madwifi headers to r1757.
only in patch2:
unchanged:
--- hostapd-0.5.5.orig/debian/patches/22_madwifi_plaintext.dpatch
+++ hostapd-0.5.5/debian/patches/22_madwifi_plaintext.dpatch
@@ -0,0 +1,21 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## madwifi_plaintext.patch by Matt Brown [EMAIL PROTECTED]
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Backport fixes for madwifi from 0.5.6
+## DP:
+## DP: Allow the hostapd_flush_old_stations call to fail
+
[EMAIL PROTECTED]@
+--- hostapd.orig/hostapd.c2006/10/07 00:06:53 1.167
hostapd/hostapd.c2006/10/16 00:00:11 1.168
+@@ -839,8 +839,7 @@
+ printf(Could not select hw_mode and channel.\n);
+ }
+
+- if (hostapd_flush_old_stations(hapd))
+- return -1;
++ hostapd_flush_old_stations(hapd);
+
+ if (hostapd_ctrl_iface_init(hapd)) {
+ printf(Failed to setup control interface\n);
signature.asc
Description: OpenPGP digital signature
Bug#394425: postinst is superfluous
Hi, The python calls in the postinst are entirely superfluous as the package does not ship any python modules. It consists only of two python scripts. I will upload an NMU built from the attached patch to fix this shortly. Kind Regards -- Matt Brown Debian Developer [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz diff -ur burn-0.4.3.orig/debian/changelog burn-0.4.3/debian/changelog --- burn-0.4.3.orig/debian/changelog 2005-03-22 10:09:20.0 +1200 +++ burn-0.4.3/debian/changelog 2006-10-28 19:19:04.0 +1300 @@ -1,3 +1,10 @@ +burn (0.4.3-2.1) unstable; urgency=low + + * Non-maintainer upload. + * Remove unneeded python compilation from postinst (Closes: #394425) + + -- Matt Brown [EMAIL PROTECTED] Sat, 28 Oct 2006 18:48:46 +1300 + burn (0.4.3-2) unstable; urgency=low * Closes bug for silent wavs in external decoding diff -ur burn-0.4.3.orig/debian/postinst burn-0.4.3/debian/postinst --- burn-0.4.3.orig/debian/postinst 2004-12-14 07:14:43.0 +1300 +++ burn-0.4.3/debian/postinst 2006-10-28 19:19:57.0 +1300 @@ -6,23 +6,4 @@ #DEBHELPER# -PACKAGE=burn -DIRLIST=/usr/share/burn - -PYTHON=python2.3 - -case $1 in -configure|abort-upgrade|abort-remove|abort-deconfigure) -for i in $DIRLIST ; do -/usr/bin/$PYTHON -O /usr/lib/$PYTHON/compileall.py -q $i -/usr/bin/$PYTHON /usr/lib/$PYTHON/compileall.py -q $i -done -;; - -*) -echo postinst called with unknown argument \`$1' 2 -exit 1 -;; -esac - exit 0 signature.asc Description: OpenPGP digital signature
Bug#394823: svn-buildpackage: should depend on libsvn-perl not libsvn-core-perl
Package: svn-buildpackage Version: 0.6.14 Severity: grave Justification: renders package unusable A recent svn update (eg, subversion = 1.4.0~rc4-1) changed the working copy format in a backwards incompatible manner. This upload also renamed the perl library package from libsvn-core-perl to libsvn-perl. There is only an old (svn 1.3) version of libsvn-core-perl in the archive that is unable to handle new working copies created by the current svn tools. Hence svn-buildpackage in it's current state is unable to deal with any package that has been touched by a subversion tool after the upgrade to 1.4.0. svn-buildpackage should depend on libsvn-perl which replaces libsvn-core-perl and is able to read the newer format svn working copies. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.18 Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Versions of packages svn-buildpackage depends on: ii devscripts2.9.22 Scripts to make the life of a Debi ii libsvn-perl [libsvn-core-perl 1.4.0-5Perl bindings for Subversion ii perl 5.8.8-6.1 Larry Wall's Practical Extraction ii subversion1.4.0-5Advanced version control system ii subversion-tools 1.4.0-5Assorted tools related to Subversi svn-buildpackage recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377692: phpwiki: edit any page impossible (PhotoAlbum.php complains)
retitle 377692 PHPwiki uses too much memory tags 377692 + confirmed, help thanks Alexis Huxley wrote: Hi, Just installed phpwiki. Followed the debconf screens. Visited the wiki page. It looked fine until I tried to edit the front page and then got: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 184320 bytes) in /usr/share/phpwiki/lib/plugin/PhotoAlbum.php on line 379 The same result trying to edit any other page. Upon further investigation this seems to be just one symptom of a larger problem. PHPwiki is being very inefficient in its use of memory. I'm about to upload a new package which fixes many other bugs, but I've currently got no good solution for this other than suggesting that you raise the memory limit in php.ini, I've documented this in the README.Debian file. I intend to raise the issue with the PHPwiki developers to see if they believe there is anything that can be done to reduce the amount of memory that PHPwiki requires. Any help or suggestions on how to reduce PHPwiki's memory usage would be appreciated. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#377692: phpwiki: edit any page impossible (PhotoAlbum.php complains)
Hi Alexis, Alexis Huxley wrote: Hi, Just installed phpwiki. Followed the debconf screens. Visited the wiki page. It looked fine until I tried to edit the front page and then got: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 184320 bytes) in /usr/share/phpwiki/lib/plugin/PhotoAlbum.php on line 379 The same result trying to edit any other page. Could you please try increasing PHP's memory limit (16MB, then 32MB, etc) and see what value you need to go to to avoid this problem. If you get to 64MB you can stop. I'm not saying this is a permanent solution, but it will help to narrow down what sort of bug this is, eg. PHPwiki just wants too many resources vs infinite memory allocation loop. Thanks -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#377692: It a known bug
Julien Louis wrote: it's a known and documented bug in the README.Debian gere is part of the README.Debian regarding this bug: snip That's a similar set of symptoms, but at this stage I don't think there is enough informatino to link it directly to this bug report. The reason for PHPwiki running out of memory when loading pages seems to be due to it loading in the source for each page from disk and not freeing the memory after it has been loaded into the database. I don't expect that PHPwiki is loading in the source for each page every time you try and edit a single page. There may be a common underlying cause of course, but this could also be a separate problem. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#361605: php4-sqlite: sqlite_escape_string tries to consume infinite memory (and dies) on amd64
Matej Vela wrote: Judging by the changes in PHP5, the problem is caused by the call to zend_parse_parameters(), which should be provided with an int rather than a long for the string length. Please test the following patch. snip Also, please test whether it accepts empty strings -- there's another change in PHP5 for that, but I'm not sure that it's strictly necessary. The patch fixes the original bug. Passing an empty string to sqlite_escape_string also succeeds (returns an empty string) without error. Thanks for providing the patch :) Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#361605: php4-sqlite: sqlite_escape_string tries to consume infinite memory (and dies) on amd64
Matthew Palmer wrote: That's quite nasty. Is this the officially-built php4-sqlite you're working from here? (I'd guess so, but better to be safe than sorry). Yes. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#352103: NMU Patch to fix this bug
On Sat, 2006-02-18 at 08:06 +0100, Javier Fernández-Sanguino Peña wrote: Should the check [ ! -f $PIDFILE ] return 1 cover that? I don't see why that should fail, if the PIDFILE does not exist it should not go ahead and try to read from it. It will cover it for most cases, but there is a race in the pathological case where you call stop twice in quick succession and the second call gets through to the running function before the TERM signal from first reaches the daemon and causes the pidfile to be removed. Doesn't happen very often, perhaps never in real life, but my tests were running two stops in a row (/etc/init.d/portreserve stop; /etc/init.d/portreserve stop) which did trigger it. It doesn't hurt the code to handle it nicely, so why not make the script more robust? Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: This is a digitally signed message part
Bug#352103: NMU Patch to fix this bug
On Thu, 2006-02-16 at 12:24 +0100, Javier Fernández-Sanguino Peña wrote:
- run 'portreserve start' twice, check # of portreserve instances. Stop
port reserve.
- run 'portreserve start' once, run 'portreserve', check # of instances and
pidfile contents. Stop port reserve.
Handles both these tests with no problems.
There are other situations which could be tested out and which, I believe,
the init.d script does not cover (like creating a stale pidfile when
portreserve is not running, stopping portreseve and trying to start it
again).
It also handles this situation cleanly.
I did however discover one minor bug that occurred when the stop target
of the init script was run twice in a row and resulted in some ugly
error output from trying to read the non-existant pidfile. The
functionality was still correct, but it didn't look nice.
Yet another version attached which fixes this minor annoyance. This is
the patch that I will pass on to my AM to NMU as part of my
application.
Thanks for working on this, hope you don't mind my nit-picking.
The package is much improved as a result.
Kind Regards
--
Matt Brown
[EMAIL PROTECTED]
Mob +64 21 611 544 www.mattb.net.nz
diff -ur portreserve-0.0.0/debian/changelog portreserve-0.0.0-matt/debian/changelog
--- portreserve-0.0.0/debian/changelog 2006-02-18 14:08:00.0 +1300
+++ portreserve-0.0.0-matt/debian/changelog 2006-02-18 14:05:59.0 +1300
@@ -1,3 +1,16 @@
+portreserve (0.0.0-2.1) unstable; urgency=low
+
+ * Non-maintainer upload
+ * Fixed minor init script bugs (Closes: #352103)
+- Use -z instead of -n to test list of service files
+- Use $NAME instead of the undefined $prog in the pidfile name
+ * Reworked portreserve pidfile handling
+- Check for existance of pidfile on startup, fail if already running
+- Create pidfile on startup
+- Remove pidfile when program exits cleanly
+
+ -- Matt Brown [EMAIL PROTECTED] Thu, 16 Feb 2006 01:02:03 +1300
+
portreserve (0.0.0-2) unstable; urgency=low
* Added xmlto to Build-Depends (Closes: #337848)
diff -ur portreserve-0.0.0/debian/portreserve.init portreserve-0.0.0-matt/debian/portreserve.init
--- portreserve-0.0.0/debian/portreserve.init 2006-02-18 14:08:00.0 +1300
+++ portreserve-0.0.0-matt/debian/portreserve.init 2006-02-18 14:07:05.0 +1300
@@ -11,19 +11,19 @@
test -f $DAEMON || exit 0
NAME=`basename $DAEMON`
-PIDFILE=/var/run/$prog.pid
+PIDFILE=/var/run/$NAME.pid
running()
{
# No pidfile, probably no daemon present
#
[ ! -f $PIDFILE ] return 1
-pid=`cat $PIDFILE`
+pid=`cat $PIDFILE 2/dev/null`
# No pid, probably no daemon present
[ -z $pid ] return 1
[ ! -d /proc/$pid ] return 1
-cmd=`cat /proc/$pid/cmdline | tr \000 \n|head -n 1 |cut -d : -f 1`
-
+cmdline=`cat /proc/$pid/cmdline 2/dev/null | tr \000 \n|head -n 1 |cut -d : -f 1`
+cmd=`basename $cmdline`
[ $cmd != $NAME ] return 1
return 0
}
@@ -36,7 +36,7 @@
if [ ! -d /etc/portreserve ] ; then
return 1
fi
- if [ -n `find /etc/portreserve \! -name *~ -a \! -name *.* -type f` ] ; then
+ if [ -z `find /etc/portreserve \! -name *~ -a \! -name *.* -type f` ] ; then
return 1
fi
return 0
Only in portreserve-0.0.0: portreserve.spec
diff -ur portreserve-0.0.0/src/portreserve.c portreserve-0.0.0-matt/src/portreserve.c
--- portreserve-0.0.0/src/portreserve.c 2003-09-04 02:12:52.0 +1200
+++ portreserve-0.0.0-matt/src/portreserve.c 2006-02-18 14:05:59.0 +1300
@@ -64,7 +64,13 @@
# include unistd.h
#endif
+#include signal.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+
#define UNIX_SOCKET /var/run/portreserve/socket
+#define PIDFILE /var/run/portreserve.pid
struct map {
struct map *next;
@@ -264,9 +270,85 @@
return 0;
}
+/* daemon_lock_pidfile and fcntl_lock taken from libslack
+ * Copyright (C) 1999-2004 raf [EMAIL PROTECTED]
+ * Licensed under the GPL
+ */
+int
+fcntl_lock(int fd, int cmd, int type, int whence, int start, int len)
+{
+struct flock lock[1];
+
+lock-l_type = type;
+lock-l_whence = whence;
+lock-l_start = start;
+lock-l_len = len;
+
+return fcntl(fd, cmd, lock);
+}
+
+static int
+daemon_lock_pidfile(char *pidfile)
+{
+mode_t mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH;
+int pid_fd;
+
+/* This is broken over NFS (Linux). So pidfiles must reside locally. */
+
+if ((pid_fd = open(pidfile, O_RDWR | O_CREAT | O_EXCL, mode)) == -1)
+{
+if (errno != EEXIST)
+return -1;
+
+/*
+** The pidfile already exists. Is it locked?
+** If so, another invocation is still alive.
+** If not, the invocation that created it has died.
+** Open the pidfile to attempt a lock.
+*/
+
+if ((pid_fd = open(pidfile, O_RDWR)) == -1
Bug#322169: NMU Patch to fix this bug
tag 322169 + patch thanks bts Hi, I have prepared a NMU patch to fix this bug as a part of the T S portion of my NM application. The patch places the locale.nopurge configuration file under the control of ucf in the postinst script. This allows conffile like behaviour to be retained while also allowing the user to make local modifications without fear of them being overwritten without warning next time the package is upgraded or reconfigured. I have also included some logic to attempt to recreate the previous 'unmodified' configuration file based on the debconf data to prevent unnecessary prompting of the user when they have not manually modified locale.nopurge. The patch also updates the documentation to remove all suggestions that the configuration file is not allowed to be modified by the user. Obviously I'm not yet a DD so this NMU will be made by my AM (formorer) at a later date. In the meantime packages are available in my repository at http://www.mattb.net.nz/debian/ Kind Regards -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz diff -ur localepurge-0.4.1/debian/README.debian localepurge-0.4.1-matt/debian/README.debian --- localepurge-0.4.1/debian/README.debian 2004-08-09 00:38:25.0 +1200 +++ localepurge-0.4.1-matt/debian/README.debian 2006-02-18 14:28:51.0 +1300 @@ -40,16 +40,6 @@ directory (or file) in /usr/share/locale not containing a subdirectory named LC_MESSAGES will be discreetly ignored. -The localepurge configuration should be configured after installation -only by using the command - - dpkg-reconfigure localepurge - -to add/remove locale entries or toggle verbosity. Since localepurge is -using the debconf facility for storing its configuration entries it -shouldn't be configured manually because all manual entries will get -lost after upgrade, reconfiguration or reinstallation of localepurge. - A Word of CAUTION: All locale directories containing a subdirectory named LC_MESSAGES diff -ur localepurge-0.4.1/debian/changelog localepurge-0.4.1-matt/debian/changelog --- localepurge-0.4.1/debian/changelog 2005-08-07 09:57:29.0 +1200 +++ localepurge-0.4.1-matt/debian/changelog 2006-02-18 13:40:14.0 +1300 @@ -1,3 +1,10 @@ +localepurge (0.4.1-0.1) unstable; urgency=low + + * Non-maintainer upload. + * Added ucf handling to the locale.nopurge file (Closes: #332169). + + -- Matt Brown [EMAIL PROTECTED] Sat, 18 Feb 2006 13:28:07 +1300 + localepurge (0.4.1) unstable; urgency=low * debian/control: Added | debconf-2.0 to dependencies to make it diff -ur localepurge-0.4.1/debian/control localepurge-0.4.1-matt/debian/control --- localepurge-0.4.1/debian/control 2005-08-07 09:57:37.0 +1200 +++ localepurge-0.4.1-matt/debian/control 2006-02-18 13:27:52.0 +1300 @@ -7,7 +7,7 @@ Package: localepurge Architecture: all -Depends: dpkg (= 1.9.7), debconf (= 1.2.0) | debconf-2.0, debianutils (= 1.6), procps +Depends: dpkg (= 1.9.7), debconf (= 1.2.0) | debconf-2.0, debianutils (= 1.6), procps, ucf Replaces: apt-localepurge Conflicts: apt-localepurge Suggests: debfoster, deborphan diff -ur localepurge-0.4.1/debian/localepurge.8 localepurge-0.4.1-matt/debian/localepurge.8 --- localepurge-0.4.1/debian/localepurge.8 2004-08-09 01:01:40.0 +1200 +++ localepurge-0.4.1-matt/debian/localepurge.8 2006-02-18 14:30:36.0 +1300 @@ -32,15 +32,7 @@ summary of freed space, and deletion of localized manual pages in addition to locale files. All actions are specified in the .BR /etc/locale.nopurge -configuration file. Since -.BR localepurge -uses debconf for storing its configuration data its configuration -should only be done via -.BR dpkg-reconfigure(8) -as outlined below. If not done via -.BR debconf(8) -any manual entries will be -irreversibly lost after an upgrade or reinstallation of the package. +configuration file. .br For detailed debugging the commandline switch .BR -debug @@ -91,15 +83,6 @@ .BR dpkg-reconfigure(8) to prevent locale files from being purged during subsequent runs of apt. .br -The localepurge configuration should only be configured by using the command -.BR 'dpkg-reconfigure -.BR localepurge' -to add/remove locale entries or toggle verbosity. Since localepurge is -using the -.BR debconf(8) -facility for storing its configuration entries it -shouldn't be configured manually because all manual entries will get -lost after upgrade, reconfiguration or reinstallation of localepurge. .SH SOLVING PROBLEMS caused by localepurge This program does interfere with the Debian package management and does provoke strange, but usually harmless, behaviour of programs related diff -ur localepurge-0.4.1/debian/postinst localepurge-0.4.1-matt/debian/postinst --- localepurge-0.4.1/debian/postinst 2004-03-10 16:44:59.0 +1300 +++ localepurge-0.4.1-matt/debian/postinst 2006-02-18 13:27:34.0 +1300 @@ -2,30 +2,19 @@ set -e
Bug#352103: NMU Patch to fix this bug
On Wed, 2006-02-15 at 15:14 +0100, Javier Fernández-Sanguino Peña wrote:
Hi there. I hope you don't mind me being a little bit picky, but I think it
helps you hone your skills :-)
I've certainly picked up a couple of pointers.
I'm pretty sure there are libraries that do implement that function already.
For exmaple, the 'daemon' package in Debian, which is based on libslack (see
http://libslack.org/) already provides a number of library functions for
daemons, such as daemon_pidfile (see
http://libslack.org/manpages/daemon.3.html). Most of the code you want
is already there (see daemon_construct_pidfile() and
daemon_lock_pidfile() or daemon_pidfile_unlocked)
A useful little library indeed, thanks for the pointer. It is very nice
and elegant code. It's still not suitable for wholesale inclusion as it
has its own memory management routines that are used in
daemon_construct_pidfile and daemon_pidfile_unlocked, but I've managed
to reuse the daemon_lock_pidfile function with a couple of small
wrappers to do the job.
The patch is now back down to the size/scope that I consider appropriate
for a NMU, I agree that the previous patch was getting a little unwieldy
and rough, my apologies.
Would you mind looking up how daemon() does this and maybe implement a
similar solution?
Please see the attached patch.
Cheers
--
Matt Brown
[EMAIL PROTECTED]
Mob +64 21 611 544 www.mattb.net.nz
diff -ur portreserve-0.0.0/debian/changelog portreserve-0.0.0-matt/debian/changelog
--- portreserve-0.0.0/debian/changelog 2006-02-12 11:07:31.0 +
+++ portreserve-0.0.0-matt/debian/changelog 2006-02-16 08:42:01.0 +
@@ -1,3 +1,15 @@
+portreserve (0.0.0-2.1) unstable; urgency=low
+
+ * Non-maintainer upload
+ * Fixed minor init script bugs (Closes: #352103)
+- Use -z instead of -n to test list of service files
+- Use $NAME instead of the undefined $prog in the pidfile name
+ * Reworked portreserve pidfile handling
+- Utilise functions from libslack to safely create and lock pidfile
+- Remove pidfile when program exits cleanly
+
+ -- Matt Brown [EMAIL PROTECTED] Thu, 16 Feb 2006 21:41:33 +1300
+
portreserve (0.0.0-2) unstable; urgency=low
* Added xmlto to Build-Depends (Closes: #337848)
diff -ur portreserve-0.0.0/debian/portreserve.init portreserve-0.0.0-matt/debian/portreserve.init
--- portreserve-0.0.0/debian/portreserve.init 2006-02-12 11:07:31.0 +
+++ portreserve-0.0.0-matt/debian/portreserve.init 2006-02-15 11:43:34.0 +
@@ -11,7 +11,7 @@
test -f $DAEMON || exit 0
NAME=`basename $DAEMON`
-PIDFILE=/var/run/$prog.pid
+PIDFILE=/var/run/$NAME.pid
running()
{
@@ -22,8 +22,8 @@
# No pid, probably no daemon present
[ -z $pid ] return 1
[ ! -d /proc/$pid ] return 1
-cmd=`cat /proc/$pid/cmdline | tr \000 \n|head -n 1 |cut -d : -f 1`
-
+cmdline=`cat /proc/$pid/cmdline | tr \000 \n|head -n 1 |cut -d : -f 1`
+cmd=`basename $cmdline`
[ $cmd != $NAME ] return 1
return 0
}
@@ -36,7 +36,7 @@
if [ ! -d /etc/portreserve ] ; then
return 1
fi
- if [ -n `find /etc/portreserve \! -name *~ -a \! -name *.* -type f` ] ; then
+ if [ -z `find /etc/portreserve \! -name *~ -a \! -name *.* -type f` ] ; then
return 1
fi
return 0
Only in portreserve-0.0.0-matt/: .deps
Only in portreserve-0.0.0: portreserve.spec
diff -ur portreserve-0.0.0/src/portreserve.c portreserve-0.0.0-matt/src/portreserve.c
--- portreserve-0.0.0/src/portreserve.c 2003-09-03 14:12:52.0 +
+++ portreserve-0.0.0-matt/src/portreserve.c 2006-02-16 08:34:09.0 +
@@ -64,7 +64,13 @@
# include unistd.h
#endif
+#include signal.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+
#define UNIX_SOCKET /var/run/portreserve/socket
+#define PIDFILE /var/run/portreserve.pid
struct map {
struct map *next;
@@ -264,9 +270,85 @@
return 0;
}
+/* daemon_lock_pidfile and fcntl_lock taken from libslack
+ * Copyright (C) 1999-2004 raf [EMAIL PROTECTED]
+ * Licensed under the GPL
+ */
+int
+fcntl_lock(int fd, int cmd, int type, int whence, int start, int len)
+{
+struct flock lock[1];
+
+lock-l_type = type;
+lock-l_whence = whence;
+lock-l_start = start;
+lock-l_len = len;
+
+return fcntl(fd, cmd, lock);
+}
+
+static int
+daemon_lock_pidfile(char *pidfile)
+{
+mode_t mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH;
+int pid_fd;
+
+/* This is broken over NFS (Linux). So pidfiles must reside locally. */
+
+if ((pid_fd = open(pidfile, O_RDWR | O_CREAT | O_EXCL, mode)) == -1)
+{
+if (errno != EEXIST)
+return -1;
+
+/*
+** The pidfile already exists. Is it locked?
+** If so, another invocation is still alive.
+** If not, the invocation that created it has died.
+** Open the pidfile to attempt a lock
Bug#352103: NMU Patch to fix this bug
Hi Javier,
Please find attached a revised patch that I propose for this NMU. It's a
bit more invasive that what I would usually feel comfortable including
in an NMU, so I won't upload without your approval.
On Tue, 2006-02-14 at 12:42 +0100, Javier Fernández-Sanguino Peña wrote:
Why doesn't --make-pidfile work?
start-stop-daemon creates the pidfile, but portreserve forks after this
as it becomes a daemon. The pidfile then points to the non-existent
parent process.
* /var/run should not be harcoded, it should be #DEFINEd (that way the
patch is usable for other distros)
Agreed, fixed.
* it should return an integer to determine if it is succesful or not (the
main program could, or could not, care about the pid file
creation and check the return value)
Agreed, fixed.
* there's a buffer overflow if 'fname' is longer than 512 chars. buf should
*not* be of a static size
There is no buffer overflow, the worst would be the pidfile name is
truncated, we are using snprintf not sprintf. However I have added
further error checking to handle the (unlikely) case of the pidfile name
exceeding 512 characters.
Note that that case is (and was in the previous patch) not possible in
this instance of the code as do_pid is only ever called with NULL as its
first argument.
* it should refuse to run (or create a pidfile) if the pidfile already
exists.
snip
Agreed - improved pidfile handling is now in the patch.
I suggest you reuse a pidfile creation function from some other tested
program, there should be plenty of examples around.
Unfortunately most are heavily integrated with the specified application
and its error logging routines etc. This is why we originally developed
the put_pid function that I included in the original patch, it acts as a
library function within my group of friends. I've now updated and
improved it based on your (much appreciated) comments on its
deficiencies.
I don't like the patch to portreserve.c and I object to this NMU. You *can*
NMU, however, to include the changes to the init.d script.
Are you happier with this revised patch?
Thanks for your time.
Regards
--
Matt Brown
[EMAIL PROTECTED]
Mob +64 21 611 544 www.mattb.net.nz
diff -ur portreserve-0.0.0/debian/changelog portreserve-0.0.0-matt/debian/changelog
--- portreserve-0.0.0/debian/changelog 2006-02-12 11:07:31.0 +
+++ portreserve-0.0.0-matt/debian/changelog 2006-02-15 12:04:55.0 +
@@ -1,3 +1,16 @@
+portreserve (0.0.0-2.1) unstable; urgency=low
+
+ * Non-maintainer upload
+ * Fixed minor init script bugs (Closes: #352103)
+- Use -z instead of -n to test list of service files
+- Use $NAME instead of the undefined $prog in the pidfile name
+ * Reworked portreserve pidfile handling
+- Check for existance of pidfile on startup, fail if already running
+- Create pidfile on startup
+- Remove pidfile when program exits cleanly
+
+ -- Matt Brown [EMAIL PROTECTED] Thu, 16 Feb 2006 01:02:03 +1300
+
portreserve (0.0.0-2) unstable; urgency=low
* Added xmlto to Build-Depends (Closes: #337848)
diff -ur portreserve-0.0.0/debian/portreserve.init portreserve-0.0.0-matt/debian/portreserve.init
--- portreserve-0.0.0/debian/portreserve.init 2006-02-12 11:07:31.0 +
+++ portreserve-0.0.0-matt/debian/portreserve.init 2006-02-15 11:43:34.0 +
@@ -11,7 +11,7 @@
test -f $DAEMON || exit 0
NAME=`basename $DAEMON`
-PIDFILE=/var/run/$prog.pid
+PIDFILE=/var/run/$NAME.pid
running()
{
@@ -22,8 +22,8 @@
# No pid, probably no daemon present
[ -z $pid ] return 1
[ ! -d /proc/$pid ] return 1
-cmd=`cat /proc/$pid/cmdline | tr \000 \n|head -n 1 |cut -d : -f 1`
-
+cmdline=`cat /proc/$pid/cmdline | tr \000 \n|head -n 1 |cut -d : -f 1`
+cmd=`basename $cmdline`
[ $cmd != $NAME ] return 1
return 0
}
@@ -36,7 +36,7 @@
if [ ! -d /etc/portreserve ] ; then
return 1
fi
- if [ -n `find /etc/portreserve \! -name *~ -a \! -name *.* -type f` ] ; then
+ if [ -z `find /etc/portreserve \! -name *~ -a \! -name *.* -type f` ] ; then
return 1
fi
return 0
Only in portreserve-0.0.0-matt/: .deps
Only in portreserve-0.0.0: portreserve.spec
diff -ur portreserve-0.0.0/src/portreserve.c portreserve-0.0.0-matt/src/portreserve.c
--- portreserve-0.0.0/src/portreserve.c 2003-09-03 14:12:52.0 +
+++ portreserve-0.0.0-matt/src/portreserve.c 2006-02-15 12:06:27.0 +
@@ -64,7 +64,13 @@
# include unistd.h
#endif
+#include signal.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+
#define UNIX_SOCKET /var/run/portreserve/socket
+#define PIDFILE_DIR /var/run
struct map {
struct map *next;
@@ -265,8 +271,76 @@
}
int
+do_pid(char *fname, int check, int unlink_pid)
+{
+ char *defname = portreserve;
+ char buf[512];
+ FILE *fp=NULL;
+ int fd, rv;
+ long int pid;
+
+ /* Determine pidfile name */
+ if( fname == NULL ) {
+ fname = defname;
+ rv = snprintf( buf[0], 512, %s/%s.pid
Bug#352103: NMU Patch to fix this bug
Hi,
I have prepared a NMU patch to fix this bug as a part of the T S
portion of my NM application.
As described in the original problem report there were several fairly
trivial fixes required to to the init script.
1) Incorrect test when checking for valid service files - fixed by using
-z not -n
2) check running function needs a call to basename to match value in
$NAME variable
Additionally the running function never succeeded because portreserve
doesn't create a pid file. This is fairly impolite for a daemon.
Unfortunately the --make-pidfile option to start-stop-daemon is not able
to create a pidfile in this situation so I have patched the portreserve
binary to create a pidfile.
Obviously I'm not yet a DD so this NMU will be made by my AM (formorer)
at a later date. In the meantime packages are available in my repository
at http://www.mattb.net.nz/debian/
Kind Regards
--
Matt Brown
[EMAIL PROTECTED]
Mob +64 21 611 544 www.mattb.net.nz
diff -ur portreserve-0.0.0/debian/changelog portreserve-0.0.0-matt/debian/changelog
--- portreserve-0.0.0/debian/changelog 2006-02-12 11:07:31.0 +
+++ portreserve-0.0.0-matt/debian/changelog 2006-02-12 11:07:14.0 +
@@ -1,3 +1,13 @@
+portreserve (0.0.0-2.1) unstable; urgency=low
+
+ * Non-maintainer upload
+ * Fixed minor init script bugs (Closes: #352103)
+- Use -z instead of -n to test list of service files
+- Use $NAME instead of the undefined $prog in the pidfile name
+ * Patched portreserve binary to write a pidfile when daemonising
+
+ -- Matt Brown [EMAIL PROTECTED] Sun, 12 Feb 2006 21:59:02 +1300
+
portreserve (0.0.0-2) unstable; urgency=low
* Added xmlto to Build-Depends (Closes: #337848)
diff -ur portreserve-0.0.0/debian/portreserve.init portreserve-0.0.0-matt/debian/portreserve.init
--- portreserve-0.0.0/debian/portreserve.init 2006-02-12 11:07:31.0 +
+++ portreserve-0.0.0-matt/debian/portreserve.init 2006-02-12 11:16:12.0 +
@@ -11,7 +11,7 @@
test -f $DAEMON || exit 0
NAME=`basename $DAEMON`
-PIDFILE=/var/run/$prog.pid
+PIDFILE=/var/run/$NAME.pid
running()
{
@@ -22,8 +22,8 @@
# No pid, probably no daemon present
[ -z $pid ] return 1
[ ! -d /proc/$pid ] return 1
-cmd=`cat /proc/$pid/cmdline | tr \000 \n|head -n 1 |cut -d : -f 1`
-
+cmdline=`cat /proc/$pid/cmdline | tr \000 \n|head -n 1 |cut -d : -f 1`
+cmd=`basename $cmdline`
[ $cmd != $NAME ] return 1
return 0
}
@@ -36,7 +36,7 @@
if [ ! -d /etc/portreserve ] ; then
return 1
fi
- if [ -n `find /etc/portreserve \! -name *~ -a \! -name *.* -type f` ] ; then
+ if [ -z `find /etc/portreserve \! -name *~ -a \! -name *.* -type f` ] ; then
return 1
fi
return 0
diff -ur portreserve-0.0.0/src/portreserve.c portreserve-0.0.0-matt/src/portreserve.c
--- portreserve-0.0.0/src/portreserve.c 2003-09-03 14:12:52.0 +
+++ portreserve-0.0.0-matt/src/portreserve.c 2006-02-12 11:07:14.0 +
@@ -264,6 +264,31 @@
return 0;
}
+void
+put_pid(char *fname)
+{
+ char *defname = portreserve;
+ char buf[512];
+ int fd;
+
+ if( fname == NULL ) {
+ fname = defname;
+ snprintf( buf, 512, /var/run/%s.pid, fname );
+ } else {
+ snprintf( buf, 512, %s, fname );
+ }
+ fd=creat(buf,0660);
+ if (fd0)
+ return;
+ sprintf(buf,%i\n,getpid());
+ if (write(fd,buf,strlen(buf)) != (signed)strlen(buf)) {
+ close(fd);
+ return;
+ }
+ close(fd);
+}
+
+
int
main (int argc, char **argv)
{
@@ -302,6 +327,7 @@
close (STDOUT_FILENO);
close (STDERR_FILENO);
setsid ();
+ put_pid(NULL);
}
return portreserve ();
signature.asc
Description: This is a digitally signed message part
Bug#337992: NMU Patch to fix this bug
Hi,
I have prepared a NMU patch to fix this bug as a part of the T S
portion of my NM application.
The problem is not that the package owning the file has changed name.
acid_conf.php should never have been a conffile in the first place as
the postinst script always updated its contents based on the results of
debconf questions to substitute in the database connection parameters.
This patch migrates acid_conf.php to be handled by ucf rather than as a
conffile. Additionally I have added logic to try and detect an upgrade
from an unmodified acid_conf.php so that the user is not prompted
unnecessarily during the Sarge - Etch upgrade. This is achieved by
shipping a copy of the configuration file as it was in the 0.9.6b20-10
version of the package, recreating the original file with the
appropriate debconf values substituted in and creating an md5sum of that
file to pass to ucf. This results in the user being prompted only if
they have modified the file by hand.
Obviously I'm not yet a DD so this NMU will be made by my AM (formorer)
at a later date. In the meantime packages are available in my repository
at http://www.mattb.net.nz/debian/
Kind Regards
--
Matt Brown
[EMAIL PROTECTED]
Mob +64 21 611 544 www.mattb.net.nz
diff -Nur acidlab-0.9.6b20/debian/acid_conf.php-0.9.6b20-10 acidlab-0.9.6b20-matt/debian/acid_conf.php-0.9.6b20-10
--- acidlab-0.9.6b20/debian/acid_conf.php-0.9.6b20-10 1970-01-01 12:00:00.0 +1200
+++ acidlab-0.9.6b20-matt/debian/acid_conf.php-0.9.6b20-10 2006-02-13 23:28:16.0 +1300
@@ -0,0 +1,275 @@
+?php
+
+$ACID_VERSION = 0.9.6b20-5.1;
+
+/* Path to the DB abstraction library
+ * (Note: DO NOT include a trailing backslash after the directory)
+ * e.g. $foo = /tmp [OK]
+ *$foo = /tmp/ [OK]
+ *$foo = c:\tmp[OK]
+ *$foo = c:\tmp\ [WRONG]
+ */
+$DBlib_path = /usr/share/adodb;
+
+/* The type of underlying alert database
+ *
+ * MySQL : mysql
+ * PostgresSQL : postgres
+ * MS SQL Server : mssql
+ */
+$DBtype = DBTYPE;
+
+/* Alert DB connection parameters
+ * - $alert_dbname : MySQL database name of Snort alert DB
+ * - $alert_host : host on which the DB is stored
+ * - $alert_port : port on which to access the DB
+ * - $alert_user : login to the database with this user
+ * - $alert_password : password of the DB user
+ *
+ * This information can be gleaned from the Snort database
+ * output plugin configuration.
+ */
+$alert_dbname = ALERT_NAME;
+$alert_host = ALERT_HOST;
+$alert_port = ALERT_PORT;
+$alert_user = ALERT_USER;
+$alert_password = ALERT_PASSWORD;
+
+/* Archive DB connection parameters */
+$archive_dbname = ARCHIVE_NAME;
+$archive_host = ARCHIVE_HOST;
+$archive_port = ARCHIVE_PORT;
+$archive_user = ARCHIVE_USER;
+$archive_password = ARCHIVE_PASSWORD;
+
+/* Type of DB connection to use
+ * 1 : use a persistant connection (pconnect)
+ * 2 : use a normal connection (connect)
+ */
+$db_connect_method = 1;
+
+/* Use referential integrity
+ * 1 : use
+ * 0 : ignore (not installed)
+ *
+ * Note: Only PostgreSQL and MS-SQL Server databases support
+ * referential integrity. Use the associated
+ * create_acid_tbls_?_extra.sql script to add this
+ * functionality to the database.
+ *
+ * Referential integrity will greatly improve the
+ * speed of record deletion, but also slow record
+ * insertion.
+ */
+$use_referential_integrity = 0;
+
+/* Path to the graphing library
+ * (Note: DO NOT include a trailing backslash after the directory)
+ */
+$ChartLib_path = /usr/share/phplot;
+
+/* File format of charts ('png', 'jpeg', 'gif') */
+$chart_file_format = png;
+
+/* Chart default colors - (red, green, blue)
+ *- $chart_bg_color_default: background color of chart
+ *- $chart_lgrid_color_default : gridline color of chart
+ *- $chart_bar_color_default : bar/line color of chart
+ */
+$chart_bg_color_default = array(255,255,255);
+$chart_lgrid_color_default = array(205,205,205);
+$chart_bar_color_default= array(190, 5, 5);
+
+/* Maximum number of rows per criteria element */
+$MAX_ROWS = 10;
+
+/* Number of rows to display for any query results */
+$show_rows = 50;
+
+/* Number of items to return during a snapshot
+ * Last _X_ # of alerts/unique alerts/ports/IP
+ */
+$last_num_alerts = 15;
+$last_num_ualerts = 15;
+$last_num_uports = 15;
+$last_num_uaddr = 15;
+
+/* Number of items to return during a snapshot
+ * Most Frequent unique alerts/IPs/ports
+ */
+$freq_num_alerts = 5;
+$freq_num_uaddr = 15;
+$freq_num_uports = 15;
+
+/* Number of scroll buttons to use when displaying query results */
+$max_scroll_buttons = 12;
+
+/* Debug mode - how much debugging information should be shown
+ * Timing mode- display timing information
+ * SQL trace mode - log SQL statements
+ * 0 : no extra information
+ * 1 : debugging information
+ * 2 : extended debugging information
+ *
+ * HTML
Bug#299144: Keep PHPWiki out of Sarge
On Sat, 2006-01-07 at 11:07 +0100, Thijs Kinkhorst wrote: Sarge has been released by now; the package has been adopted by a new maintainer who made quite some progress in reducing the bug list. Is it now time to let the package flow into testing? [puts maintainer hat on] I would have no problem with this happening, however I wasn't personally planning to close this bug until the next upload which I'm planning to get out the door towards the end of Jan / early Feb. If you feel that it would be beneficial for PHPwiki to enter testing before then, please go ahead and close the bug. While it's still not perfect (particularly on upgrades) the package is definitely in much better shape now :) Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 275 611 544 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315467: Quagga explicitly flushes all routes when upgrading or restarting
On Mon, 2005-11-28 at 00:54 +0100, Christian Hammers wrote: Using the --retain option does not do what you want. It does, in so far you are indeed right, retain the routes when the Daemons are stopped but it DOES NOT import them when they are started again. The kernel continues to use them though. snip So as far as I see it, the situation is still the same. There is no known unix routing suite that is able to get updated e.g. stopped and restarted without loosing the BGP/OSPF/etc routes and thus I can only ask the admin if he really likes to upgrade Quagga. I don't like this neither but please provide a working alternative that's better. I certainly I agree with your comments above Christian, but I have a question. Why is the explcit flush needed in the init script? In my experience zebra does a great job of removing any routes it has created from the kernel's routing table on it's own. If this explicit flush was removed from the init script then it would be much easier for the site admin to implement site specific policy for things (such as --retain) that are not suitable for the Debian package. Does this make sense? -- Matt Brown [EMAIL PROTECTED] Mob +64 275 611 544 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294501: php4-pgsql: php4-psql causes apache to segfault upon startup
On Sat, 2005-03-26 at 17:45 +1100, Adam Conrad wrote: Hrm, on my system, I got the segv even with a more minmal config (I can remove the vhost, log_module, and dir_module, and it still dies). Interesting, I definitely need those directives in the config file to cause a segfault. If I reverse imap.so and pgsql.so in my php.ini (so that pgsql is loaded first), my segv disappears. I don't suppose you'd have any luck with trying that as well? Reversing those entries does solve the segfault. As does included mod_ssl in the apache config as I reported earlier. Can the unreproducible tag be removed from this bug now? -- Matt Brown [EMAIL PROTECTED] Mob +64 275 611 544 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294501: Question regarding apache-crash
Hi David, On Sat, 2005-02-26 at 00:42 +0100, David Schmitt wrote: Do you have ulimits (max RAM, max CPU or so) enabled on your system? A friend of mine had apache crashing without useful errormessages after memory limiting apache and installing another module and thus exceeding the allowance... There are no ulimits enabled on the system that I am aware of (ie. It's a bog standard sarge install, which afaik doesn't setup ulimits by default, if it does there may be some, but I haven't setup any myself). Regards -- Matt Brown [EMAIL PROTECTED] Mob +64 275 611 544 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294501: php4-pgsql: php4-psql causes apache to segfault upon startup
On Wed, 2005-02-09 at 23:36 -0800, Steve Langasek wrote: Yes indeed, since php4-imap is the traditional home for this particular bug, I'm reassigning. Can you send version/dependency information for the php4-imap package you have installed, and if appropriate, upgrade those packages as well to see if that changes the symptoms? xenon:/etc/php4/apache# dpkg -s php4-imap Package: php4-imap Status: install ok installed Priority: optional Section: web Installed-Size: 111 Maintainer: Adam Conrad [EMAIL PROTECTED] Architecture: i386 Source: php4 Version: 4:4.3.10-2 Replaces: php4-cgi-imap Depends: libc-client2002edebian, libc6 (= 2.3.2.ds1-4), libcomerr2 (= 1.33-3), libkrb53 (= 1.3.2), libpam0g (= 0.76), libssl0.9.7, debconf (= 0.5) | debconf-2.0, phpapi-20020918, php4-common (= 4:4.3.10-2) I just apt-get dist-upgrade'd my system, and symptoms are still exactly the same. I've included versions of the dependencies listed above for your reference ii libc-client2002edebian 2002edebian1-6 UW c-client library for mail protocols ii libc62.3.2.ds1-20 GNU C Library: Shared libraries and Timezone data ii libcomerr2 1.35-6 The Common Error Description library ii libkrb53 1.3.6-1 MIT Kerberos runtime libraries ii libpam0g 0.76-22 Pluggable Authentication Modules library ii libssl0.9.7 0.9.7e-2 SSL shared libraries After reading back through the numerous other similar archived reports for php4-imap, I installed libapache-mod-ssl to see what effect that would have. Surprise surprise, if I load mod_ssl (even if it's not being used), apache doesn't segfault, even with the imap and pgsql modules enabled. Regards -- Matt Brown [EMAIL PROTECTED] Mob +64 275 611 544 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294501: php4-pgsql: php4-psql causes apache to segfault upon startup
On Wed, 2005-02-09 at 21:01 -0800, Steve Langasek wrote: Please upgrade to a current version of libpq3 and let me know if this segfault goes away. [EMAIL PROTECTED]:~$ dpkg -s libpq3 Package: libpq3 Status: install ok installed Priority: optional Section: libs Installed-Size: 324 Maintainer: Martin Pitt [EMAIL PROTECTED] Architecture: i386 Source: postgresql Version: 7.4.7-1 Segfault still exists. If not, please run gdb apache, run -X so we can get a backtrace of this segfault (strace output is not generally useful for debugging segfaults), and forward a copy of your php.ini file. Hmm, not sure if this segfault will be much help, the apache binary has had debugging information stripped... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 635)] 0x40765324 in ERR_add_error_data () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 (gdb) bt full #0 0x40765324 in ERR_add_error_data () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 No symbol table info available. #1 0x406ce380 in ?? () No symbol table info available. #2 0x403bd380 in ssl3_undef_enc_method () from /usr/lib/i686/cmov/libssl.so.0.9.7 No symbol table info available. #3 0x40765320 in ERR_add_error_data () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 No symbol table info available. #4 0x0810f028 in ?? () No symbol table info available. #5 0x0810f028 in ?? () No symbol table info available. #6 0x403bd380 in ssl3_undef_enc_method () from /usr/lib/i686/cmov/libssl.so.0.9.7 No symbol table info available. #7 0x40760f45 in lh_insert () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 No symbol table info available. #8 0x0810f028 in ?? () No symbol table info available. #9 0x403bd380 in ssl3_undef_enc_method () from /usr/lib/i686/cmov/libssl.so.0.9.7 No symbol table info available. #10 0xb8d8 in ?? () No symbol table info available. #11 0x407648ce in ERR_add_error_data () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 No symbol table info available. #12 0x0001 in ?? () No symbol table info available. #13 0x14064057 in ?? () No symbol table info available. #14 0x407dcd04 in ?? () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 No symbol table info available. #15 0x407c526d in CAST_S_table7 () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 No symbol table info available. #16 0x0810f028 in ?? () No symbol table info available. #17 0xb968 in ?? () No symbol table info available. #18 0x40764b3d in ERR_add_error_data () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 No symbol table info available. #19 0x403bd380 in ssl3_undef_enc_method () from /usr/lib/i686/cmov/libssl.so.0.9.7 No symbol table info available. #20 0x407c526d in CAST_S_table7 () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 No symbol table info available. #21 0x0185 in ?? () No symbol table info available. #22 0x407dcd04 in ?? () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 No symbol table info available. #23 0x403bd388 in ssl3_undef_enc_method () from /usr/lib/i686/cmov/libssl.so.0.9.7 No symbol table info available. #24 0x1400 in ?? () No symbol table info available. #25 0x407635f3 in ERR_load_ERR_strings () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 No symbol table info available. #26 0x403bd380 in ssl3_undef_enc_method () from /usr/lib/i686/cmov/libssl.so.0.9.7 No symbol table info available. #27 0x407df5a0 in p_CSwift_ReleaseAccContext () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 No symbol table info available. ---Type return to continue, or q return to quit--- #28 0x40baa458 in php_builtin_extensions () from /usr/lib/apache/1.3/libphp4.so No symbol table info available. #29 0x4076352d in ERR_load_ERR_strings () from /usr/lib/i686/cmov/libcrypto.so.0.9.7 No symbol table info available. #30 0x403be010 in ?? () from /usr/lib/i686/cmov/libssl.so.0.9.7 No symbol table info available. #31 0x001e in ?? () No symbol table info available. #32 0x40baa458 in php_builtin_extensions () from /usr/lib/apache/1.3/libphp4.so No symbol table info available. #33 0x403b69b2 in ERR_load_SSL_strings () from /usr/lib/i686/cmov/libssl.so.0.9.7 No symbol table info available. #34 0x0014 in ?? () No symbol table info available. #35 0x403bd380 in ssl3_undef_enc_method () from /usr/lib/i686/cmov/libssl.so.0.9.7 No symbol table info available. #36 0x40baa590 in ?? () from /usr/lib/apache/1.3/libphp4.so No symbol table info available. #37 0x408f0267 in zm_startup_openssl () from /usr/lib/apache/1.3/libphp4.so No symbol table info available. Previous frame inner to this frame (corrupt stack?) php.ini attached as requested. -- Matt Brown [EMAIL PROTECTED] Mob +64 275 611 544 www.mattb.net.nz [PHP] ;;; ; WARNING ; ;;; ; This is the default settings file for new PHP installations. ; By default, PHP installs itself with a configuration suitable for ; development purposes, and *NOT* for production purposes. ; For several security-oriented considerations that should be taken ; before going online with your site, please consult php.ini
