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#736192: scamper: please package new upstream version
Thanks Zack, Unfortunately there was a mismatch in dates between Debian's freeze and Scamper's releases which meant we got stuck with the old version, and then a new baby in the family meant I haven't had time to package the new version post freeze. I appreciate your patch and I'll try and get it merged and uploaded ASAP (this week, or the weekend at the latest). Cheers On Mon, Jan 20, 2014 at 8:38 PM, Zack Weinberg za...@panix.com wrote: Package: scamper Version: 20111202b-1 Severity: wishlist Please package the current version of Scamper. Upstream has moved to http://www.caida.org/tools/measurement/scamper/ and there is a substantially newer version, 20130824. For your convenience I have updated the packaging and will attach a new .debian.tar.xz and a diff from the previous version. This also fixes the outstanding bug #733581, updates to debhelper 9 and multiarch for the shared library, and fixes the more significant lintian errors. (Lines in the diff that appear to do nothing are removing trailing whitespace.) This packaging corresponds to upstream tarball http://www.caida.org/tools/measurement/scamper/code/scamper-cvs-20130824.tar.gz -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages scamper depends on: ii libc62.17-97 ii libscamperfile0 20111202b-1 scamper recommends no packages. scamper suggests no packages. -- no debconf information -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602013: RM: phpwiki -- ROM; package not up to Debian standards
Package: ftp.debian.org Severity: normal Hi, I'd like to request the removal of PHPwiki from the archive. The package is in a fairly bad state and has just been removed from testing (#601512) at the request of the security team (and although I wasn't consulted on their decision I don't disagree with it.). I filed (#600371) several weeks ago asking for help to bring the package up to our current standards and haven't had a response. Upstream development of PHPwiki is extremely slow/stalled and many of the issues with embedded code are not easily resolved without upstream changes. PHPwiki is not a widely used package in Debian. See #601512 for even more reasons why this package isn't fit to remain in Debian. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601512: Removal request for phpwiki filed
Hi, The security team requested the removal of PHPwiki from testing in #601512, and although I wasn't consulted (or notified) of the request I do not disagree with it and it is in-line with the course of action for this package that I outlined in the RFA bug #600371 several weeks ago. Consequently I've gone ahead and filed #602013 to request that the ftp-masters remove phpwiki from Debian completely. This mail serves as notification of that action to interested parties and also to close the RFA bug as it is now obsolete. Thanks. -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600371: RFA: phpwiki -- informal collaborative website manager
Package: wnpp Severity: normal I request an adopter for the phpwiki package. I'm actually willing to stay on as a co-maintainer, but the package needs a huge amount of work to be fit for release and continued inclusion in Debian that I think it's best for someone else to take it on completely if they are interested. The primary issue is that the PHPwiki upstream development is extremely slow, and there are a number of issues in the codebase (embedded libraries mainly) which aren't going to be addressed upstream in the near future and need someone with significant time to patch around for Debian. The current package has a RC bug since it doesn't work at all with PHP5.3, there is a release candidate for phpwiki 1.4 (1.4.0rc1) available upstream which fixes this. The final release was meant to be real soon as of Aug 4, but hasn't materialised yet. I've been holding off packaging 1.4.0rc1 in favour of the real release, but even if we were to package 1.4.0rc1 the embedded library issues remain and I don't have time to do all the patcing myself. So please let me know if you're interested in taking over this package, otherwise I plan to file a bug to have it removed from the archive sometime next week. The package description is: PHPWiki is a reimplementation in PHP of the wiki engine behind the original WikiWikiWeb at http://c2.com/cgi-bin/wiki?WikiWikiWeb. A wiki is a dynamic website which can be edited by anyone at any time. Over time bad information is naturally filtered out, since the barrier to modification is very low. Malicious or accidental destruction is limited by keeping backup versions of all pages. . This package includes introductory material for the wiki concept, which can be viewed via the wiki interface when the package has been installed. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595817: ITP: libpam-ssh-agent -- PAM module providing authentication via ssh-agent
Package: wnpp Severity: wishlist Owner: Matt Brown ma...@debian.org * Package name: libpam-ssh-agent Version : 0.9.2 Upstream Author : Jamie Beverly jamie.r.beve...@gmail.com * URL : http://sourceforge.net/projects/pamsshagentauth/ * License : BSD Programming Lang: C Description : PAM module providing authentication via ssh-agent This pluggable authentication module (PAM) provides authentication via secure shell (SSH) agent. Written with sudo in mind, but like any auth PAM module, can be used for many purposes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595817: ITP: libpam-ssh-agent -- PAM module providing authentication via ssh-agent
On Mon, Sep 6, 2010 at 9:57 PM, Timo Juhani Lindfors timo.lindf...@iki.fi wrote: Matt Brown ma...@debian.org writes: This pluggable authentication module (PAM) provides authentication via secure shell (SSH) agent. Written with sudo in mind, but like any auth PAM module, can be used for many purposes. Is there any way to see what sudo command is being authenticated? sudo logs the command being run as part of it's standard logging, e.g: Sep 6 21:18:45 neon sudo[1589]: pam_ssh_agent_auth: Authenticated: `matt' as `matt' using /etc/security/authorized_keys Sep 6 21:18:45 neon sudo: matt : TTY=pts/1 ; PWD=/home/matt ; USER=root ; COMMAND=/bin/bash -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595817: ITP: libpam-ssh-agent -- PAM module providing authentication via ssh-agent
On Mon, Sep 6, 2010 at 10:18 PM, Timo Juhani Lindfors timo.lindf...@iki.fi wrote: Matt Brown ma...@debian.org writes: sudo logs the command being run as part of it's standard logging, e.g: Yes after the fact. I meant, is there a way to see before I click accept in my ssh-agent? Not currently. If you think such a feature would be useful you're probably best to talk to the upstream developers directly. Cheers -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544100: phpwiki: General update after the debconf review process
Hi Christian, On Sat, Sep 19, 2009 at 9:24 PM, Christian Perrier bubu...@debian.org wrote: Please note that this patch applies to the templates and control file(s) of your package as of Friday, August 14, 2009. If your package was updated in the meantime, I may have updated my reference copybut I also may have missed that. This is indeed why I suggested you do not modified such files while the review process was running, remember..:-) It is now safe to upload a new package version with these changes. Please notify me of your intents with regards to this. Thanks very much, to you and the translators for the work on this package. I will review the changes and make a new upload as soon as possible, with my current schedule this should be sometime before the end of September. Thanks again. -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544100: phpwiki: [debconf_rewrite] Debconf templates and debian/control review
On Fri, Aug 28, 2009 at 11:34 PM, Christian Perrierbubu...@debian.org wrote: Quoting Matt Brown (m...@mattb.net.nz): My only comment is about the changing of some words from British english spelling to American english spelling. It makes me sad, but I assume it is following some pre-defined specification for Debian to always follow the American spellings? This has been a trade-off. When we started the review process, we checked the web site and the major documentations and found out that US spelling was in majority. As a consequence, and even though most reviewers are UK folks (except me, of coursebut I'm closer from UK than US..:-)), we settled for US spelling. OK, sounds fine. We should maybe choose NZ spelling, after all..:) (but I guess you guys use UK spelling, you just use a subtle different way to *pronounce* things..:-)) Heh, yes. We use the UK spelling in NZ, and I'm living in Ireland at the moment, so I'm definitely more in tune with the British spellings, although working for an American company means that I'm forever switching between the two. Anyway, thanks for your prompt answer and ACK. I'll launch the translation update process. Thanks again, look forward to receiving them. -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544100: phpwiki: [debconf_rewrite] Debconf templates and debian/control review
Hi Christian, On Fri, Aug 28, 2009 at 12:54 PM, Christian Perrierbubu...@debian.org wrote: Please review the suggested changes, and if you have any objections, let me know in the next 3 days. Thanks for your work on this, I have no objections to the changes. My only comment is about the changing of some words from British english spelling to American english spelling. It makes me sad, but I assume it is following some pre-defined specification for Debian to always follow the American spellings? The call for translation updates and new translations will run until about Monday, September 21, 2009. Please avoid uploading a package with fixed or changed debconf templates and/or translation updates in the meantime. Of course, other changes are safe. snip Around Tuesday, September 22, 2009, I will contact you again and will send a final patch summarizing all the updates (changes to debconf templates, updates to debconf translations and new debconf translations). Again, thanks for your attention and cooperation. Thank you! -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540880: phpwiki: Minor error in your Debconf template
On Tue, Aug 11, 2009 at 7:34 AM, Christian Perrierbubu...@debian.org wrote: Usually, when templates are changed in a package, I take this opportunity to trigger a full review by debian-l10n-english. Being on holidays, I skipped that one, which explains why I missed these details. Please do. I made these changes based on how I read the suggestions lintian gave me. If you're suggesting that these changes are incorrect then a review by someone else might be worthwhile. Cheers -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505043: Please use system php-fpdf
package phpwiki tag 505043 + help thanks On Sat, Nov 8, 2008 at 7:39 PM, Joey Schulzej...@infodrom.org wrote: Package: phpwiki Version: n/a It seems that phpwiki distributes an embedded copy of fpdf which is included in Debian as system-wide package php-fpdf. From a security point of view it is unacceptable to distribute several copies of the same library, thus, please switch to using the system-wide library. The version of fpdf shipped within PHPwiki appears to be 0.52 vs the version 0.53 in the debian php-fpdf package. There appears to have been quite some code reorganisation within fpdf between these two revisions so it's not immediately apparent if there are any changes that would be relevant to the interface between fpdf and PHPwiki. More importantly however, the PDF generation functionality in PHPwiki in the default configuration of the package appears to be broken (fpdf complains about data already output so it is unable to set the Content-Type headers), making it difficult to test whether swapping out the included fpdf for a packaged copy works at all. I'm tagging this bug as help needed as we need someone to determine if the PDF generation breakage is our fault, or an upstream bug and then act accordingly. -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540061: RFH: phpwiki -- informal collaborative website manager
Package: wnpp Severity: normal I request assistance with maintaining the phpwiki package. In particular, I need assistance dealing with a number of bugs related to code from other packages that is embedded within the PHPwiki codebase. There is also at least one further instance of this reported by lintian which is not yet in the BTS. PHPwiki wasn't really designed to have these dependencies fulfilled outside of the PHPwiki source and the upstream has not made a release for quite some time (although there are sporadic commits to the upstream svn repository). Some of the code included in PHPwiki is older than the currently packaged versions and a quick diff shows large changes between the packaged versions and PHPwiki's embedded copy. Anyone interested in working on this will likely need to be willing to modify PHPwiki to support loading the dependencies from outside of the PHPwiki source tree, fix any breakage/changes required by the newer versions and then submit the patches upstream. I don't have the time to undertake this kind of work at the moment. Let me know if you are interested. Cheers -- Matt Brown ma...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529576: phpwiki: Should depend on libnusoap-php instead of shipping it
package phpwiki tag 529576 + help thanks bts On Wed, May 20, 2009 at 9:28 AM, Olivier Berger olivier.ber...@it-sudparis.eu wrote: FYI, libnusoap-php entered Debian (http://packages.qa.debian.org/n/nusoap.html). A copy of nusoap is shipped in the phpwiki package. The phpwiki packaging should then be updated to depend on libnusoap-php instead of shipping it. Please check if there's no version discrepency when makeing such change, which could cause problems, though. The version of phpwiki shipped within PHPwiki is 0.6.3 vs the recently packaged 0.7.3. The diff is large: m...@neon:~/debs/phpwiki/trunk/lib/nusoap$ diff -uwb nusoap.php /home/matt/otherdebs/nusoap-0.7.3/lib/nusoap.php | diffstat nusoap.php | 7008 +++-- 1 file changed, 5458 insertions(+), 1550 deletions(-) This is not a bug that I'll be able to resolve myself in any reasonable timeframe as I do not have the time to scour through a diff that large to verify the changes. The best solution to this bug will be for upstream to either update nusoap in PHPwiki (seems unlikely as it's nearly dead upstream) or for someone to provide a patch to the current package that they have verified does not break any functionality. As such I'm tagging this bug as help wanted. Thanks -- Matt Brown m...@mattb.net.nz Mob +353 86 608 7117 www.mattb.net.nz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492073: setting package to phpwiki, tagging 489818, tagging 482777, tagging 450310, tagging 492073
# Automatically generated email from bts, devscripts version 2.10.34 # via tagpending # # phpwiki (1.3.14-3.1) UNRELEASED; urgency=low # # * Remove extraneous comma in sqlite-initialize.sql. (Closes: #482777) # * Include updated watch file thanks to Raphael Geissert. (Closes: #450310) # * Updated pt translation thanks to Ricardo Silva. (Closes: #489818) # * Updated nl translation thanks to Thijs Kinkhorst. (Closes: #492073) package phpwiki tags 489818 + pending tags 482777 + pending tags 450310 + pending tags 492073 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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#456995: ITP: scamper - advanced traceroute and network measurement utility
Package: wnpp Severity: wishlist * Package name: scamper Version : 20070523i Upstream Author : Matthew Luckie [EMAIL PROTECTED] * URL or Web page : http://www.wand.net.nz/scamper/ * License : GNU GPL v2 Description : advanced traceroute and network measurement utility scamper is a program that is able to conduct Internet measurement tasks to large numbers of IPv4 and IPv6 addresses, in parallel, to fill a specified packets-per-second rate. Currently, it supports the well-known ping and traceroute techniques. . scamper can do ICMP-based Path MTU discovery. scamper starts with the outgoing interface's MTU and discovers the location of Path MTU bottlenecks. scamper performs a PMTUD search when an ICMP fragmentation required message is not returned to establish the PMTU to the next point in the network, followed by a TTL limited search to infer the where failure appears to occur. -- 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#377692: possibly solved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've just uploaded a new version of PHPwiki 1.3.14-1 which I couldn't reproduce any of the previous memory related errors that I have seen with. I'm not aware of any specific fixes that went into this new version, but it's also the first version of the package that uses only PHP5 which may also have provided some improvements. Unless I hear otherwise that memory issues are still being regularly encountered I intend to close this bug in a week or two when the new package moves into testing. - -- 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 iD8DBQFG/ofs/pqN2EBUqwgRAmRqAJ9s5Bq/6Gjg4SKsfFNskYcLzmw+jACfZtkW Aik6xYirIflT263+E+AqXyQ= =ZC2y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441936: phpwiki: debconf dependency unsatisfiable with cdebconf
On 12/09/2007, Jiří Paleček [EMAIL PROTECTED] wrote: your package still depends on debconf without an alternate of debconf-2.0. This means it doesn't allow cdebconf to be installed. See http://lists.debian.org/debian-devel/2005/08/msg00136.html for details. Thanks, I'm on a semi-vac due to lack of a functioning Debian environment at the moment, but should be able to have an updated package fixing this uploaded within the next month. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +353 86 608 7117 www.mattb.net.nz
Bug#429201: Any progress on security issue?
On 29/08/2007, Thijs Kinkhorst [EMAIL PROTECTED] wrote: Is there any progress on this security issue? The fix is in the upstream released 1.3.13p1 package. I'm currently Debian computer less after my move to Ireland (I should have updated my VAC on -private sorry). I have a new computer ordered and should be able to provide a new package within 2 weeks, however please feel free to NMU before then. -- 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#425262: dbconfig-common: Support of sqlite3
dbconfig-common seems to not supporte sqlite3. If only sqlite3 is installed, dbconfig-common complains about sqlite not being installed. sqlite3 executable name is sqlite3 instead of sqlite. Adding sqlite3 support should be relatively straight forward and can hopefully be accomplished using the existing sqlite code by creating a variable to distinguish between calling the sqlite or sqlite3 binary. The command interface has remained the same only the database format changed. Some code to migrate between the databases would be nice, and relatively simple to write to. Adding sqlite3 support is on my TODO list, but I'm currently settling in to a new country, so it's not likely to happen in the next month, I'm happy to answer any questions about the sqlite code though :) Cheers -- Matt Brown [EMAIL PROTECTED] Mob +353 85 170 3177 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425262: dbconfig-common: Support of sqlite3
On 5/20/07, Vincent Bernat [EMAIL PROTECTED] wrote: Do you prefer a separate backend for sqlite3 (so, no conversion needed) or do you prefer a backend that will use sqlite3 if available (or ask the user ?) and convert from sqlite to sqlite3 ? My impression is that it should be a separate backend so that an administrator can choose between using sqlite or sqlite3 for their database. A separate option could then be added to allow upgrades between sqlite and sqlite3 if desired. I don't think that automatically upgrading databases to sqlite3 if it is available is a good idea, as it becomes hard to ensure that the package is depending on correct sqlite3 bindings for php, python, ruby, etc rather than plain old sqlite bindings. What I was trying to say originally is that regardless of how sqlite3 is handled my hope is that it doesn't require too much duplication of dbconfig-common code. Even if it is functionally a completely separate backend to sqlite it should still be able to share most of the exist sqlite code. Does that make sense? -- Matt Brown [EMAIL PROTECTED] Mob +353 85 170 3177 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425262: dbconfig-common: Support of sqlite3
On 5/20/07, Vincent Bernat [EMAIL PROTECTED] wrote: Here is a patch that adds sqlite3 backend. It is very light and I have tested with sqlite and sqlite3 examples without any problem (I have tried without sqlite3 and without sqlite installed respectively). Awesome, I can't actually test it, but it looks sane to me. My only question is whether we need a whole second test package for sqlite3 in the examples directory. But that's a minor issue. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +353 85 170 3177 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416796: phpwiki: [INTL:pt] Portuguese translation for debconf messages
tag 416796 + help thanks Thanks for these updates, I'm about to leave New Zealand and I'm unlikely to have Internet access for four+ weeks. If someone wants to NMU PHPwiki to add these updates they would be most welcome. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz
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#397089: [Dbconfig-common-devel] Re: Bug#397089: dbconfig-common: migration fails when dbconfig-load-include returns empty values
Matt Brown wrote:
So I'll whip up a patch that ignores the d-l-i import if
a) dbtype is unset OR
b) d-l-i returns non-zero error status
If dbtype is set and d-l-i returns zero, the other values are pre-seeded
as per the current behaviour and installation proceeds as per normal.
Patch attached. Only minimal changes were required from the previous
version. dbconfig-load-include already returned a non-zero error status
for every case, except when a custom include script returned an error.
dbconfig-common now checks the return value of dbconfig-load-include and
gracefully stops the migration if one of the above conditions is met.
Hopefully there are no further objections to this patch?
--
Matt Brown
Debian Developer
[EMAIL PROTECTED]
Mob +64 21 611 544 www.mattb.net.nz
diff -ur dbconfig-common-1.8.28/dbconfig-load-include dbconfig-common-1.8.28.1/dbconfig-load-include
--- dbconfig-common-1.8.28/dbconfig-load-include 2006-08-21 23:44:35.0 +1200
+++ dbconfig-common-1.8.28.1/dbconfig-load-include 2006-11-18 14:56:09.0 +1300
@@ -145,6 +145,7 @@
fi
inputfile=$1
+rv=0
if [ ! $inputfile ]; then
echo error: you must specify an inputfile 2
@@ -237,8 +238,9 @@
exec)
sh -c $inputfile
+ rv=$?
;;
esac
-exit 0
+exit $rv
diff -ur dbconfig-common-1.8.28/dpkg/config dbconfig-common-1.8.28.1/dpkg/config
--- dbconfig-common-1.8.28/dpkg/config 2006-10-13 10:52:19.0 +1300
+++ dbconfig-common-1.8.28.1/dpkg/config 2006-11-18 14:57:17.0 +1300
@@ -61,11 +61,21 @@
db_set $dbc_package/internal/reconfiguring true
fi
+ ##
+ ## start new dbc upgrade section
+ ##
+ # if there is a previously existing version already installed
+ # *and* the maintainer has provided the first version that used
+ # dbconfig-common *and* this version is newer than the
+ # previously installed version... do the dbc import stuff.
+ if [ $migrating ]; then
+ dbc_migrate
+ fi
+
# and start our beautiful state-machine
- # we start in STATE=1 (install_question) in all but two situations:
- # - we're migrating from a previous non-dbc version
+ # we start in STATE=1 (install_question) in all but one situation:
# - we're installing a frontend/readonly app
- if [ ! $migrating ] [ ! $dbc_frontend ]; then
+ if [ ! $dbc_frontend ]; then
STATE=1
else
STATE=2
@@ -86,69 +96,6 @@
fi
##
- ## start new dbc upgrade section
- ##
- # if there is a previously existing version already installed
- # *and* the maintainer has provided the first version that used
- # dbconfig-common *and* this version is newer than the
- # previously installed version... do the dbc import stuff.
- if [ $migrating ]; then
- # if dbc_load_include is set, determine the format
- # and location of the old config file
- if [ $dbc_load_include ]; then
-iformat=`echo $dbc_load_include | cut -d: -f1`
-ifile=`echo $dbc_load_include | cut -d: -f2-`
- fi
-
- ##
- ## if they want to import settings from a previous
- ## non-dbc version, do that and mark the questions
- ## skipped
- ##
- if [ $ifile ] [ -f $ifile ]; then
-dbc_logpart migrating old settings into dbconfig-common:
-if [ $dbc_debug ]; then
- dbc_debug dbconfig-load-include $dbc_load_include_args -f $iformat $ifile
- dbconfig-load-include $dbc_load_include_args -f $iformat $ifile
-fi
-eval `dbconfig-load-include $dbc_load_include_args -f $iformat $ifile`
-# if the dbtype is hardcoded, reset it no matter what
-# dbconfig-load-include tells us
-if [ $dbc_hardcoded_dbtype ]; then
- dbc_dbtype=$dbc_hardcoded_dbtype
-fi
-
-for f in database-type $dbc_dbtype/method db/dbname; do
- db_fset $dbc_package/$f seen true || true
-done
-if echo $dbc_authenticated_dbtypes | grep -q $dbc_dbtype; then
- for f in pgsql/authmethod-admin pgsql/authmethod-user $dbc_dbtype/admin-user db/app-user; do
- db_fset $dbc_package/$f seen true || true
- done
- db_set $dbc_package/db/app-user $dbc_dbuser
- db_set $dbc_package/$dbc_dbtype/app-pass $dbc_dbpass
- db_set $dbc_package/password-confirm $dbc_dbpass
-fi
-if echo $dbc_remote_dbtypes | grep -q $dbc_dbtype; then
- for f in remote/host remote/newhost remote/port ; do
- db_fset $dbc_package/$f seen true || true
- done
- db_set $dbc_package/remote/host $dbc_dbserver
- db_set $dbc_package/remote/newhost $dbc_dbserver
- db_set $dbc_package/remote/port $dbc_dbport
- if [ $dbc_dbserver ]; then
- db_set $dbc_package/$dbc_dbtype/method tcp/ip
- fi
-fi
-
-db_set $dbc_package/database-type $dbc_dbtype
-db_set $dbc_package/db/dbname $dbc_dbname
-
-dbc_logline done
- fi
- fi
-
- ##
## start multidb section
##
# if the dbtype is hardcoded (using config.mysql, etc), use that
@@ -398,3 +345,73 @@
db_set $dbc_package/internal/skip-preseed true
}
+
+dbc_migrate() {
+
+ # if dbc_load_include is set, determine the format
+ # and location of the old
Bug#397089: [Dbconfig-common-devel] Re: Bug#397089: dbconfig-common: migration fails when dbconfig-load-include returns empty values
sean finney wrote: the problem is most/all of the values can be blank, depending on the package. for example, an unset db_port setting means the default port, likewise for the host, and in some instances applications will even default to a hardcoded user. of course if all of the values are blank at the same time, that could be a sign that there's a problem... I think the only value that is absolutely required is dbtype. i can't recall right now if it's already the case, but for some cases if the file can't be read or parsed, we could rig d-l-i to return nonzero error status and catch it in the relevant maintscript hooks. If we do this, then we avoid the problem of the dbtype being always set for single forced type packages. Perhaps the real solution is to make dbconfig-load-include only act as hints and have the user still asked the questions... this is an option. in fact, this is already what's happening iirc, but the questions are explicitly set as seen so they're not prompted, i *think*. so making this happen would probably mean less code as opposed to more :) Yes, this is what happens, but if d-l-i doesn't return a dbtype then the setting to seen fails. So I'll whip up a patch that ignores the d-l-i import if a) dbtype is unset OR b) d-l-i returns non-zero error status If dbtype is set and d-l-i returns zero, the other values are pre-seeded as per the current behaviour and installation proceeds as per normal. I think that will fix the original bug and work in the exception cases you pointed out. Cheers -- Matt Brown Debian Developer [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#397089: [Dbconfig-common-devel] Re: Bug#397089: dbconfig-common: migration fails when dbconfig-load-include returns empty values
sean finney wrote: what if the app is a single dbtype application (and thus always has dbc_dbtype set)? otherwise, i agree with the approach, and it cleans up the state machine area quite a bit which is a good thing. Hmm, that could be a problem yes. Unfortunately I'm not familiar with all the nuances of dbconfig-common to know what a good solution to this is. I could check every return value from dbconfig-load-include and only error out if they are all blank, or we could get more sophisticated and check only the required values for the selected database type... Perhaps the real solution is to make dbconfig-load-include only act as hints and have the user still asked the questions... I have time to work on a patch, but I'll need your expertise and knowledge of the code to suggest which approach fits in best. Cheers -- Matt Brown Debian Developer [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#397089: dbconfig-common: migration fails when dbconfig-load-include returns empty values
Package: dbconfig-common
Version: 1.8.28
Severity: important
Package upgrades fail if dbconfig-load-include returns empty output
during the migration from a package without dbconfig-common support.
This situation can occur if dbconfig-load-include is unable to parse the
specified configuration file, or the configuration file currently uses a
database type that is not supported by dbconfig-common.
An example from the PHPwiki package.
phpwiki is using a custom load script, eg
dbc_load_include=exec:$loadscript
In some cases the script cannot parse the config file (it's using an
unsupported db type) and returns blank output, eg:
dbc_dbuser=''
dbc_dbpass=''
dbc_basepath=''
dbc_dbname=''
dbc_dbserver=''
dbc_dbport=''
dbc_dbtype=''
This is the same output that dbconfig-load-include outputs if run in
other modes and given a file that does not contain valid information.
dbconfig-common then tries to load the answer into the debconf
database, because no dbtype is set the templates it tries to use do not
exist.
+ read -r _db_internal_line
+ RET='value set'
+ case ${_db_internal_line%%[ ]*} in
+ return 0
+ db_set phpwiki//app-pass ''
+ _db_cmd 'SET phpwiki//app-pass' ''
+ IFS=' '
+ printf '%s\n' 'SET phpwiki//app-pass '
+ IFS='
'
+ read -r _db_internal_line
+ RET='10 phpwiki//app-pass doesn'\''t exist'
+ case ${_db_internal_line%%[ ]*} in
+ return 10
dpkg: error processing phpwiki (--install):
subprocess post-installation script returned error exit status 10
I think the solution to this bug is that dbconfig-common should check
the output to dbconfig-load-include to ensure that valid answers were
able to be extracted, and only load the answers into debconf if that is
true. If nothing could be read from the existing config, the user should
see a warning and dbconfig-common should proceed as if its a new
installation (ask the user if they want to use dbconfig-common, etc).
I'll see if I can come up with a patch to implement this behaviour.
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.16.18
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Versions of packages dbconfig-common depends on:
ii debconf [debconf-2.0] 1.5.8 Debian configuration management sy
ii ucf 2.0016 Update Configuration File: preserv
dbconfig-common recommends no packages.
-- debconf information:
dbconfig-common/dbconfig-upgrade: true
* dbconfig-common/remote-questions-default: true
dbconfig-common/db/basepath:
dbconfig-common/pgsql/revertconf: false
dbconfig-common/install-error: abort
dbconfig-common/pgsql/no-empty-passwords:
dbconfig-common/mysql/method: unix socket
dbconfig-common/pgsql/admin-user: postgres
dbconfig-common/dbconfig-install: true
dbconfig-common/pgsql/no-user-choose-other-method:
dbconfig-common/upgrade-backup: true
dbconfig-common/internal/reconfiguring: false
dbconfig-common/passwords-do-not-match:
dbconfig-common/pgsql/authmethod-admin: ident
dbconfig-common/remove-error: abort
dbconfig-common/internal/skip-preseed: false
dbconfig-common/db/dbname:
* dbconfig-common/remember-admin-pass: false
dbconfig-common/mysql/admin-user: root
dbconfig-common/dbconfig-reinstall: false
dbconfig-common/remote/host:
dbconfig-common/pgsql/manualconf:
dbconfig-common/pgsql/changeconf: false
dbconfig-common/remote/newhost:
dbconfig-common/pgsql/method: unix socket
dbconfig-common/pgsql/authmethod-user:
dbconfig-common/upgrade-error: abort
dbconfig-common/database-type:
dbconfig-common/dbconfig-remove: true
dbconfig-common/db/app-user:
dbconfig-common/remote/port:
dbconfig-common/purge: false
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397089: dbconfig-common: migration fails when dbconfig-load-include returns empty values
tag 397089 + patch thanks Matt Brown wrote: I think the solution to this bug is that dbconfig-common should check the output to dbconfig-load-include to ensure that valid answers were able to be extracted, and only load the answers into debconf if that is true. If nothing could be read from the existing config, the user should see a warning and dbconfig-common should proceed as if its a new installation (ask the user if they want to use dbconfig-common, etc). I'll see if I can come up with a patch to implement this behaviour. Ok, patch attached. This changes the behaviour of dbconfig common in three ways 1) If the dbconfig-load-include script fails to set dbc_dbtype it is assumed to have failed and none of its return values are used. 2) The user is always asked whether they want to use dbconfig-common to manage the database. Previously this only happened for new installs, migrations were assumed to want to use dbconfig-common. I see no justification for why the user shouldn't have a choice when upgrading. 3) dbconfig-load-include now runs before the state machine starts so that the user can make a decision on whether to use dbconfig-common based on whether or not the migration succeeded. I think this is a reasonable solution to the problem. I've only filed the bug as important as it breaks a subset of cases, but it would be nice to get this fix into etch if possible. Cheers -- Matt Brown Debian Developer [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#396712: phpwiki: post-installation script error: return: can only `return' from a function or sourced script
Matt Brown wrote: Hmm, I see the bug, I'll upload a fixed package tonight. Thanks for the report. Ok. I've fixed the error in the PHPwiki package, upgrades from installations that are currently using DBA databases are still not going to be completely smooth though thanks to the following bug in dbconfig-common. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397089 Once that bug is fixed, an upgrade from PHPwiki using DBA will go smoothly, but your database won't be automatically migrated to dbconfig-common control. Given that DBA hasn't been supported in the PHPwiki packages for a long time now, I don't think I can justify upgrading the severity of either bug. You best hope for a clean upgrade at the moment is to migrate to sqlite (or mysql or postgres if you prefer) before you attempt to upgrade the PHPwiki package. The best way to do this is to use the dump file feature at PhpWikiAdministration to get the data out of the DBA database, create a new (blank) database of the appropriate type and then use the corresponding import feature at PhpWikiAdministration to get the data back in. I hope you find that helpful. Cheers -- Matt Brown Debian Developer [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#397089: dbconfig-common: migration fails when dbconfig-load-include returns empty values
Matt Brown wrote:
Ok, patch attached.
This time!
--
Matt Brown
Debian Developer
[EMAIL PROTECTED]
Mob +64 21 611 544 www.mattb.net.nz
diff -ur dbconfig-common-1.8.28/dpkg/config dbconfig-common-1.8.28.1/dpkg/config
--- dbconfig-common-1.8.28/dpkg/config 2006-10-13 10:52:19.0 +1300
+++ dbconfig-common-1.8.28.1/dpkg/config 2006-11-05 15:43:53.0 +1300
@@ -61,11 +61,21 @@
db_set $dbc_package/internal/reconfiguring true
fi
+ ##
+ ## start new dbc upgrade section
+ ##
+ # if there is a previously existing version already installed
+ # *and* the maintainer has provided the first version that used
+ # dbconfig-common *and* this version is newer than the
+ # previously installed version... do the dbc import stuff.
+ if [ $migrating ]; then
+ dbc_migrate
+ fi
+
# and start our beautiful state-machine
- # we start in STATE=1 (install_question) in all but two situations:
- # - we're migrating from a previous non-dbc version
+ # we start in STATE=1 (install_question) in all but one situation:
# - we're installing a frontend/readonly app
- if [ ! $migrating ] [ ! $dbc_frontend ]; then
+ if [ ! $dbc_frontend ]; then
STATE=1
else
STATE=2
@@ -86,69 +96,6 @@
fi
##
- ## start new dbc upgrade section
- ##
- # if there is a previously existing version already installed
- # *and* the maintainer has provided the first version that used
- # dbconfig-common *and* this version is newer than the
- # previously installed version... do the dbc import stuff.
- if [ $migrating ]; then
- # if dbc_load_include is set, determine the format
- # and location of the old config file
- if [ $dbc_load_include ]; then
-iformat=`echo $dbc_load_include | cut -d: -f1`
-ifile=`echo $dbc_load_include | cut -d: -f2-`
- fi
-
- ##
- ## if they want to import settings from a previous
- ## non-dbc version, do that and mark the questions
- ## skipped
- ##
- if [ $ifile ] [ -f $ifile ]; then
-dbc_logpart migrating old settings into dbconfig-common:
-if [ $dbc_debug ]; then
- dbc_debug dbconfig-load-include $dbc_load_include_args -f $iformat $ifile
- dbconfig-load-include $dbc_load_include_args -f $iformat $ifile
-fi
-eval `dbconfig-load-include $dbc_load_include_args -f $iformat $ifile`
-# if the dbtype is hardcoded, reset it no matter what
-# dbconfig-load-include tells us
-if [ $dbc_hardcoded_dbtype ]; then
- dbc_dbtype=$dbc_hardcoded_dbtype
-fi
-
-for f in database-type $dbc_dbtype/method db/dbname; do
- db_fset $dbc_package/$f seen true || true
-done
-if echo $dbc_authenticated_dbtypes | grep -q $dbc_dbtype; then
- for f in pgsql/authmethod-admin pgsql/authmethod-user $dbc_dbtype/admin-user db/app-user; do
- db_fset $dbc_package/$f seen true || true
- done
- db_set $dbc_package/db/app-user $dbc_dbuser
- db_set $dbc_package/$dbc_dbtype/app-pass $dbc_dbpass
- db_set $dbc_package/password-confirm $dbc_dbpass
-fi
-if echo $dbc_remote_dbtypes | grep -q $dbc_dbtype; then
- for f in remote/host remote/newhost remote/port ; do
- db_fset $dbc_package/$f seen true || true
- done
- db_set $dbc_package/remote/host $dbc_dbserver
- db_set $dbc_package/remote/newhost $dbc_dbserver
- db_set $dbc_package/remote/port $dbc_dbport
- if [ $dbc_dbserver ]; then
- db_set $dbc_package/$dbc_dbtype/method tcp/ip
- fi
-fi
-
-db_set $dbc_package/database-type $dbc_dbtype
-db_set $dbc_package/db/dbname $dbc_dbname
-
-dbc_logline done
- fi
- fi
-
- ##
## start multidb section
##
# if the dbtype is hardcoded (using config.mysql, etc), use that
@@ -398,3 +345,69 @@
db_set $dbc_package/internal/skip-preseed true
}
+
+dbc_migrate() {
+
+ # if dbc_load_include is set, determine the format
+ # and location of the old config file
+ if [ $dbc_load_include ]; then
+ iformat=`echo $dbc_load_include | cut -d: -f1`
+ ifile=`echo $dbc_load_include | cut -d: -f2-`
+ fi
+
+ ##
+ ## if they want to import settings from a previous
+ ## non-dbc version, do that and mark the questions
+ ## skipped
+ ##
+ if [ -z $ifile ] || [ ! -f $ifile ]; then
+ return
+ fi
+
+ dbc_logpart migrating old settings into dbconfig-common:
+ if [ $dbc_debug ]; then
+ dbc_debug dbconfig-load-include $dbc_load_include_args -f $iformat $ifile
+ dbconfig-load-include $dbc_load_include_args -f $iformat $ifile
+ fi
+ eval `dbconfig-load-include $dbc_load_include_args -f $iformat $ifile`
+
+ # the load script needs to return at least a database type
+ if [ -z $dbc_dbtype ]; then
+ dbc_logline failed
+ return
+ fi
+
+ # if the dbtype is hardcoded, reset it no matter what
+ # dbconfig-load-include tells us
+ if [ $dbc_hardcoded_dbtype ]; then
+ dbc_dbtype=$dbc_hardcoded_dbtype
+ fi
+
+ for f in database-type $dbc_dbtype/method db/dbname; do
+ db_fset $dbc_package/$f seen true || true
+ done
+ if echo $dbc_authenticated_dbtypes | grep -q $dbc_dbtype
Bug#396712: phpwiki: post-installation script error: return: can only `return' from a function or sourced script
tag 396712 + pending thanks Julien Charbon wrote: Package: phpwiki Version: 1.3.12p3-2 Severity: important Hmm, I see the bug, I'll upload a fixed package tonight. Thanks for the report. Cheers -- Matt Brown Debian Developer [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz 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#391040: quagga: ospfd segfault
tag 391040 + patch
stop
Andre Tomt wrote:
Any hope on getting the fix pushed into Etch? Right now OSPFd is
basically unusable.
If so, this bug should be set to a higher priority to make it release
critical.
For the time being, I've prepared a NMU patch to apply the fix for this
bug. If Christian has no comments or objections over the next few days
I'll be happy to upload it.
Cheers
--
Matt Brown
Debian Developer
[EMAIL PROTECTED]
Mob +64 21 611 544 www.mattb.net.nz
diff -u quagga-0.99.5/debian/changelog quagga-0.99.5/debian/changelog
--- quagga-0.99.5/debian/changelog
+++ quagga-0.99.5/debian/changelog
@@ -1,3 +1,10 @@
+quagga (0.99.5-2.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Backport CVS fix for an OSPF DD Exchange regression. (Closes: #391040)
+
+ -- Matt Brown [EMAIL PROTECTED] Wed, 25 Oct 2006 23:58:37 +1300
+
quagga (0.99.5-2) unstable; urgency=medium
* Added LSB info section to initscript.
only in patch2:
unchanged:
--- quagga-0.99.5.orig/debian/patches/100_ospfd_ddexchange_regression.dpatch
+++ quagga-0.99.5/debian/patches/100_ospfd_ddexchange_regression.dpatch
@@ -0,0 +1,76 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 100_ospfd_ddexchange_regression.dpatch by [EMAIL PROTECTED]
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Backport a fix for an OSPF regression introduced in 0.99.5
+## DP: See Debian Bug #391040 and
+## DP: http://bugzilla.quagga.net/show_bug.cgi?id=304
+## DP: for details
+
[EMAIL PROTECTED]@
+
+--- a/ospfd/ChangeLog
b/ospfd/ChangeLog
+@@ -1,3 +1,11 @@
++2006-08-28 Andy Gay [EMAIL PROTECTED]
++
++ * ospf_packet.c: (ospf_make_db_desc) Assert added with More-bit
++ fixes does not hold up with addition of Ogier DB-Exchange
++ optimisation, which can empty the db-summary list in between
++ sent DD packets. Remove assert, update More-bit always when
++ in Exchange.
++
+ 2006-08-27 J.J. Krabbendam [EMAIL PROTECTED]
+
+ * ospfd.c: (ospf_finish_final) default redistribute should be
+--- a/ospfd/ospf_packet.c
b/ospfd/ospf_packet.c
+@@ -2712,25 +2712,9 @@ ospf_make_db_desc (struct ospf_interface
+ /* Set DD Sequence Number. */
+ stream_putl (s, nbr-dd_seqnum);
+
++ /* shortcut unneeded walk of (empty) summary LSDBs */
+ if (ospf_db_summary_isempty (nbr))
+-{
+- /* Sanity check:
+- *
+- * Must be here either:
+- * - Initial DBD (ospf_nsm.c)
+- * - M must be set
+- * or
+- * - finishing Exchange, and DB-Summary list empty
+- * - from ospf_db_desc_proc()
+- * - M must not be set
+- */
+- if (nbr-state = NSM_Exchange)
+- assert (!IS_SET_DD_M(nbr-dd_flags));
+- else
+-assert (IS_SET_DD_M(nbr-dd_flags));
+-
+- return length;
+-}
++goto empty;
+
+ /* Describe LSA Header from Database Summary List. */
+ lsdb = nbr-db_sum;
+@@ -2785,9 +2769,17 @@ ospf_make_db_desc (struct ospf_interface
+ /* Update 'More' bit */
+ if (ospf_db_summary_isempty (nbr))
+ {
+- UNSET_FLAG (nbr-dd_flags, OSPF_DD_FLAG_M);
+- /* Rewrite DD flags */
+- stream_putc_at (s, pp, nbr-dd_flags);
++empty:
++ if (nbr-state = NSM_Exchange)
++{
++ UNSET_FLAG (nbr-dd_flags, OSPF_DD_FLAG_M);
++ /* Rewrite DD flags */
++ stream_putc_at (s, pp, nbr-dd_flags);
++}
++ else
++{
++ assert (IS_SET_DD_M(nbr-dd_flags));
++}
+ }
+ return length;
+ }
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#394825: ITP: libtrace3 -- network trace processing library supporting many input formats
Package: wnpp Severity: wishlist Owner: Matt Brown [EMAIL PROTECTED] * Package name: libtrace3 Version : 3.0.0-beta5 Upstream Author : The University of Waikato [EMAIL PROTECTED] * URL : http://research.wand.net.nz/software/libtrace.php * License : GPL Programming Lang: C Description : network trace processing library supporting many input formats libtrace is a library for trace processing. It supports multiple input methods, including device capture, raw and gz-compressed trace, and sockets; and multiple input formats. libtrace is developed by the WAND Network Research Group at Waikato University in New Zealand. -- 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) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392060: rp-pppoe: incorrect package format - missing .diff.gz
Package: rp-pppoe Version: 3.8-1 Severity: normal The current version of the rp-pppoe source package is built as a native debian package. There is no reason for this that I can see. Please upload a fixed version so it is easy to separate the Debian changes from the pristine upstream source. Many thanks -- 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) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388537: DSA-1172 upgrade sets incorrect permissions on rndc.key
Package: bind9 Version: 1:9.2.4-1sarge1 Hi, After applying the security update from DSA-1172 to two Sarge systems that I run the permissions of /etc/bind/rndc.key are set to bind:bind 0640. This prevents rndc from communicating with the daemon and leads to failure at the next time someone attempts to stop or reload the daemon via rndc. Both these systems were originally installed as Woody boxes, and were subsequently upgraded to Sarge. /etc/default/bind9 does not contain -u bind in the OPTIONS= field. The problem is fixed by reverting the permissions of /etc/bind/rndc.key to root:root 0640 as it was before the upgrade. -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#387143: phpwiki errors on loading; Driver initialization failed for handler: db4...
Isaac Bennetch wrote: I'm still surprised that you feel my files are in a non-standard place, since aptitude should have handled everything automatically, I certainly don't remember moving it and would have no reason to have done so. `dpkg -L phpwiki` lists /var/lib/phpwiki for what that's worth. Any more than that, though, and I'm at a loss. I may be incorrect about the filename. The history of this is that the PHPwiki package has not actually dealt with db4 files for a long time (1.3.7-1 in 2004 was the last release that actually created db4 files). Newer releases shouldn't break your db4 setup, but a brand new fresh install will be setup to use sqlite by default instead of db4. I took over the package just after 1.3.7-4, so I've never dealt with db4 stuff directly, hence my confusion. After taking a deeper look at the old packages it seems that your file probably is in a standard location. I just wasn't expecting the final 4 in the filename... Additionally, I've backed up my phpwiki files, purged the package (and it's dependancies), and reinstalled. It worked. I assume this was with a SQLite database at /var/lib/phpwiki/phpwiki_pagedb.db ? I copied my phpwiki_pagedb.db4 to replace the default, and there was no change (it didn't break, but my wiki didn't appear, either). This is probably because the config file was still looking for a SQLite database and you copied a DB4 database on top of it. Finally I copied my config.ini file to replace the default in /etc/phpwiki/, and it broke again -- so it does seem to be my config.ini file, though I hadn't edited it since it was working, so I still don't know what the problem was. Not that it matters much, though, if I'm able to recover my database I'll be happy (and if not, hey, that's what backups are for)... At this stage I'd suggest asking the upstream mailing list for help. It doesn't seem to be anything that is identifiably wrong with the package from the information that you've provided so far. If you can successfully get the data out of the db4 database, I would suggest migrating to a SQLite backend. Hope that helps. -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#387143: phpwiki errors on loading; Driver initialization failed for handler: db4...
tag 387143 + unreproducible moreinfo thanks bts Hi Isaac, Isaac Bennetch wrote: Greetings, I have a problem with my phpwiki install. I haven't accessed it in some time (perhaps a week), but now get an error attempting to load any page: Did anything change related to PHPwiki on your system during this time (eg, upgrade to a new version, etc)? Did anything related to DB4 or PHP's DB4 bindings change on your system during this time? lib/DbaDatabase.php:54: Error: dba_open(/var/lib/phpwiki/phpwiki_pagedb.db4,w) [a href='function.dba-open'function.dba-open/a]: Driver initialization failed for handler: db4: Unknown error 139424368 * file: /var/lib/phpwiki/phpwiki_pagedb.db4 * mode: w * handler: db4 The file location (/var/lib/phpwiki/phpwiki_pagedb.db4) is not a standard location configured by the package, as far as I know, have you configured this PHPwiki instance manually? Are you sure the specified database file is writeable by the webserver? Is the specified database file valid (perhaps the tools from the db4.4-util package can help here)? At this stage, with the information you've provided this looks very much like a configuration error, or a corrupted database, rather than a bug in PHPwiki. Please provide some more information that would help to pinpoint and reproduce this problem. Particularly answers to the questions above. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#386951: driver loses association repeatedly (WPA)
Hi Martin, martin f krafft wrote: As said, from time to time it *does* work with the same configuration (-D madwifi, I never actually got it to work with wext). Also, other machines are associating fine with the AP, so it really seems to be an atheros problem. Is there any chance that your access point is using an agere/orinoco/proxim chipset? If so you may be hitting http://madwifi.org/ticket/698 -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#379796: dbconfig-common: Please support sqlite as a database type
tags 379796 pending thanks bts sean finney wrote: cool! could i nitpick and ask that they be called dbc_dbfile_foo, or something similar, just so that it's more clear what they are used for? Done since you and thijs are both reporting success with this now, go ahead and merge this into trunk and let's do a release. and done :) I look forward to seeing the release soon! -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#379796: dbconfig-common: Please support sqlite as a database type
Thijs Kinkhorst wrote: On Thu, 2006-08-10 at 10:53 -0400, sean finney wrote: there are some hinting variables which you can use to specify the defaults. i believe they're dbc_generate_include_owner and dbc_generate_include_mode, though don't trust my memory. there should also be something like dbc_generate_include_args for even more control. Yes, but this is about the database that is created by sqlite, not the include file. Maybe we should have the same set of variables for any backend that creates a database file on the local filesystem, that performs the same chown / chmod like with the include file. New packages at http://www.mattb.net.nz/debian/dists/sid/main/source/admin/ now have two variables dbc_owner and dbc_perms modeled off the dbc_generate_include_ versions to allow you to hint at the desired settings. Let me know how it goes. -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#379796: dbconfig-common: Please support sqlite as a database type
Thijs Kinkhorst wrote: Sure, thanks for the quick response. I've checked it out and it works good, except for the fact that the database is owned by root:root and filemode 0640. That makes it unreadable for my webapp. Would there be a way to specify the file owner to be www-data, or would I have to code that into the package scripts? See the following post (2nd point) for background. http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/2006-June/000545.html So the answer is code it into your package scripts. I haven't really tested that we preserve permissions on upgrade, and I have a nasty feeling that we probably don't... I'll take a look at that. It would be nice to come up with some examples for how a packager should set custom permissions from their maintainer scripts. One more tweak, you didn't add lintian overrides for the newly added example packages; it should be easy to add that to the existing debian/lintian file following the lines already there. Will do. -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#379796: dbconfig-common: Please support sqlite as a database type
sean finney wrote: oh, sorry, brain fart. yes, i think there should be something similar for that, but i don't think it's there currently. so then there are two issues :) There was but it was implemented as the debconf question rather than hints from the maintainer file. I'll add it back in without the debconf questions in a similar format to how the dbconfig-generate-include permissions are handled. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#379796: dbconfig-common: Please support sqlite as a database type
Hi Thijs, Thijs Kinkhorst wrote: I've done so on a new package of mine. It took a while to get it working, because as it seems sqlite is very picky (or even buggy) on SQL syntax. I've now transformed my inserts into a format that all database types will accept. Thanks for helping out with the testing :) What I noticed: * Purge does not purge the database, and is very noisy. snip * Install outputs a strange notice. snip Both errors were caused by a simple typo in the function that checked whether a database existed. I've also made a few other tidy ups and merged in the changes from trunk. I've built new packages (1.8.19~sqlite0) and put them at: http://www.mattb.net.nz/debian/dists/sid/main/source/admin/ Would you have time to test them out with your package again? It would be much appreciated. It works but it the verify reports that it failed. Otherwise, it works just fine! I hope it can be included in dbconfig-common 'release' soon. I'm planning to get my PHPwiki package working with it to test the migration features, once that's done I'll merge the changes into the trunk and then sean can make a new release when he's ready. Hopefully I'll have all that done by the end of the weekend at the latest. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#379796: dbconfig-common: Please support sqlite as a database type
sean finney wrote: if there are 2 or 3 packages that can already make use of it, i suggest that we do the following: Sounds like a good plan to me. - build yourself a dbconfig package from the sqlite branch - set up your sqlite-using package to use dbconfig I've built a package based on the current state of the branch and placed it at: http://www.mattb.net.nz/debian/dists/sid/main/source/admin/ Feel free to use it for testing. - after you can verify there are no apparent problems with install/reconfigure/remove/purge actions for all 2 or 3 packages, we go ahead and merge the sqlite branch, and upload it. Hopefully I'll be able to report on how it goes with PHPwiki after the weekend. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#379796: dbconfig-common: Please support sqlite as a database type
tag 379796 + patch thanks Hi Thijs, Thijs Kinkhorst wrote: I see that you've mentioned this already in your TODO file in the package, but I'd like to register still that we (the phpgedview maintainers) would appreciate to see sqlite support in dbconfig-common. Since sqlite operation is currently our default modus operandi this is a blocker for us to use dbconfig-common for the package. I've recently added SQLite support to dbconfig-common because I need it for the phpwiki package. It's in the svn repository in a branch called sqlite http://svn.debian.org/wsvn/dbconfig-common/branches/sqlite/?rev=0sc=0 It just waiting on a bit more testing before I prompt sean again to get it into the proper release. 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)
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#366995: phpwiki: Upgrade from 1.3.7 destroys apache.conf
Zed Pobre wrote: It was invoked via a ssh connection from another machine inside of an invocation of screen, using dsh to parallelize and grc to colorize for quick review of problems as upgrades scrolled by. Specifically, the command would have looked something like: grc -e dsh -M -c -g linux apt-get -y upgrade where linux is a group file containing a list of the linux boxes to be upgraded. At this length of time, I can't guarantee exactly what I typed in, but this is generally how we handle bulk upgrades. Thanks for the detail, I still can't reproduce your exact problem, but I have fixed several bugs with unattended upgrades and ucf that were definitely causing problems. I suspect that this bug is simply another failure case of one of those problems that my environment cannot reproduce. At this stage I'm going to mark the bug as closed in the next upload. Thanks for your time reporting this. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#366996: Pending upload fixes documentation and adds upgrade schemas
severity 366996 wishlist thanks The pending upload of phpwiki 1.3.12p3-1 which I expect to go into the archive within the next 3 days contains updated documentation and a NEWS notice that clearly tells the user that automatic upgrades to postgres databases are not yet supported and provides instructions on the alternate upgrade method. Upgrade schemas are also installed in /usr/share/doc/phpwiki/schemas as per your suggestion. Moving to a fully managed system using dbconfig-common is still on the TODO list, but is still blocked on the dbconfig-common packages gaining the necessary SQLite support. There are patches in svn to add this functionality so hopefully a new dbconfig-common package is not far away. 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#375584: reprepro: please support pulling only a specific package using the commandline
Hi Bernhard, Thanks for your prompt response to this, and for chasing me up to respond :P Bernhard R. Link wrote: Please try reprepro copy dest-distribution source-distribution packagenames from the recently released reprepro 1.0.0. That should hopefully do what you want. (Unless I introduced some errors which my simple testcases did not catch). I've not given it thorough testing, but assuming it's bug free then it will do what I want :) I also thought about some way to copy a source package with all its binaries (i.e. everyting which has Source: xyz or Package: xyz if it has not source), but refrained from it because it was too complex for something I do not know if anyone needs it. It would certainly be useful, but it's not too hard to specific the source + binaries names on the command line for a single copy. So I guess it's not a crucial feature. You can consider this bug solved :) Thanks again. -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#366995: phpwiki: Upgrade from 1.3.7 destroys apache.conf
clone 366995 -1 reassign -1 ucf retitle -1 ucf: noninteractive upgrade fails when package uses debconf tags -1 - unreproducible found -1 2.0012 thanks bts Zed Pobre wrote: I had a custom apache.conf required for supporting multiple parallel wikis in /etc/phpwiki/apache.conf. This file was replaced with a default file on a noninteractive upgrade, and no .dpkg-old version was created (fortunately, it was very simple to rewrite). Looking at your postinst, I don't see anything immediately wrong, but there may be some oddity involved with ucf when there is no attached tty. There was a bug in my postinst, I was invoking ucf with redirections to and from /dev/tty which isn't always available during a non-interactive upgrade. However this should cause dpkg to exit with an error like the following and wouldn't result in any configuration loss. Setting up phpwiki (1.3.12p2-1) ... /var/lib/dpkg/info/phpwiki.postinst: line 135: /dev/tty: No such device or address dpkg: error processing phpwiki (--configure): subprocess post-installation script returned error exit status 1 How did you invoke the non-interactive upgrade? However, in fixing the bug in phpwiki's postinst I've stumbled across another similar bug that appears to be inside ucf itself. It still can't reproduce your exact situation (loss of old configuration file) but the bug does prevent noninteractive upgrades where the configuration file has been modified. The remainder of this mail is for the new bug report I've just cloned and assigned to ucf. The problem occurs when upgrading a package containing a new configuration file managed by ucf where the new configuration file is different to both the original file installed by the previous package and the current version of the file on disk. Additionally the postinst script must be using debconf for the bug to occur. When these four conditions are satisified ucf attempts to prompt the user as to what it should do with the file on disk, however it attempts to read the answer from /dev/tty which may not exist during a non-interactive installation. The full upgrade log (ucf debug and verbose flags turned on) including the error is shown below: (Reading database ... 34584 files and directories currently installed.) Preparing to replace foo 1 (using foo_2_amd64.deb) ... Unpacking replacement foo ... Setting up foo (2) ... ucf: The Source directory is /usr/share/foo ucf: The State directory is /var/lib/ucf The hash file exists egrep [[:space:]]\/etc\/foo\.conf$ /var/lib/ucf/hashfile 60ce0a64962adb638065b6c0e3f3f0a8 /etc/foo.conf The new start file is `/usr/share/foo/configuration\' The destination is `/etc/foo.conf\' (`\/etc\/foo\.conf\') The history is kept under \'/usr/share/foo\' The file may be cached at \'/var/lib/ucf/cache/:etc:foo.conf\' The destination file exists, and has md5sum: 8e9beae8f0aed324944f37224f6be2b9 /etc/foo.conf The old md5sum exists, and is: 60ce0a64962adb638065b6c0e3f3f0a8 The new file exists, and has md5sum: 0a6e31644d037c2959dc6e6ab50f9ebd /usr/share/foo/configuration Historical md5sums are not available Configuration file `/etc/foo.conf' == File on system created by you or by a script. == File also in package provided by package maintainer. 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 S : show the side-by-side differences between the versions Z : start a new shell to examine the situation The default action is to keep your current version. *** foo.conf (Y/I/N/O/D/Z) [default=N] ?/usr/bin/ucf: line 855: /dev/tty: No such device or address dpkg: error processing foo (--install): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: foo The expected behaviour of ucf in this case is to leave the configuration file as is, and install the new configuration file at /etc/foo.conf.ucf-dist. This expected behaviour occurs correctly if debconf is removed from the package's postinst script. Steps to reproduce: I have built two versions of a very basic test package (foo) to help diagnose / test this error case. The package installs a single configuration file /etc/foo.conf from /usr/share/foo/configuration using stripped down versions of the example maintainer scripts shipped with ucf. 1. Obtain packages from http://www.mattb.net.nz/debian/misc/ucf/ 2. Install version 1 3. Edit /etc/foo.conf so it differs from the installed version 4. Perform a non-interactive upgrade to version 2 via the following command echo DEBIAN_FRONTEND=noninteractive dpkg -i foo_2_amd64.deb | at now + 1 min 5. Observe breakage and error output as shown above Please let me know if there is any further information you need to track down the cause of this bug. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz
Bug#375584: reprepro: please support pulling only a specific package using the commandline
Package: reprepro Severity: wishlist Currently when using the pull feature of reprepro the only method of restricting which packages are updated is to use the FilterFormula and FilterList configuration file options. I would like a method to be able to pull only a specific package leaving the other packages in the source distribution as they are. I'm imagining a command format like reprepro pull dest-distribution packagename The reason that I want this is so that I can implement a set of archives that behave like testing and stable. At the end of each day I want to pull certain packages (which have been tested) into stable, but leave the untested packages in testing. I can currently implement this functionality but it requires editing the configuration files every night which is tedious. A commandline option would be much more convenient. Thanks for your consideration of this option. Cheers -- 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) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368684: nagios3: segfault caused by p1.pl being installed incorrectly
Marc Haber wrote:
I have to disagree here. The directive is documented, and the default
config we ship correctly sets it. What else should we do?
I was thinking an entry in README.Debian or similar would be appropriate.
Additionally, I cannot reproduce the segfault when commenting the
p1_file directive from the default config. The nagios2 daemon just
keeps running.
Two factors here:
1) As described in the original bug report the segfault happens some
time after startup (1 minute in my case) - I suspect the time it crashes
is the first time a perl check plugin is used.
2) The default debian config does not make use of any perl checks so
will probably never trigger the segfault. If I add the following stanza
to /etc/nagios2/conf.d/localhost_nagios2.cfg and comment out the p1_file
directive in /etc/nagios2/nagios.cfg then I can make nagios segfault
with the error described in the original bug report after 5-6 minutes.
define service {
use generic-service
host_name localhost
service_description NTP
check_command check_ntp
}
(check_ntp uses a perl based plugin)
HTH.
Cheers
--
Matt Brown
[EMAIL PROTECTED]
Mob +64 21 611 544 www.mattb.net.nz
signature.asc
Description: OpenPGP digital signature
Bug#338128: miredo: alternative package available
Bernhard Schmidt wrote: Since the package there is slightly outdated maybe joint-effort would be a plan? I would be happy with that. My other packages are taking more time than anticipated so Miredo (unfortunately) hasn't made its way to the top of my TODO list yet. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#372024: reprepro: minor spelling mistake in --help output
Package: reprepro Version: 0.9.1-1 Severity: minor The first line of the help text is: reprepro - Produce and Manage and Debian package repository which does not read correctly, I think the and is meant to be 'a' reprepro - Produce and Manage a Debian package repository There are also some minor spelling mistakes in the --help text for the include* actions. In particular the word Include in the description of each action is misspelt 'Inlcude' rather than 'Include' Cheers -- 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) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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#368684: nagios3: segfault caused by p1.pl being installed incorrectly
Marc Haber wrote: Can you give a example configuration? Well, in the course of trying to narrow down my configuration to a set of directives that triggers the error I came across a directive shipped in the default nagios.cfg that is not in my configuration. p1_file=/usr/lib/nagios2/p1.pl I don't actually use the embedded perl interpreter (that I know of) so my configuration (which was originally for Nagios 2.0) did not contain this directive. Adding this directive to my configuration resolves the error. As far as I can tell this is an undocumented directive, but one that any Debian based configuration will need seeing as p1.pl has been relocated from its default location. So I guess this now becomes a documentation bug :) Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#368714: config script fails if no configuration present in /etc/dbconfig-common
Package: dbconfig-common
Version: 1.8.13
Severity: normal
When there are no configuration files in /etc/dbconfig-common the config
maintainer script suffers an error as it does not check the result of a
shell expansion.
The offending code is lines 199-202 of dpkg/config.
The root cause is that the expansion will return the literal string
/etc/dbconfig-common/*.conf if it could not match any actual
configuration files. This string is then passed directly into
dbconfig-generate-include which generates an error as shown below:
Unpacking db-test-sqlite (from db-test-sqlite_2.0_all.deb) ...
Setting up db-test-sqlite (2.0) ...
unable to read input file /etc/dbconfig-common/*.conf
dpkg: error processing db-test-sqlite (--install):
subprocess post-installation script returned error exit status 10
As the script is set -e this causes the installation to fail.
The patch below offers one possible solution to the problem,
alternatively dbconfig common could run 'shopt -s nullglob' to request
bash returns an empty string when the expansion fails.
--- dpkg/config (revision 216)
+++ dpkg/config (working copy)
@@ -197,6 +197,7 @@
# package, and create a list of hosts.
_preconf_list=` (
for f in /etc/dbconfig-common/*.conf; do
+ test -f $f || continue
eval \`dbconfig-generate-include --dbserver=_s
$f | grep -v '^#'\`
[ $_s ] echo $_s
done
Cheers
-- 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-xen
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Versions of packages dbconfig-common depends on:
ii debconf [debconf-2.0] 1.5.1 Debian configuration management sy
ii pwgen 2.05-1 Automatic Password generation
ii ucf 2.0010 Update Configuration File: preserv
dbconfig-common recommends no packages.
-- debconf information:
dbconfig-common/internal/reconfiguring: false
dbconfig-common/import-oldsettings:
dbconfig-common/dbconfig-upgrade: true
dbconfig-common/passwords-do-not-match:
dbconfig-common/pgsql/authmethod-admin: ident
dbconfig-common/pgsql/revertconf: false
dbconfig-common/install-error: abort
dbconfig-common/remove-error: abort
dbconfig-common/db/dbname: ${pkg}
dbconfig-common/pgsql/no-empty-passwords:
dbconfig-common/mysql/method: unix socket
dbconfig-common/remember-admin-pass: false
dbconfig-common/pgsql/admin-user: postgres
dbconfig-common/mysql/admin-user: root
dbconfig-common/remote/host:
dbconfig-common/pgsql/manualconf:
dbconfig-common/pgsql/changeconf: false
dbconfig-common/remote/newhost:
dbconfig-common/dbconfig-install: true
dbconfig-common/pgsql/method: unix socket
dbconfig-common/pgsql/authmethod-user: ident
dbconfig-common/upgrade-error: abort
dbconfig-common/database-type:
dbconfig-common/dbconfig-remove: true
dbconfig-common/db/app-user:
dbconfig-common/pgsql/no-user-choose-other-method:
dbconfig-common/remote/port:
dbconfig-common/upgrade-backup: true
dbconfig-common/performing_upgrade: false
dbconfig-common/purge: false
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368684: nagios3: segfault caused by p1.pl being installed incorrectly
Package: nagios3 Version: 2.3-1 Severity: normal (this problem is being experienced on a self-made backport, so I've chosen normal rather than important as the priority. However I'm 99% sure this problem would also be exhibited in unstable but haven't had time to check). When the embedded perl interpreter is enabled the Nagios binary looks for a script called p1.pl in $(bindir) (set to /usr/sbin by configure), however the debian package moves this file from $(bindir) to /usr/lib/nagios2. This causes the following error when the daemon is started: orwell:~# nagios2 /etc/nagios/nagios.cfg Nagios 2.3 Copyright (c) 1999-2006 Ethan Galstad (http://www.nagios.org) Last Modified: 05-03-2006 License: GPL Nagios 2.3 starting... (PID=21189) Can't open perl script /usr/sbin/p1.pl: No such file or directory After roughly one minute the process exits. The log file contains [1148444358] Nagios 2.3 starting... (PID=21221) [1148444358] LOG VERSION: 2.0 [114832] Caught SIGSEGV, shutting down... Moving p1.pl to /usr/sbin (either physically or via symlink) resolves the problem and appears to make Nagios operate correctly. Please escalate this to important if you agree that this is likely to affect the packages in unstable as well. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#367422: phpwiki: user_tbl missing from postgresql schema
Hi Zed, Zed Pobre wrote: The table 'user' is not specified in the postgresql schema, though there is an attempt to grant permissions to :user_tbl down at the very bottom. Although this table is deprecated, its existence is required for the Convert cached_html feature to function, which in turn is required when upgrading from an older version. Can you please provide some more information about the error you are experiencing. I can't see how the user table is required for the Convert cached_html operation to complete successfully. As you state the table is not a normal part of the PHPwiki database (and hence is not in the schema), it is only used when an administrator has specifically enabled database backed user accounts in the configuration file (and created the necessary tables). The permissions directive you refer to is commented out in the default schema and from what I can make out is included in their only as an example.. At this stage I can't reproduce the bug. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#366999: phpwiki: Upgrade from 1.3.7 doesn't even try to find parallel wikis
Zed Pobre wrote: Package: phpwiki Version: 1.3.12p2-1 Severity: wishlist This is probably in the category of extraordinary measures, but it would be nice if the upgrade script checked /etc/phpwiki/apache.conf for any additional alias lines or directory entries, as those would be solid signs of an additional install. Particularly, any entry of the form: Alias /somename//some/path/to/index.php/ is likely to give you the name and location of any other wikis in parallel. As you say its relatively easy to guess if the admin has added extra wikis. The problem is what would you like the package to do once its discovered that you have additional wikis installed side by side? I can't think of any sensible course of action that would allow the package to upgrade arbitrary instances of PHPwiki that have not ever been managed by the package. There are simply too many possible configurations to deal with. Maybe once the package moves to dbconfig-common it might be possible to provide a registration method to allow the administrator to register additional PHPwiki databases with the package which would then take care of upgrading them as new versions are released. I very much doubt that's doable before etch however... Suggestions welcome :) -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#366892: phpwiki: unserialize errors
Zed Pobre wrote: Okay, I'll fire off a few shortly. Thanks, I'll respond over the next couple of days. There is no such button at the bottom of the PhpWikiAdministration page on either of my wikis. There is a Purge Markup Cache button, which I pressed, but it did not solve the problem. (In fact, the serialize error message showed up on the page saying that the cache had been purged). Hmm, another PHPwiki gremlin strikes. Currently when you upgrade to a new version the default (pgsrc) pages are not updated as upstream has not yet added the necessary functionality to do so without potentially overwriting local changes. This is listed as a known problem in their upgrade path so I should have realised you would hit it sorry. Your PhpWikiAdministration page is almost certainly still using the 1.3.7 (or possibly even earlier) source which doesn't have the necessary actions in it. There are two options here. 1) Manually copy the content of /usr/share/phpwiki/pgsrc/PhpWikiAdministration into the PhpWikiAdministration page source field while logged into the wiki as the Administrator. or for a smaller change 2) Add the following code to the end of PhpWikiAdministration !! Convert cached_html to new SQL column This is only needed on SQL or ADODB if you didn't do action=upgrade, but created the new page.cached_html field seperately, and now you want to move this data from page.pagedata over to page.cached_html. ?plugin WikiAdminUtils action=convert-cached-html label=Convert cached_html ? Once you've got the convert button, hopefully you'll be able to solve the source of the errors. It looks like I'm going to have to code up a little helper script to solve this problem for other upgrading users. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#366996: phpwiki: Upgrade from 1.3.7 does not update postgresql tables
Zed Pobre wrote: The ideal way of handling this is to create SQL scripts that update from one version to the next for each stage at which there was a schema change, and for each database, and then make them available in the schemas directory for users to run on their own. Potentially, the could be run automatically based on the old version number during the postinst, as well, if the scripts are idempotent (i.e. they would just throw error messages if run on an already-updated database, rather than corrupting the tables). I'm planning to move the package to using the dbconfig-common framework sometime in the next month or two which should vastly improve this situation. The big blocker at the moment is that dbconfig-common does not yet support sqlite and I want to retain the ability for users to install phpwiki without the overhead of a large system like postgres/mysql. This is very definitely a release goal for PHPwiki's inclusion in etch however. -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#367000: migrate-phpwiki-config usage example incorrect
tags 367000 + pending thanks Zed Pobre wrote: The usage guide for migrate-phpwiki-config claims that you should run it as: Usage: ./phpwiki-migrate-config config-template.ini If you just do this, however, it will appear to hang. Quick perusal of the code shows that it is meant to be used as a pipe, so the example should probably read: Usage: cat index.php | ./phpwiki-migrate-config config-template.ini Fix committed to svn, will be in the next package. Thanks for noticing :) -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#366892: phpwiki: unserialize errors
Hi Zed, Zed Pobre wrote: I accidentally upgraded an old 1.3.7 install of PHPWiki. This broke all of my wikis, in case you were unaware that the automatic upgrades still aren't working, but that's not what this bug is about, as I managed to massage that part back into shape. I'm not aware of any upgrade issues other than the one reported in #361337 which I'm waiting to hear back from the reporter for more info on. If you have some specific issues could you please file bugs on them so that I can look into it? Thanks. Unfortunately, I am still getting the following errors at the bottom of each page: lib/WikiDB/backend/PearDB_pgsql.php:134: Notice: unserialize(): Error at offset 0 of 192 bytes (...repeated 4 times) lib/WikiDB/backend/PearDB_pgsql.php (In template 'browse-footer'):134: Notice: unserialize(): Error at offset 0 of 196 bytes lib/WikiDB/backend/PearDB_pgsql.php (In template 'browse-footer'):134: Notice: unserialize(): Error at offset 0 of 268 bytes This doesn't actually seem to prevent the wiki from working in any way that I've noticed, but it is unsightly, and a quick perusal of the section involved makes me think that it is trying to unserialize data that wasn't serialized to begin with, which may be a sign of a much larger problem. Hmm, I have a theory. The package bypasses the upgrade.php mechanism that upstream recommends you use when switching between new versions because I've found it too be too buggy and reliable. But I may have missed a step. Older versions of PHPwiki sometimes stored cached_html as a page property, this has now be moved to its own column in the page table. This may not be happening in your case. Please go to PhpWikiAdministration and click the Convert cached_html button at the bottom of the page. Does this fix the problem? Thanks for your help. -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#364458: madwifi-source: Error on 'ifdown' and 'iwconfig mode auto'
Kel Modderman wrote: Ok, thanks for reporting this issue (and sorry for a late reply!). Could you please suggest some text for inclusion in the docs? (if not I guess I could think of something :-) ) I did look into this the other day just to verify that it wasn't anything critical. I haven't responded yet because I'm not sure whose fault the problem is and hence how to fix it. The message is caused by /etc/network/if-post-down.d/wireless-tools attempting to run iwconfig $IFACE mode auto which of course fails on madwifi as it does not allow interface mode changes. The best solution imo would be to fix madwifi so that it did allow mode changes, but I can't see that happening anytime soon as I understand it would involve rewriting half the driver. I think the best compromise would be for wireless-tools to silently hide (or redirect to syslog) any errors that occur when deconfiguring an interface. I've copied the wireless-tools maintainers on this mail to see if they have any thoughts on this approach. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#364458: madwifi-source: Error on 'ifdown' and 'iwconfig mode auto'
Kel Modderman wrote: Indeed, Matt's statements were about madwifi-ng, I think. And it is good he brought it up, as the madwifi-ng codebase could be entering debian any time soon. Yes, sorry for the confusion. I didn't realise madwifi-ng wasn't in the archive yet and this bug is present in the madwifi-ng packages. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#312969: apt-proxy: Incorrect permissions on /var/cache/apt-proxy cause silent failure of package caching
Ben Hutchings wrote: You misunderstand me. I meant that if apt-proxy does not have permission to write to the cache dir, serving files without caching them is the best it can do. Ah, sure, I agree, apt-proxy's behaviour is not bad, I'm quite happy with apt-proxy doing that. The point of this bug report is that the package installation scripts need to be fixed so that apt-proxy functions correctly after installation. Now I'm confused about what you're trying to tell me about how this should be fixed. Could you rephrase please? -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#312969: apt-proxy: Incorrect permissions on /var/cache/apt-proxy cause silent failure of package caching
Ben Hutchings wrote: How about: --- debian/postinst~ 2005-08-18 16:48:31.0 +0100 +++ debian/postinst 2006-04-13 21:58:19.076626250 +0100 @@ -17,15 +17,15 @@ echo creating $APTPROXY_USER user... adduser --quiet --system --ingroup nogroup \ --home $CACHEDIR --no-create-home $APTPROXY_USER - - # Make apt-proxy user own cache directory - chown -R $APTPROXY_USER $CACHEDIR - # Create a blank logfile owned by apt-proxy user - touch $APTPROXY_LOGFILE - chown $APTPROXY_USER:adm $APTPROXY_LOGFILE - chmod 640 $APTPROXY_LOGFILE fi + # Make apt-proxy user own cache directory + chown -R $APTPROXY_USER $CACHEDIR + # Create a blank logfile owned by apt-proxy user + touch $APTPROXY_LOGFILE + chown $APTPROXY_USER:adm $APTPROXY_LOGFILE + chmod 640 $APTPROXY_LOGFILE + PREV=$2 db_fget $NAME/upgrading-v2 had_v2_conf || true had_v2_conf=$RET -- END -- That looks like it would do the trick to me. Thanks -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#338128: Miredo ITP
Clément Stenac wrote: Is it possible to get an update about the status of this ITP ? Stuck on my TODO list :( I discovered a stack of legal issues that I did not know how to deal with, so I stopped work on Miredo for several months until I discovered the appropriate way to deal with them. I'm hoping to have an upload prepared within the next month. It seems miredo got dropped from NEW, do you have the reason and maybe a target date for reuploading ? I've not created a package suitable for uploading yet and I certainly have never sent it anywhere near the archive. I wasn't aware that a Miredo package had ever entered the NEW queue! Sorry for the delays! -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#312969: apt-proxy: Incorrect permissions on /var/cache/apt-proxy cause silent failure of package caching
Ben Hutchings wrote: However, both these actions are conditional on the aptproxy user not existing. Therefore if apt-proxy is removed and reinstalled, the the ownership of /var/cache/apt-proxy will not be changed as required. (This happened on my system, where I accidentally deleted /var/cache/aptproxy and attempted to repair it by reinstalling.) Is it possible that you have installed apt-proxy more than once? There was almost certainly the previous version of the package (from woody) removed but not purged on the system. Given that the silent failure is noted in the log, I think apt-proxy is doing the best it can in this situation. But the postinst script is buggy. I don't understand how you think it's doing the best it can. Why restrict the permissions fixes to only run when the username is created? Where is it noted in the log? I hardly think an obscure backtrace counts as a log message to inform the user that the package is not caching as it should. -- 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
Package: php4-sqlite Version: 1.0.2-9 Severity: important On amd64 the sqlite_escape_string function is faulty and causes PHP to kill the script due to PHP's internal memory limit being reached. An example script that reproduces this problem is: ?php echo sqlite_escape_string(a); ? Running this script will result in an error message such as: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate -1969234011 bytes) in /var/www/test.php on line 2 The string passed to sqlite_escape_string and the value of the PHP memory limit do not effect the behaviour of the bug. The number of bytes attempted to allocate seems completely bogus. php5-sqlite (linked against the same libsqlite0) is not affected and neither is php4-sqlite on i386. This bug is currently breaking the PHPwiki package on amd64 systems. -- 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-xen Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Versions of packages php4-sqlite depends on: ii libapache2-mod-php4 [phpapi-2 4:4.4.2-1 server-side, HTML-embedded scripti ii libc6 2.3.6-4GNU C Library: Shared libraries an ii libsqlite02.8.16-1 SQLite shared library php4-sqlite recommends no packages. -- no debconf information -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#361337: phpwiki: Upgrade re-initialized database
Chris Adams wrote: On 2006-04-07, at 5:17 PM, Matt Brown wrote: - I assume you are using sqlite? Correct. - Is your database stored in the standard location /var/lib/phpwiki/phpwiki_pagedb.db ? Yes - the file opened correctly with sqlite for the database upgrade scripts. OK, The most likely cause is one of these upgrade scripts failing - although you should definitely have got an error... Can I get you to do the following please? On a copy of the original database (ie what you were upgrading from), run the following two commands in order /usr/bin/sqlite DB_FILE \ /usr/share/doc/phpwiki/schemas/sqlite-upgrade-1.3.10.sql /usr/bin/sqlite DB_FILE \ /usr/share/doc/phpwiki/schemas/sqlite-upgrade-1.3.11.sql (replacing DB_FILE with the location of the old database) after each command you could check that the contents of the page table in the database appears correct. You can do this by loading up the database with sqlite DB_FILE which will drop you at a console where you can execute standard sql commands. The command .schema [tablename] will show you the tables in the database and the structure of a table. I believe so - we were using external HTTP authentication which IIRC was not turned on by default or configurable using debcconf. If you'd like I can send you the old index.php. It's probably not relevant at this stage, the results of the above tests will be much more revealing. My current hypothesis is that there is something in your database that is causing the upgrade scripts to silently fail. I can't reproduce the problem here unfortunately so hopefully you'll be able to see something go wrong with the above tests. Thanks for your help. -- 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#361337: phpwiki: Upgrade re-initialized database
Hi Chris Adams wrote: I upgraded a running phpwiki install from a sarge system. We used external authentication in the past which meant that phpwiki bombed out the first time it tried to hit the user table; after changing ENABLE_USER_NEW to false I was able to login but phpwiki starts setting up the database from scratch, deleting all of our content and inserting its default pages. PHPwiki itself does not delete pages. Default pages are only inserted when PHPwiki is first run with a completely blank database. The fact that you encountered this seems to suggest that something went wrong during the upgrade (at the dpkg step - probably postinst) and trashed the database file. I'll need some more information from you to help determine what. - I assume you are using sqlite? - Is your database stored in the standard location /var/lib/phpwiki/phpwiki_pagedb.db ? - What version of the package were you upgrading from? - Did you have any customisations to the config.ini/index.php that you were upgrading from? - Were there any errors output by dpkg (or the postinst script) during the upgrade process? That should give us a start to tracking down what went wrong. Since it's probably going to be difficult to reproduce this problem I entered this bug more to request that any updates with significant database changes save a copy of the original sqlite file in case something goes wrong with the update.. That could be a solution, but I'll need to work out exactly what failed before determining what needs to be done to fix it. Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: OpenPGP digital signature
Bug#318030: [Buildd-tools-devel] Bug#318030: Does not pass -sa to dpkg-buildpackage when sbuild is run with -s
Michael Banck wrote: Is there a use-case for this (always including the .orig when telling sbuild to build source as well, no matter what revision)? Yes, the use case I have is that we are created a derived distribution from Debian. The first revision of the package that we put into our archive is not necessarily the -1 revision that would trigger the source to be placed in the Debian archive. For this reason we want sbuild to include the source tarball in all packages built for our custom distribution. If so, it should maybe be made an official config option perhaps. This is clearly not useful for buildds (at least the official ones), so this is our decision I guess. I cannot see a usecase for this option when using sbuild as an offical buildd. It's primary use is for those building a derived Debian distribution. An option that is off by default and only turned on when required would be fine by me. Whether that option is on the command line or in the configuration file is not important. Kind Regards -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318030: Does not pass -sa to dpkg-buildpackage when sbuild is run with -s
Roger Leigh wrote: Are there any objections to applying the last patch? http://bugs.debian.org/cgi-bin/bugreport.cgi/sbuild-include-source.diff?bug=318030;msg=55;att=1 It is fine with me. It would have been nice if you kept the patch small and contained to the source build change rather than fixing other unrelated errors however (documentation escaping for example). But that's a minor nitpick :P Cheers -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318030: Does not pass -sa to dpkg-buildpackage when sbuild is run with -s
Roger Leigh wrote: Super, thanks for the quick response. I did change the option to --force-orig-source; is this OK with you? Yes, I'd much rather have the option available than worry about what it is called. This will be available with the next upload, unless you would like anything amending before then. No that is all. Thanks for your work :) Regards -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356474: phpwiki: does not work with PHP5
tag 356474 + accepted thanks bts On Sun, 2006-03-12 at 11:21 +0100, Carlos Izquierdo wrote: I have an Apache2 server with PHP5. When trying to install phpwiki, the system asks me to remove php5 and install the corresponding php4 libraries. I've checked some documentation and phpwiki apparently works with php5. Can the dependencies for phpwiki be modified so it supports php5 as well as php4? Most certainly, this has been on the TODO list for a while. I'll try my best to get a new release uploaded in the next week or two. Kind Regards -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344687: phpwiki: French debconf templates translation update
tag 344687 + pending thanks bts On Sat, 2005-12-24 at 19:42 +0100, Jean-Luc Coulon (f5ibh) wrote: Please find attached the French debconf templates translation update, proofread by the debian-l10n-french mailing list contributors. Thanks very much Jean-Luc. This has been committed as r135 in the package repository at http://svn.mattb.net.nz/trac/debian/changeset/135 A new version of the package should be uploaded with this fix very shortly. -- Matt Brown [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz signature.asc Description: This is a digitally signed message part
Bug#353617: dbconfig-common lacks dependency on postgresql-client
Hi Sean, Thanks for your response. On Mon, 2006-02-20 at 01:15 -0500, sean finney wrote: if you depend on dbconfig-common, then you also need to depend on the cmdline tools for the database types you support. otherwise you'd have to install postgres clients and libraries even if you were packaging a mysql app and vice versa. It still seems strange for my package to have to depend on a package that doesn't provide anything I directly use. I guess how I would like dbconfig-common to work would be to present a list of possible databases to install to (being the intersection between those that are available on the system and those that the package maintainer has provided schemas, etc for). The mysql, postgres and in the future (sqlite, etc) tools could be promoted to Recommended for dbconfig and then dbconfig would simply present options for those databases the admin has indicated they might want to use by installing the tools. Do you think there would be any chance of dbconfig-common moving to a scheme such as this in the future. Shall I downgrade this bug to a wishlist? 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 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#353617: dbconfig-common lacks dependency on postgresql-client
Package: dbconfig-common
Version: 1.8.11
Severity: important
Justification: renders package mostly unusable
Hi,
dbconfig common failed to install the database for my package because
the postgresql-client package was not installed which prevented
dbconfig-common from creating a user for the package. The following
error is output
sanity check failed for createuser.
error encountered creating user:
No pgsql createuser to execute. (have you installed postgresql-client?
dbconfig-common: ccsd configure: aborted.
dbconfig-common: flushing administrative password
dpkg: error processing ccsd (--install):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
ccsd
I notice that you already suggest postgresql-client but I believe this
should be a dependency as the package is unable to operate successfully
without this utility installed.
I've added a dependency on postgresql-client to my program as a
workaround, however my package uses the python libpq bindings so this is
a redundant dependency.
(Note: I am using a backported dbconfig-common package for Sarge, but
I've kept the dependencies the same, so there is no problem there).
Please consider adding a Depends for postgresql-client to the
dbconfig-common package.
Kind Regards
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.13.5
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages dbconfig-common depends on:
ii debconf [debconf-2.0] 1.4.30.13 Debian configuration management sy
ii pwgen 2.03-1 Automatic Password generation
ii ucf 1.17 Update Configuration File: preserv
-- debconf information:
dbconfig-common/import-oldsettings:
dbconfig-common/pgsql/revertconf: false
dbconfig-common/install-error: abort
dbconfig-common/pgsql/no-empty-passwords:
dbconfig-common/pgsql/admin-user: postgres
dbconfig-common/dbconfig-install: true
dbconfig-common/db/dbname: ${pkg}
dbconfig-common/remote/host:
dbconfig-common/pgsql/manualconf:
dbconfig-common/pgsql/changeconf: false
dbconfig-common/remote/newhost:
dbconfig-common/dbconfig-remove: true
dbconfig-common/dbconfig-upgrade: true
dbconfig-common/mysql/method: unix socket
dbconfig-common/pgsql/no-user-choose-other-method:
dbconfig-common/upgrade-backup: true
dbconfig-common/performing_upgrade: false
dbconfig-common/passwords-do-not-match:
dbconfig-common/pgsql/authmethod-admin: ident
dbconfig-common/remove-error: abort
dbconfig-common/remember-admin-pass: false
dbconfig-common/mysql/admin-user: root
dbconfig-common/pgsql/method: unix socket
dbconfig-common/pgsql/authmethod-user: ident
dbconfig-common/upgrade-error: abort
dbconfig-common/database-type:
dbconfig-common/db/app-user:
dbconfig-common/remote/port:
dbconfig-common/purge: false
--
Matt Brown
[EMAIL PROTECTED]
Mob +64 21 611 544 www.mattb.net.nz
signature.asc
Description: This is a digitally signed message part
