Bug#772993: O: chimera2 -- ancient web browser
Package: chimera2 Chimera2 is an ancient web browser for X11. Fifteen years ago when I packaged it, it was handy to have a less bloated web browser, and almost all web pages still worked well on it. Now it's basically useless as a browser, at least for the public internet, as hardly any web pages will work with it, and the hardware that needed it is even more obsolete. It hasn't had a new upstream version since 1999. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772994: O: pcre3 -- Perl 5 Compatible Regular Expression Library
Package: wnpp Severity: important I am orphaning and request an adopter for the pcre3 package. If you don't already know what it is, you're probably not the right person to take it over, but the description is: This is a library of functions to support regular expressions whose syntax and semantics are as close as possible to those of the Perl 5 language. I am orphaning this because I intend to retire from Debian, as I don't feel I have enough time to do a good job any more. It's an important package and I wouldn't orphan it otherwise. The package is currently in a reasonably good state.
Bug#772995: O: chimera2 -- ancient web browser
Package: wnpp Chimera2 is an ancient web browser for X11. Fifteen years ago when I packaged it, it was handy to have a less bloated web browser, and almost all web pages still worked well on it. Now it's basically useless as a browser, at least for the public internet, as hardly any web pages will work with it, and the hardware that needed it is even more obsolete. It hasn't had a new upstream version since 1999. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772997: O: pcre3 -- Perl 5 Compatible Regular Expression Library
Package: pcre3 Severity: important I request an adopter for the pcre3 package. If you don't already know what it is, you're probably not the right person to take it over, but the description is: This is a library of functions to support regular expressions whose syntax and semantics are as close as possible to those of the Perl 5 language. I am orphaning this because I intend to retire from Debian, as I don't feel I have enough time to do a good job any more. It's an important package and I wouldn't orphan it otherwise. The package is currently in a reasonably good state.
Bug#772993: Acknowledgement (O: chimera2 -- ancient web browser)
close 772993 thanks This was of course a mistake - should have been filed on wnpp not the package I was orphaning. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760327: pcre: disable JIT on powerpcspe, x32
I apologise for not having done anything about this yet. I've been busy with various things including moving house, and still do not have internet in the new house. Your patch looks good. If you want to do an NMU that would be appreciated; otherwise I will do a release as soon as I can but that will be next week. -Original Message- From: Thorsten Glaser [mailto:t.gla...@tarent.de] Sent: 24 October 2014 16:59 To: 760...@bugs.debian.org Cc: cont...@bugs.debian.org Subject: Bug#760327: pcre: disable JIT on powerpcspe, x32 tags 760327 + patch thanks Hi, attached a debdiff, which also takes care of powerpcspe. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763054: pcre3: FTBFS on hurd because of stack size problem
On 27 Sep 2014, at 16:10, Ólafur Jens Sigurðsson ojs...@gmail.com wrote: The package fails to build on hurd because the pthread stack size in only 2024 kb instead of the 8192 kb that linux has. Would it be a good idea to use the heap instead of the stack to fix this? I have considered using this anyway, to fix the many bug reports where pathological input can cause it to crash. I think now that, with the limit recursion feature and pcre_dfa_exec() I can close those bugs or re-assign them back to the applications. I'm not averse to using the heap for recursion on hurd if that's what you guys decide is the best option. I don't see any reason why it has to be the same on hurd as it is on linux. I'll go with what you decide. But it sounds like you've decided not to do this and to increase the stack space instead. In that case can I close this bug? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656008: nmu for pcre3
Oh I'm sorry, I'd completely forgotten about that one. I have no objection to your NMU. On 29 Sep 2014, at 00:21, Michael Gilbert michael.s.gilb...@gmail.com wrote: Hi, I've uploaded an nmu enabling build hardening flags for pcre3 to delayed/5. Please let me know if I should delay longer. Best wishes, Mike pcre3.patch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751828: pcre3: FTBFS [ppc64el]: Test failure in common with amd64
Thanks for the patch. In fact I was intending to do an upload yesterday, and held off when I saw this message. Looking at the bugs you filed on PCRE and glib (thanks), it looks like I should go ahead with a pcre 8.35 release, and glib will have to deal with this, do you agree? On 20 Jul 2014, at 18:56, Simon McVittie s...@debian.org wrote: On Sun, 20 Jul 2014 at 16:07:06 +0100, Simon McVittie wrote: This was already reported as http://bugs.exim.org/show_bug.cgi?id=1463 and fixed upstream as part of r1472. However, the upstream fix did not update the expected output, so the tests still fail. The upstream fix did in fact update the expected output, I just wasn't paying enough attention to the other contents of the svn commit. I plan to do a delayed NMU soon with the attached changes, if the maintainer doesn't upload first. However, I haven't done so yet, because the updated pcre3 seems to trigger a test failure in the pcre consumer I'm mainly interested in (GLib), and I want to be sure that these changes aren't what's to blame for that. Thanks, S pcre3-nmudiff-751828.diff -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751390: src:pcre3: use dh-autoreconf to fix FTBFS on ppc64el
On 18 Jun 2014, at 18:44, Helmut Grohne hel...@subdivi.de wrote: Control: tags -1 - patch On Mon, Jun 16, 2014 at 06:28:40PM +0200, Helmut Grohne wrote: On Thu, Jun 12, 2014 at 02:00:26PM +0200, Erwan Prioul wrote: * Build using dh-autoreconf for new port support. The original pcre3 package patches configure to fix the soname. Yes. It is unfortunate that this is necessary, but debian had PCRE building a shared library before this was supported upstream, and when upstream added shared library support I felt that compatibility with existing debian packages was more important than compatibility with other linux distributions so kept the soname I had previously used. Since then there has never been a need for a change to the soname, or I would have taken the opportunity to change it to be the same as upstream. By applying dh-autoreconf this fix is ignored and the resulting binary packages become broken. Presumably what I need to do is to patch configure.ac instead of configure. The version numbers appear to be conveniently at the top of there, so this should be straightforward. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747385: pcre3 failed to run test on mips64el: segmentation fault
It build successfully while failed when run test. Specifically it failed when testing pcregrep - the tests of the library itself worked. Have previous versions worked? After the build has failed, you should be able to find pcregrep in the directory where it has built, and try running it yourself. I would expect it to consistently crash, since every one of the tests did. Can you use gdb to see where it is crashing? I think it's built with debug symbols . I don't have access to a mips64el machine so I can't do this myself. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745222: src:pcre3: FTCBFS on arm64 m68k and others: sljit detection uses build compiler
I fully agree with your assessment. Would you like me to work on an improved patch or would you like to do it yourself? I'd like to do it myself. I'm going to add a shell script as follows: #!/bin/sh $1-gcc jit-test.c -o/dev/null If [ $? -eq 0 ]; then echo --enable-jit fi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745222: src:pcre3: FTCBFS on arm64 m68k and others: sljit detection uses build compiler
On 19 Apr 2014, at 10:03, Helmut Grohne hel...@subdivi.de wrote: pcre3_8.31-4.1.debdiff Surely that's not going to work? Having used the host compiler to build the test program, it then tries to execute it on the build machine. I think what is needed is to use #error to abort the compilation of the test program when JIT is not supported, and check the exit code from the compiler. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745114: src:pcre3: FTBFS on arm64 m68k and others: sljit not implemented
Rather than hard-coding a list of architectures in the build script, I have
included this very simple program:
#define SLJIT_CONFIG_AUTO
#include ../sljit/sljitConfigInternal.h
#include stdio.h
int main(void)
{
#ifndef SLJIT_CONFIG_UNDEFINED
printf(--enable-jit);
#endif
return 0;
}
so it uses the macros that are in sljit to decide whether it is supported, and
outputs --enable-jit accordingly.
However I haven't yet tested it on any architecture that doesn't support JIT,
so please re-open this bug if necessary.
On 18 Apr 2014, at 06:36, Helmut Grohne hel...@subdivi.de wrote:
Package: src:pcre3
Version: 1:8.31-3
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Since you added --enable-jit, pcre3 startes to FTBFS on various
architectures:
http://buildd.debian-ports.org/status/package.php?p=pcre3
For architectures such as arm64 or m68k, the jit simply is not
implemented and the CPU detection in sljit fails. I suggest that you
disable the jit for architectures where it is not supported.
I attach a patch for arm64 and m68k, but this likely affects others as
well.
Helmut
pcre3_disable_jit.debdiff
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#24509: test patch for this issue
On 11/05/13 15:58, Flos Lonicerae wrote: I rebuilt the package 'chimera2_2.0a19-7_amd64.deb' with '-g -O0' then collected the core dump file. And try to look into the issue with gdb: [...] And from the context, it seems that the XLFD_COUNT is related to the XLFD, not the count of FontList info. I suspect that it would be misused... I agree with your analysis. And I recompile the package, the segfault does not happen again. And the patch works for me too. I'll upload a new package with this fix in it. Thank you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686495: libpcre3: Very large value for re_nsub
I wasn't attempting to get a fix into testing. I agree that the bug is not that serious and I would have no problem with wheezy releasing with the bug present. However I don't need to cherry pick the patch, it's quite separate from the new version update that was also in that version, so I can very easily apply that patch to 8.30 for a testing-proposed-updates upload, if people think that I should. On 24 Sep 2012, at 15:35, Cyril Brulebois wrote: Control: severity -1 important Patrick Häcker pa...@web.de (02/09/2012): Package: libpcre3 Version: 1:8.30-5 Severity: grave Tags: patch Justification: causes non-serious data loss […] so unsaved data gets lost. That's not data loss, then. I'm downgrading the severity of this bug report accordingly. Given the huuuge diff between testing and unstable (156 files changed, 11615 insertions(+), 6940 deletions(-)), if you want to get a bug fix into wheezy anyway, I'd suggest cherry-picking the patch and considering an upload to testing-proposed-updates. In which case, please contact debian-release@ with a prospective diff against testing. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686495: libpcre3: Very large value for re_nsub
The patch has now been accepted by upstream and will be in the next release. http://bugs.exim.org/show_bug.cgi?id=1287 I'm happy to include it in the debian package before that, and will do when I get time in the next week. On 2 Sep 2012, at 12:35, Patrick Häcker wrote: Package: libpcre3 Version: 1:8.30-5 Severity: grave Tags: patch Justification: causes non-serious data loss Dear Maintainer, when compiling the regular expression regex_t rx; regcomp(rx, ^(\\(\\))? *(.*)$, 0) I get the large value 140733193388034 for rx.re_nsub. As this value is often used afterwards in malloc this normally leads to the termination of the programm (either because of the segfault or due to the assumption of no free memory), so unsaved data gets lost. The problem is well known (http://www.exim.org/lurker/message/20120822.143744.147fd5d2.de.html) and a patch exists (http://bugs.exim.org/attachment.cgi?id=586). I can confirm that the patch works. Please consider applying the patch. Cheers Patrick -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-proposed-updates'), (500, 'stable-updates'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpcre3 depends on: ii libc6 2.13-35 ii multiarch-support 2.13-35 libpcre3 recommends no packages. libpcre3 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670018: libpcre3-dbg: arch-dependent files in multiarch: same package
Is there any consensus about where debug files should go? Or should I use .buildid instead? On 22 Apr 2012, at 14:20, Julien Cristau wrote: Package: libpcre3-dbg Version: 1:8.30-4 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch Hi, libpcre3-dbg is marked as Multi-Arch: same, but contains files in arch-independent paths with arch-specific contents: [libpcre3-dbg 1:8.30-4] usr/lib/debug/usr/lib/libpcre.so.3.13.1 usr/lib/debug/usr/lib/libpcreposix.so.3.13.1 Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667664: libpcre3: upgrade from 8.12 to 8.30 breaks (oldstable-era) dansguardian
I can't reproduce this with dansguardian 2.9.9 either. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667664: libpcre3: upgrade from 8.12 to 8.30 breaks (oldstable-era) dansguardian
On 5 Apr 2012, at 20:19, Yann Dirson wrote: Disclaimer: I am still using an old dansguardian (2.9.9.7-2.1, last pre-2.10 packaged version) because http://bugs.debian.org/536778 which in itself is a blow in the face of us developers, but that's another story which *should not* be related to compatibility breakages... I can't reproduce this with 2.10; I'll try downgrading to 2.9 and see if I can reproduce it there. Now dansguardian does not have a lot of debug traces to activate, and I didn't look at the libpcre API yet. Any idea of a particular change that could cause such a breakage ? I'm not aware of any change that's likely to cause such a breakage. There are two incompatible changes in this version of PCRE, one is that the pcre_info() has been removed, but I put that back in, the other is that the unicode code points that are reserved for encoding high characters in UTF-16 are not accepted in UTF-8 mode. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665421: pcre3: Invalid version string 8.30..-3 makes impossible to download the packages with apt
On 24 Mar 2012, at 00:53, Dmitrijs Ledkovs wrote: Please do not use two consecutive dots in the package name? There's nothing wrong with two consecutive dots. The specification says only that a version number consists of digits separated by non-digits. There is nothing special about dots, and it is very common to have more than one consecutive non-digit. However, you're not the only person to have had problems with it and in the latest release I have reluctantlly used an epoch instead. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664983: Version
Since someone has released an 8.30.really8.12-1.1 version, I'm going to released the fixed version as 8.30..-2, as that sorts correctly after 8.30.really8.12-1.1 and before 8.31-1. What would have been wrong with 8.30-1.really.8.12.1 which would have let me replace it with a proper 8.30 version easily? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664983: pcre3 #664983
On Thu, March 22, 2012 12:44 pm, Torsten Wohlfarth wrote: EXTRA_LIBPCRE_LDFLAGS=$EXTRA_LIBPCRE_LDFLAGS \ - - $NO_UNDEFINED -version-info 1:0:0 + $NO_UNDEFINED -version-info 16:1:13 Thanks. Actually I knew what the problem was as soon as I saw the bug report. I updated the last number but should have updated the first one too. There are many reasons I hate libtool but the obscurity of the version numbering system is definitely on the list. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664983: closed by Mark Baker m...@mnb.org.uk (Bug#664983: fixed in pcre3 8.30..-2)
In personal email, Hector Oron wrote: There were more files with wrong SONAME. I assume you have verified it. There were two libraries that were wrong, and I fixed the only two places that had a version number set, so I assumed it was all fixed, but I only checked libpcre.so.3. After I got your email I checked the other one, and it was still wrong. This was a different bug - the version number was not set on libpcreposix.so at all, but was wrongly set on the 16 bit version of libpcre.so, which doesn't get built at all. This is because I applied the diff manually (it didn't work automatically) and got it wrong. I doubt anyone would ever have noticed, I don't think anyone uses libpcreposix I've now uploaded a version which fixes this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634250: Please transition pcre3 for multiarch
On 18/07/11 07:47, Steve Langasek wrote: Please find attached a patch to pcre3 to transition it to use of the multiarch library paths as described at http://wiki.debian.org/Multiarch/Implementation. Thanks. I've been meaning to look into this for a while. I hadn't realised it was so straightforward. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522441: misreported gzip-compressed files
Similarly, my manpage is mis-reported as a GRUB stage 2. (that's /usr/share/man/man3/pcre_copy_substring.3.gz in libpcre3-dev). gunzip --test would be a more reliable check for whether something is really in gzip format. It's potentially far slower of course, but for changelogs and man pages I wouldn't have thought it would be a problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581202: libpcre3 8.02-1 causes approx/stable to segfault
On 11/05/2010 15:59, Lucas Nussbaum wrote: Upgrading libpcre3 from version 7.8-3 (in testing) to version 8.02-1 (in unstable) causes approx 3.3.0 (in stable) to start segfaulting at startup (on amd64). It works OK on i386. The version in unstable works on both. Although I can reproduce this easily, I'm not sure how to go about tracking down the problem. There are no debugging symbols in the released binary so gdb doesn't reveal much. When I built approx 3.3.0 from source, it worked (or at least didn't crash on startup, I didn't try to install it). pcre_config(0, 0x7fffd014, 57, 0x7f7e6fb36900, 0x7fffcf40) = 0 pcre_config(1, 0x7fffd014, -84616, 0x7f7e6fb36900, 0x7fffcf40) = 0 pcre_config(2, 0x7fffd014, -84632, 0x7f7e6fb36900, 0x7fffcf40) = 0 pcre_config(4, 0x7fffd014, -84584, 0x7f7e6fb36900, 0x7fffcf40) = 0 Which returned OK, so it didn't crash in these functions. I'm not sure what ltrace outputs if a signal is received during a library call, does it output anything for the library call at all? i.e. could there be another pcre function called after these ones, which ltrace hasn't output anything for because of the seg fault? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555808: libpcre3: segfault on matching certain regexes with large input
I believe this is a duplicate the many other bugs in PCRE; basically that it's possible to get stack overflows with certain regexes. It's not a major security problem, in that I don't think you can get arbitrary code execution by a stack overflow. It could possibly allow DoS attacks in some cases. There are a couple of compile time options for PCRE that can ameliorate the problem. One allows a maximum recursion depth to be set, which avoids seg faults (so long as the stack space is large enough) but limits the regexes that can be used. The other stops it using recursion in this way, instead allocating memory on the heap to store state that would be on the stack in a recursive call. I am thinking of using the latter option in the next version. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552002: Time to remove pcregrep?
It's unclear to me that pcregrep is a genuinely useful alternative, as as far as I can see it just tries to be like a standard grep but with PCRE regexs, hence I don't think this is squashing choice or insisting on One True Grep, but reducing confusion and effort. There is one useful feature that I don't think GNU grep has, which is multiline mode. Even without that, I don't see that there is a good reason to drop it; some people will be used to using it, and it's name is sufficiently specific that it's not clogging up the namespace. It really isn't any extra effort to maintain it. I'm happy to get rid of it if the general consensus is that that would be the right thing to do, but personally I'm not convinced. (The main reason for its existence in the upstream source is as sample code, but as more and more features have been added it's not as useful for that as it was in early versions) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#465676: I have the same bug with subtitleeditor (0.20.0)
Anibal Avelar wrote: Some users has gone this message: $ subtitleeditor subtitleeditor: symbol lookup error: subtitleeditor: undefined symbol: _ZN7pcrecpp6no_argE I think the problem is exactly the same described on this bug. The users had the version 7.4-1+lenny1 and 7.6-1, but I can't reproduce it. I don't know if the last version 7.6-2 to fix the problem. That looks like the same problem, and 7.6-2 should fix it. I suppose if you wanted to be sure you could downgrade pcre on your system and see if you can reproduce the fault that way, but with that error message I'm fairly sure it's the same problem. The problem was marked how grave, but I'm thinking to reassign the bug to the libpcre3 package. If you do, I'll immediately close it, as it's a duplicate of this and so is already fixed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464320: Request for binNMUs for libpcre3 [Fwd: Bug#463413: problem solved by recompiling the package !]
On Wed, Feb 06, 2008 at 06:54:47PM +0100, Andreas Metzler wrote: It simple rebuild would still break partial upgrades. Yes, I agree. I don't think rebuilding the reverse dependencies is the right solution. The changelog suggests that the ABI change is un-necessary (it was an attempt to fix a problem on windows). We could just revert the change, but that would mean we had a different ABI from other distributions. I'm not sure what the best solution is here. What if anything have other distros done? Is it clear at all yet whether the ABI breakage is in the C++ wrapper libpcrecpp0 or in the main library? Yes, it's in the C++ wrapper. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377587: Patch to ship pcredemo.c in libpcre3-dev
Daniel Hahler wrote: In Ubuntu, we've applied the attached patch to achieve the following: - debian/libpcre3-dev.examples, debian/rules: Install pcredemo.c example. We thought you might be interested in doing the same. Thank you, yes I will do this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443114: Please provide an udeb
On Tue, Sep 18, 2007 at 09:32:58PM +0200, Loïc Minier wrote: Do you think you could provide an udeb for libpcre3? I can't think of any reason why not. I've never built a udeb before so it will have to wait until I've got a few hours free to learn how to do it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436277: pcregrep: unknown option bit(s) set
Carl Fürstenberg wrote: Everytime I tries to use pcregrep, it just fails telling: pcregrep: Error in command-line regex at offset 0: unknown option bit(s) set It works fine for me: p4-7088:~grep power.*wait /etc/inittab pf::powerwait:/etc/init.d/powerfail start po::powerokwait:/etc/init.d/powerfail stop p4-7088:~dpkg -l pcregrep Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii pcregrep 7.2-1 grep utility that uses perl 5 compatible reg p4-7088:~ Please send me the input you used to get the error message and I will investigate. Until then there's not a lot I can do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420280: libpcre3: Please package PCRE 7.0, which includes important fixes and updates
Magnus Holmgren wrote: PCRE is now at version 7.2, with 7.3 coming up. I've tried to package it before. Most of it was easy, but I couldn't get the test-suite to pass because the tests for pcregrep are dependent on a directory listing being in a particular order, which it wasn't. No, I know that's not a good excuse for why I still haven't packaged it. I've been a bit busy since then and not had time to get back to it. I should have more time now. Have you discussed the things you mention in README.Debian with Philip (proper library versioning The upstream library versioning is perfectly OK, and in line with libtool guidelines. It's just that as debian had been packaging pcre as a shared library for many years before upstream did we've ended up with different numbers. I don't see how either us or upstream can change right now, but it would be good if next time, if ever, there's an incompatible ABI change we can get a soname that both debian and upstream can use. No I haven't discussed this with Philip. and the pcreposix clashes with libc)? I can't remember. I'm surprised no-one else has found the problem, and can only assume that no-one uses pcreposix, at least not on linux. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329759: I have this problem
I've got a sarge/testing system, and tried to upgrade to lenny this week, but ran into exactly this problem. Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420280: libpcre3: Please package PCRE 7.0, which includes important fixes and updates
I was waiting for etch to come out. I guess I don't have that excuse any more. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420191: ftp.debian.org: please remove exim from sid and lenny
Marc Haber wrote: please consider removing exim (that is exim 3, not exim4) from sid and lenny. The package is unmaintained upstream, the last updates have been NMUs (with Mark Baker's consent), exim4 is a replacement. Just to confirm that I agree with this; exim should be removed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385718: Are you sure?
Are you sure? This web page, which appears to be the official download site, says at the top that the latest version is 6.30. http://www.inform-fiction.org/software/current.html Yes, I can see that there's a Windows binary that claims to be 6.31. Perhaps there's a Windows specific bug-fix in there? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400121: Can't reproduce 400121 with libpcre3
On Wed, Nov 29, 2006 at 12:59:47PM +0100, Tom Parker wrote: I've just been doing the test that Olivier Trichet mentioned with pcretest, with a file containing 30,000 Z's, and I don't get a crash. This is with libpcre3 6.7-1 on i386. I can reproduce it with pcregrep; no idea why pcretest might not suffer from it. It crashes when it gets to 8192 recursive instances of the match function, possibly due to running out of stack space? You are looking for a pattern of (.)* I assume? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400121: Can't reproduce 400121 with libpcre3
On Wed, Nov 29, 2006 at 03:49:02PM +0100, Tom Parker wrote:
about my system... where exactly does pcregrep crash? A stack trace
would be nice.
p4-7088:~for i in $(seq 1 8192); do echo -n Z file; done
p4-7088:~pcregrep '(.)*' file
Segmentation fault
Running it under gdb, using the copy in the build tree (as the installed
version is stripped):
(gdb) run '(.)*' /home/mark/file
Starting program: /home/mark/debian/pcre/pcre3-6.7/.libs/pcregrep '(.)*'
/home/mark/file
Program received signal SIGSEGV, Segmentation fault.
match (eptr=0xbfff842d 'Z' repeats 200 times..., ecode=0x804df0f \vC,
offset_top=4, md=0xbfff72f8, ims=0, eptrb=0xbf800644, flags=2, rdepth=8156)
at ./pcre_exec.c:378
378 {
(gdb) bt
#0 match (eptr=0xbfff842d 'Z' repeats 200 times..., ecode=0x804df0f \vC,
offset_top=4, md=0xbfff72f8, ims=0, eptrb=0xbf800644, flags=2, rdepth=8156)
at ./pcre_exec.c:378
#1 0x40029014 in match (eptr=value optimized out,
ecode=value optimized out, offset_top=value optimized out,
md=0xbfff72f8, ims=0, eptrb=0xbf800644, flags=value optimized out,
rdepth=8155) at ./pcre_exec.c:629
#2 0x400255b7 in match (eptr=0xbfff842d 'Z' repeats 200 times...,
ecode=value optimized out, offset_top=4, md=0xbfff72f8, ims=0,
eptrb=0xbf800e44, flags=value optimized out, rdepth=8154)
at ./pcre_exec.c:1190
#3 0x40029014 in match (eptr=value optimized out,
ecode=value optimized out, offset_top=value optimized out,
md=0xbfff72f8, ims=0, eptrb=0xbf800e44, flags=value optimized out,
rdepth=8153) at ./pcre_exec.c:629
#4 0x400255b7 in match (eptr=0xbfff842d 'Z' repeats 200 times...,
ecode=value optimized out, offset_top=4, md=0xbfff72f8, ims=0,
eptrb=0xbf801644, flags=value optimized out, rdepth=8152)
at ./pcre_exec.c:1190
and so on for thousands more calls to match(), with alternating calling
addresses. Where it's actually failed is right at the beginning of the
function, before it's got to any code. Looks like a stack overflow?
Ah, yes, if I use ulimit to make my stack size unlimited it works as
expected. (presumably that's what's different about your system).
I don't think there's a bug here. Using lots of stack space for a
pattern like this is not unreasonable, and dying horribly when you run
out is something you don't get a whole lot of control over.
There is a limit recursion feature of PCRE, which the calling program
could use.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380725: incompatible soversion
On Tue, Aug 01, 2006 at 09:40:26AM +0200, Harald Dunkel wrote: Upstream uses a different soversion for libpcre than Debian. RedHat and Suse are using upstream's soversion, i.e. packages built on these distros cannot be run on Debian. Debian have always built libpcre as a shared library, starting with version 1.x which we used a soname of libpcre.so.1 for; after 3.x, for which we used a soname of libpcre.so.3, we haven't had to change the version number as the interface has been compatible. The upstream makefile has only built a shared library since 4.x; since we were already building one we kept our existing soname rather than changing to be compatible with upstream as I felt that being compatible with existing other debian software that already used our shared library was more important than compatibility with third party software that might exist in future. I would suggest to add a symbolic link to libpcre3, providing upstream's soversion. Will that work? I thought the soname compiled in to the library had to match as well. Sorry I didn't respond to the email you sent last week on this subject. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375965: Bug#359397: Bug#359404: [exim] Intend to NMU: /usr/doc transition
On Fri, Jul 14, 2006 at 02:14:42PM +0200, Marc Haber wrote: Can we then follow this steps? - tag the bugs as etch-ignore - retitle them slightly (so that I can track that this was dealt with? No objections on these counts. Please be aware, though, that exim 3 is maintained by Mark Baker, not me. I'm happy with this suggestion. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377295: exim: db_upgrade error during configuration
severity 377295 normal thanks Marc Haber wrote: On Fri, Jul 07, 2006 at 02:32:04PM -1000, Ryo Furue wrote: bash# dpkg-reconfigure exim db_upgrade: /var/spool/exim/db/retry.lockfile: unrecognized file type db_upgrade: DB-upgrade: /var/spool/exim/db/retry.lockfile: Invalid argument bash# I marked this bug as grave but I actually don't know how severe this error is. All I can say is that exim *seems* to continue to be working, but . . . This is the usual berkeley DB foo. Try moving /var/spool/exim/db away, creating an empty directory, and see whether this helps. Not entirely. There's a bug here that it tries to check all files in the directory, including the lockfile. I ought to write a more complicated pattern so it ignores lock files. However, there shouldn't ordinarily be a lock file there as exim isn't running - something must have crashed and left it perhaps? All errors from the database upgrade are ignored, so this will have no effect on whether exim runs properly, so this is not really a problem. However the error message sounds bad, so this will confuse people and ought to be fixed. I will do something about it if and when I do another exim package. And, please take a look at the new Description of the exim 3 package, consider that it might disappear from Debian any time soon, and update to exim4. I second this excellent advice. Despite maintaining the exim 3 packages, I have run exim4 on my own server for years. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369241: Esperanta traduko de exim4/debian/po/eo.po
reassign 369241 exim4 thanks Serge Leblanc wrote: Hello, herewith a translation in esperanto of the file: ./exim4/debian/po/eo.po Sincerely, Thanks, however this is for exim 4, which is in the exim4 package; the package called exim contains the (obsolete) exim 3. I've reassigned your bug report to the correct package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359662: libpcre3-dev doesn't install libpcre.pc, so pkg-config can't find libpcre
Charles Kerr wrote: In this case, the only way this bug would be 'important' would be if most people only use libpcre3-dev for compiling someone else's software, rather than for writing and developing their own. If you're writing your own software that uses pcre, obviously you'll know better than to rely on pkg-config to find every last library in the world. Even if you know that pcre is supposed to support pkg-config, it won't faze you much when Debian's happens not to. You can debate whether this issue is a wishlist or important, but IMO there's not been a good explanation of _why_ Debian shouldn't ship with the pc file that the pcre developers, and the other distros, use. The reason why it doesn't is that pcre didn't used to include a pc file, and the fact that it was included wasn't mentioned sufficiently prominently in the changelog for me to notice it, so the debian package never got updated to included it. I'm not sure why it isn't installed automatically anyway without any intervention from me, but apparently it isn't. There is no reason why it shouldn't be included, and now I know it exists (I hadn't heard of pkg-config until I got this bug report) I will include it in the next release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354754: chimera2: Crashes on www.debian.org (recompile needed?)
On Tue, Feb 28, 2006 at 10:12:26PM +0100, Helge Kreutzmann wrote: [EMAIL PROTECTED]:~$ env LANG=C chimera2 Cache resource not found. Not caching. libpng warning: Application was compiled with png.h from libpng-1.0.6 or earlier libpng warning: Application is running with png.c from libpng-1.0.18 libpng error: The png struct allocated by the application for reading is too small. I notice you're using revision -3.3, which is the latest one in debian stable. Have you tried the package from unstable (-5)? I think that one should work; I think it depends on an even later version of libpng than you have installed. I'm not sure what happened to the version you have; I'm sure it used to work. I think the libpng upstream changed the ABI without changing the soname, and therefore with the debian maintainer didn't change the package name. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354754: chimera2: Crashes on www.debian.org (recompile needed?)
Helge Kreutzmann I rebuild the sid version on Sarge without problems and now chimear works on several pages where it used to crash badly with the above error (including www.debian.org) Good. The sid version includes some changes to the source code to work with libpng12, which has a slightly different API. sid version requires libpng12-dev. Since a trivial recompile (I tried this first) did not help, I would have expected that recompiling using the libpng2-dev corresponding to the libpng2 that you want to use it with ought to work - if not that's a serious bug in the libpng2 packages, since it will stop anything from working with it properly. If you can nail down the problem and convince Joey that a minimal modified chimera could enter Sarge at the next dot-release, fine, otherwise you can close this bug (with the proper versioning, of course). I'll close the bug. Thanks for maintaining chimera2, it is probably the oldest unchanged browser for Debian, a good way-back machine. When I first packaged it I actually used it most of the time. Back then, although a high proportion of commercial web sites wouldn't work properly with it, most sites with useful content on worked very well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353075: exim: Can't send mail: sendmail process failed with error code 1
Tuomo Valkonen wrote: After recent upgrade exim stopped working at all. 'mail' and 'mutt' simply report Can't send mail: sendmail process failed with error code 1 Hi. Sorry I didn't get back to you sooner. I can't think of any reason why this would happen. I suggest running with debugging on to see what's happening. mail and mutt will be invoking exim with the -bm option (or without any option at all, since that's the default). You can try manually running /usr/sbin/exim -bm [EMAIL PROTECTED]. If this works, you should be able to type in an email, headers and all, and finish with a dot on a line by itself, and the email should then be sent. If that works, then there's something odd about the way mutt and mail are invoking exim, and I'd look into their configuration. If as I suspect that doesn't work, try again but with -d added to the command line. This turns on the lowest level of debugging. There are other levels of debugging which might be useful, try with -d9 for the highest, but they only work if you are an admin user (because they can reveal passwords etc which you might not want all your users to see). To set yourself up as an admin user, put any group that you are a member of into the list of groups in the admin_groups config file option. If you need any help understanding the output of this, I'm happy to have a look at them. Either way, please tell me what you find out (particularly if it looks like a bug in exim or its packaging, of course). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347350: unclear errors on clean install
Edwin Martin wrote: The second part of the error message File exists is confusing, since the doesn't seem to exist (but maybe existed at the time of the error). The error is very unclear. Especially on a freshly installed system, you wouldn't expect errors. A previous bug report claims that the error text in all DB errors from exim is bogus, because it uses errno but that isn't correctly set by the database functions. The code that calls those database functions tries to set errno, which I think ought to work even if errno is a macro (as it's allowed to be, and will be in many cases on linux), so I'm not sure why it wouldn't work. But assuming it doesn't work, you should ignore that text, and look to see if there is any other reason why opening the database doesn't work - it not existing seems likely in your case! As you'll now have been running exim for a while (sorry I didn't respond to your report sooner), you probably have databases there by now - have the errors gone away? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339250: libstdc++ allocator change
Adeodato Simó wrote: please find a patch at http://people.ubuntu.com/patches/c2a-pcre3.diff Mark, please don't use that patch. The libpcre3 package ships both a C library and a C++ library, and only the C++ one is affected by this libstdc++ change. That's why I haven't done anything about this yet. Given the high number of libpcre3 reverse dependencies (116), Very few of which use the C++ library, of course. it's very unadvisable to rename the whole package. The right course of action would be to ship the C++ library in a separate package, so that in can be independently renamed in further transitions. So I should put the C++ library in a new package, and no longer include it in the libpcre3 package. What should I do about dependencies to get a smooth upgrade path? Obviously people installing new versions of things that use the C++ library will get the new package; until they do isn't there a danger that they will install the new libpcre3 and things will stop working? Mark, please let us know if you'll be able to fix this bug yourself in the next days, so that other libraries depending on libpcre3 can transition themselves. I should have some time at the weekend. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339630: 'man exim' typos: matically and straightfoward
A Costa wrote: Found a few typos in '/usr/share/man/man8/exim.8.gz', see attached '.diff'. Thanks for this and the others. I'll include them in the next release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338658: [Fwd: pcre-config.1]
Package: pcre ---BeginMessage--- Mark, I've cleaned up the pcre-config man page you wrote for Debian. If you like, you can get the updated version here: http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/pcre/pcre-config.1 Thanks, -- Alexander Peslyak solar at openwall.com GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598 http://www.openwall.com - bringing security into open computing environments ---End Message---
Bug#324531: pcre3: CAN-2005-2491
On Mon, Aug 22, 2005 at 06:15:53PM +0200, Adrian Bunk wrote: It should be checked which of the versions in unstable/testing, stable and oldstable might be affected by CAN-2005-2491 (PCRE Heap Overflow May Let Users Execute Arbitrary Code). I'm away on business until wednesday night; if anything needs doing urgently it would be good if someone else could deal with it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323024: /usr/bin/newaliases: error in manpage for newaliases
On Sun, Aug 14, 2005 at 09:11:13AM +0200, root wrote: In the manpage for newaliases it sais This is a simple shell script calling /usr/lib/sendmail with the -bi option When I look into `which newaliases` it calls /usr/sbin/sendmail instead of /usr/lib/sendmail. Could maybe get corrected in the manpage. This is a minor issue, I do not even know for sure if this is a mistake. Since /usr/lib/sendmail and /usr/sbin/sendmail are guaranteed to be the same file, this is a very minor issue, but it should be corrected and I'll fix it in the next version of the package. Thanks for reporting it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#130902: patch for chimera2 png segfault
Jeremie Koenig wrote: The attached patch fixes the random segfaults from chimera when loading PNG files. The libpng interface used by image/png.c was deprecated, I updated it to the newer one. Thankyou. Your patch looks good (though I've never used libpng so I'll take your word for it that what you're doing is correct). I've been able to display http://www.debian.org/ other pages correctly, while they previously crashed chimera2. That's good. I'll release a new package including your patch soon. Thanks for packaging chimera, it's a great browser ! I used to use it all the time, but gave up a few years ago as more and more web pages wouldn't work with it, and as computers got faster so there was less benefit in having a lightweight browser like chimera. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318725: libpcre3-dev: Cannot be installed (wrong dependency)
Helge Kreutzmann wrote: The following packages have unmet dependencies: libpcre3-dev: Depends: libpcre3 (= 4.5-1.2) but 5.0-1 is to be installed E: Broken packages It is built to depend on the same version as the library that's built at the same time. I therefore uploaded library and -dev packages of 4.5-1.2 together, and of 5.0-1 together. If somehow 5.0 of the library had got into sarge but the same version of the -dev package hadn't, that would clearly be a bug, but not anything to do with me. However, this doesn't appear to be the case. As far as I can see sarge contains 4.5-1.2 of both, and unstable contains 5.0-1 of both. How you have ended up with 5.0-1 of the library on your system I don't know. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316553: exim: db_upgrade noisy on lockfile
Justin Pryzby wrote:
| db_upgrade: /var/spool/exim/db/retry.lockfile: unrecognized file type
| db_upgrade: DB-upgrade: /var/spool/exim/db/retry.lockfile: Invalid
| argument
Yes, I know. Oops.
Now, those lockfiles are stale; I seem to recall that there's an
opened bug about that, too.
Is there? I don't recall seeing one. But it was something that I had
looked into, and not got very far with. It doesn't happen to everyone
(and hadn't happened on the system I tested that version on, obviously,
or I'd have realised the bug you report)
A suggested fix might be:
for fn in /var/spool/exim/db/*; do
switch $fn in
(*.lockfile)
continue;
;;
(*)
db_upgrade;
;;
esac;
done;
That's a bit neater than how I was planning to do it, thanks.
By the way, why does the postinst create the /var/{log,run}/exim,
instead of including them in the package?
I can't remember, but I remember doing it, and there was a good reason
at the time. It may no longer matter, but I'd rather not change it now.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309606: [ia64] FTBFS: testsuite failure
Luk Claes wrote: Relevant snippet of the build log [1]: ./RunTest: line 111: 25459 Bus error ./pcretest -i $testdata/testinput2 testtry make[1]: *** [runtest] Error 1 I can't reproduce this. I've logged in to merulo.debian.org, got the latest source using apt-get, and built it, without any problems. That second test does give some errors about unaligned accesses: lt-pcretest(19487): unaligned access to 0x6fffbaec, ip=0x200498a0 lt-pcretest(19487): unaligned access to 0x6fffbaec, ip=0x200498a0 lt-pcretest(19487): unaligned access to 0x6fffbaec, ip=0x200498a0 lt-pcretest(19487): unaligned access to 0x6fffbaec, ip=0x200498a0 Are these the same problem, that for some reason causes a bus error when the build daemon does it but is caught and just gives an error message here? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307659: exim: /var/lib/dpkg/info/exim.postinst: line 70: db3_upgrade: command not found
severity 307659 important severity 307602 important merge 307659 307602 thanks On Wed, May 04, 2005 at 10:15:11AM -0400, Michael Erana wrote: need to add libdb3-util to depends list to ensure db3_upgrade will be there. This will likely affect users moving from woody to sarge and should be addressed before it makes it to that build. I'm not sure it does affect them, but yes it ought to be fixed before sarge is released. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304538: Still broken: 248622 - exim_tidydb failed to open DB file
Shannon Dealy wrote: The bug previously reported in #248622 (caused by incompatible database formats), and closed by this version of exim (3.36-14) still exists in this version. Among the changes noted in the message closing the previous bug report was that the postinst script was calling db3_upgrade to fix this problem, however, if it is doing so, it doesn't do it directly and I was unable to locate any indirect calls to db3_upgrade either. I remember fixing this. I'm not sure what happenened to it, maybe I didn't save the file or something. Without any old databases to test it with my testing would have been limited to checking it ran without errors, so I wouldn't have picked up on this. Thanks for pointing this out. I'll fix it now; no guarantees that the change will get into sarge now though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303684: 'exim' v3.36-15 setup: /var/lib/dpkg/info/exim.postinst: 5: Syntax error: ( unexpected
A Costa wrote:
/var/lib/dpkg/info/exim.postinst: 5: Syntax error: ( unexpected
Line five is
function press_return() {
which only works on bash (standard POSIX syntax doesn't have the
function. I'm guessing your /bin/sh is not bash?
I'll fix this and release another version that should work with any /bin/sh.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302185: breaks noninteractive installations
Henning Glawe wrote: automatic installations fail because read -p is called after displaying the 'exim 3.x is obsolete' message in postinst _without_ checking for DEBIAN_FRONTEND=noninteractive. this makes the whole machine wait during the installation and thus renders the system unusable It's not just that one, there were many other places where it did this. However, they were all on upgrades, so perhaps weren't much of a problem as people don't tend to do non-interactive upgrades (don't they? I'd have thought it was a fairly common thing to do from a cron job or the like). Anyway, I've fixed this now and will upload shortly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#248622: old DB version bug: need to fix the upgrade procedure
On Fri, Feb 25, 2005 at 08:56:54AM +0100, Tomas Pospisek wrote: # db3_upgrade retry # db3_upgrade reject # db3_upgrade wait-remote_smtp There's not much point. They can just be deleted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#171774: should I do an NMU?
On Fri, Feb 25, 2005 at 09:06:44AM +0100, Tomas Pospisek wrote: Since the patch for the security vulnerability has been out since November 2004 - should I do an NMU with this bugfix only? Please don't. I'd forgotten about that one. I was planning to do a new release soon, I'll include this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296784: exim: some error messages live infinitely
Al Nikolov wrote: After looking in /var/spool/exim/msglog/ i found that all those aged frozen error messages have identical reason to be frozen: 2005-02-11 18:10:54 [EMAIL PROTECTED] R=lookuphost defer (-1): lowest numbered MX record points to local host *** Frozen That is interesting. Could you do the debug commadn I suggested, if you haven't already, and attach all the relevant output to this bug report? Sorry I closed the bug, by the way, I thought your bug report was invalid before I read it in more detail, and forgot to remove the cc to the bug -done address. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296478: exim: incomplete initialization of groups when running commands in system_aliases
Jerome Alet wrote: but only the primary group for this user is initialized, not the additionnal groups this user is a member of. This is designed behaviour. The documentation for the user option says: If this option is set, it specifies the user under whose uid the delivery process is to be run. If it is not set, a value must have been associated with the address by the director that handled it. If the string contains no $ characters, it is resolved when Exim starts up. Otherwise, the string is expanded at the time the transport is run, and must yield either a digit string or a name which can be looked up using getpwnam(). When getpwnam() is used, either at start-up time or later, the group id value associated with the user is taken as the value to be used if the group option is not set. so it's only supposed to get the group ID from the password file, and it only uses that if you haven't specified a group using the group option; generally it is a good idea to use the group option. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295713: Exim 3 is obsolete and should be removed from future releases
severity 295713 normal thanks Nigel Metheringham wrote: Future debian releases should either:- * Not provide an exim 3 package and obsolete it so that existing installations are upgraded to exim4. * Very clearly mark the package as deprecated so that users do not continuing using it without taking responsibility for their actions. Any new installation of debian (from the current unstable branch which will be released soon (hopefully)) will get exim4 installed, so to get exim 3 someone would have to un-install exim 4 first; I think this, and the package priorities (standard vs. extra; note that very few things are extra, generally only things that conflict with standard packages or are deprecated) are sufficient to stop someone installing it on a new system. The exim 3 package is only really included for people upgrading from an older version of debian, so that they do not have to convert their config files immediately; while upgrading from 3 to 4 is not difficult it's not entirely automatic, particularly for more complicated installations. As exim 3 was the standard mail server in the currently stable release of debian, I don't think it would be a good idea to drop it completely from the next release. Probably it should be dropped from the subsequent release. A warning on installation, or on upgrade from a version too old to have the warning, saying that exim 3 is no longer supported upstream and that we advise people to upgrade to exim4 would probably be a good idea, and I will add this. If this is rejected then please remove any references to the Exim mailing lists from enclosed documentation because they cannot provide support for Exim 3. I will leave the reference in but add a big obvious warning that people shouldn't use the lists for support queries relating to exim 3.x. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295287: pcre3: pcre version 5.0 is out
Jay Berkenbilt wrote: I can look into this in more depth to see whether one is required or not. There's a good chance there won't be even though 5.0 supports many more Unicode properties. From a five minute look through the header files, I don't believe that a new soname is required. It seems to be quite well designed for compatibility. Please tell me if you think otherwise. Probably all old interfaces still work and do the same thing. Some constructs that were formerly invalid will be valid now, and there may be some more values that can be orred into the option flags, but hopefully that's the end of it. It pretty much looks like it to me. Since pcre3 is standard, I'm guessing this won't be approved for sarge anyway. I don't intend to try to get it into sarge. Sorry I didn't notice this when it came out back in September, by the way. I thought I was on the pcre mailing list, but obviously I'm not, and indeed there doesn't appear to be one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
