Bug#1066483: scrollz: FTBFS: configure: error: Fatal: You must get working getaddrinfo() function.
I've updated this package to a newer upstream release and it seems to build fine on my own amd64 system. However, I haven't had a key in the Debian key ring for quite some time and I'm not able to upload. I'm starting here in the hopes that someone who's also interested in this package will see it; I'll seek a sponsor to upload it on my behalf soon if this bug doesn't catch anyone's eye. -- Mike Markley
Bug#999083: gkrellm-leds: missing required debian/rules targets build-arch and/or build-indep
On Wed, Dec 15, 2021 at 09:28:39AM +0100, Christoph Biedl wrote: > > The severity of this bug will be changed to 'serious' after a month. > > In coordination with the maintainer, I will take over and do an > upload to resolve the issue soon. Current maintainer acknowledging. Thanks, Christoph. -- Mike Markley
Bug#989623: buster-pu: package scrollz/2.2.3-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Version 2.2.3-2 of this package fixed a grave bug (#986215, a remote crash) in
this package for unstable with the smallest set of changes possible, by
applying an upstream PR targeting the specific issue. The fix was tested in
that version, and is now also in bullseye.
Version 2.2.3-1+deb10u1 is a rebuild of the same package targeted for buster.
I spoke with the security team and they did not feel a DSA was warranted, but
as it is a fairly serious issue with the client, I'm hoping this fix can be
included in a point release of buster.
--
Mike Markley
diff -Nru scrollz-2.2.3/debian/changelog scrollz-2.2.3/debian/changelog
--- scrollz-2.2.3/debian/changelog 2014-11-05 17:37:01.0 -0700
+++ scrollz-2.2.3/debian/changelog 2021-06-06 10:16:54.0 -0600
@@ -1,3 +1,12 @@
+scrollz (2.2.3-1+deb10u1) buster; urgency=high
+
+ * Applied patch to ctcp.c to fix CVE-2021-29376 from
+https://github.com/ScrollZ/ScrollZ/pull/26 (Closes: #986215)
+ * Applied minor patch from upstream to the above fix
+ * Rebuild for buster
+
+ -- Mike Markley Sun, 06 Jun 2021 10:16:54 -0600
+
scrollz (2.2.3-1) unstable; urgency=low
* New release.
diff -Nru scrollz-2.2.3/debian/patches/CVE-2021-29376.patch
scrollz-2.2.3/debian/patches/CVE-2021-29376.patch
--- scrollz-2.2.3/debian/patches/CVE-2021-29376.patch 1969-12-31
17:00:00.0 -0700
+++ scrollz-2.2.3/debian/patches/CVE-2021-29376.patch 2021-06-06
10:12:06.0 -0600
@@ -0,0 +1,46 @@
+diff --git a/source/ctcp.c b/source/ctcp.c
+index b977f9b..32a496a 100644
+--- a/source/ctcp.c
b/source/ctcp.c
+@@ -31,7 +31,7 @@
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+- * $Id: ctcp.c,v 1.56 2009-12-21 14:39:21 f Exp $
++ * $Id: ctcp.c,v 1.56 2021-04-26 19:57:28 t Exp $
+ */
+
+ #include "irc.h"
+@@ -1629,14 +1629,29 @@ do_utc(ctcp, from, to, args)
+ *to,
+ *args;
+ {
+- time_t tm;
++ time_t tm = time(NULL),
++ curtime = time(NULL);
+ char*date = NULL;
+
+ if (!args || !*args)
+ return NULL;
+ tm = atol(args);
+- malloc_strcpy(, ctime());
+- date[strlen(date)-1] = '\0';
++ curtime = ctime();
++
++ if (curtime)
++ {
++ u_char *s = index(curtime, '\n');
++ if (s)
++ {
++ *s = '\0';
++ }
++ malloc_strcpy(, UP(curtime));
++ }
++ else
++ {
++ /* if we can't find a time, just return the number */
++ malloc_strcpy(, args);
++ }
+ return date;
+ }
+
diff -Nru scrollz-2.2.3/debian/patches/CVE-2021-29376-update.patch
scrollz-2.2.3/debian/patches/CVE-2021-29376-update.patch
--- scrollz-2.2.3/debian/patches/CVE-2021-29376-update.patch1969-12-31
17:00:00.0 -0700
+++ scrollz-2.2.3/debian/patches/CVE-2021-29376-update.patch2021-06-06
10:12:06.0 -0600
@@ -0,0 +1,13 @@
+diff --git a/source/ctcp.c b/source/ctcp.c
+index 32a496a..2b661bd 100644
+--- a/source/ctcp.c
b/source/ctcp.c
+@@ -1630,7 +1630,7 @@ do_utc(ctcp, from, to, args)
+ *args;
+ {
+ time_t tm = time(NULL),
+- curtime = time(NULL);
++ curtime;
+ char*date = NULL;
+
+ if (!args || !*args)
diff -Nru scrollz-2.2.3/debian/patches/series
scrollz-2.2.3/debian/patches/series
--- scrollz-2.2.3/debian/patches/series 2014-10-22 16:08:28.0 -0600
+++ scrollz-2.2.3/debian/patches/series 2021-06-06 10:12:06.0 -0600
@@ -4,3 +4,5 @@
spelling-errors.patch
rijndael-prototypes.patch
sys-stat-h.patch
+CVE-2021-29376.patch
+CVE-2021-29376-update.patch
Bug#988608: RFS: scrollz/2.2.3-2 - advanced ircII-based IRC client
I've also uploaded scrollz_2.2.3-2+deb10u1 to mentors.debian.net and stand ready to open the necessary bug against release.debian.org justifying the buster update. It can be found at: https://mentors.debian.net/debian/pool/main/s/scrollz/scrollz_2.2.3-2+deb10u1.dsc I would very much appreciate it if someone could assist by uploading it on my behalf. Thanks in advance, -- Mike Markley
Bug#989190: unblock: scrollz/2.2.3-2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package scrollz
This upload fixes a grave bug (#986215) by applying a patch from an
upstream PR targeting that specific issue. I've received exploit code
from upstream and tested that it is able to crash 2.2.3-1 but not 2.2.3-2.
unblock scrollz/2.2.3-2
diff -Nru scrollz-2.2.3/debian/changelog scrollz-2.2.3/debian/changelog
--- scrollz-2.2.3/debian/changelog 2014-11-05 17:37:01.0 -0700
+++ scrollz-2.2.3/debian/changelog 2021-04-29 17:55:12.0 -0600
@@ -1,3 +1,11 @@
+scrollz (2.2.3-2) UNRELEASED; urgency=medium
+
+ * Applied patch to ctcp.c to fix CVE-2021-29376 from
+https://github.com/ScrollZ/ScrollZ/pull/26
+ * Applied minor patch from upstream to the above fix
+
+ -- Mike Markley Thu, 29 Apr 2021 17:55:12 -0600
+
scrollz (2.2.3-1) unstable; urgency=low
* New release.
diff -Nru scrollz-2.2.3/debian/patches/CVE-2021-29376.patch
scrollz-2.2.3/debian/patches/CVE-2021-29376.patch
--- scrollz-2.2.3/debian/patches/CVE-2021-29376.patch 1969-12-31
17:00:00.0 -0700
+++ scrollz-2.2.3/debian/patches/CVE-2021-29376.patch 2021-04-29
12:51:47.0 -0600
@@ -0,0 +1,46 @@
+diff --git a/source/ctcp.c b/source/ctcp.c
+index b977f9b..32a496a 100644
+--- a/source/ctcp.c
b/source/ctcp.c
+@@ -31,7 +31,7 @@
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+- * $Id: ctcp.c,v 1.56 2009-12-21 14:39:21 f Exp $
++ * $Id: ctcp.c,v 1.56 2021-04-26 19:57:28 t Exp $
+ */
+
+ #include "irc.h"
+@@ -1629,14 +1629,29 @@ do_utc(ctcp, from, to, args)
+ *to,
+ *args;
+ {
+- time_t tm;
++ time_t tm = time(NULL),
++ curtime = time(NULL);
+ char*date = NULL;
+
+ if (!args || !*args)
+ return NULL;
+ tm = atol(args);
+- malloc_strcpy(, ctime());
+- date[strlen(date)-1] = '\0';
++ curtime = ctime();
++
++ if (curtime)
++ {
++ u_char *s = index(curtime, '\n');
++ if (s)
++ {
++ *s = '\0';
++ }
++ malloc_strcpy(, UP(curtime));
++ }
++ else
++ {
++ /* if we can't find a time, just return the number */
++ malloc_strcpy(, args);
++ }
+ return date;
+ }
+
diff -Nru scrollz-2.2.3/debian/patches/CVE-2021-29376-update.patch
scrollz-2.2.3/debian/patches/CVE-2021-29376-update.patch
--- scrollz-2.2.3/debian/patches/CVE-2021-29376-update.patch1969-12-31
17:00:00.0 -0700
+++ scrollz-2.2.3/debian/patches/CVE-2021-29376-update.patch2021-04-29
17:55:12.0 -0600
@@ -0,0 +1,13 @@
+diff --git a/source/ctcp.c b/source/ctcp.c
+index 32a496a..2b661bd 100644
+--- a/source/ctcp.c
b/source/ctcp.c
+@@ -1630,7 +1630,7 @@ do_utc(ctcp, from, to, args)
+ *args;
+ {
+ time_t tm = time(NULL),
+- curtime = time(NULL);
++ curtime;
+ char*date = NULL;
+
+ if (!args || !*args)
diff -Nru scrollz-2.2.3/debian/patches/series
scrollz-2.2.3/debian/patches/series
--- scrollz-2.2.3/debian/patches/series 2014-10-22 16:08:28.0 -0600
+++ scrollz-2.2.3/debian/patches/series 2021-04-29 17:55:12.0 -0600
@@ -4,3 +4,5 @@
spelling-errors.patch
rijndael-prototypes.patch
sys-stat-h.patch
+CVE-2021-29376.patch
+CVE-2021-29376-update.patch
Bug#988608: RFS: scrollz/2.2.3-2 - advanced ircII-based IRC client
On Sun, May 16, 2021 at 02:55:32PM -0600, Mike Markley wrote: > Package: sponsorship-requests > Severity: normal > > I'm seeking assistance uploading a new version of the ScrollZ IRC client > to unstable that addresses an outstanding CVE: > https://security-tracker.debian.org/tracker/CVE-2021-29376. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986215 > > Changes: > scrollz (2.2.3-2) unstable; urgency=high > . >* Applied patch to ctcp.c to fix CVE-2021-29376 from > https://github.com/ScrollZ/ScrollZ/pull/26 (Closes: #986215) >* Applied minor patch from upstream to the above fix > > I'm listed as the maintainer in this package's control file, but I haven't > had a key in the keyring for several years. > > This should be the minimum change required to fix this issue. I anticipate > there will also be stable and possibly oldstable uploads, as well. > > Post-freeze, I do plan to update the source package to a newer upstream > version. I received numerous DMARC reports indicating that this original message wasn't delivered, so I'm quoting this entire message to highlight it, now that I've relaxed that policy. The package is up on https://mentors.debian.net/package/scrollz/ now. -- Mike Markley
Bug#988608: RFS: scrollz/2.2.3-2 - advanced ircII-based IRC client
Package: sponsorship-requests Severity: normal I'm seeking assistance uploading a new version of the ScrollZ IRC client to unstable that addresses an outstanding CVE: https://security-tracker.debian.org/tracker/CVE-2021-29376. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986215 Changes: scrollz (2.2.3-2) unstable; urgency=high . * Applied patch to ctcp.c to fix CVE-2021-29376 from https://github.com/ScrollZ/ScrollZ/pull/26 (Closes: #986215) * Applied minor patch from upstream to the above fix I'm listed as the maintainer in this package's control file, but I haven't had a key in the keyring for several years. This should be the minimum change required to fix this issue. I anticipate there will also be stable and possibly oldstable uploads, as well. Post-freeze, I do plan to update the source package to a newer upstream version. -- Mike Markley
Bug#987537: RM: scrollz -- RoQA unmaintained, dead upstream, has security issues
On Mon, May 03, 2021 at 07:58:06AM +0200, Tobias Frost wrote: > I just gave upstream a pointer to the ircii code that fixes this CVE. Maybe > they have tested it? I reached out via email yesterday and I'm awaiting a response. > (MIA Team hat partly on) That sounds a bit like the package should be > orphaned or some RFH/RFA bug being filed? Or join efforts in some team? > As said, you can use mentors.debian.net for uploading. The only hard > point I can't give you advice is the time issue… Well, there was a time issue and a potential employer issue (and I can't expect advice from you on either :). I've spoken with my employer and confirmed that there actually isn't an issue there. > But maybe you'll find a bit of time working to update your package; > But note, we are currently frozen, uploads to unstable should be > minimal and targeted fixes only… Understood; I've updated the 2.2.3-1 package from the PR and from a small patch upstream made to that, and, as noted above, just want to make sure it's tested before bugging mentors.debian.net for assistance uploading. (I'm still unclear on if the package version should be updated to indicate that this is a security fix, but that's obviously a very small detail overall that can be dealt with at any point before upload.) On Thu, May 13, 2021 at 02:10:05PM +0300, Adrian Bunk wrote: > https://security-tracker.debian.org/tracker/CVE-2021-29376 > [buster] - scrollz (Minor issue) > > So the correct instructions are in this case > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#special-case-uploads-to-the-stable-and-oldstable-distributions I can build/test on a stable and an oldstable system, but per those instructions, I'll first focus on getting a 2.2.3-2 uploaded to unstable that contains just the fix that would then go into 2.2.3-1+deb10u1 (and potentially 2.2.3-1+deb9u1, if that even makes sense timing-wise anymore). Given the existence of a CVE and a security-tracker entry, what is the appropriate urgency for these uploads? (I'm happy to reach out to the team if that's more appropriate.) -- Mike Markley
Bug#987537: RM: scrollz -- RoQA unmaintained, dead upstream, has security issues
On Tue, Apr 27, 2021 at 10:02:13AM -0600, Mike Markley wrote: > I do see that there's a recent PR upstream to fix this CVE: > https://github.com/ScrollZ/ScrollZ/pull/26 I see that this PR has now been merged. I rebuilt 2.2.3-1 with the ctcp.c portion of the patch locally, but I haven't installed it yet as I don't have exploit code to test against the old build (I'd like to verify that it crashes my client before upgrading). I don't actually know the procedures for a security update, in any case. so if anyone has advice on next steps, I'd appreciate it. -- Mike Markley
Bug#987537: RM: scrollz -- RoQA unmaintained, dead upstream, has security issues
On Sun, Apr 25, 2021 at 11:33:32AM +0200, Tobias Frost wrote: > Additionally, even if there was a new upstream version in 2016, it was never > packaged for Debian. This lets me believe that the package is no longer > maintained in Debian. > > Due to the fact that the scrollz has an open security issue, is not maintained > upstream and Debian, having a very low popcon value and ircii being available, > I think it is probably best to remove the package from Debian at this point. > > If there is no answer to this bug within 3 months, I will reassign this bug to > ftp.debian.org for the actual removal. > > If you disagree, just close the bug, but it would be great if the package > could > be fixed into back into an releasble state. Unfortunately, though I'm still listed as the maintainer, I haven't had a key in the keyring since 1024-bit GPG keys were removed and am not in a position to actively upload. I do see that there's a recent PR upstream to fix this CVE: https://github.com/ScrollZ/ScrollZ/pull/26 I pinged the upstream author last week on IRC and didn't get a response, so I don't know what the chances are that it will be merged. He may pay more attention to GitHub email these days, though. I haven't looked at the state of debhelper and the rest of the packaging toolchain since my last upload. I could take a look at the latest version and this patch and see about updating the existing source package with those, but I don't know how much time I'll have to put into updating anything that's changed, and I would still need help uploading. -- Mike Markley
Bug#752300: scrollz: Please build against libgnutls28-dev
On Sun, Aug 17, 2014 at 01:34:48PM +0200, Andreas Metzler ametz...@bebt.de wrote: Control: tags 752300 + patch Control: tags 752300 + pending On 2014-06-22 Andreas Metzler ametz...@bebt.de wrote: [...] Please build scrollz against libgnutls28-dev instead of libgnutls-dev, the older GnuTLS version should not be part of jessie. Dear maintainer, I've prepared an NMU for scrollz (versioned as 2.1-1.2) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. That's fine. I still don't have a sid system to give this the maintenance it needs, and if I can't get one set up soon, I'll probably need to ask for assistance. -- Mike Markley m...@markley.org It's easier to wear the spandex than to do the crunches. - David Lee Roth -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564576: Package completely fails to support IPv6
On Sat, Nov 12, 2011 at 02:07:14PM +0100, Philipp Kern pk...@debian.org wrote: clone 564576 -1 reassign -1 ftp.debian.org retitle -1 RM: libspf -- RoQA; unmaintained, buggy severity -1 normal thanks On Mon, Sep 05, 2011 at 12:05:55PM +0200, Philipp Kern wrote: On Wed, Feb 16, 2011 at 09:56:32AM -0500, Scott Kitterman wrote: I replied directly, rather than to the bug by mistake. I will contact the maintainers of the two rdepends (spfmilter and whitelister) to see if they will fix libspf0, port their packages to libspf2 (which does support IPv6), or have them removed. Given that the orphan bug is already quite old (2007, #433108) and that it causes data loss, let's get rid of it. Filing bugs against its reverse dependencies because the library is going away. I'll try to remember to ask for its removal in a few weeks and upgrade those bugs to serious then. There's only one rdep left (spfmilter) where the maintainer did not reply. So let's get rid of libspf. I did reply -- only I forgot to actually send it. Oops. No disagreement from here; the reply I never sent is below: It's not really maintained upstream anymore. An attempt to port it to libsfp2 was made a few years ago, but it was a much older version of libspf2 (with big API differences) and it was never stable. I don't have the cycles to port it; in addition, spf-milter-python appears to be a suitably functional replacement. Given those facts, I suppose dropping it is for the best. -- Mike Markley m...@markley.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481072: dk-filter crash seems to be for a specific use case (-k parameter)
On Mon, Aug 16, 2010 at 10:57:35AM +0300, Teodor MICU mteo...@gmail.com wrote: I've been checking the status of 'dk-filter' for squeeze and it is blocked for inclusion by this RC bug report. As far as I can see this reliable crash is reproduced only if you use the -k parameter. I don't use it (I don't have multiple domains) and I don't have crashes, I had only one this morning but that all for almost a year of working properly. I admit that I've been remiss in further investigating this because dk-filter has dropped quite a bit in importance. I'm using this feature myself, so I'm sure it's something to do with the submitter's local configuration. I never did get any strace output to allow me to dig into which of the three calls to dk_sterilize() is actually the issue. That said, I'm not convinced that removing the assert() is a bad idea. It's only used in three places, and in all of those places, it's protected with an if (results ==NULL) return -1. The dk-filter package in Debian is NOT shipping a libdk.so or libdk.a, so there's no risk of affecting any other packages were I to modify the function to e.g. if NULL return NULL in place of the assertion. From my point of view development of dk-filter has stopped and only dkim-filter is maintained properly. Thus this bug and the other I reported will have to be avoided as there are specific use cases. Actually, dkim-filter itself has stopped as well, for the time being, although it is quite stable. The primary contributors to the dkim-filter project have moved on to a fork, opendkim. In conclusion, can we downgrade the severity of this bug report so that at least we have the same version from lenny in squeeze too? If there are no objections I can do this at the end of the week, though it is better to be done by Mike Markley. I don't object, either, but I would also like input from the release team. I can chase that, if you'd like. -- Mike Markley m...@markley.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562429: dk-filter: internal error on verify with dk_eom(): resource unavailable: BIO_new_mem_buf() failed
Do you still consider this an issue? If so, can you provide a sample of the types of messages (specifically, the senders and selectors or, at least, enough headers to figure out that information) that are causing the issues? I could use that to determine whether these represent an issue with the filter or an unavoidable problem with the sender's configuration. -- Mike Markley m...@markley.org Experience varies directly with equipment ruined. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481072: dk-filter crash seems to be for a specific use case (-k parameter)
On Wed, Aug 18, 2010 at 02:37:10AM +0300, Teodor MICU mteo...@gmail.com wrote: By all means I do prefer to have you as the maintainer of the package to contact the Release team. I'm not sure if this is necessary, but its your call. Personally, since I think a simple patch can cause this to not actually halt the filter, I'd prefer to consult the release team and prepare a fixed package. My best guess, at this point, is that the original bug report is due to an issue with the path to the key file. -- Mike Markley m...@markley.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575296: (opendkim_2.0.0+dfsg-1/avr32): FTBFS: Outdated config.{sub,guess}
Oops, looks like I'm copying config.sub/config.guess to the wrong directory for this package, so the autotools-dev build-dependency isn't doing any good. This should be fixed in a forthcoming 2.0.1 upload. -- Mike Markley m...@markley.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554273: spfmilter: please build it with libspf2 as the upstream recommends
On Wed, Nov 04, 2009 at 12:30:19AM +0200, Teodor mteo...@gmail.com wrote: On /usr/share/doc/spfmilter/README is written: | Spfmilter implements the Sender Policy Framework (http://spf.pobox.com/) | as a milter, using the libspf2 library. From this I understand that spfmilter is already ported to work with libspf2. Please build it against libsfp2 library instead of libspf0. spfmilter does not work with libspf2 1.2.x. With libspf2 1.0.x (which is not currently in the Debian distribution), there are known crash and memory leak issues. -- Mike Markley m...@markley.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544802: opendkim: FTBFS on various archs
On Wed, Sep 09, 2009 at 11:08:20PM +0200, Kurt Roeckx k...@roeckx.be wrote: My concern is how cross-platform that is. I work very closely with upstream and we're discussing now the best way to accomplish this. The code doesn't even call res_mkquery() unless --enable-arlib is set in configure (which it isn't in the Debian build), so we're thinking that changing the check to something like AC_SEARCH_LIBS(dn_expand, resolv) would be more appropriate. Thoughts there? AC_SEARCH_LIBS is always going to fail: objdump -T /usr/lib/libresolv.so |grep dn_expand 5400 gDF .text 0025 GLIBC_2.2.5 __dn_expand You need to #include resolv.h to get the right name of the symbol. Cool, thanks for the options. I do wonder if just adding a check for __res_mkquery in addition to the res_mkquery check would be a simpler solution. I'll start adapting the suggestions you sent, but would either of you be able to test that? (or do either of you think it's insane? :) -- Mike Markley m...@markley.org Where are the calculations that go with a calculated risk? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544802: opendkim: FTBFS on various archs
On Wed, Sep 09, 2009 at 04:46:14PM +0200, Kurt Roeckx k...@roeckx.be wrote: On Fri, Sep 04, 2009 at 12:35:47AM +0200, Cyril Brulebois wrote: The problem actually comes from the following: | AC_SEARCH_LIBS(res_mkquery, resolv) The problem here is that the symbol is not called res_mkquery but __res_mkquery and you need to #include resolv.h to get that. On older arches there is a weak alias res_mkquery that gets you __res_mkquery on them for backwards compatibility. I had to fix alot of configure scripts for this issue at the time amd64 got added. My concern is how cross-platform that is. I work very closely with upstream and we're discussing now the best way to accomplish this. The code doesn't even call res_mkquery() unless --enable-arlib is set in configure (which it isn't in the Debian build), so we're thinking that changing the check to something like AC_SEARCH_LIBS(dn_expand, resolv) would be more appropriate. Thoughts there? -- Mike Markley m...@markley.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544802: opendkim: FTBFS on various archs
Based on the platforms involved, I suspect this is due to the old versions of config.sub and config.guess shipping with the package. However, I have no platform to test on, and I'd rather do so before uploading a package that just updates those (or with a build-depends: autotools-dev). Do you have any advice there? -- Mike Markley m...@markley.org Spock: The odds of surviving another attack are 13562190123 to 1, Captain. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544802: opendkim: FTBFS on various archs
On Fri, Sep 04, 2009 at 12:35:47AM +0200, Cyril Brulebois k...@debian.org wrote: Mike Markley m...@markley.org (03/09/2009): Based on the platforms involved, I suspect this is due to the old versions of config.sub and config.guess shipping with the package. Could have been, but those are updated at build time, so that's not the issue. It could also have been a need for relibtoolizing, but that's not the case either. Also please note it would be nice to modify configure.ac the same way you modify configure, so that this modification isn't lost when relibtoolizing (which mostly boils down to running ???autoreconf -vfi???). They're only updated at build time if autotools-dev is installed, which I don't currently have a Build-Depends: on. Unless it got snuck into build-essential while I wasn't looking :). But certainly, if you built with autotools installed, they would be updated. My change to configure is already in upstream CVS; I missed it while chasing down an issue with Makefile dependencies. The next release will have it. The problem actually comes from the following: | AC_SEARCH_LIBS(res_mkquery, resolv) It looks like it turns out to ???none required??? on the architectures with the FTBFS, so there's a missing -lresolv (explaining while some related symbols are unresolved -- oh the irony). I'd have to set up an i386 chroot to compare config.log and others, and maybe figure out a fix. I guess a quick workaround would be adding -lresolv manually to some linking command lines. Okay, I believe a similar bug is fixed in CVS; I'll investigate that. Thanks for checking out the config.sub/guess for me. -- Mike Markley m...@markley.org The word genius isn't applicable in football. A genius is a guy like Norman Einstein. - Joe Theisman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543426: ITP: opendkim -- An open-source DKIM library and mail filter implementation
Package: wnpp Severity: wishlist Owner: Mike Markley m...@markley.org * Package name: opendkim Version : 1.0.0 Upstream Author : The OpenDKIM project * URL : http://www.opendkim.org/ * License : BSD Programming Lang: C Description : An open-source DKIM library and mail filter implementation The OpenDKIM Project is a community effort to develop and maintain a C library for producing DKIM-aware applications and an open source milter for providing DKIM service. The project started from a code fork of version 2.8.3 of the open source dkim-milter package developed and maintained by Sendmail, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542948: dkim-filter: Consider packaging fork
I've actually already assembled a package and will be uploading this week, in all likelihood. -- Mike Markley m...@markley.org Phasers locked on target, Captain. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541640: libunbound-dev: .la file depends on libraries that the package doesn't depend on
On Sun, Aug 16, 2009 at 11:23:24PM +0200, Ond??ej Surý ond...@sury.org wrote: I rather suggest droping .la file from package. Libtool is a crap. Or at least fix it, so it does have those libraries in private section of .la file. Either the library actually requires libldns to provide some of its functionality, in which case it SHOULD have that dependency, or it doesn't, in which case the .la file has bad information and should be fixed. Since libunbound1 depends on libldns1, I have assumed here that the former is the case, and that this is a simple missing dependency in the -dev package. -- Mike Markley m...@markley.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541640: libunbound-dev: .la file depends on libraries that the package doesn't depend on
It's also worth noting that -lcrypto is included in the .la dependency_libs, as well, so a Depends: on libssl-dev also seems appropriate. -- Mike Markley m...@markley.org If entropy is increasing, where is it coming from? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541640: libunbound-dev: .la file depends on libraries that the package doesn't depend on
Package: libunbound-dev Version: 1.3.2-1 Severity: normal libunbound-dev in sid ships a .la file that includes dependencies on libldns and libcrypto: $ grep dependency_libs /usr/lib/libunbound.la # Linker flags that can not go in dependency_libs. dependency_libs=' -lldns -lcrypto' This causes libtool-based build systems to attempt to link against those libraries whenever using -lunbound. However, the package does not depend on the appropriate library packages, so linking fails. Suggested fix: add libldns-dev and libssl-dev to libunbound-dev's Depends: line. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libunbound-dev depends on: ii libunbound1 1.3.2-1library implementing DNS resolutio libunbound-dev recommends no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532961: scrollz: New upstream version 2.0
On Sat, Jun 13, 2009 at 10:45:45AM +0200, Andreas Metzler ametz...@downhill.at.eu.org wrote: 2.0 was released in December 2008. cu andreas That it was. I'm working on a package now. -- Mike Markley m...@markley.org Deflector shields just came on, Captain. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529846: scrollz: FTBFS against gnutls26 = 2.7.x
Will the AM_PATH_LIBGNUTLS macro continue to be supported using an updated mechanism to identify the correct paths? -- Mike Markley m...@markley.org I have hardly ever known a mathematician who was capable of reasoning. - Plato -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513034: dkim-milter: New upstream version.
On Mon, Mar 02, 2009 at 11:15:15PM +0100, Kurt Roeckx k...@roeckx.be wrote: Are you still waiting for something? Now that lenny is released looks like a good time to upload packages. Just dealing with the 2.6.0 remote crash; I've already got 2.8.1 packaged and will update that to 2.8.2 before uploading. -- Mike Markley m...@markley.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#500882: DoS secuirty vulnerabilty 2.6.0-2.8.0
On Sun, Feb 08, 2009 at 05:10:10PM +1100, Daniel Black dragonhe...@gentoo.org wrote: http://sourceforge.net:80/project/shownotes.php?group_id=139420release_id=654247 Mike, as you discovered 2.6.0-2.8.0 has a DoS security vulnerability. Can this be fixed in lenny/etch-backports please? Yes, I plan to upload 2.8.1; I just haven't had a moment to consult with the release team to ensure that the fix makes it into lenny. -- Mike Markley m...@markley.org No one can guarantee the actions of another. - Spock, Day of the Dove, stardate unknown -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513030: What a great idea
On Sun, Jan 25, 2009 at 10:16:52PM +0100, Jérémy Lecour jeremy.lec...@gmail.com wrote: Hi, I've just noticed that backporting dk-milter is in the air. I couldn't be more interrested in it. A few weeks ago I've installed dkim-filter from the backport and I'm very happy with it. I wanted to do the same with dk-filter but didn't find it in the repository. I know that I could learn to do such backporting myself, but I'm not that confident in the resulting quality as I want to put that on a production server. Thank you very much for all the effort. It's actually quite trivial; I maintain an unofficial backport for my own etch boxes, and no changes to the source are necessary. I'd be happy to support the existing dkim-milter backporter doing this, or to do it myself. The latter may require a little more time as I've never uploaded to backports.org. -- Mike Markley m...@markley.org You can get more with a kind word and a two-by-four than you can with a kind word. - Marcus Cole, Ceremonies of Light Dark -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513034: dkim-milter: New upstream version.
This will be done sometime this week, time permitting; I'd been awaiting 2.8.0 before packaging a new version, and then after discovering a DoS bug, felt it'd be best to wait until the fix in 2.8.1 :). -- Mike Markley m...@markley.org Nothing is rich but the inexhaustible wealth of nature. She shows us only surfaces, but she is a million fathoms deep. - Ralph Waldo Emerson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#500967: Further thoughts on feature request
I've changed the severity of this to wishlist because, IMO, that's precisely what it is. I understand and don't necessarily disagree with these suggestions; to that end, I have opened a SourceForge RFE. With that said, I'm not entirely convinced that dkim-filter is the place to solve these issues. Off the top of my head, using the l= tag to work around listserv munging breaks if any multipart/alternative components of a list message are not text/plain, for example. In the meantime, while the listservs of the world are updated to properly support re-signing messages (which I agree will not happen overnight), the proposed ADSP extension does give you, as a sender, some input into this (all vs. discardable; see http://tools.ietf.org/html/draft-ietf-dkim-ssp-08#section-4.2.1). -- Mike Markley m...@markley.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491134: dk-filter: Sudden verification errors, signing seems fine
On Wed, Jul 23, 2008 at 10:55:03AM -0700, Richard A Nelson [EMAIL PROTECTED] wrote: Sadly, no - and I think that is to be expected since the DNS request actually worked - it just got bum data. That sent me back to the fine manual pages and I tried -Cinternal=accept which seemed more apropos. Unfortunately, that too fails... [...] # grep dk_eom /var/log/mail.log Jul 23 17:52:55 ultima-thule dk-filter[21476]: m6NHqtXn011780: dk_eom(): resource unavailable: d2i_PUBKEY_bio() failed So m6NHqtXn011780 was still tempfailed? That would definitively be an upstream bug, since -Cinternal=accept should be preventing that. -- Mike Markley [EMAIL PROTECTED] How often I found where I should be going only by setting out for somewhere else. - R. Buckminster Fuller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491134: dk-filter: Sudden verification errors, signing seems fine
On Mon, Jul 21, 2008 at 06:08:53PM -0700, Richard A Nelson [EMAIL PROTECTED] wrote: Yes, and I'm leaning heavily in that direction - depending upon the vagaries of MTA queueing/coattailing/pipelining is problematic at best. This could windup being a DDOS against MTAs (both receiving and sending) Does starting the filter with -Cdnserror=accept help this issue? -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491134: dk-filter: Sudden verification errors, signing seems fine
Hi Richard, Could you clarify one thing for me? I'm not sure from your message if this issue is causing the filter to stop being able to verify OTHER messages, or if it's just for messages from this domain. The latter is easily explained, as the key listed in DNS does seem to be truncated; the former is definitely an important bug. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490276: Supplied configuration file contains invalid options
On Sat, Jul 12, 2008 at 03:33:55PM -0700, Mike Markley [EMAIL PROTECTED] wrote: Possibly so; the configuration file I'm shipping pre-dates the upstream sample, but it may be time to replace it. In any case, it's available in /usr/share/doc/dkim-filter/examples. I've applied a patch from Scott Kitterman of Ubuntu to start in verify- only mode when there's no key configured, but my temptation is to revamp the default config to run in verify-only mode and provide boilerplate for adding keys, etc. I'm quite open to user suggestion... Just FYI, I'm going to go ahead and close this with my next upload that fixes the SendReports option, but feel free to re-open this as wishlist if you have a strong opinion about any of the above. -- Mike Markley [EMAIL PROTECTED] I don't believe in God because I don't believe in Mother Goose. - Clarence Darrow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490276: Supplied configuration file contains invalid options
On Fri, Jul 11, 2008 at 12:30:38AM -0700, Don Armstrong [EMAIL PROTECTED] wrote: The configuration file supplied with dkim-filter contains invalid options that are commented out, such as ReportInfo. [It's now SendReports.] Thanks, I'll fix that in this 2.6.0 upload I'm about to make. Furthermore, the upstream-supplied example configuration seems to be far more useful. Possibly so; the configuration file I'm shipping pre-dates the upstream sample, but it may be time to replace it. In any case, it's available in /usr/share/doc/dkim-filter/examples. I've applied a patch from Scott Kitterman of Ubuntu to start in verify- only mode when there's no key configured, but my temptation is to revamp the default config to run in verify-only mode and provide boilerplate for adding keys, etc. I'm quite open to user suggestion... -- Mike Markley [EMAIL PROTECTED] No one may kill a man. Not for any purpose. It cannot be condoned. - Kirk, Spock's Brain, stardate 5431.6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398345: Fix for the problem
The patch is greatly appreciated. However, it appears to be a bit off, as include/config.h looks like a diff of a diff, or similar. Nonetheless, it appears that this is easily replicated in config.h. Have you already uploaded an NMU? -- Mike Markley [EMAIL PROTECTED] After the last of 16 mounting screws has been removed from an access cover, it will be discovered that the wrong access cover has been removed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398345: Fix for the problem
Nevermind, clearly the patch just adds another patch to debian/patches. Since these aren't automatically applied, that patch will need to be applied by hand in the Debian version of the source repository. -- Mike Markley [EMAIL PROTECTED] Support your country all the time and your government when it deserves it. - Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481072: dk-filter reliably crashes upon connection from postfix
I'm interpreting this to mean that it doesn't crash until Postfix actually makes the Milter callout to dk-filter; is that correct? If so, then it's probably not an issue with the formatting of the keys file, as that is read on startup. Would you be able to grab an strace? -- Mike Markley [EMAIL PROTECTED] She won' go Warp 7, Cap'n! The batteries are dead! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475130: Some more info..
On Mon, May 05, 2008 at 03:21:50PM +0100, Marcin Owsiany [EMAIL PROTECTED] wrote: My guess would be that the API does not work like spfmilter assumes it does. I don't know where the bug lies, though. Yes, I am using etch, postfix 2.3.8-2 My understanding from talking to other Postfix folks is that the Milter API in Postfix 2.3.x is rather immature. The API documentation reflects exactly what spfmilter is attempting to do: https://www.milter.org/developers/api/smfi_chgheader There are only two lines of code making this call, the first used when there are more than 10 Received-SPF headers and the second when there are Received-SPF headers purporting to be from the local host: smfi_chgheader( ctx, HEADER_NAME, i, (char*) 0 ); and smfi_chgheader( ctx, HEADER_NAME, cd-del_header_list[i], (char*) 0 ); Which is why I mentioned HEADER_NAME: #define HEADER_NAME Received-SPF If this header is actually being eaten by the smfi_chgheader() then it is a bug in the Postfix Milter implementation. The code for deleting this header should only be triggered if there's an existing Received-SPF: header. You can check for yourself; smfi_chgheader() is called at no other times :). -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475130: Some more info..
It seems more likely to me that the Received header is somehow being suppressed (it should be inserted by the host that's running spfmilter, right?) I still don't understand how spfmilter could be causing this, so I plan to take it to postfix-users or similar. Based on the spfmilter package version, I'm guessing you're running etch, and therefore Postfix 2.3.8; can you confirm that? -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478599: dkim-filter: package fails to configure
On Wed, Apr 30, 2008 at 01:18:01AM +0200, Roberto Lumbreras [EMAIL PROTECTED] wrote: while installing dkim-filter... Starting DKIM Filter: dkim-filter: /etc/dkim-filter.conf: at least one selector and key required for signing mode invoke-rc.d: initscript dkim-filter, action start failed. dpkg: error processing dkim-filter (--configure): subprocess post-installation script returned error exit status 78 Errors were encountered while processing: dkim-filter maybe it needs configuration, but it should not fail to install or configure if unconfigured. You're right; it's supposed to be catching this. I'll check it out before I upload the coming 2.5.5 release. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475130: Followup
On Wed, Apr 09, 2008 at 11:07:40AM +0100, Marcin Owsiany [EMAIL PROTECTED] wrote: It seems to be a bug in the code that removes duplicate Received-SPF headers, because the Received header is properly retained when I send the message from another host. Thanks for the extra information. I should be able to investigate more this evening. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475130: eats first Received header
Are you seeing any found possible spoofed header messages in your syslog (facility mail, level notice)? Looking through the source code, it doesn't appear that spfmilter even attempts to delete other Received-SPF headers unless it detects ones it thinks are spoofed, and even when it does decide to do so, it specifies Received-SPF as the header name to delete. The Milter function that actually deletes the header (smfi_chgheader()) actually takes a header name to act upon, so even if the filter was detecting (or mis-detecting) a spoofed Received-SPF header, the only way it could request the deletion of a Received header is if you've changed HEADER_NAME in spfmilter.c. I'd like to learn a little more about your test setup to see if I can reproduce this locally. Can you send me the relevant snippets of your postfix main.cf or master.cf? -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472887: dkim-filter: dies unexpectedly
Could you run dkim-filter under strace and send the output? -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472888: dkim-filter: configurable socket group ownership
severity 472888 wishlist thanks On Wed, Mar 26, 2008 at 08:58:02PM -0400, Clint Adams [EMAIL PROTECTED] wrote: Please make the socket group ownership configurable. The group ownership on the socket is picked up from the environment (namely, the GID of the dkim-filter user). Are you looking for anything in particular that can't be satisfied by modifying the primary GID of the dkim-filter user? -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450711: Bugtracker error
On Fri, Feb 08, 2008 at 11:41:07AM +0100, Jos [EMAIL PROTECTED] wrote: I send the requested files 3 times, but got no confirmation from the bugtracker. Maybe a spamfilter is blocking the mail? Are you sending it just to the BTS, or to both me and the BTS? -- Mike Markley [EMAIL PROTECTED] I THINK THEY SHOULD CONTINUE the policy of not giving a Nobel Prize for paneling. - Jack Handey, The New Mexican, 1988. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450711:
On Thu, Jan 24, 2008 at 05:56:24PM +0100, Jos [EMAIL PROTECTED] wrote: Mike, did you ever received the requested info, I send dec 30? I don't see it in the bug tracker, I don't see it in my maibox, either. You may want to resend. -- Mike Markley [EMAIL PROTECTED] There's another way to survive. Mutual trust -- and help. - Kirk, Day of the Dove, stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461632: Updated for 2.4.4 release
On Mon, Jan 28, 2008 at 12:23:04AM -0500, Scott Kitterman [EMAIL PROTECTED] wrote: http://mentors.debian.net/debian/pool/main/d/dkim-milter/dkim-milter_2.4.4.dfsg-1.dsc Thanks, Scott. As I keep my package in a CVS repository, picking up and using someone else's package wholesale isn't a very clean option for me. With that said, I'll definitely take a look and see what you've got that I might be missing, and borrow (with appropriate attribution, of course). I plan to find out tonight if my Debian dev box survived a recent brownout... if so, then I'll be working this package tonight and maybe tomorrow. -- Mike Markley [EMAIL PROTECTED] Beam me up, Scotty! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450711:
On Sun, Dec 23, 2007 at 12:37:02PM +0100, Jos [EMAIL PROTECTED] wrote: with 2.4.1, still a can't initialize DKIM library Then it may be a different problem; 2.4.1 should be able to handle the empty resolv.conf. Can you grab another set of ltrace/strace output for me? -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450711:
Hi Jos, I've been unable to make heads or tails of this issue, so I'd like you to try with the 2.4.0 package I've just rolled. I'm uploading it tonight, but I can send you an i386 deb out-of-band if you'd like to try before it hits the mirrors. Just let me know. Also, do you mind if I attach the config and trace files you sent me to this bug report? That would be very helpful if I'm unable to make any headway and I ask upstream to take a look. Thanks, -- Mike Markley [EMAIL PROTECTED] Elliptic paraboloids for sale. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452603: dkim-filter: wrong default in etc/default/dkim-filter
tags 452603 + confirmed retitle 452603 clarify default socket address severity 452603 wishlist thanks This syntax should be valid and is, in fact, what's used by the init script if nothing is specified. Nonetheless, it may be more clear to specify local:, so I'm happy to do so in the init script and default file. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392927: Spfmilter dies unexpectedly with SIGABRT
On Sat, Nov 17, 2007 at 04:23:26PM +0200, Mattias Nordstrom [EMAIL PROTECTED] wrote: Ok, so just to be on the clear, an update that would include the three line patch on main.c fixes the problem in question? It appears so; that's the only difference between 0.999-1.0.0-p3-3 and what I'm running on my backup MX. -- Mike Markley [EMAIL PROTECTED] As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. - Albert Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392927: Spfmilter dies unexpectedly with SIGABRT
I've been running the patches suggested in here since July on my backup MX without any evidence of problems. In fact, spfmilter's memory footprint has not budged since I began doing so. On the other hand, I'm replacing that server with a new one that just got a fresh etch install. spfmilter crashes pretty much daily. If the libspf maintainer is listening in, is there any chance we can get this bundled up for proposed-updates? -- Mike Markley [EMAIL PROTECTED] Support your country all the time and your government when it deserves it. - Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450711: dkim-filter(2.3.2.dfsg-1) fails to start with settings that works with version2.0.2.dfsg-1. Only message is in syslog dkim-filter[26391]: can't initialize DKIM library.. Settings are che
On Fri, Nov 09, 2007 at 03:23:54PM +0100, Jos Zonneveld [EMAIL PROTECTED] wrote: dkim-filter(2.3.2.dfsg-1) fails to start with settings that works with version2.0.2.dfsg-1. Only message is in syslog: dkim-filter[26391]:can't initialize DKIM library.. Settings are checked and are valid for version 2.3.2.dfsg-1. ... What exactly are those settings? Can you send your /etc/default/dkim-filter and /etc/dkim-filter.conf (and any other associated files)? -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445298: When packaging new version
On Thu, Oct 04, 2007 at 03:05:14PM -0400, Micah Anderson [EMAIL PROTECTED] wrote: When packaging the new version, please note the difference in the README about performance notes, specifically: 2. Make sure to build dkim-filter using the asynchronous (ARLIB) resolver. This is accomplished by modifying site.config.m4 to enable these lines: define(`bld_USE_ARLIB', `True') I'm well aware of arlib and waiting to see the current revision in wider production use before enabling it in the package. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445145: init script ignores /etc/default/dkim-filter settings
tags 445145 confirmed pending thanks Thanks; this is fixed in the version of the package that's awaiting upload after I sort out some packaging issues. I'll close the bug when that gets uploaded. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440577: libdkim-dev: Package namespace conflict
On Sun, Sep 02, 2007 at 11:46:18PM +0200, Magnus Holmgren [EMAIL PROTECTED] wrote: Both dkim-milter and libdkim builds libdkim-dev, and libdkim0 and libdkim2 conflict too, even though the names aren't completely identical. As I explained when dkim-milter was first packaged, I'm not completely foreign to dropping Alt-N's libdkim altogether, but the issue should be properly discussed first. Somehow I'd had a brainlapse and forgotten about this issue before uploading the new packages; entirely my fault. If you still see value in the AltN library, I'm happy to rename my packages (probably to something like libdkim-sendmail or libsmdkim or the like). We'll still need to decide about library names, but I don't see that you need to drop your packages unless they're completely unnecessary. -- Mike Markley [EMAIL PROTECTED] You're out of your mind. That's between me and my mind. - Simon Tam and Jubal Early, Firefly: Objects in Space -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436922: dkim-filter: v2.0.0 has been released
retitle 436922 Package description should be more MTA-agnostic severity 436922 wishlist thanks Neither a request for new version nor a semantic quibble about the contents of the Description field warrant an important bug. In addition, 2.0.2.dfsg-1 is already in incoming; it now includes libdkim packages and, as such, is awaiting overrides. -- Mike Markley [EMAIL PROTECTED] A woman should have compassion. - Kirk, Catspaw, stardate 3018.2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433717: DKIM DNS record in debian/README.Debian incomplete
On Thu, Jul 19, 2007 at 12:42:10AM -0400, Scott Kitterman [EMAIL PROTECTED] wrote: The example TXT record in README.Debian is incomplete. The final version of the DKIM spec added a mandatory version number v=DKIM1\;. Additionally, the records I've managed to check all have a trailing \;. I am not sure if this is actually required by the RFC, but appears to be common usage. The trailing ; is definitely not required (and shouldn't be escaped unless the zone file format requires it), but you're absolutely right about the v= tag. I've added it to the latest rev of the package. -- Mike Markley [EMAIL PROTECTED] You can get more with a kind word and a two-by-four than you can with a kind word. - Marcus Cole, Ceremonies of Light Dark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392927: Spfmilter dies unexpectedly with SIGABRT
On Thu, Jul 19, 2007 at 03:36:27PM -0700, Mike Markley [EMAIL PROTECTED] wrote: On Fri, Jul 13, 2007 at 04:26:08PM +, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: commenting out the three xfree()s after the referenced comment stops the crash. I couldn't say whether spfmilter will then leak in the way that the comment warns ofi (I suspect not), but that would be a less severe bug in my book. I will feedback when I know more about that question. scary though it may sound, please consider applying this to libspf0, and putting the resulting package(s) forward for the next point release of etch. I've applied this patch on one of my etch boxes that often experiences this crash. It's quite memory-contrained, so any memory leaks should also be reasonably obvious. I'll report results as I get them. I've been running this for nearly a week on my medium-volume backup MX, and if there's a memory leak, it's a very slow one. My baseline (off-peak) vsize for spfmilter started out as 10340 on 7/20 and then increased to 10396 on 7/21 and to 10460 on 7/23. Nonetheless, it does appear to be leaking. I can't actually prove that it's libspf0 leaking, though, since I'm not stable enough without the patch to take any real measurements. According to my etch system, whitelister is the only other package using libspf0. It's probably worth getting in touch with its maintainer to get his take. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392927: Spfmilter dies unexpectedly with SIGABRT
On Fri, Jul 13, 2007 at 04:26:08PM +, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: commenting out the three xfree()s after the referenced comment stops the crash. I couldn't say whether spfmilter will then leak in the way that the comment warns ofi (I suspect not), but that would be a less severe bug in my book. I will feedback when I know more about that question. scary though it may sound, please consider applying this to libspf0, and putting the resulting package(s) forward for the next point release of etch. I've applied this patch on one of my etch boxes that often experiences this crash. It's quite memory-contrained, so any memory leaks should also be reasonably obvious. I'll report results as I get them. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428392: dkim-filter.sock permissions should be more MTA friendly
tags 428392 + confirmed pending thanks On Fri, Jun 15, 2007 at 11:08:40AM +0100, Tony Hoyle [EMAIL PROTECTED] wrote: Postfix. It runs as its own unprivileged user (I'm surprised that sendmail doesn't do this also). What user is Postfix running as when it attempts to connect to the socket, BTW? I'd like to update README.Debian with explicit instructions on how to add the correct user to the group. You could probably just set the sgid bit on the parent directory... then there's just the actual permissions on the socket to change (is it obeying umask by any chance??). It does obey umask, and I have a patch in hand that will setgid() the binary to the run-as user's primary GID, which obviates the need for a setgid bit on the directory. -- Mike Markley [EMAIL PROTECTED] You're out of your mind. That's between me and my mind. - Simon Tam and Jubal Early, Firefly: Objects in Space -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428392: dkim-filter.sock permissions should be more MTA friendly
You don't specify which MTA you're running; stock Sendmail shouldn't have an issue. With that said, I'm perfectly fine with adding such a group, but I'll need to figure out the best way to make this happen. The socket's being created and having its permissions set out of libmilter by smfi_opensocket(). -- Mike Markley [EMAIL PROTECTED] Everyone is entitled to an informed opinion. - Harlan Ellison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425324: dkim-milter: FTBFS: mv: cannot stat `/build/buildd/dkim-milter-0.8.0.dfsg/debian/dkim-filter/usr/share/man/man4/dkim-filter.conf.4': No such file or directory
On Mon, May 21, 2007 at 12:00:07AM +0200, Kurt Roeckx [EMAIL PROTECTED] wrote: Your package is failing to build with the following error: mv /build/buildd/dkim-milter-0.8.0.dfsg/debian/dkim-filter/usr/share/man/man4/dkim-filter.conf.4 /build/buildd/dkim-milter-0.8.0.dfsg/debian/dkim-filter/usr/share/man/man5/dkim-filter.conf.5 mv: cannot stat `/build/buildd/dkim-milter-0.8.0.dfsg/debian/dkim-filter/usr/share/man/man4/dkim-filter.conf.4': No such file or directory make: *** [install] Error 1 Strange, didn't happen in my sid chroot. Looking into it. -- Mike Markley [EMAIL PROTECTED] Totally illogical, there was no chance. - Spock, The Galileo Seven, stardate 2822.3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#217567: closed by Mike Markley [EMAIL PROTECTED] (closing due to lack of information)
On Sun, May 20, 2007 at 10:28:12PM +0200, Klaus Ethgen [EMAIL PROTECTED] wrote: Am So den 20. Mai 2007 um 7:15 schrieb Debian Bug Tracking System: #217567: scrollz dosn't mather off ajoin, [...] Still awaiting more info on this bug I've been unable to reproduce. It's been in this state since October 2006. Closing now. I have no clou what information you need. Please tell me and I will answer it. I'd asked for output from /on invite. Are you still experiencing this issue? -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417039: spfmilter: diff for NMU version 1.99+0.97-2.1
On Sun, May 20, 2007 at 04:06:30PM +0200, Luk Claes [EMAIL PROTECTED] wrote: Attached is the diff for my spfmilter 1.99+0.97-2.1 NMU during the current BSP which I'll upload to delayed-0. Thanks, I'd somehow missed this bugreport while preparing my last upload. I'll add your NMU to my copy of the tree. -- Mike Markley [EMAIL PROTECTED] Everyone is entitled to an informed opinion. - Harlan Ellison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417039: spfmilter: diff for NMU version 1.99+0.97-2.1
Upon further inspection, this doesn't actually fix the core issue, which is that the postinst and postrm scripts require adduser/deluser. IMO, the best solution is a Depends: on adduser. I'll prepare an upload. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315196: update
Is this still happening with the current version linked against libspf? -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389927: followup
tags 389927 + pending thanks As it turns out, spfmilter and the current libspf2 still don't get along (read: porting required to make it build at all). For the moment, I'll have to stick with libspf. I've added some doc notes about the unavailability of --recipientmx and I've removed it from the defaults file's list of interesting options. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425324: dkim-milter: FTBFS: mv: cannot stat `/build/buildd/dkim-milter-0.8.0.dfsg/debian/dkim-filter/usr/share/man/man4/dkim-filter.conf.4': No such file or directory
tags 425324 + confirmed thanks I've reproduced it, and I'm digging into the build system to see why it's doing what it's trying to do. The build system wants to run some groff commands on the manpages before installing them, for reasons that aren't entirely clear. It amounts to a no-op, so I'll try to remove the processing rather than add a dependency. I expect to have an upload soon. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417039: spfmilter: diff for NMU version 1.99+0.97-2.1
On Mon, May 21, 2007 at 06:43:00AM +0200, Luk Claes [EMAIL PROTECTED] wrote: Mike Markley wrote: On Mon, May 21, 2007 at 06:34:40AM +0200, Luk Claes [EMAIL PROTECTED] wrote: Mike Markley wrote: Upon further inspection, this doesn't actually fix the core issue, which is that the postinst and postrm scripts require adduser/deluser. IMO, the best solution is a Depends: on adduser. I'll prepare an upload. Which I also added in my NMU... The only files touched in the patch you sent were changelog and postrm; did I miss something? Yes, that you already have a dependency on adduser. You're right; I've clearly misunderstood the problem. I see the part of policy that makes this an RC bug. What I'm curious about are best practices for a solution: is the correct behavior in that circumstance really to leave old users lying around? How have others approached this? -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396312: RFA: gnome-pilot -- A GNOME applet for management of your Palm PDA
Package: wnpp Severity: normal As I no longer have a PalmOS PDA or a GNOME installation, I am decidedly not the person to be maintaining this package. It probably makes sense for any new maintainer of this to also take over gnome-pilot-conduits; while they're not the same sources upstream, the same team maintains both, and they're released in tandem. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#217567: more info needed
tags 217567 + moreinfo unreproducible thanks I haven't heard anything on this for quite a long time and there have been several releases since; I plan to close this bug if there are no further updates in a couple weeks' time. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389927: spfmilter: Needs to be built against libspf2.
On Thu, Sep 28, 2006 at 08:48:36AM -0400, Ken Long [EMAIL PROTECTED] wrote: I was looking at the /etc/default/spfmilter file and trying out the suggested options, when I found that I could not use the --recipientmx option. If I include that in the options, I get the following error when I try to start spfmilter: Starting SPF Milter: Sorry, --recipientmx mode is not implemented with libspf; if you wantto use that flag you will need to rebuild spfmilter with libspf2. spfmilter: lib_init() failed I see libspf2-2 is a valid package in etch. Would it be possible to build spfmilter against that so that all the features will be available? spfmilter was rebuilt against libspf instead of libspf just a couple of months ago because of some other libspf2 issues. I'm working on packaging 0.97 as we speak, but both SPF libraries are somewhat in flux as far as features and stability, so there will probably be tradeoffs no matter which library is linked with. Once I get the 0.97 packaging sorted out I can see if libspf2 is viable, but there's a bit of history that you can still see under the fixed bugs on the spfmilter bugs page at http://bugs.debian.org/spfmilter. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353854: scrollz - FTBFS: find: /usr/share/scrollz: No such file or directory
Guess that's what happens when I don't have a chroot to test the build in. Fix is on its way... -- Mike Markley [EMAIL PROTECTED] Only God can make random selections. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330106: gnome-pilot: Sync with evolution drops location field on thungsten e
reassign 330106 evolution thanks The Evolution conduits are part of the Evolution source and binary package. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318049: intent to NMU
On Wed, Sep 07, 2005 at 07:47:41PM -0600, dann frazier [EMAIL PROTECTED] wrote: As this bug has been open with a patch for 56 days, I intend to NMU this package in 1 week (or sooner, at the maintainer's request). Please feel free to do so. I have not had time to do anything with it. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320123: support page irc client list
Package: www.debian.org Severity: wishlist Would it be possible to add ScrollZ to the list of IRC clients available in Debian on http://www.debian.org/support#irc (second paragraph)? Thanks! -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317523: aide: CAN-2005-2096: Staticly linked to zlib
On Sat, Jul 09, 2005 at 11:30:50AM +, Kurt Roeckx [EMAIL PROTECTED] wrote: It seems your package is linked staticly to zlib. There recently was a new version of zlib uploaded that fixed a security issue, so your package probably needs to be rebuild agains the new version. See DSA-740. Michael Stone points out that there doesn't seem to be an attack vector for this; aide only uses zlib for creating and opening its own database, and if a user is able to modify that then they've already compromised the system. I'm willing to listen to persuasive arguments in favor of an update, though, so I'll leave this bug open for a little longer. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317543: arson: FTBFS: ISO C++ forbids declaration of 'KXMLGUIClient' with no type
On Sat, Jul 09, 2005 at 04:44:20PM +0200, Kurt Roeckx [EMAIL PROTECTED] wrote: /usr/include/kde/kactioncollection.h:242: error: ISO C++ forbids declaration of 'KXMLGUIClient' with no type /usr/include/kde/kactioncollection.h:242: error: expected ';' before '*' token /usr/include/kde/kactioncollection.h:345: error: expected ',' or '...' before '*' token /usr/include/kde/kactioncollection.h:345: error: ISO C++ forbids declaration of 'KXMLGUIClient' with no type It may well be, but I honestly don't know how to confirm that. Certainly KXMLGUIClient appears nowhere in the arson source, so it's either a kdelibs bug or arson is doing something it shouldn't with the headers. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318746: arson: debian/rules does not honor noopt / build with -g
On Sun, Jul 17, 2005 at 02:38:00PM +0200, Helge Kreutzmann [EMAIL PROTECTED] wrote: As you can see, DEB_BUILD_OPTIONS is completely ignored[1]. Also the binary is never build with -g, (which is the entire reason I wanted to rebuild arson, btw). Also -Wall is not used. First, why do you set CFLAGS in debian/rules? You have a C++-programm (correct me if I am wrong) so IMHO it should be CXXFLAGS instead. It would be great if you could actually support these flags. But if you do not intend to do so, then remove the first lines in debian/rules, because the give the reader the impression that you actually do support them. Please also read section 10.1 (especially the notes for porters!) of debian-policy and adapt. It is only a should directive to use -g (and the other points mentioned there), but it helps. I've modified that snippet to set CXXFLAGS instead of CFLAGS since there seems to be nothing that actually uses CFLAGS. I'm also attempting to override INSTALL_STRIP_PROGRAM for the nostrip option, because it's explicitly defined with -s and used in a few Makefiles. Let me know if you have any other thoughts on this. I'm dist-upgrading my box right now so that I can test the build. -- Mike Markley [EMAIL PROTECTED] Everyone is entitled to an informed opinion. - Harlan Ellison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306071: (no subject)
On Mon, Jun 27, 2005 at 11:19:01PM +0100, Qingning Huo [EMAIL PROTECTED] wrote: Please find attached patch file to build spfmilter with libspf instead of libspf2. This should fix both bug#307086[0] and bug#306071[1]. Last time I tried, spfmilter didn't build at all with current the libspf version. That was with spfmilter 0.95, though; I'll give it a shot with 0.97, now that it's out. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315196: spfmilter: unexpectedly dies/stops responding
On Mon, Jun 20, 2005 at 08:32:44PM -0700, Stuart Sheldon [EMAIL PROTECTED] wrote: Socket goes away for no apparent reason. Known bug, probably related to the version of libspf2 against which it's linked. Unfortunately, libspf has issues of its own, as do the newer versions of libspf2 (against which spfmilter will not compile). At the moment, I'm afraid, the spfmilter package quite lives up to its pre-1.0 version number and should probably remain in unstable only for the time being. I'll leave this open until a fix is available either way, so that others are aware that it's known. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314224: expect: Tcl8.4 link problem
On Wed, Jun 15, 2005 at 11:45:32AM +0200, Alain Degreffe [EMAIL PROTECTED] wrote: I'm the author of ciscocmd, a short and simple expect script for CISCO, hosted on COSI Website and I can't release my script because I use the fork command and expect is broken under Sarge. Under Woody, I was able to run my scripts with forking mechanism. After dist-upgrade, the spawn command in forked process doesn't work anymore. This problem is well known and depends from the compilation option of tcl. The linked tcl version is compiled with enable-threads. This is incompatible with expect forking mechanism. Debian maintainer of tcl has been contacted but he says that a version without thread is provided for this : tcl 8.3. To test it, I have modified the debian rules file to use tcl 8.3 instead 8.4 and all is working now. Could you provide a version of expect that use tcl 8.3 ? I was under the impression that the current TCL maintainer did not want tcl8.3 in sarge. If I'd been aware that it was going to release with it, I would have simply rebuilt the main expect package against it. Sigh. At any rate, I've Cc:ed one of the hppa guys, who is maintaining a version of the package linked against tcl8.3. If he's willing to maintain a version of it for stable, then that may be a workable solution. Otherwise, I can look at doing so. Note, though, that it's highly unlikely that a new package or that a change as major as rebuilding the main expect package against tcl8.3 would make it into sarge, now. -- Mike Markley [EMAIL PROTECTED] In Nature there are neither rewards nor punishments, there are consequences. - R.G. Ingersoll -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308713: expect: Dummy packages still needed?
On Thu, May 12, 2005 at 01:59:21AM +0200, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: The expect source package creates a number of dummy packages that were targeted at potato-woody upgrades but are still available in sarge/sid. If there is no reason to keep these dummy packages please remove them from the distribution. Dummy packages include: expect5.24, expectk5.24, expect5.31 and their -dev packages. I was under the impression that official support for upgrades is current release - 2, so potato-sarge should be possible. If I'm misunderstanding (or if I'm just imagining that), I'd be glad to remove the dummy packages... -- Mike Markley [EMAIL PROTECTED]
Bug#293457: NMU
On Thu, Apr 21, 2005 at 02:38:30PM +0400, Al Nikolov [EMAIL PROTECTED] wrote: If that workaround accepted, i would prepare NMU. Objections? I'm working on an upload (and I only received the suggestion yesterday...). -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293457: NMU
On Thu, Apr 21, 2005 at 05:31:05PM -0600, Bob Proulx [EMAIL PROTECTED] wrote: Excellent! Any previews? What is plan for dealing with this part of the problem? Well, I could always just skip the autogenerated config if the user invoking aide does not have write permission to it, though doing so silently may violate the principle of least surprise. I'm open to other suggestions. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297751: arson: UI completely unresponsive#
On Wed, Mar 02, 2005 at 06:46:13PM +0100, Helge Kreutzmann [EMAIL PROTECTED] wrote: I noticed, that the command line options work, and if I start it with LANG=C arson I get english menu items instead of german ones. Sorry for the long-delayed response; I recently moved and my development box's /usr drive didn't handle the move so well... It's not clear from the above: does arson work properly with LANG=C? It looks like you're using [EMAIL PROTECTED]; I wasn't able to reproduce this, even with that as my LANG and LC_CTYPE, not even under windowmaker. -- Mike Markley [EMAIL PROTECTED] I don't believe in God because I don't believe in Mother Goose. - Clarence Darrow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298303: aide: statically linked but depends on libc (?)
On Sun, Mar 06, 2005 at 03:59:04PM +0100, Santiago Vila [EMAIL PROTECTED] wrote: While building this package for the hurd-i386 architecture, I noticed that there is a hardcoded dependency on libc0.2, which does not exist. Then I noticed about the debian/mkdep script, which seems like a hack. Indeed it is. It was my understanding that statically linked executables, by definition, do not depend on libc at all, so the package dependency is artificial, but if I'm missing anything and there is a real need to depend on the libc of the day, then please do it in a portable way, which does not need to be updated for every architecture. For example, you could include a simple hello world program in the package source and just compile and run dpkg-shlibdeps on it. You're probably absolutely right about the libc6 dependency not being there, now that I think it through. I suspect it is probably there out of sheer force of habit, where compiled binaries are concerned. Unless anyone raises objections, I'll remove the dependency. -- Mike Markley [EMAIL PROTECTED] I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones. - Albert Einstein. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293073: Solution for aideinit conf file missing
Before becoming unavailable (for a lot longer than expected, I'll admit), I added a co-maintainer and asked him to take a look at this bug. I guess he hasn't had the time, either, so I'll look for a permament solution, hopefully sometime tonight. -- Mike Markley [EMAIL PROTECTED] (1) Never draw what you can copy. (2) Never copy what you can trace. (3) Never trace what you can cut out and paste down. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301556: tcl8.4 based expect doesn't deliver reliable test results on hppa
Finally have my development box fixed. I will be following up on this in the next day or so. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278814: checking out old bugs
tags 278814 + unreproducible tags 278814 + moreinfo severity 278814 normal thanks I created this config: # database=file:/tmp/aide.db database_out=file:/tmp/aide.db.test Binlib = p+i+n+u+g+b+m+c+sha1 ConfFiles = p+i+n+u+g+s+b+m+c+md5 /tmp/aidetest/1 Binlib /tmp/aidetest/2 ConfFiles # I then populated the /tmp/aidetest/1 and 2 directories with empty files and ran an aide --init with that config file. The end result was that the file in /tmp/aidetest/1 was stored with an sha1 hash but no md5, and the file in /tmp/aidetest/2 was stored with an md5 hash but no sha1 -- in other words, the exact behavior one would expect. Perhaps you can post a more complete configuration and send me a copy of the database (if it's large you might want to skip Cc:ing the BTS). -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#267978: please consider adding support for /etc/aide/aide.conf.d
On Sun, Jan 16, 2005 at 01:07:38AM +0100, Marc Haber [EMAIL PROTECTED] wrote: On Sat, Jan 08, 2005 at 12:45:23AM +0100, Marc Haber wrote: The attachment has a preliminary patch which, however, was done against my local cdbs'ized version. So it probably won't apply to your version right away, so please take it as a preview of what to expect. Can you give feedback based on this before I delve into your more old-fashioned way of packaging? May I remind? By all means. I plan to make a few uploads this weekend (had to run a long-overdue upgrade). -- Mike Markley [EMAIL PROTECTED] The universe does not have laws -- it has habits, and habits can be broken. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
