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#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#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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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#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#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#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:
On Mon, Dec 17, 2007 at 10:08:07AM +0100, Jos [EMAIL PROTECTED] wrote: search kast How do you do name resolution? -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450711:
On Mon, Dec 17, 2007 at 12:31:12PM +0100, Jos [EMAIL PROTECTED] wrote: with bind9. the server has the name kast. Ah. I'm afraid that's not how resolv.conf works. search simply specifies a list of domains under which to search for hosts. So, for example, if you attempted to look up a host simply called foo, the resolver would try resolving just foo, then foo.kast. That keyword has no bearing on where lookups are performed. Your system still needs nameserver entries so it knows what name server(s) to actually query. Upstream has dug into the resolver functions a bit and confirmed that this behavior would occur on a system with no nameservers available. -- 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#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#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#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#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#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#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#423758: FTBFS bugs
The Sendmail maintainer recently moved libmilter.so from /usr/lib to /usr/lib/libmilter. I am consulting with him on this change and will fix these builds once that's cleared up. -- 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#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#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#306071: spfmilter: fails to start with a missing shared object error
According to upstream, spfmilter does not work with libspf2 1.2.x. I will test to see if that's out of date, but I will probably end up having to rebuild against libspf instead, which means missing functionality (--trustedforwarders and --recipientmx) -- but that's better than no functionality. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
