Re: Richard A Nelson (Rick) cow...@debian.org MIA
On Mon, 1 Nov 2010, Harald Jenny wrote: sorry to disturb you but it seems like a month has passed and the situation is still unclear. 'Tis now on the correct track, finally. Trying to contact you in private seems to fail so I was forced to use this way. Fail? How? I checked my logs (back to Oct 17th at least) and I only see those going debian - no temp/perm fails, etc. If you have a failure report - I'd love to see it (maybe time to drop my MX service!). Could you give us a quick overview what the current state of packaging sendmail and libmilter is? Do you need any help? Is there a chance to get this new version still into Squeeze (release team?) or should we rather focus on backporting the necessary changes to 8.14.3? As the libmilter problem renders a class of applications unreliable this should IMHO really be classified as RC bug. It was a comedy of errors - all mine *) I had a build ready to go the day after my last note *) I had issues uploading: *) I now have to add options to force inclusion of source (didn't before) *) My Key old key had been removed from the keyring *) I was building newer keys, so it took a while to find the proper key *) The last upload attempt on Oct 16 may have been partial - never saw any accept note, nor a rejection ... I ran out of time Then the Work/Life balance was tilted by serious family health issues :( Your note reminded me (thanks) that this still wasn't done - so I tried again and just got back: sendmail_8.14.4-1_amd64.changes ACCEPTED into unstable So, barring bugs, it should hit testing soon -- Rick Nelson chesty xemacs fixed my flatulence -- From the XEmacs: Not just an editor department -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1011011633210.26...@hygvzn-guhyr.pnirva.bet
Re: Richard A Nelson (Rick) cow...@debian.org MIA
On 09/27/2010 10:14 PM, Stefano Zacchiroli wrote:
On Mon, Sep 27, 2010 at 06:33:05PM +0200, Harald Jenny wrote:
I'm sorry for disturbing all of you but I'm currently facing the problem that
the maintainer of the Debian sendmail package, Richard A Nelson, seems to be
lost. He does not react to bug reports nor mails concerning the libmilter
package which is used by some other software. Please if anybody is in contact
with him try to convince him that an update of this package is really needed.
If there is no response from him I must contact the release team and ask if
they would be willing to accept an NMU as the bug in libmilter bites a lot of
other software.
I have indeed been MIA, working though back-to-back product releases - and now
have some breathing room before it all starts over again.
I had an upload of sendmail 8.14.4 all ready to go, but got bitten by DB 4.8
changes that completely broke sendmail (and a few other apps), and now there's
been a NMU or two that I have to refit and re-check DB 4.7 vs 4.8.
However, since we're now frozen, I'm not sure if a new version is going to be
accepted. As I recall, upstream did not use the suggested patch verbatim, so
any updates to 8.14.3 should check against 8.14.4.
I'll get 8.14.4 into unstable in the next day or so, but what happens to
'stable' is likely going to be a policy/RM call.
Here's the upstream changelog which shows several important fixes - with the
most important (IMNSHO) being:
* The Security (top) entry
* Host lookup crash
* Several milter issues
8.14.4/8.14.4 2009/12/30
SECURITY: Handle bogus certificates containing NUL characters
in CNs by placing a string indicating a bad certificate
in the {cn_subject} or {cn_issuer} macro. Patch inspired
by Matthias Andree's changes for fetchmail.
During the generation of a queue identifier an integer overflow
could occur which might result in bogus characters
being used. Based on patch from John Vannoy of
Pepperdine University.
The value of headers, e.g., Precedence, Content-Type, et.al.,
was not processed correctly. Patch from Per Hedeland.
Between 8.11.7 and 8.12.0 the length limitation on a return
path was erroneously reduced from MAXNAME (256) to
MAXSHORTSTR (203). Patch from John Gardiner Myers
of Proofpoint; the problem was also noted by Steve
Hubert of University of Washington.
Prevent a crash when a hostname lookup returns a seemingly
valid result which contains a NULL pointer (this seems
to be happening on some Linux versions).
The process title was missing the current load average when
the MTA was delaying connections due to DelayLA.
Patch from Dick St.Peters of NetHeaven.
Do not reset the number of queue entries in shared memory if
only some of them are processed.
Fix overflow of an internal array when parsing some replies
from a milter. Problem found by Scott Rotondo
of Sun Microsystems.
If STARTTLS is turned off in the server (via M=S) then it
would not be initialized for use in the client either.
Patch from Kazuteru Okahashi of IIJ.
If a Diffie-Hellman cipher is selected for STARTTLS, the
handshake could fail with some TLS implementations
because the prime used by the server is not long enough.
Note: the initialization of the DSA/DH parameters for
the server can take a significant amount of time on slow
machines. This can be turned off by setting DHParameters
to none or a file (see doc/op/op.me). Patch from
Petr Lampa of the Brno University of Technology.
Fix handling of `b' modifier for DaemonPortOptions on little
endian machines for loopback address. Patch from
John Beck of Sun Microsystems.
Fix a potential memory leak in libsmdb/smdb1.c found by parfait.
Based on patch from Jonathan Gray of OpenBSD.
If a milter sets the reply code to 421 during the transfer
of the body, the SMTP server will terminate the SMTP session
with that error to match the behavior of the other callbacks.
Return EX_IOERR (instead of 0) if a mail submission fails due to
missing disk space in the mail queue. Based on patch
from Martin Poole of RedHat.
CONFIG: Using FEATURE(`ldap_routing')'s `nodomain' argument would
cause addresses not found in LDAP to be misparsed.
CONFIG: Using a CN restriction did not work for TLS_Clt as it
referred to a wrong macro. Patch from John Gardiner
Myers of Proofpoint.
CONFIG: The option relaytofulladdress of FEATURE(`access_db')
did not work if FEATURE(`relay_hosts_only') is used too.
Problem noted by Kristian Shaw.
CONFIG: The internal function lower() was broken and hence
strcasecmp() did not work either, which could cause
problems for some FEATURE()s if upper case
Re: libgcrypt brain dead?
On Tue, 9 Mar 2010, Brian May wrote: Unfortunately, gcrypt is used by gnutls, which is used in ldap, which is frequently used in PAM and NSS. So this is an issue. There might be other NSS and PAM modules that use it too. Indeed, and this causes significant pain for Debian users in a lot of environments. * GnuTLS does not negotiate well with some corporate SSL libraries and the kluge patches applied to products like OpenLDAP don't offer the ability to turn of TLS 1.1 negotiation * GnuTLS has other issues (fairly old, but still interesting): http://www.openldap.org/lists/openldap-devel/200802/msg00072.html * Couple this with the fact that our OpenLDAP packages are not new enough for multi-master support, and even one of the maintainers recommends not using Debian slapd package for 'Production use' - and you wind up with a variant of 'DLL Hell', but at least dpkg properly reports all failing/conflicting dependencies. Note: This would be so much easier if I only needed slapd compiled against OpenSSL ... but alas, that is not the case :( What is the solution? Should we go back to using openssl, at least with libraries such as openldap that are commonly used in pam and nss modules? That would certainly help folks who choose to build their servers on Debian and must operate in a heterogenous environment (mostly of older crap based on older OpenSSL/OpenLDAP/Apache/etc.) Or is there another way? For interoperability, OpenSSL is much better, but there is apparently still some amount of work to be done on license exemptions (how much?), and even if that were done, it'd take a bit of work to switch everything back to it ... if there was concensus Alternatively, have I got something wrong? Exactly correct from my PoV :( -- Rick Nelson SomeLamer what's the difference between chattr and chmod? SomeGuru SomeLamer: man chattr 1; man chmod 2; diff -u 1 2 | less -- Seen on #linux on irc -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1003201039320.25...@hygvzn-guhyr.pnirva.bet
Re: libgcrypt brain dead?
On Sat, 20 Mar 2010, Russ Allbery wrote: Hrm, I've been swamped with work, and have neglected most of my packages for far too long (though some intentional), I'll give the idea some thought, though, OpenLDAP is *very* critical to both my home and work setup ! The first step would be to reach consensus on removing from our archive the traditional LDAP NSS and PAM modules and replacing them with the ldapd versions, which talk to a system daemon over a protocol rather than pull all the libraries into the same executable. Oh Hell yeah, I've been neglecting libnss-ldap and libpam-ldap whilst investigating and moving all my usage to Arthur's excellent nss-pam-ldapd package ... It now has enough support that I've been trying to find a 'nice way' to ask for the deprecation and/or removal of the older and very problematical PADL packages. The early boot issues are gone, as are shutdown (due to bash/library) issues, proper filtering and attribute request, password changing works now - krb5 support seems to work, ... Once that's been done, the problem of getting license exceptions for all other GPL packages that link directly to OpenLDAP might be tractable. (Or it might not; I haven't done any of the necessary investigative work.) Ditto, being stuck between idiology, and needing to actually get my work done can be a rough spot - it becomes too easy to blame others for work I've neglected getting involved in :( -- Rick Nelson _Anarchy_ Argh.. who's handing out the paper bags 8) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1003201614300.2...@hygvzn-guhyr.pnirva.bet
Re: Bug#560216: Missing symbol HEIMDAL_KRB5_1.0
On Thu, 10 Dec 2009, Brian May wrote: What do I do about this issue: On Wed, Dec 09, 2009 at 09:07:45PM +0100, Guido Günther wrote: $ krb5-auth-dialog -A krb5-auth-dialog: /usr/lib/libkrb5.so.25: version `HEIMDAL_KRB5_1.0' not found (required by krb5-auth-dialog) If I look through the library with objdump, I see HEIMDAL_KRB5_2.0 defined not HEIMDAL_KRB5_1.0. libpam-heimdal is in the same boat - completely hosing any box with an upgraded heimdal. My guess is that upstream have increased the version number of the library versioned symbols, but did not increase the soname number. Is this wrong? It feels wrong to me. The heimdal (and reverse-depends) package dependencies are pretty much useless ... Rolling back from the unstable version to the prior working heimdal was a royal pita; when it seems like it should've been sufficient to 'aptitude install heimdal-xyz/testing', instead I had to generate a transitive closure of the dependencies and manually select them all - meaning they're now 'manually installed' Is this something I should be reporting back to upstream? I'd think a rebuild of the debian package providing krb5-auth-dialog against current Debian Heimdal packages would suffice. Thanks. Good luck with this. When I installed heimdal, it was the only choice that allowed me to utilize the existing LDAP db - which has alot of benefits... I may reconsider, if MIT's LDAP support is reasonable There just doesn't seem to be a good way to keep the MIT and HEIMDAL versions of some important packages in sync :( -- Rick Nelson ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. (By Matt Welsh)
Re: integrating PAM module into nss-ldapd (RFH)
On Sat, 16 May 2009, Arthur de Jong wrote: I'm working on integrating a PAM module into nss-ldapd and am looking for input on this. The PAM module was kindly provided by Howard Chu from the OpenLDAP project but I'm still working on the server part. Interesting, I talked briefly with Howard (on IRC) about this a few times, quite a while ago... talking about possible ways to impliment this. With this new functionality I'm planning to generate three binary packages (instead of the now one): libnss-ldapd (the NSS module), libpam-ldapd (the PAM module) and nslcd (the daemon). The reason for this split is that some users may want to stick with the other PAM module. Also the OpenLDAP people are working on an overlay that could replace the nslcd part (but it's up to the OpenLDAP maintainers if they want to provide such a package). This is great news! I've already converted all my boxes and am continually exhorting conversion to libnss-ldapd (mostly on IRC, but also those who report bugs on the libnss-ldap package). It seems to me, as the libnss-ldap maintainer, that libnss-ldapd is functional enough that we should deprecate libnss-ldap. I would also, as the pam-ldap maintainer, recommed similar deprecation for it once you have bind-auth (for auth), and exop (for pw change) going. There is already so many mis-configured machines out there, and the older packages have some significant issues, that I really believe Debian would do well by standardizing/offering only the one, superior, solution. Also, I'm looking for people who are willing to spend some time on nss-ldapd. I could use some help with the PAM packaging part, I know libpam-runtime was changed recently so if anyone can help to get the the PAM packaging into shape that would be great. Whilst I'm no pam wizard (by any stretch), we can likely take some information from the extant pam-ldap package. Since nss-ldapd seems to be used more often now, having a co-maintainer for the package would really help. There is still enough development work to be done but also packaging work with the upcoming split. Count me in - in whatever way I can be of assistance ... I've moved most of my machines to KRB5 auth, but the LDAP passward are being still kept in sync; so I can easily run tests. Another important part where I would really welcome suggestions is a better name for the software. I've seen some confusion over the current name (people not noticing the d at the end) and with the integration of PAM functionality the name no longer covers the functionality. Yes, the name does cause confusion (often an issue on #ldap and #openldap), which is one reason I favour deprecation of the older packages (if not removal), and having one solution for Debian. But even if we don't do that, I think the current name proposals make sense - even if somewhat confusing. Current work on integrating the PAM functionality can be tracked here: http://arthurenhella.demon.nl/svn/nss-ldapd/nss-pam-ldapd/ http://arthurenhella.demon.nl/viewvc/nss-ldapd/nss-pam-ldapd/ /me makes a note to pull these Tuesday afternoon (this weekend is my 28th anniversary) - and we're still recovering from 3weeks on the road, so I wont have much computer time until then. -- Rick Nelson We don't do a new version to fix bugs. - Bill Gates The new version - it's not there to fix bugs. - Bill Gates -- Retranslated from Focus 43/1995, pp. 206-212 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Tue, 5 May 2009, Russ Allbery wrote: Stefano Zacchiroli z...@debian.org writes: Yes, the most repeated argument has been mount /usr via NFS. Unfortunately, nobody yet explained how do they update the resulting cluster of machines. It's not particularly difficult. You update the system master and push that update into NFS, synchronizing any non-/usr data as you need to across all the systems mounting that NFS partition. If you don't want to take downtime, you have two chroots on the NFS server and pivot systems back and forth between the two chroots as you do updates. I have parts of /usr and /var shared via NFS and use cfengine to push/pull related updates to /etc and other non-shared locations. cfengine will keep the non-shared portions synchronized, and restart services when their config files are updated. People did and still do this all the time with AFS. It's pretty well-established how to make it work. 'Tis a little harder now with my servers being split betwixt i686 and amd64 machines (db format differs, so I had to use inn peering, not shared spool, etc). I personally don't care any more because hard drives have gotten a lot bigger, but it's technically quite feasible. Yes, but I see this as an management of space/time/etc trade-off. For me the big items for standalone /usr are mentioned elsewhere - I tend to have a separate /boot and put everthing else in a (encrypted for laptops) LVM where resizing/moving/backup/security/etc all argure for independant partitions. I see as quite pointless to use let's export /usr via NFS as an argument, if Debian does not provide a way to make that setup tenable. Certainly looks tenable right now to me. Indeed, tenable - and working -- Rick Nelson miguel `You have been unsubscribed from the high energy personal protection devices mailing list' miguel I dont remember getting into the mailing list -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sorting out mail-transport-agent mess
On a related note flashback,mode=bugs bunny If I dood it, I get a whipping. I dood it. /flashback What about the possibility of MTA/MSP alternatives - I'd like to support the next generation sendmail (Meta - used to be SM x) - a very postfix like design for enhanced security. I recall RH, or a deriviative that supported multiple MTAs being installed concurrently via alternatives. For quite a while, Meta was only usable for an outgoing MTA, and was missinge milter support (making it unusable, IMNSHO for inbound) so I did some prelimiary work to support this in the sendmail package, there would need be much infrastructure suppport to make this feasible. -- Rick Nelson Even more amazing was the realization that God has Internet access. I wonder if He has a full newsfeed? (By Matt Welsh) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: flock() and sendmail
On Fri, 17 Nov 2006, John Kelly wrote: Then I have to wonder why sendmail is still configured to use fcntl() when running on linux. Sounds like the modern kernel implementation of flock() would be better. The most general solution wins ... and that is fcntl() ! afaict, flock() *still* does not work over NFS Just because you may not need that feature does not mean I can screw up the maildirs, databases, etc of those who happen to use NFS (and NFS v4 is looking *very* nice...) -- Rick Nelson |Rain| with sane code, maybe I could figure out the renderer :) LordHavoc rain: I'd probably be the one writing the renderer |Rain| well, er, uh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: flock() and sendmail
On Thu, 16 Nov 2006, John Kelly wrote: I don't need NFS with sendmail. Surely flock() is not *still* broken in 2.6 kernels? I doubt that flock is *still* broken - that was quite some time ago... ** NOTE: Override HASFLOCK as you will but, as of 1.99.6, mixed-style ** file locking is no longer allowed. In particular, make sure ** your DBM library and sendmail are both using either flock(2) ** *or* fcntl(2) file locking, but not both. This, indeed, is the important part ! DB has changed alot, and now has its own locking system, and whatever it uses to lock the entire DB is what should be used by its callers. Has DB changed from fcntl to flock ? Are you trying to access the sendmail databases from another program that has differing locking conventions ? You fail to provide any hints as to on why fcntl which is used instead of flock is causing you grief. -- Rick Nelson Oryn anyone know if there is a version of dpkg for redhat? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sun, 17 Sep 2006, Marco d'Itri wrote: On Sep 17, Petter Reinholdtsen [EMAIL PROTECTED] wrote: I got the commands used by Andreas Metzler to extract packages in sarge with files or directories in /var/run/, and ran the it on etch. These are the 159 packages: Not all of them are buggy, e.g. ssh, inn and inn2 have the directory in the package but also create it in the init script if needed. ditto for sendmail -- Rick Nelson I've heard a Jew and a Muslim argue in a Damascus cafe with less passion than the emacs wars. -- Ronald Florence [EMAIL PROTECTED] in [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: System users and valid shells...
On Wed, 3 May 2006, Colin Watson wrote: On Wed, May 03, 2006 at 02:45:56AM +0200, Uwe Hermann wrote: this may be a dumb question, but I really wonder if there's a policy (which I obviously haven't found) about which system users should get a valid shell and which shouldn't. Yeah, I had the same thoughts when I first installed tiger This is bug #330882, and is basically because I'm exceptionally conservative when it comes to base-passwd and it's rather hard to tell whether anything in Debian might be relying on any of those users having a valid shell. I worried about that as well I'm willing to change these, but I'd like to do it on a case-by-case basis after scanning the archive for potential problems. At the moment I'm not even sure how to begin that scan ... As as a small datapoint, I took 4 machines I could play with and just fixed all the IDs tiger bitched about - and waited for the fallout. The results so far (several months later): * fetchmail needs a shell (likely because of my pam.d auth) * news needs a shell to do any maintenance * uucp needs a shell The rest of the system accounts are happily running with /bin/false I'm sure a few more folk could do likewise, and with some tracking, this should be fairly easy to nail down... With more testers, the faster we'd find the few exceptions. -- Rick Nelson By golly, I'm beginning to think Linux really *is* the best thing since sliced bread. (By Vance Petree, Virginia Power) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Accepted ibm-3270 3.3.4p6-1 (source all i386)
On Mon, 20 Feb 2006, Joerg Jaspert wrote: On 10571 March 1977, Richard A. Nelson wrote: Not only did you hijack these packages, and without *ANY* communication, you missed tcl3270, ICU builds (for the non-US folk)... You know that this package set was removed since march, so you cant say much against him bringing it back? Yes I know... I'm the one that had it removed ! The issues for which it was removed have gotten better, but have not yet been fully resolved. If you had the courtesy to contact me, as did the last person - who at least followed procedure and issued an ITP, you would know this. You would also know that I use this package every day, have kept it current, fixed some bugs... Even distribute updates. So yes, I can, and will say much against you bringing it back ! Look, I depend upon on this package for my living - It wasn't lightly that it was removed from Debian, some of the final issues were, in my opinion nits - but they still needed to be resolved. If you had managed to clear the remaining issues, courtesy would've compelled you to contact me - I've not fallen off the face of the earth; especially since you started with the last Debian version of the package (even leaving my changelogs intact). -- Rick Nelson _Anarchy_ Argh.. who's handing out the paper bags 8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Accepted ibm-3270 3.3.4p6-1 (source all i386)
Not only did you hijack these packages, and without *ANY* communication, you missed tcl3270, ICU builds (for the non-US folk)... Have you dealt with anyone on the issues, or do you even know what they are ? On Sun, 19 Feb 2006, Bastian Blank wrote: Date: Sun, 19 Feb 2006 11:12:39 -0800 From: Bastian Blank [EMAIL PROTECTED] Reply-To: debian-devel@lists.debian.org To: debian-devel-changes@lists.debian.org Subject: Accepted ibm-3270 3.3.4p6-1 (source all i386) Resent-Date: Sun, 19 Feb 2006 13:14:42 -0600 (CST) Resent-From: debian-devel-changes@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 13 Feb 2006 10:47:59 +0100 Source: ibm-3270 Binary: c3270 s3270 pr3287 x3270 tcl3270 xfonts-x3270-misc 3270-common Architecture: source all i386 Version: 3.3.4p6-1 Distribution: unstable Urgency: low Maintainer: Bastian Blank [EMAIL PROTECTED] Changed-By: Bastian Blank [EMAIL PROTECTED] Description: 3270-common - Common files for IBM 3270 emulators and pr3287 c3270 - Curses program for telnet sessions to IBM mainframes pr3287 - IBM 3287 printer emulation for telnet sessions to IBM mainframes s3270 - Program for scripted telnet sessions to IBM mainframes x3270 - X11 program for telnet sessions to IBM mainframes xfonts-x3270-misc - Font files for the x3270(1) IBM 3270 emulator Changes: ibm-3270 (3.3.4p6-1) unstable; urgency=low . * Reintroduce into main. * New upstream version. Files: 38249e21b317f47d335c8f1fec8d50bb 680 net optional ibm-3270_3.3.4p6-1.dsc b0b9dec67a451042a36cee51aba867f8 2652646 net optional ibm-3270_3.3.4p6.orig.tar.gz bcfd48c9992e732b6cd0eaef8afd7ac5 10147 net optional ibm-3270_3.3.4p6-1.diff.gz 60aa38b55f76835c9f9520be3d902532 98222 x11 optional xfonts-x3270-misc_3.3.4p6-1_all.deb 9dae1b8f838f7f707e116d7781cd15c5 228584 net optional x3270_3.3.4p6-1_i386.deb cc7fc6aaee34cd989a2f869e663b5c62 133544 net optional c3270_3.3.4p6-1_i386.deb e239af9f574cd397bdb278587defa6ee 37442 net optional pr3287_3.3.4p6-1_i386.deb 06865b0d3805272d0c1454434bed4b6f 107228 net optional s3270_3.3.4p6-1_i386.deb 75ae44a76bf6254e752cdb7bbd663300 21386 net optional 3270-common_3.3.4p6-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iEYEARECAAYFAkP3e0AACgkQLkAIIn9ODhG8jwCfSAS23dH6l/fXb8CqJsJ6DO3m wGAAoMssXK5y8/KEixu2jr+QqAd1HFZF =STVo -END PGP SIGNATURE- Accepted: 3270-common_3.3.4p6-1_i386.deb to pool/main/i/ibm-3270/3270-common_3.3.4p6-1_i386.deb c3270_3.3.4p6-1_i386.deb to pool/main/i/ibm-3270/c3270_3.3.4p6-1_i386.deb ibm-3270_3.3.4p6-1.diff.gz to pool/main/i/ibm-3270/ibm-3270_3.3.4p6-1.diff.gz ibm-3270_3.3.4p6-1.dsc to pool/main/i/ibm-3270/ibm-3270_3.3.4p6-1.dsc ibm-3270_3.3.4p6.orig.tar.gz to pool/main/i/ibm-3270/ibm-3270_3.3.4p6.orig.tar.gz pr3287_3.3.4p6-1_i386.deb to pool/main/i/ibm-3270/pr3287_3.3.4p6-1_i386.deb s3270_3.3.4p6-1_i386.deb to pool/main/i/ibm-3270/s3270_3.3.4p6-1_i386.deb x3270_3.3.4p6-1_i386.deb to pool/main/i/ibm-3270/x3270_3.3.4p6-1_i386.deb xfonts-x3270-misc_3.3.4p6-1_all.deb to pool/main/i/ibm-3270/xfonts-x3270-misc_3.3.4p6-1_all.deb -- Rick Nelson Delenn I wouldn't make it through 24 hours before I'd be firing up the grill and slapping a few friends on the barbie. spacemoos Why would you slap friends with barbies, thats kinda kinky -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Can't we at least agree on Anti-Virus for our mail
Just today 250+ viruses, mostly - clamd found the Worm.Mydoom.AT virus These are coming from master/gluck, and being a good citizen, I'm just dropping them on the floor (instead of creating backscatter). I know there's been heated debate about which, if any RBLs and other anti-spam tools to employ, but come on... an AV should be a no-brainer ! I'm personally running both clamav and f-prot with very nice results... -- Rick Nelson Knghtbrd I really don't want much at all... Just a kind word, an attractive woman, and UNLIMITED BANDWIDTH!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ppp/ip-up vs. network/if-up
On Wed, 13 Oct 2004, Thomas Hood wrote: FYI: The experimental ifupdown does not currently rerun up scripts if pppd reconnects. Is not the same true for DHCP ? I can see why, in the case of PPP interfaces, that might be desired. I am not sure that we should implement it, though. It would depart from the way ifupdown up and down scripts have worked in the past for other interfaces. I don't see how we can get this kind of support without ppp and dhcp support... The two would be very similiar (the potential to get the same address, or a new one). It would take some thought to handle all the possibilities properly but the end result would be *very* nice. I've tried a few times, and wound up with scripts in ppp, dhcp, and network - all modelled similiar to the DHCP state management. -- Rick Nelson Linux poses a real challenge for those with a taste for late-night hacking (and/or conversations with God). -- Matt Welsh
Re: Intent to package: smtpfeed and sendmail-wide
hrm... The requested URL /~monotori/sendmail.html was not found on this server. Is there somewhere else I can look? am I correct in assuming that WIDE is support for DBCS? -- Rick Nelson On Thu, 8 Oct 1998, Fumitoshi UKAI wrote: Date: Thu, 08 Oct 1998 14:34:14 +0900 (JST) From: Fumitoshi UKAI [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: Intent to package: smtpfeed and sendmail-wide Resent-Date: 8 Oct 1998 05:34:24 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; SMTPfeed is the mail transport agent invoked as LMTP mailer. SMTPfeed requires WIDE patch for sendmail, so I'll upload sendmail-wide package too. The pacakge sendmail-wide is same as sendmail except /usr/sbin/sendmail, so I'd like to build sendmail-wide pacakge depending on sendmail and diverting /usr/sbin/sendmail. About smtpfeed and sendmail WIDE patch, see http://www.wide.ad.jp/~monotori/sendmail.html Regards, Fumitoshi UKAI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: strange sendmail behaviour (bug?)
Yes, a bug... due to socks support (which is being taken out until I figure a better way to handle it; runsocks just don't cut it). This, and a few more will be corrected very quick now -- Rick Nelson On 8 Oct 1998, Ardo van Rangelrooij wrote: Date: 08 Oct 1998 21:19:27 +0200 From: Ardo van Rangelrooij [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: strange sendmail behaviour (bug?) Resent-Date: 8 Oct 1998 19:21:07 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; Hi, Last Monday I uploaded a new version of one of my packages. In my ~/.dupload.conf file I've defined the parameter 'fullname' as my full name :-). The dupload script passes this parameter to the -F flag of sendmail as '($fullname)'. Everything went ok, accept that sendmail complained that van and Rangelrooij) are unknown users and Rangelrooij)... Unbalanced ')'. Am I doing something wrong here, or is sendmail's behaviour being changed? I tried several qoutes and such, but nothing seemes to overcome this problem so far. Thanks, Ardo -- Ardo van Rangelrooij home email: [EMAIL PROTECTED], [EMAIL PROTECTED] home page: http://www.tip.nl/users/ardo.van.rangelrooij PGP fp: 3B 1F 21 72 00 5C 3A 73 7F 72 DF D9 90 78 47 F9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sendmail 8.9.0
Ack... Been out of town, no computer access. Sorry for the delay, but I'm looking at these now... -- Rick Nelson On 6 Jun 1998, John Goerzen wrote: Date: 06 Jun 1998 11:49:57 -0500 From: John Goerzen [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: sendmail 8.9.0 Resent-Date: 6 Jun 1998 16:56:34 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; Hi, I've recently reported two critical bugs with sendmail 8.9.0: 1) it completely breaks incoming UUCP mail 2) it completely breaks outgoing Majordomo messages #1 I solved easily, and fortunately, UUCP saves off failed messages. #2 has caused numerous lost messages. I have yet to receive any sort of response from either of these bugs. Can somebody please take a look and fix the problems? John -- John GoerzenLinux, Unix programming [EMAIL PROTECTED] | Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org | + Visit the Air Capitol Linux Users Group on the web at http://www.aclug.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
