severity 227464 important reassign 232664 uucp thanks On Wed, Mar 24, 2004 at 09:04:52PM -0500, Nathanael Nerode wrote: > => easy xfree86/4.3.0-7 sppc/1.0.1-7 tulip/1.2.5-4 > Lets XFree86 in.
Added as "hint xfree86/4.3.0-7", in case there are other packages lurking that haven't been built for alpha. > => easy lam/7.0.4-2 blacs-mpi/1.1-21 scalapack/1.7-7 > python-scientific/2.4.5-2 hdf5/1.6.1-4 netpipe/3.6-1 xmpi/2.2.3b8-3 > Lets that whole list in. > => easy lm-sensors/2.8.5-3 mrtgutils/0.5 wmsensors/1.0.4-3.3 > hardware-monitor/1.0-2 wmgtemp/0.6-3 xsensors/0.40-2 > Lets lm-sensors and all dependencies in, though only once hardware-monitor > has built on powerpc and waited a few more days. Hints added for both of these, with a comment on the last one to remind me to pay attention to it. > And the old removals: > => remove atmelwlandriver/2.1.1-3.3 > #229159 (and other bugs) Hinted. > => remove dovecot/0.99.10.4-3 > #225048 (data loss). I know this has been argued, but I still think it's > not right to ship a package with a dataloss bug like this; your mileage may > vary. My mileage doesn't vary. Package also was not shipped with woody; I don't see any reason to be lenient about letting another buggy imap server into stable, we have some of those there already. > => remove drivel/0.9.1-4 > #226492 Looks like the fixed package is just pending sponsorship, which is forthcoming. Hinted anyway for now. > => remove kronolith/1.1-1 > #227461 Hinted, though hoping someone will package the necessary PEAR glue soon. > => remove sendmail/8.13.11.Beta0-1 > #227464. Also #232664 227464 is now downgraded. Nowhere in policy does it say that debconf use is a must, for precisely the reason that not everyone has transitioned to it yet. #232664 -- wow, sendmail and uucp, two of my favorite technologies, let me think about this one. ;p While I see in policy that it states rmail should be /usr/sbin/rmail, I don't see anything to support the claim that a package providing mail-transport-agent is required to contain /usr/sbin/rmail. In fact, the only mention of rmail at all is a "should". I'm reassigning this bug back to uucp. The fact that mail-transport-agent did correlate with the rmail command in the past does not seem to impose an obligation on MTA maintainers to ensure this going forward. Without a policy mandate, the responsibility seems to lie with the uucp package to depend on a list of acceptable packages (in the absence of a virtual package with the requisite meaning). Also, the claim that sendmail is the only mta not providing rmail is false. The ssmtp package provides: mail-transport-agent without providing an rmail binary, and I suspect nullmailer is the same way. So sendmail is spared. > => remove zope/2.6.4-1 > #222443 Hinted with dismay. -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
