Re: Bug#397646: exim4-config: reportbug mail issue
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >Reportbug installs who do not have exim installed correctly should be >using reportbug's built-in SMTP handling abilities and either relaying >to their upstream smtp server or bugs.debian.org; the latter as the >default if nothing else is selected. > >Since this is the way that reportbug works currently, I really don't >see the problem. [Perhaps the only bug here is that it even asks >whether to use the local smtp server in the "novice" case.] bugs.debian.org isn't always willing to accept mail. Besides the times like last night when a denial of service attack[0] made it so no mail was accepted for half an hour, spohr also uses greylisting. I don't think reportbug does mail queueing. Also, some ISPs do not allow direct outgoing mail connections. [0] Load average over 400 for a while, 25% idle time, 50% wait. The only unusuall thing running was many exim4 and procmail processes starting and completing quickly. My guess is spammers tried sending so much spam at once that nothing got through. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lots of (easily recognisible) spam sent to the BTS today
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >a) for mails to -close or to [EMAIL PROTECTED] to prevent a spammer/malicious > person from closing all the bugs or mangling with the BTS in such a way > that would take us some effort to recover Rather than that, I would like to see non-versioned close messages depriciated, other than ones that are explicitly so. No change would be needed for the majority of cases, only the rare "not a bug" close message would need to be different. Spammers basicly don't manipulate the BTS other than sending messages to any and all addresses they find or make up. (There was one spammer that figured out how to open bugs, and created three bugs before stopping.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lots of (easily recognisible) spam sent to the BTS today
On Tue, Oct 31, 2006 at 02:51:20PM +0100, David Weinehall wrote: > Isn't there a risk of causing double work? > > Person A reports spam, Blars removes it > Person B reports the same spam, Blars checks again - no spam found My script to clean bugs checks to see if the bug has been cleaned since the last time it received mail. In other words, don't worry about duplicated reports. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lots of (easily recognisible) spam sent to the BTS today
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>BTW, could it be possible to provide an alternate interface to submit spam?
>(like the 'report-listspam AT lists.debian.org' we can bounce spam from the
>mailing lists to)
Here's a short script I use to process messages sent to [EMAIL PROTECTED]
that report spam. It uses the existing interface.
#!/usr/bin/perl
use strict;
use LWP::Simple;
my @mess = ;
my $mess = join('', @mess);
my @bugs = $mess =~ /[^\d](\d{3,8})/gs;
foreach my $bug (@bugs) {
my $ans = get("http://bugs.debian.org/cgi-bin/bugspam.cgi?bug=$bug";);
}
--
Blars Blarson [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lots of (easily recognisible) spam sent to the BTS today
On Mon, Oct 30, 2006 at 10:50:51PM +0100, Kurt Roeckx wrote: > Does that mean that we shouldn't report spam we see in the BTS? If I > now see spam going to a bugreport of mine, I always go and press the > "this bug log contains spam". Should I just not bother with it? The ones that are reported generally get cleaned sooner, but new spam to bugs should be cleaned out without being manually reported anyway. Tomas Pospisek has started searching older bugs for obvious spam, and that is being cleaned out as I have time available. The amount of time this is taking has been going up, and I expect to have less time available for it in the future. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lots of (easily recognisible) spam sent to the BTS today
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >On Sun, 29 Oct 2006 16:02:41 -0800, Blars Blarson <[EMAIL PROTECTED]> >wrote: >>We have a SA rule for this run now, but sending such hints to >>[EMAIL PROTECTED] will get them seen much faster than debian-devel that I'm >>more than a week behind in reading. > >So you really want to be manually informed about spam runs against the >BTS? Don't you notice unusual activity in some rrd-based monitoring >system? If you have an idea for a new spamassassin rule that will get a current spam run without triggering on non-spam, send it to [EMAIL PROTECTED] Unfortunatly, much spam is now using anti-bayes tecniques and is hard to catch without also getting non-spam. I do see each message with a SA score >= -1, but at times I've been days behind slogging through them. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lots of (easily recognisible) spam sent to the BTS today
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >I'm not sure if anybody else is seeing this but I have seen (just today) 28 >spam messages sent to the BTS. I've received them because they were all sent >to (at least) the 'www.debian.org' pseudo-package, and I have reported all of >them in the BTS' spam interface [1] We have a SA rule for this run now, but sending such hints to [EMAIL PROTECTED] will get them seen much faster than debian-devel that I'm more than a week behind in reading. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian ISOs
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >When a nice bittorrent frontend is installed, the user will only have to >click on the link to start the download. This is true for Windows and >Linux. You left out the reconfigure the firewall(s) step. Not only is this non-trivial, the user may not have the ability to do so. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >At least for the BTS, those messages are not discarded; they're just >separated out and processing on them is halted. Blars spends a lot of >time looking at "borderline" messages to put back in non-spam into the >queue, and catches most of them. Not quite right, I look at the borderline messages that got passed through and delete them from bugs if they are spam. (and use them to train the filters either way.) I do look at the messages caught by crossassassin and reinject if needed, but that's many orders of magnatude less than those caught by spamassassin. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >there appears to currently be a sparc release of debian, >http://www.debian.org/ports/sparc/ (not currently a release candidate for etch) >and it appears to claim to support some kind of limited 64bit support. >There are some unstated things from the page that I would like to bring to >the table as relevant: > >1. since it is sparc, I would presume debian/sparc is "big endian" Yes. >2. since the amd64 arch now has 64bit applications (?) I would guess that > at some point, the debian sparc folks may follow suit. It does support 64-bit applications. However, in almost all cases compiling for 64-bit just makes the application slower. Don't expect all 64-bit mode support for sparc. (amd64 is only faster in 64-bit mode because of all the poorly designed x86 32-bit instruction set.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
O: cutter
retitle 316195 O: cutter -- disconnect routed IP connections severity 232058 grave thanks I'm not using this package, and it reportedly does not work with 2.6 kernels. It's been in RFA state for almost a year, with no takers. (One NM contacted me, but never prepared a fixed package for sponsorship.) As it looks like 2.4 kernels will not ship with etch, I'm increasing the severity of the outstanding bug and orphaning the package. If noone adopts the package I will request removal in a few weeks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lists.d.o Spam (was: Marking BTS spam)
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >on 2: we would need a whole spam-mail including all headers so we can > find charakteristika to filter on, so i now take all nominated > postings, and try to find patterns with some black > shell-magic. Is "sa-learn --spam" considered "black shell magic"? Of course you need to "sa-learn --ham" on some non-spam too. That's what I do with nominated messages to the BTS, and messages with a certain range of spamassassin scores. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Marking BTS spam
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >there was added a 'button' on all bug-number pages to 'mark as spam' on >near the bottom but IIRC it was marked as an experimental project to >only collect data for future use. If this has been implemented and >affect filtering, I guess the list-master would know. I guess some >script-foo could be used to 'click' the spam 'button' on the web page >but not my me x-) The lists.debian.org spam "button" doesn't have much immediate effect. The bugs.debian.org spam "button", after manual review, is used to clean the BTS and train the spam filters. This review usually occurs daily. An occasional mistake is no problem, but using it excessivly on bugs that don't have spam may get your IP address banned from the BTS web site. I also clean bugs that have gotten messages with questionable spamassassin scores. Scripting using the BTS spam feature is pretty easy, I've done so to process the email to [EMAIL PROTECTED] telling us about spam in a bug. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sparc build failure analysis (was Re: StrongARM tactics)
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote: >> I can do the analyzing, but what should I do with the results? >> [EMAIL PROTECTED] seems to be a black hole. You'll need to find >> someone willing to communicate with access to the buildd queues before >> the porters can do anything. > >I said that deciding which packages should belong in P-a-s is porter work; >as is filing bugs on failed packages that shouldn't, providing patches, and >doing porter NMUs if necessary. Again: what can I do with such a list? See the list below. >If the porters do this effectively, there's really not much need at all for >telling the buildd maintainers about transient build failures, because >they'll be pretty obvious (and account for the majority of failures, as it >should be). Just because it is obvious does not mean that the buildd adminstrator does the correct thing. kq was "uploaded" 51 days ago, trustedqsl was "uploaded" 25 days ago, neither is in the archive. openoffice.org has been "building" for 8 days, it only took 57 hours on my slower than any current sparc buildd pbuilder. kexi has been "building" for 6 days, it took less than 2 hours. The sparc buildd mainainter has in the past left transient build failures lie for over 6 months. For the past year he's been requeuing all maybe-failed packages every 1-3 months. I've gone through the list of "maybe-failed" packages on sparc again. The first sections is the packages that shouldn't be attempted on sparc. Two packages need requeued now that bugs in other packages are fixed. Several packages need to be put in dep-wait, and of course there is a large list that should be moved to failed. If nothing useful is done with this list, don't expect me to repeat the work again. NOT-FOR-US numactl only supports i386 amd64 ia64 appears to assume intel-style stuff, would need major redesign for other architectures vm only supports all, not any see bug 342185 wmkbd gsnes9x pistachio needs arch-specific code acpidump kexec-tools bug 338846 redboot bug 152911 rsbac-admin hdaps-utils lcd4linux bug 336017 vnstat hotkey-setup gwp snes9express contrib, needs snes9x-x libaio adeos defrag ree odyssey nvidia-cg-toolkit atokx2 xmms-openspc lcrash grub2 php4-maxdb libpam-encfs 915resolution pcsx acpica-unix REQUEUE mcvs1.0.13-12 341850 qterm 0.4.0pre3-2+b1 342381 DEP-WAIT galago-sharplibmono-dev dmraid libklibc-dev motvibzvbi0 (= 0.2.17-3.0.1) qmailadmin vpopmail-bin wvstreams libxplc0.3.13-dev sylpheed-claws-gtk2 libclamv-dev digikam libartsl-dev (>=1.4.2) tulip mesa-common-dev (= 6.2.1-7) liferea libdbus-glib-1-dev kwave kdemultimedia-dev ivtools libace-dev fwbuilder libfwbuilder-dev gtksharp2 libmono-dev libavg libavcodeccvs-dev gnucash slib memepackr-base-dev r-cran-bayesm r-base-dev FAILED bazaar 1.4.2-2 334320 palo1.9 320284 raidutils 0.0.4-7 326922 icon9.4.2-2.3 322972 erlang 1:10.b.7-1 326031 ispell-fi 0.7-16 326025 gmpc0.12.0-1333711 cursel 0.2.2-3.1 267900 supercollider 20050624-1 290339 qprof 0.5.1-6 323094 silc-toolkit0.9.12-4.1 326924 libgstreamer-perl 0.04-1 328051 jmagick 6.0.4-0-1 329104 mesa-lagacy 6.2.1-8 327637 xsim0.3.9.4-6 221453 haskell-http0.4.20050430-1 315333 rhyme 0.9-5 269371 ultrapossum-slapd 0.0.4+2.2.20sb3-1 304092 wmtune 1.1-1 269718 siptoolbox 0.3.99rc2alpha3-2 332526 slate 0.3.4.3-2 323126 postgis 1.0.0-1 323120 php4-vpopmail 4.3.4-5.4.4+2 309556 babel 0.10.2-2.1 309272 stalin 0.9+0.10alpha2-2337169 klibc 1.1.1-4 330191 libopenspc 0.3.99a-2 322979 iproute 20041019-4 336675 swish-e 2.4.3-2 339343 rcalc
Re: buildd administration
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >Setting up a buildd system do not require extra privileges from the >Debian project, as far as I know. Any Debian developer with his >public key in the keyring can sign uploads. and get threats from the current buildd administrator to "make sure you don't do that". (Who could abuse his power as part of other teams to do that.) Been there, done that. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >- How can I get information from "inside" a buildd, e.g. temporary files > created during a failed build. First pass answer: you can't. sbuild (tries to) clean up after builds. Alternate: try to get a porter to redo the build and give you the desired info. Best: rewrite your build script to put the desired info into the build log. Instead of: foo >/tmp/foo 2>&1 use: if foo >/tmp/foo 2>&1 ; then : ; else cat /tmp/foo ; exit 1 ; fi -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >Um... no. This is *porter* work; one does not have to be a buildd admin to >analyze a build failure to see whether the package belongs in P-a-s, and >there's no reason that the buildd admins alone should bear the >responsibility for figuring out whether a permanent build failure should be >fixed or ignored. (Maintainers probably need to be involved in this >process, but usually maintainers don't have the requisite knowledge about >all our ports to make informed decisions on their own.) I can do the analyzing, but what should I do with the results? [EMAIL PROTECTED] seems to be a black hole. You'll need to find someone willing to communicate with access to the buildd queues before the porters can do anything. >Wonderful. Nice to see that you think P-a-s entries are somebody else's >problem that should be "handled centrally". The buildd administrators have made it clear that's the way they want it. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My IP address seems listed as a spammer address by bugs.debian.org
In article <[EMAIL PROTECTED]> you write: >(this mail was CC'ed to debian-admin but I messed up in the To field) [EMAIL PROTECTED] would be the correct place to send this. >Since yesterday, I'm afraid that my IP address 81.56.227.253 is listed >on bugs.debian.org among addresses which get a "Go away" answer when >requesting a specific bug report (http://bugs.debian.org/xx) And as of about 9 hours ago the listing was removed. >>From discussions I had on IRC with Anthony Towns, this seems to be >caused by numerous requests made by my system to the BTS at regular >intervals. The BTS web pages are NOT designed to be abused like that. We've had cases where a single IP drove the load average of spohr over 80 and basicly shut down all bug processing for hours. As most of the obvious cases where many requests are being made to the BTS web look like spammers harvesting email addresses, I've been blocking systems from accessing the BTS more lately. If you need to access the BTS data from a program, there is an LDAP interface available and a copy of entire BTS database on one of the developer accessable machines. >Is there something I can do for getting my address unlisted (apart >from again reducing the load I put on b.d.o...which I did again down >to the lowest acceptable refresh rate on my side)? [EMAIL PROTECTED] is the proper place to send your request. If you can't use one of the program intfaces listed above for some reason, put a 5 second sleep between the completion of one request and sending the next. That spreads the load out and gives others a chance to access the BTS. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default? "Thu, 3 Nov 2005 23:16:43 -0500")
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >> session optional pam_tmpdir.so >Another potential problem is if a run a suid (non-root) program that >attempts to create a file in $TMP. But it's suid, so it doesn't run >under my uid, and doesn't have permissions to write to $TMP. But I've >never run across that -- suid programs are pretty uncommon. Some buildds use sudo rather than fakeroot. This could cause problems for them... (like the /dev/null one being discussed on #debian-devel) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iso2mirror
In article <[EMAIL PROTECTED]> you write: >On 11/3/05, Blars Blarson <[EMAIL PROTECTED]> wrote: > >> I submitted a patch to apt-move to do this to the Debian BTS. > >Does it also provide the "symbolic links only" functionality the >parent poster mentioned? No. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iso2mirror
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >Some time ago I searched for a tool to convert my already downloaded and >mounted stable Debian CDs into a mirror structure. However I failed (the >ways was able to find didn't seem feasible or couldn't find the actual >way, please tell me if something along the same lines exists). I submitted a patch to apt-move to do this to the Debian BTS. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tools for rebuilding after buildd
When I mentioned that I was rebuilding things on my sparc pbuilder after they failed on a sparc buildd, there was some interest before I pointed out how manual my process was at that time. Since then I've mostly automated it, so I just have to check out the list of packages that failed and failed or failed and succeeded. If there is interest, I can do some rough documentation and cleanup. I don't think it's worth putting in the Debian archives. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder help (bug 334877)
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: > >I'm trying to solve bug 304932/334877. > >I can reproduce the build failure using pbuilder, but not when I build >on my own system directly. > >I would like to do the pbuilder build and then examine the failing >filesystem, but pbuilder always deletes the build directory, and the >manual gives no clear indication of how to prevent this. --debug says >that it only avoids cleanup in update and create. Use: pbuilder login sed -i~ -e 's/#//g' /etc/apt/sources.list cd /tmp/build apt-get build-dep $package apt-get source $package cd $package-ver dpkg-buildpackage -us -uc -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Spam on the BTS (was: Spam on this list)
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >Blars Blarson <[EMAIL PROTECTED]> wrote: >> In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >>>I have also noticed tickets submitted to the bug facility that are >>>spam. Can that facility be configured so that if the format (package >>>name, version, etc) is not followed; the bug will not be emailed out >>>to the lists? >> >> I've been working on the spam filtering for the BTS. We are getting >> over 100,000 spams/day and about 50/day get through the filters. > >Do you tried bogofilter No > or the like? Depends how like you consider spamassassin's bayes filters, which are used. >> Would it be acceptable to reject or drop more non-spam? > >Drop not, but reject. It would be the best, if you can reject spam in >the SMTP dialog. This would take cooperation from debian-admin. >> Would it be acceptable to delay questionable messages for a human to >> review? > >How many message would be this? Is a spam team needed? I'm already doing the reviewing, but after the messages get to the bugs. My guess is reviewing a few hundred messages/day, with a dozen or two being non-spam. The point to set could be tuned. Mainly I'd need help when I'm unavailable, but the other BTS admins would probably be willing, or this could be turned off for a few days at a time. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Spam on the BTS
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >Blars Blarson wrote: >> I've been working on the spam filtering for the BTS. We are getting >> over 100,000 spams/day and about 50/day get through the filters. > >are these numbers available somewhere? (the spam/day ratio for example) >it would be interesting to graph the data. Not easily. There are tons of spam archives on spohr, as well as the spam I deleted archives. The latter includes historical spam recently deleted. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Spam on the BTS
On Sat, Sep 03, 2005 at 06:59:44PM +0200, Florian Weimer wrote: > CBL has the advantage that you can make a local copy of the list > (which reduces name server load and avoids the name lookup latency), > but its license is somewhat non-free. Is this a problem for Debian? spohr is already running a nameserver, so it would have to run on an alternate port. I havn't looked into how hard it would be to convice spamassassin to use something like this. > What's causing most of the load right now? I think some of the effort > should probably concentrate on getting legitimate mail through faster. spamscan is single-threaded, and the latency of DNSBL lookups is the main delay. We have less than 1 second to process each message on average. Any good recomendations for a perl inter-process communications library? Once it becomes multi-threaded CPU usage could become an issue, especially if we upgrade to spamassassin 3. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Spam on the BTS (was: Spam on this list)
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >> Would it be acceptable to reject or drop more non-spam? (We could >I am uncomfortable with dropping any mail, but I encourage a sensible >policy to reject spam. Sorry if I did not make it clear before, we already are dumping 100,000 messages/day into files noone ever looks at other than in unusual situations. (If someone reports having a problem getting a message through to [EMAIL PROTECTED], I do grep through them. This happens a few times a year.) The only thing being discussed is how aggressive the spam filters are tuned, not if we do it or not. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Spam on this list
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >On Thu, Sep 01, 2005 at 09:03:26PM +0200, Nico Golde wrote: >> What about using the msgid instead of the id so it would be >> possible to use your MUA to mark a mail as spam via a script >> which can be executed and calls the spam-report.pl script >> just like sa-learn or something like this? >> So it would be possible to mark mails as spam without going >> to the website of the archive. > >What happens if someone fakes a message-id? The reports need to be verified anyway, so I fail to see the problem. Either: the message ID exists and is unique (normal case) the message ID does not exist (bogus/malformed report) the message ID exists and is not unique (chances are some if not all are spam) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Spam on the BTS (was: Spam on this list)
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >I have been noticing (and a bit irritated) at the spam I am seeing >on this and some other email lists. Others have commented on this, I have little to add to this part. >I have also noticed tickets submitted to the bug facility that are >spam. Can that facility be configured so that if the format (package >name, version, etc) is not followed; the bug will not be emailed out >to the lists? I've been working on the spam filtering for the BTS. We are getting over 100,000 spams/day and about 50/day get through the filters. (Both are rough estimates, and the spam volume is continuing to rise.) There are limitations on what we can do with the resouces available. Would it be acceptable to reject or drop more non-spam? (We could reject on CBL, getting rid of about half the spam and rejecting about one non-spam per day. CBL is easy to get off of.) Would it be acceptable to delay questionable messages for a human to review? (Due to spam bursts, sometimes the BTS already takes 6 hours or more to processes the message queue.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Closing bugs in BTS
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >In recent announce about changes in BTS (Subject: BTS version tracking >Date: Mon, 18 Jul 2005 12:06:29 +0100) is described how to use new >versioning system. I'm not sure if sending mail to [EMAIL PROTECTED] is >now prefered way to closing bug rather than closing it in Changelog ? If the bug is fixed by an upload, close it in the changelog. If the bug is fixed some other way, or the change has already been uploaded, use the nnn-done address with a version pseudo-header. >(I conclude that it is not possible to close bug for specific version, >in testing, unstable and allow to remain opened in stable closing via >Changelog, am I right ?). Closing it in the changelog will mark it fixed in that version. >Moreover I wonder if when closing via mail should I write in Changelog >sth like: this upload fixes bug number 1234567 in testing and >unstable which has been closed via mail, and add tag sarge to bug that >remain opened in &dist=3Dstable ? No, use the found and notfound BTS commands to mark what package version the bug applies to if needed. You can even keep track of bugs fixed in multiple versions. (Mainly for release-critical bugs fixed by security/proposed updates.) >Next issue I wanted to discuss is information on the page generated by >BTS. The bug by default applies from the version reported until the version it is fixed in. >Thanks in advance for answering my mail and sorry for taking Your time >if I really omitted some part of documentation or so ! The version tracking stuff is new and may still have a few rough edges. It is documented on http://www.debian.org/Bugs/ -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: vancouver revisited
In article <[EMAIL PROTECTED]> you write: >The problem is not requiring a redundant buildd, the problem is >the arbitrary limit on the amount of 'buildd machines' of 2. Sparc currently has only one working buildd, which is having trouble keeping up. At least one offer of an additional buildd was turned down. Offers of additional machines have been made as well, and an "forklift" upgrade of the existing buildd is pending agreement of debian-admin and the local admin. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
In article <[EMAIL PROTECTED]> you write: >Hmmm, IIRC I was among these ones and the reasons was the CBL listing >all dynamic and non dynamic addresses from Free, one of the 2-3 major >ISPs for DSL in France. I think you are confusing CBL with another DNSbl. CBL only lists addresses that spam thier spamtraps, and removes listings automaticly after several days. They attempt not to list mail servers. To be removed immediatly, just fill out their web form with the IP address to be removed. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >Now that we have released sarge, I would like to ask debian-admin and >the Project Leader to consider seriously doing something to reduce the >level of spam we have to receive, store, and filter in our @debian.org >addresses. I recomed using spamhaus SBL-XBL, or at least CBL (which is included in SBL-XBL). When I did some checking earlier this year, CBL would reject about half of the spam to the Debian BTS, with about one false positive a day. That's around 5 rejected spam and one rejected non-spam per day. Many of the false positives were from the same people, who could have removed their CBL listing easily. (If they didn't fix the problem that caused the CBL listing first they would get listed again.) Note that it does not make sense to do it only on the server, any backup MX servers need to filter at least as well. (Some spammers only send to backup MX servers.) See http://www.spamhaus.org/ and http://cbl.abuseat.org/ for more information on the lists. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package building problems (was Re: Canonical and Debian)
On Thu, Jun 09, 2005 at 12:00:54AM +0200, Kurt Roeckx wrote: > What do you mean with the "not-for-us" errors? I think what > you're refering too is that quinn-diff tells you to build > packages you really shouldn't. I filed a bug with a patch that > works for me: > http://bugs.debian.org/275835 I mean the buildds spend time trying to build packages that they are not on the architecture list for. There is also the case of packages that have internal architecture checks, but that varies enough that I don't think detecting it can be automated. (In those cases the package maintainer should fix the architecutes line.) I don't know the internals of the buildd process, but it appears your patch would fix the problem. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd machines (was Re: Canonical and Debian)
In article <[EMAIL PROTECTED]> you write: >On Tue, Jun 07, 2005 at 06:13:10AM -0700, Blars Blarson wrote: >> In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] = >writes: >> >- sparc: one buildd which is not consistently able to keep up with the >> > volume of incoming packages; no backup buildd, no additional porter >> > machine. > >> Second faster machine has been down, reportedly with disk problems. > >Hardware flaw. (RAID array can only be reinitialized from Solaris.) Admin flaw in not being able to do that. Alternate replace with storage that does not have that problem. I'm willing to donate a 50-gig drive with spud braket that should fit internally. >> Even faster replacement machine (with more redunancy) has been >> offered. Apparently waiting coordination between doner (who is a DD) >> and Debian System Admin team. > >The offer in question is to take us down to *zero* build machines, and then, >if everything goes right, replace it with an SMP system that would pass for >two. The only reason I've heard of for that is space at the hosting facility. Have they even been asked if they would be willing to continue to host vore (an ultra-30, PC tower size) either temporarily while the new machine is set up or permentantly? >> Offers of an addional buildd have been refused. Offers of addional >> hardware have been ignored or refused. > >Refused, or not acknowledged? If they were refused, what reason was given? The initial responce to my offer of a buildd with me acting as maintainer was apparently refused by my spam filters. When given an address that would bypass the filter, the buildd maintainer refused to send the message even when asked to do so politly by the Debian Project Leader. So, if you want a reaon for the refusal you'll have to ask him yourself. I made more offers to the hardware-donations page today. I wasn't specific on the sparc stuff, but hopefully they'll let me know what kind of stuff is being looked for, if any. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package building problems (was Re: Canonical and Debian)
On Tue, Jun 07, 2005 at 09:37:15PM -0400, Stephen Frost wrote: > * Blars Blarson ([EMAIL PROTECTED]) wrote: > > I've been watching the sparc buildd queues for the past 9 months or > > so, filing most of the ftbfs bugs for sparc, and prodding the buildd > > maintainer when a package needs a simple build requeue or the sbuild > > chroot is broken. > > Great! What mechanisms have you been using to do that, and what could > we do to make it easier for other people to do that? Is there a way to > get the sparc buildd queues and associated information to be more > pro-actively sent to people? I know that, at least for myself, I'm much > more inclined to do things or at least try to help with things when an > email about a problem shows up in my email client than if I have to > periodically check a website, etc. I've been planning on automating more of what I'm doing, but it is done after a mirror pusle: Update build machine (to get current unstable source package file). pbuilder update Check http://buildd.debian.org/stats/?arche=sparc&state=Building Look for packages that have been in state "building" for more than 40 hours. apt-get -d source $PACKAGE pbuilder build --binary-arch $PACKAGE_$VERSION.dsc $LOG 2>&1 (two at a time, since I've got a dual-processor box) Check pbuilder build log. If it isn't an obvious build-dependancy or not-for-us error, check packages.qa.debian.org for already filed bugs and compare the buildd's build log to mine. File bugs and mail the buildd maintainer as needed. dep-wait and obvious ftbfs issues are most common. Sometimes sbuild finds a package error pbuilder doesn't. Occasionally an sbuild chroot is broken. Sometimes packages build on my pbuilder because it has more up-to-date packages. (The package needed versioned build dependancies.) All of the first paragraph could be automated, including local dep-wait and not-for-us. > > >4) buildd software issues(pbuild,sbuild,wanna-build,etc) > > It looks like this software could use some redesign to put less work > > on the buildd maintainers and scale better to more buildds. > Do you have some specific insights into this? This certainly sounds > like a good area for us to work on.. Almost all of the dep-wait and many of the not-for-us errors could be detected by the software. wanna-build could probably be turned into a distributed process if it can't be handled on a single box, as could buildd logs. I'm not sure how the buildd maintainer interface works now, but it may be able to be improved. (Based mainly on the reluctance of some buildd maintainers to use existing features.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
package building problems (was Re: Canonical and Debian)
I've been watching the sparc buildd queues for the past 9 months or so, filing most of the ftbfs bugs for sparc, and prodding the buildd maintainer when a package needs a simple build requeue or the sbuild chroot is broken. In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >IIUC, this is a summary: >make source, build package, upload i386 deb to incomming, tell wanna-build,= > [build >on buildd, upload non-i386 deb to incomming] repeat for all archs >Is the issue:=20 >1) buildd availability (network or amount) sometimes >2) buildd admin responcivness, sometimes. The buildd maintainer needs to manually put packages in dep-wait or requeue the build when the problem is a build dependency issue. >3) arch-specific issues that cause build problems for non-i386 not getting = >fixed? sometimes >(would that be the 'porters' job?) Depends on the cause. In the most common case of broken packages, it is primarily the package maintainer's job, but the porters should be willing to help. >4) buildd software issues(pbuild,sbuild,wanna-build,etc) occasionally. sbuild is vulnerable to broken packages breaking it's chroot, sometimes in ways that only effect a few packages and may not be quickly noticed. wanna-build has scalability issues, but it can be bypassed for unstable if the buildd maintainer doesn't interfere. (Just build and upload all the new packages.) It looks like this software could use some redesign to put less work on the buildd maintainers and scale better to more buildds. >5) something else? occasional. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Vancouver prpopsal (was Re: Canonical and Debian)
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >[Josselin Mouette] >> However that won't help the architecture make it to a Vancouver-like >> release. > >I suspect you have misunderstood the content and intention of the >proposal from the group meeting in Vancover. The intent was not at all that clear. The content made it quite clear that under those rules many architectures could not ever be in any future stable release of Debian. No amount of work by the porting team could ever get the situation changed without active support of people who are either apithetic about the architecture or activly hostile to it. The proposal gives veto power over getting an architecture in Debian to dozens of people, and all they need do to exersize it is to not fix a non-release-critical bug. In addtion, the DSA, buildd, security, and release teams all have veto power. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
buildd machines (was Re: Canonical and Debian)
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >- sparc: one buildd which is not consistently able to keep up with the > volume of incoming packages; no backup buildd, no additional porter > machine. Second faster machine has been down, reportedly with disk problems. Even faster replacement machine (with more redunancy) has been offered. Apparently waiting coordination between doner (who is a DD) and Debian System Admin team. Offers of an addional buildd have been refused. Offers of addional hardware have been ignored or refused. Binary uploads of packages by a Debian developer trying to help the situation have been strongly discouraged. (Puting it mildly.) Exactly what can an ordinary Debian Developer do to fix this situation? How is it fair to blame the porters when the DSA and buildd teams refuse offers of help? -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: successful sparc buildd log, but no upload after 11 days
In article <[EMAIL PROTECTED]> you write: >Ren=E9 van Bevern wrote: >> One of my packages (ncmpc) is kept out of testing because of a missing >> build for sparc (it is unblocked). Looking at the buildd log for sparc >> [1], the package seems to have built successfully on April 25th 2005. >> Unfortunately, there has been no upload until now. I have contacted >> [EMAIL PROTECTED] but have still no reply. Is there anything >> else I could do? > >Well be assured you're not alone; several packages being tracked by the >release team are blocked due to missing sparc uploads. > >However, I don't know what to do about it, except hope the buildd >maintainers check their email eventually, and wish there was a place in >the BTS for these things.. I'm able to build the packages on my sparc pbuilder, but the sparc buildd maintainer insisted I don't upload them. As a normal DD, I'm not fighting this issue further without the backing of either the technical committee (which refused to rule) or the DPL (the previous one eventually sided with the buildd maintainer). -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gluck (cvs, people, planet, etc.) downtime - ongoing raid problems
>Name Server:SAENS.DEBIAN.ORG >Name Server:KLECKER.DEBIAN.ORG >Name Server:SPOHR.DEBIAN.ORG spohr changed IP addresses last week, and the glue record returned by the .org nameservers still had the old address when I checked a few hours ago. This has been reported to debian-admin. (The new address is 140.211.166.43) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible compromise on releasing architectures
On Thu, Mar 24, 2005 at 10:12:35AM +0100, Jan Niehusmann wrote: > On Thu, Mar 24, 2005 at 12:59:19AM -0800, Blars Blarson wrote: > > Release candidate architecture: > > > > * testing managed by port release manager(s) > > * testing consists of packages that built on the candidate and > > are in release architecture testing with the same version > > Please specify what applies to sources and what to binaries. As I > understand your proposal, one would need architecture specific source > repositories (as different architectures may have different versions > in testing). My proposale included "same version". Testing will have the same version if any on all architectures. Testing may be broken by missing packages on the candidate. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Possible compromise on releasing architectures
The Vancouver meeting concluded that more of the burden of supporting the various architectures needs to be on the port teams, but did not supply a workable way for releases to be made on less popular architectures. Here's a proposal that will hopefully both meet the main desires of the release managers and the port teams. Release architecture: * All FTBFS and architecture specific bugs are release critical * packages must be built on all to propagate to testing Release candidate architecture: * testing managed by port release manager(s) * testing consists of packages that built on the candidate and are in release architecture testing with the same version * testing proposed updates may be needed more often due to changes in dependencies * need a way to propagate architecture specific packages (such as boot loaders) to testing * FTBFS and other architecture specific bugs are release critical if a reasonable[0] patch is in the BTS * Will release if testing is in good shape at release time, or at point release time * stable security team may decide not to provide security support Non-release architecture: * no testing, unstable only [0] When there is a difference on what is reasonable, the technical committee will decide. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>On 17-Mar-05, 01:01 (CST), Joel Aelwyn <[EMAIL PROTECTED]> wrote:
>> * The ability for an interface to receive, by default, only traffic that
>> is destined for that interface. (Non-promiscuous mode; promiscuous mode
>> availability is a big plus, but not required from the OS point of view)
>
>Linux fails this. Even with forwarding disabled, it will accept packets
>for an address on interface A via interface B.
Enable rp_filter and it does reject such packets.
echo 1 >/proc/sys/net/ipv4/conf/${dev}/rp_filter
--
Blars Blarson [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Buildd redundancy (was Re: Bits (Nybbles?) from the Vancouver...)
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >- the release architecture must have N+1 buildds where N is the number > required to keep up with the volume of uploaded packages If we are going to require redundancy, I think we should do it better and add: - at least two buildd administrators - systems located in at least two different facilities (different cities and backbones if at all possible) This allows the buildd administrator to take vacations, etc. This allows for redundancy in case of fire, flood, earthquake etc. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >> According to db.d.o: > >The complete URL is http://db.debian.org/machines.cgi just for >reference. > >> - auric: RAID is dead (and auric is basically demilitarized since the >>compromise -- not even running a buildd, although I'm not sure >>about that) > >As I understand it, the plan was to convert auric into a buildd but >the RAID needs to be fixed. auric has been a buildd on and off. Apparently it's off again. From what I understand the raid needs solaris to configure, it might be better to switch to conventional disks with software raid since this seems to be a reliability issue. I've also offered a machine I have to run as a sparc buildd, hosting and maintaining it myself. >Ben Collins was looking into this but I >don't know about the status. I've also heard discussions several >months ago about using one of Ben's really fast machines. >If we do need auric and if we need resources to fix the RAID, Debian >can make funding available. > >> - kubrick: disk is dead I've also volenteered disks if needed. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
In article <[EMAIL PROTECTED]> you write: >I have an e3500 to replace both auric and vore (and the raid), but I >haven't gotten an ok from James to do so yet. That would cut the number of sparc buildds down to one, when two are required for RC archtectures under the new proposal. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: s390 not currently projected releasable (was: Re: Dropping from mirror network vs dropping from tier-1)
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >Bastian Blank <[EMAIL PROTECTED]> writes: >Why don't you start building packages yourselves? You do have access >to the hardware, right? It's supposed to be blindingly fast, right? Another architecure that isn't keeping up to the 98% mark has a buildd mainainter who insists (to the point of threating) that I don't build and upload packages to help the build with its backlog and lack of requeueing. As far as I can tell, only the 98% mark and the second buildd being down are keeping this arcitecture in the release architecture list. (I also volenteered my own machine as a buildd, but that was refused.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Restrictive SMTP server
In article <[EMAIL PROTECTED]> you write: >The fact is that I am unable to send emails with my debian.org address. >Does someone has some idea of how can I fix that? ssh to people.debian.org and send the mail from there. (use mutt, mailx, etc.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the ongoing xfree86 buildd saga
In article <[EMAIL PROTECTED]> you write: >On Wed, Feb 23, 2005 at 09:17:59PM +0100, Adeodato Simó wrote: >> * Thomas Bushnell BSG [Wed, 23 Feb 2005 12:13:42 -0800]: >> > Do the buildd people read this list? How do we get this cleaned up? >> That's not relevant, really. What matters is if they read their logs, >> and they certainly do. >Indeed. The logs you see on buildd.debian.org arrive there by mail; they >are also sent to the buildd admin, because every build requires some >manual action to be performed (signing the .changes file for a >successful build, telling the autobuilder what to do with an >unsuccessful build). At least one buildd maintainer signs successfull builds but apparnetly ignores failed ones. After random intervals (usually several months) all failed builds are requeued whether they should be or not. Requesting a specific requeue works with a week or two delay at times. I've been filing most of the ftbfs bugs for that architecture. You may wish to see my question to the tecnical committe on this matter. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >> > > Machines don't have IP numbers. Interfaces have IP numbers. Every >> > > machine >> > >> > Actually, that's not quite the case (as a number of users of Linux's ARP >> > implementation have found), though it's a good approximation. >This portion is unclear to me; could you shed some light ? > >Do you mean: [wrong guesses omitted] A machine may use the same IP on multiple interfaces. A machine may use multiple IP addresses on a single interface. The two may be combined. A router may use proxy arp. A machine may use the same ethernet address on multiple interfaces on different physical networks. This tends not to work well with vlans. (switches pretending to be multiple networks) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LCC and blobs
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >How does moving firmware from the disk to the hardware (therefore making >it harder to modify and more expensive) further the cause of free >software? It makes it covered by the hardware manufacturers warentee. If it is faulty, you can return it for repair or refund. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature.
Re: about volatile.d.o/n
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: > >--gKMricLos+KVdGMg >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >also sprach Andreas Barth <[EMAIL PROTECTED]> [2004.10.08.2051 +0200]: >> Well, I would start small (and this means to exclude whois), and >> revisit policy after some time to see what we should add or remove >> to it. And, furthermore, why not do the next release of whois in >> a way that it's possible to dynamically only update the zones >> (quite similar to the virus scanners definitions), perhaps >> downloading from some debian site once a month? > >There is some network tool in the archive that does something >similar. The name evades me right now... it asks with debconf how >often to download, kinda like a news client. hinfo optionally periodicly updates a couple of files using wget. Never, once, weekly and monthy are the current options. (Daily would be easy to add, but I considered it inappropriate for how often the hinfo data changes.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature.
Re: Some observations regardig the progress towards Debian 3.1
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >Given a person with the hardware and time I'm certain support can be >added in a single day. The big problem is getting access to the >hardware directly or indirectly through a tester. Given that I've spend about 20 hours trying to get debian-installer working on sparc, and havn't yet tried to boot it, I'm sure you are wrong. (Three bugs reported and fixed already, one that still needs to be filed.) >And don't tell me use debians machines unless you are able to provide >accounts for sveral non DD d-i developers (which needs sudo for >additional build-depends needed for that arch). As far as I can tell, there are three people who have done any attempt at getting d-i workin on sparc. None of them is lacking the needed hardware. If hardware was all that was needed, I could have not given away some of what I've given away, or picked up slightly better machines for not much money. I may be given a few in the near future. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature.
Re: [debian-devel] Re: which policy checker?
In article <[EMAIL PROTECTED]> you write: >Try reading upgrading-checklist.txt. Where do I get a copy of this document? A summery of what to check for when updating a package would be very useful. (I've just agreed to take over a few more packages, two which havn't been updated since woody.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature.
get together at torcon3? Toronto, Aug 28-Sep 1
I'm going to the World Science Fiction Convention, torcon3, (http://www.torcon3.on.ca) in Toronto, Onterio, Canada at the end of the month. Is there any interest in a get-togther there or nearby? [Is there a better place for these requests? As someone on the NM queue, I don't have access to -private.] -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html "Text is a way we cheat time." -- Patrick Nielsen Hayden
Re: setgid crontab
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >On Sat, Aug 02, 2003 at 02:51:03PM -0500, Steve Greenland wrote: >Under this setup, when cron opens a crontab file, it should fstat() it and >check that it is owned by the uid under which its contents will be executed >before trusting it. It should not trust symbolic links either. Otherwise it instanly promotes everything that looks like a crontab into one. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html "Text is a way we cheat time." -- Patrick Nielsen Hayden
Re: the RFC mess: tentative summary
Does it seem ironic to others that documents titled "Request for Comments" can't be quoted while making comments on them? (This is a flame of the current IETF, which has goals contrary to the people who originally designed the Internet.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html "Text is a way we cheat time." -- Patrick Nielsen Hayden
Re: Every spam is sacred
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >On Sun, Jun 15, 2003 at 11:45:17AM -0500, Steve Langasek wrote: >If some number of Debian developers utilizing blocking that has a >false positive rate of as high as 2 per day by some estimates, do we >as a body consider it acceptable if some percentage of Debian >developers: Alternativly, if Debian dosn't implement spam blocking, do we consider it acceptable that: Some developers stop reading any email, since the vast majority of it is spam. Developers delete messages unread because of spammy sounding subjects. Developers spend so much time reading spam they don't have time to fix bugs and do other useful work. People advocating not filtering spam based on some false positives seem to forget that being burried under the load of spam can cause more false postitives by the human forced to do the filtering. On my personal mailbox, I use some rather aggrasive lists that I wouldn't recomend to Debian at this time. (relays.osirusoft.com, which includes SPEWS and SBL, and block.blars.org that I run myself and don't recomend to others.) It still gets ten times as much spam as non-spam. Without the spam filters, I'd probably wind up not reading email at all. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html "Text is a way we cheat time." -- Patrick Nielsen Hayden
Re: Daft Internet Stuff [Re: Returning from "vacation". (MIA?)]
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >It's very rare for me to have a HTML email that I actually want to read, I >probably should configure my mail server to reject them all. I have sendmail rules to do that. I may go back to rejecting multipart/alternative mail as well. (sendmail.mc changes available on request.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html "Text is a way we cheat time." -- Patrick Nielsen Hayden
Re: /run and read-only /etc
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >I won't debate whether this is true in general, bug it is certainly >unnecessary in the case of pump. I have specifically added code to >deal with the inability to write to /var/run by making pump fall back >to using TCP sockets. It will also need to cope with writing to /var/run on the root partition, having /var mounted, and later processes not being able to open the file since the /var/run directory on the root disk is inaccessable. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html "Text is a way we cheat time." -- Patrick Nielsen Hayden
Re: When bind9 reinstalls, no db.root
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >because there is no compelling reason >to keep db.root a configuration file But there IS a compelling reason to keep db.root a configuration file: alternic I don't use them, but debian shouldn't trash files that a sysadmin needs to change to use them just because they arn't recomended. (See http://www.alternic.org/ for info on alternic. While I have my problems with the way icann runs the DNS, alternic doesn't show signs of being run better, just differently.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html "Text is a way we cheat time." -- Patrick Nielsen Hayden
Spamassassin config files in /usr/share
The spamassasin maintainer doesn't think that there are settings in /usr/share that can't be overridden by the settings in /etc should be considered "serious". See bug #141125 and spamassassin bug #188. Currently, I edit the file in /usr/share to implement my site-wide policies, but this will be overridden every time spamassassin is upgraded. Why shouldn't this be considered a violation of policy 11.7.1? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
