Bug#479472: heartbeat(8) documents a binary which is not shipped in PATH
Package: heartbeat-2 Version: 2.0.7-2 Hi, There's a manual page for heartbeat in section 8 (system management commands), but there is no command called like that in the package. The binary appears to be shipped in /usr/lib/heartbeat/heartbeat, but it should be in /usr/sbin or somewhere else in PATH. Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478916: gtkpool: GTK Pool does not have a GNOME menu entry; this fixes that
On Thu, May 01, 2008 at 01:35:05PM -0400, Daniel Dickinson wrote: Package: gtkpool Version: 0.5.0-7 Severity: wishlist Tags: patch There is no .desktop file under /usr/share/applications and therefore no applications menu entry for GNOME or other freedesktop.org compliant window managers. I have attached a .desktop file you can use. Er, doesn't GNOME co. use the Debian menu entries? The file you sent in looks awfully like /usr/share/menu/gtkpool. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425137: nagios plugin issues that I reported
Is anyone planning to fix the plugin issues that I submitted a year ago in #425129 and #425137, and more recently in #467493? I've included the (pretty obvious) fixes with all of them, but it's been a while with no action, and I'd hate to see it the same silly errors remain in lenny... Do you guys need any help with the package, such as another uploader? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477220: Proposing NMU for feature enhancements
On Mon, Apr 21, 2008 at 10:49:02PM +0200, Frank Lichtenheld wrote: Package: dupload Version: 2.6.3.3 Severity: normal Tags: patch I've prepared a new upload for dupload with some fixes and support for the new checksums-* fields. Please comment whether you approve the upload. (May I also suggest that I add my names to Uploaders, given that would be my third consecutive upload of this package?) Oh, most certainly, I actually thought that you did that already. :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422347: [pkg-ntp-maintainers] Bug#422347: Bug#422347: can't get ntpq without ntpd
On Thu, Apr 24, 2008 at 08:44:55PM +0200, Peter Eisentraut wrote: Josip Rodin wrote: I don't find your lack of understanding of my original report relevant, then? What part of not having excess daemons by default don't you understand? The part I asked you about: Why don't you disable that the ntpd daemon starts? Surely you don't mind that the binary is installed. So just arrange that it is not started at boot. I don't like that, because it requires extra intervention, where no such intervention was necessary in oldstable, and it really should not be necessary, because it's really a BCP to separate server and client software in different packages. Obviously the case for separation is stronger for obvious applications such as DNS clients and servers, SMTP clients and servers, HTTP clients and servers, ... but I see no reason why to switch to a different model for NTP clients and servers. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422347: [pkg-ntp-maintainers] Bug#422347: Bug#422347: can't get ntpq without ntpd
On Thu, Apr 24, 2008 at 10:58:37AM +0200, Peter Eisentraut wrote: Am Mittwoch, 23. April 2008 schrieb Josip Rodin: Why don't you just turn off the starting of ntpd? Because of the reasons stated in the original report. Sorry, I don't find a relevant reason in the original report. I understand you only want to use the client tools, but I don't see why you couldn't just turn off the server then. I don't find your lack of understanding of my original report relevant, then? What part of not having excess daemons by default don't you understand? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422347: [pkg-ntp-maintainers] Bug#422347: Bug#422347: can't get ntpq without ntpd
On Mon, Apr 21, 2008 at 05:00:12PM +0200, Peter Eisentraut wrote: Am Donnerstag, 3. April 2008 schrieb Josip Rodin: Er, ntpdc isn't the NTP server, it's a query program for the separate server program called ntpd. It's customary to refer to these as clients. But regardless, I really don't care much about the exact package name, just about the restoration of old functionality. Why don't you just turn off the starting of ntpd? Because of the reasons stated in the original report. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445360: rxvt+mutt crash - solved?
On Sun, Apr 20, 2008 at 08:48:20PM +0200, Jan Christoph Nordholz wrote: Hi Josip, Okay, I would be happy to try and narrow it down some more - just give me more hints where to look... what would be next - terminfo? locales? good news: I think I've found it. Could you please verify that this update[1] fixes the bug? [1]: http://www-pool.math.tu-berlin.de/~hesso/deb/rxvt_2.6.4-14.dsc It's fixed. Thanks! (What was it? There is no description.) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476193: ntpdc times out when the server monlist has over 600 clients
Package: ntp
Tags: upstream
Hi,
I've been getting inexplicable errors from 'ntpdc -c monl hostname':
hostname: timed out with incomplete data
They didn't appear to make any sense, because tcpdump was showing that
traffic was flowing, and then the program just decided to give up.
Running with -d shows:
Received sequence numbers 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,
34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52,
53, 54, 55, 56, 57, 58, last frame not received
The numbers varied between 57 and 94.
After numerous repeats, ocasionally I would get the actual monlist,
and it contained = 600 hosts.
Apparently the people at support.ntp.org have it documented:
http://support.ntp.org/bin/view/Support/MonitoringAndControllingNTP#Who_is_using_my_NTP_server
| Please note that a maximum of 600 entries is supported with current
| versions of ntpdc. The protocol (or better: the contents of the return
| packets) used by ntpdc is not standardized, therefore it is recommended
| to only use ntpdc with a matching ntpd, i.e. both should have the same
| version number.
|
| To get by this 600 entry limitation, many server operators run client
| statistics scripts [...]
I went to look at the code, and it looks like ntpdc/ntpdc.c is printing the
contents of the haveseq array, whose size is MAXSEQ+1, which would be 128,
so that doesn't sound like. At the other end,
ntpd/ntp_request.c:mon_getlist_0() is sending over all of the mon_data
structures found in mon_mru_list, and after looking at that, I see the
culprit in ntpd/ntp_monitor.c:
/*
* Limits on the number of structures allocated. This limit is picked
* with the illicit knowlege that we can only return somewhat less
* than 8K bytes in a mode 7 response packet, and that each structure
* will require about 20 bytes of space in the response.
*
* ... I don't believe the above is true anymore ... jdg
*/
#ifndef MAXMONMEM
#define MAXMONMEM 600 /* we allocate up to 600 structures */
#endif
[...]
int
ntp_monitor(
[...]
if (mon_free == NULL mon_total_mem = MAXMONMEM) {
[...]
I can't help but think that there are better ways to handle this in
both ntpd and ntpdc. :)
Please fix this. TIA.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476193: ntpdc times out when the server monlist has over 600 clients
On Tue, Apr 15, 2008 at 02:44:25AM +0200, Josip Rodin wrote: I see the culprit in ntpd/ntp_monitor.c: /* * Limits on the number of structures allocated. This limit is picked * with the illicit knowlege that we can only return somewhat less * than 8K bytes in a mode 7 response packet, and that each structure * will require about 20 bytes of space in the response. * * ... I don't believe the above is true anymore ... jdg */ #ifndef MAXMONMEM #define MAXMONMEM 600 /* we allocate up to 600 structures */ #endif http://ntp.bkbits.net:8080/ntp-stable/ntpd/ntp_monitor.c?PAGE=annoREV=4501fb5ciab3mg65AEoxeovMbL3KMg and http://ntp.bkbits.net:8080/ntp-stable/ntpd/ntp_monitor.c?PAGE=history seem to indicate that this code is over 9 years old (older than the initial commit on 1999-05-25)... http://www.eecis.udel.edu/~ntp/ntp_spool/depredated/xntp2/xntp.tar.Z contains a copy where MAXMONMEM is 400, dated 1989-11-06. The difference between those two versions also includes this comment: + * trimmed back memory consumption ... jdg 8/94 Whoa. It looks like this code could use some help. I can't remember what could have been too much memory consumption in 1989/1994, but I'm pretty sure that we'd all just chuckle at those numbers these days. :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475922: RFP: sweethome3d -- interior design application with a 2D plan and 3D preview
Package: wnpp Severity: wishlist Sweet Home 3D is a nice interior design application that I've seen used under Windows :) but as it runs under Linux, too, it would be nice if someone would package it. Upstream URL: http://sweethome3d.sourceforge.net/ Version: 1.2.1 Programming language: Java License: main program - GNU General Public License (version 2) bundled third-party add-ons, which could well be made optional or deps: * furniture catalogs - Free Art License (version 1.2) * itext-2.0.4.jar - GNU Lesser General Public License (version 3) * JRE version 6 - Sun Microsystems, Inc. Binary Code License Agreement * Java 3D libraries - Java Distribution License (version 1.0) * Loader3DS1_2.jar - GNU Lesser General Public License (version 3) * Tango theme toolbar and menu icons - Creative Commons Attribution-ShareAlike (version 2.5) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445360: rxvt+mutt crash - new, smaller test case
On Fri, Apr 11, 2008 at 01:26:40PM +0200, Jan Christoph Nordholz wrote: Hi Josip, Ha, found it - it's just one setting: XTerm*termName: xterm-debian The first step to reproduce can be changed to: xrdb -remove xrdb -merge rxvt-bug.Xresources rxvt even with that resource setting I cannot reproduce it. And that's why I had tagged the bug 'unreproducible' - I never doubted that you can reproduce it, I just wanted to note that nobody else can... I was hoping that perhaps a few more affected users would join the report, maybe with slightly different environments which would have helped me narrow down the error precondition. Okay, I would be happy to try and narrow it down some more - just give me more hints where to look... what would be next - terminfo? locales? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445360: rxvt+mutt crash - new, smaller test case
On Thu, Jan 03, 2008 at 12:21:23PM +0100, Josip Rodin wrote: I've run into the bug again a few times, but most recently on a rather inconspicuous bit - just scrolling within one single message crashed rxvt. Because this message wasn't signed or anything, so not that many colors would be involved in the crash, I then also took a wild guess and reduced the .muttrc to just the ignore/unignore part, and that was the part that made the difference. With default etch mutt settings, it doesn't crash, with the attached muttrc, it does. I also obfuscated the text in the message to protect the guilty :) and to make it a bit more homogenous - and it still crashes on it. Steps to reproduce: * run rxvt * inside, run mutt -F rxvt-bug.muttrc -f rxvt-bug.mbox2 * press enter (show message) * press space (scroll one screen down) * poof Here's another clue - it doesn't crash when I run it with 'xrdb -remove'! I'll go dissect my .Xresources file now and report the offending setting (hopefully in a few minutes). -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475263: phpldapadmin stopped supporting sambaUnixIdPool, really uncleanly
Package: phpldapadmin Version: 0.9.8.3-8 Severity: serious Hi, The other day I was unpleasantly surprised that the setting: $ldapservers-SetValue($i,'auto_number','mechanism','uidpool'); the equivalent of which worked normally in sarge, doesn't actually work on etch, but is still part of the configuration file. /usr/share/phpldapadmin/lib/functions.php still describes the mechanism, but the code was apparently ripped out, uncleanly - the switch($mechanism) default case still references 'uidpool', but the case for it simply isn't there. I found this out after a routine check of home directories showed inconsistencies - old, deleted users' home directories started being owned by new users, which were created by phpldapadmin with the old UIDs. This is a privilege escalation (users being given access to data which doesn't belong to them), and never should have happened if phpldapadmin was still honoring my sambaUnixIdPool settings. A Google search shows that the feature may have been intentionally removed upstream. The package should have *at least* warned about this on upgrade. Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445360: rxvt+mutt crash - new, smaller test case
On Wed, Apr 09, 2008 at 09:51:51PM +0200, Josip Rodin wrote: On Thu, Jan 03, 2008 at 12:21:23PM +0100, Josip Rodin wrote: I've run into the bug again a few times, but most recently on a rather inconspicuous bit - just scrolling within one single message crashed rxvt. Because this message wasn't signed or anything, so not that many colors would be involved in the crash, I then also took a wild guess and reduced the .muttrc to just the ignore/unignore part, and that was the part that made the difference. With default etch mutt settings, it doesn't crash, with the attached muttrc, it does. I also obfuscated the text in the message to protect the guilty :) and to make it a bit more homogenous - and it still crashes on it. Steps to reproduce: * run rxvt * inside, run mutt -F rxvt-bug.muttrc -f rxvt-bug.mbox2 * press enter (show message) * press space (scroll one screen down) * poof Here's another clue - it doesn't crash when I run it with 'xrdb -remove'! I'll go dissect my .Xresources file now and report the offending setting (hopefully in a few minutes). Ha, found it - it's just one setting: XTerm*termName: xterm-debian The first step to reproduce can be changed to: xrdb -remove xrdb -merge rxvt-bug.Xresources rxvt -- 2. That which causes joy or happiness. XTerm*termName: xterm-debian
Bug#474108: samba domain controller disregarding 'valid users' settings
On Thu, Apr 03, 2008 at 02:00:13PM +0200, Josip Rodin wrote: Package: samba Version: 3.0.24-6etch9 Severity: important It appears that once you set a Samba server to be a primary domain controller that authenticates via a back-end LDAP server, it can no longer serve as a meaningful file server, because the 'valid users' setting simply doesn't work any more. It works on the normal Sambas which are set to use 'security = domain' with the Samba PDC, but not on the controller itself, for some reason. Now I'd have to edit the code, recompile and test it on a production PDC :/ I'll have to go reproduce it in a lab setting... I reproduced it separately, but it depended on the LDAP entries being the same, and that Samba saw them (i.e. that the SIDs matched). Without that (by accident I had a different SID prefix in the test installation), the 'valid users' list got parsed just as expected. I'll be fiddling with the source now... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474108: samba domain controller disregarding 'valid users' settings
On Mon, Apr 07, 2008 at 11:04:51PM +0200, Josip Rodin wrote: It appears that once you set a Samba server to be a primary domain controller that authenticates via a back-end LDAP server, it can no longer serve as a meaningful file server, because the 'valid users' setting simply doesn't work any more. I reproduced it separately, but it depended on the LDAP entries being the same, and that Samba saw them (i.e. that the SIDs matched). Without that (by accident I had a different SID prefix in the test installation), the 'valid users' list got parsed just as expected. I'll be fiddling with the source now... It looks like lp_valid_users(snum) is actually including my username, one which is decidedly *not* part of the 'valid users' setting for that share in smb.conf. Or at least that's what token_contains_name_in_list(...) thinks. I'll have to spend some more time unscrambling these ghastly list structures... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474108: samba domain controller disregarding 'valid users' settings
Package: samba Version: 3.0.24-6etch9 Severity: important Hi, It appears that once you set a Samba server to be a primary domain controller that authenticates via a back-end LDAP server, it can no longer serve as a meaningful file server, because the 'valid users' setting simply doesn't work any more. It works on the normal Sambas which are set to use 'security = domain' with the Samba PDC, but not on the controller itself, for some reason. This behaviour may not be a bug in itself (I don't have any idea about the motivation, I suppose it could be sensible), but it is not documented in the manual page or the HOWTO, and the code doesn't warn me that the 'valid users' setting was ignored intentionally (if it has). It allows for information disclosure (shares that are accessible to the wrong users, even though you set them not to be), so it's a security problem, really. But I've kept the bug at a non-RC severity because I'm unsure of the reasoning, and because this isn't a particularly common setup, I guess. I'm not sure what's happening there, really... the smbd/service.c:575 check succeeds where it shouldn't. Annoyingly enough, you have to up the general debug level to 10 to get anything useful out of smbd/share_access.c:user_ok_token(). Even then, it doesn't show anything much: [2008/04/03 13:42:09, 10] smbd/share_access.c:user_ok_token(229) user_ok_token: share nagios is ok for unix user joy [2008/04/03 13:42:09, 10] smbd/share_access.c:is_share_read_only_for_token(271) is_share_read_only_for_user: share nagios is read-only for unix user joy The else cases of the lp_invalid_users(snum), lp_valid_users(snum) and lp_onlyuser(snum) should have DEBUG(20, ...) messages, because this way I don't really know if it's those NULL comparisons which have failed, or if the problems were the token_contains_name_in_list() checks within them. Now I'd have to edit the code, recompile and test it on a production PDC :/ I'll have to go reproduce it in a lab setting... Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422347: can't get ntpq without ntpd
retitle 422347 ntp package lumps client software with the server (regression) thanks On Sat, May 05, 2007 at 12:04:59PM +0200, Josip Rodin wrote: I had the ntp package because I wanted the ntpq utility Now I found that I also have use for the the ntpdc utility on a machine where openntpd suffices as the server. In general, all this generic NTP client software that doesn't depend on a NTP server on localhost needs to be split out. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422347: [pkg-ntp-maintainers] Bug#422347: can't get ntpq without ntpd
On Thu, Apr 03, 2008 at 03:52:11PM -0400, Steve Kostecke wrote: Josip Rodin said: On Sat, May 05, 2007 at 12:04:59PM +0200, Josip Rodin wrote: I had the ntp package because I wanted the ntpq utility Now I found that I also have use for the the ntpdc utility on a machine where openntpd suffices as the server. In general, all this generic NTP client software that doesn't depend on a NTP server on localhost needs to be split out. The same binary is both the NTP client _and_ the NTP server. If you do want to separate out the utilities the resulting package should be named ntp-utilities. Er, ntpdc isn't the NTP server, it's a query program for the separate server program called ntpd. It's customary to refer to these as clients. But regardless, I really don't care much about the exact package name, just about the restoration of old functionality. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473518: dupload: Fails to parse the .changes file with latest dpkg-dev
On Mon, Mar 31, 2008 at 08:27:05PM +0200, Frank Lichtenheld wrote: On Mon, Mar 31, 2008 at 08:00:34AM +0300, Guillem Jover wrote: It fails to work with dpkg-dev 1.14.17 from experimental. This is due to the new Checksums fields, I think. Would be nice to get fixed before we upload a new dpkg version to unstable, and people can no longer properly use dupload. Urgs, that code is horrid. It assumes that the Files: field will always be last in the .changes file. The unstable version should obviously be fixed. But we might be able to work around it for the etch version by just assuring that the Files: field is indeed listed last. Yep, the parser works when you move the two new Checksums-* fields before Files, I just tested it. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473675: RADIUS namespace pollution
Package: libradius1 Hi, This package is named libradius1, but the shared library inside it is actually: % objdump -p /usr/lib/libradiusclient.so.0.0.1 | grep SONAME SONAME libradiusclient.so.0 So, the package should actually be named libradiusclient0. Furthermore, the package description says: This is the libraries needed by any client needing the RADIUS protocol. That is way too broad - not every RADIUS client needs this, indeed, a cursory search shows that only a single package other than radiusclient1 needs this particular library. There are several other RADIUS protocol implementations, in Debian packages as well. Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470977: freeradius package lumps client software with the server
On Fri, Mar 14, 2008 at 10:34:27PM +0100, Josip Rodin wrote: Package: freeradius Version: 1.1.3-3 It's currently impossible to get the RADIUS client software from the FreeRADIUS distribution without getting the server, which opens a network port, which is obviously bad for security when you just wanted a client, and if you disable the server you have to maintain a heap of needless software on the system and a conffile change, yadda yadda yadda. It's just wrong (against the spirit of the packaging system and the practice of every other client-server software package in Debian). The following binaries should be in a package called freeradius-client or something like that: /usr/bin/radclient /usr/bin/radeapclient /usr/bin/radtest They are all generic RADIUS client software that doesn't depend on a FreeRADIUS server in particular, and they don't depend on a RADIUS server on localhost either. I think I see the reason why they were kept inside the same package: libradius-1.1.7.so = /usr/lib/freeradius/libradius-1.1.7.so (0x2b2b3ea9d000) Ugh. This would usually go into a libradius-1.1.7 package, but because this is a just a shared object file (rather than a proper shared library), you can put it into something like freeradius-common, and keep a strict dependency on it. Also, radclient needs the dictionary files, so /etc/freeradius/dictionary and /usr/share/freeradius/dictionary* should go in the common package too. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470977: freeradius package lumps client software with the server
On Tue, Apr 01, 2008 at 01:23:11AM +0100, Stephen Gran wrote: Ugh. This would usually go into a libradius-1.1.7 package, but because this is a just a shared object file (rather than a proper shared library), you can put it into something like freeradius-common, and keep a strict dependency on it. I was thinking of an arch all -common, an arch any -utils, a library package, and a server package. But yes, the dependencies need to be strict. Right, if you have a relatively large arch-indep file percentage... putting the documentation in there will probably tip the scale to make it worth the while, but I didn't check. Also, radclient needs the dictionary files, so /etc/freeradius/dictionary and /usr/share/freeradius/dictionary* should go in the common package too. This is being worked on for the 2.x packages now. Amusingly, for built libraries we now get: libfreeradius-radius-2.0.3.la libfreeradius-radius-2.0.3.so libfreeradius-radius.a libfreeradius-radius.la libfreeradius-radius.so Even better, really. Ugh, indeed. Did you check if that's not some libtool-related problem? Theoretically the upstream might actually want to start shipping out one of those two as a real shared library, but wanting is one thing... :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473478: strict dependency on xterm only
Package: clusterssh Version: 3.19.1-4 Hi, README.Debian clearly states that xterm is not the only x-terminal-emulator which is tested and believed to work - why is it necessary to force the installation of the xterm package on users of those other six programs, particularly rxvt which has no noted caveats? Please use the piped dependency as appropriate. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423461: http.cfg/check_http flawed arguments (-H/-I confusion)
Hi, It's apparent that nobody is going to want to change the meaning of an existing command definition, as Sean noted. So, I concede that the applicable solution is the one where a new command is defined by the package's file. Call it check_http_with_host_name, that sounds straightforward enough? Ditto for check_https_with_host_name and check_https_auth_with_host_name. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458436: [php-maint] Bug#458436: php-pear doesn't warn when modules are upgradeable
severity 458436 normal thanks Hi, severity 458436 wishlist thanks Since the PEAR packages provided by de Debian package are updated/upgraded this is not a bug but a feature request. Your suggestion on using debconf shouldn't be followed because debconf shouldn't be used for those kind of things, NEWS.Debian should be used instead. First off, please use the right address when you wish to talk to submitters, your message never reached me because it was sent to the bug address only. I disagree on the wish part - the whole purpose of the pear package is to get those external PEAR packages. If pear is used to put those files on users' systems, it also has the responsibility to take care of them once they're there. The tool itself does do that, but the package doesn't properly integrate with it. If we lower the bar for package quality to the level where one only has to ship the binaries and be done with it, then integration of software features with package features is a wish, but it's 2008... I also don't agree with using NEWS.Debian, for two reasons - firstly, php-pear would have to depend on apt-listchanges (which shows the file), and secondly it doesn't make sense to couple this with news items, because each item has to be written, only to be shown once, which means that users who skip it in the first run are never again alerted to the likely problems. That's why a generic check and a prompt would make more sense than a news item. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470994: mail_spool default mode is 0660
On Mon, Mar 17, 2008 at 09:56:52PM -0700, Russ Allbery wrote: Josip Rodin [EMAIL PROTECTED] writes: Okay, given that I see no rationale for the sentence Mailboxes must be writable by group mail., I'm reassigning this to debian-policy. There is an ancient bug #24772 that was closed without a proper justification (it appears to have been rejected because it was in limbo with regard to the policy process). I don't know what the original Debian rationale was, but the traditional UNIX rationale for group-writable user mail spools is so that you don't have to run your mail system as root and can instead run it as some other user in group mail. However, everyone seems to have given up on that or at least uses a setuid-root MDA, so I'm not sure it's serving any real purpose at this point. Or they don't use root at all for the MDA, instead setuid'ing to the user itself. See also #405584. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471568: socket-dir from /etc/powerdns/recursor.conf ignored by init script and rec_control
Package: pdns-recursor Version: 3.1.4-1 Hi, As the title says... if you change socket-dir in the configuration file, the init script and rec_control by default don't see it - they insist on using the hardcoded /var/run. That is annoying in the (hopefully common) case where one uses chroot() - you have to put the control socket somewhere inside the chroot directory, and it would be a bit silly to chroot into /var/run (there are other programs' files in there). rec_control allows for the --socket-dir option to be specified, but it shouldn't be necessary, it could find that out itself. The init script just does PIDFILE=/var/run/$NAME.pid, whereas the pid file actually gets written into the socket directory (pdns_recursor.cc:writePid() defines fname as ::arg()[socket-dir]+/+s_programname+.pid). And then the error handling for that doesn't work, because: + PIDFILE=/var/run/pdns_recursor.pid ... + echo -n 'Stopping PowerDNS recursor: pdns-recursor' Stopping PowerDNS recursor: pdns-recursor+ stop + start-stop-daemon --stop --quiet --retry=HUP/30/TERM/5/KILL/5 --pidfile /var/run/pdns_recursor.pid --name pdns_recursor % echo $? 0 What really happens is: % sudo start-stop-daemon --stop --quiet --retry=HUP/30/TERM/5/KILL/5 --pidfile /var/run/pdns_recursor.pid --name pdns_recursor --verbose No pdns_recursor found running; none killed. % echo $? 1 start-stop-daemon exits with an error, and then the shell stops the execution of the entire script, because you use 'set -e'. You need to put 'set +e' at the beginning of the stop() function to get the ability to handle non-success exit values in there. But even then, that error handling is SNAFU. This is what happens: + echo -n 'Stopping PowerDNS recursor: pdns-recursor' Stopping PowerDNS recursor: pdns-recursor+ stop + set +e + start-stop-daemon --stop --quiet --retry=HUP/30/TERM/5/KILL/5 --pidfile /var/run/pdns_recursor.pid --name pdns_recursor + RETVAL=1 + '[' 1 = 2 ']' + start-stop-daemon --stop --quiet --oknodo --retry=HUP/30/KILL/5 --exec /usr/sbin/pdns_recursor + '[' 0 = 2 ']' + rm -f /var/run/pdns_recursor.pid + return 1 + case $? in + log_progress_msg '(not running)' ... That's just wrong. The second invocation of start-stop-daemon actually kills the running pdns_recursor process, and returns 0 because that succeeds, and that is then falsely reported. It doesn't look like the same person wrote the stop() function and the main body, because the intent is clearly not the same... The Policy manual isn't precise as to what to do in this situation. It says: The init.d scripts must ensure that they will behave sensibly if invoked [...] with stop when [the service] isn't [already running], and that they don't kill unfortunately-named user processes. The best way to achieve this is usually to use start-stop-daemon. This technically allows the current behaviour (killing instances of /usr/sbin/pdns_recursor which don't have the same pid file) but IMHO that's not right, because the sysadmin could rightfully have configured other configurations which shouldn't get killed just because they share the binaries with the main instance. The powerdns daemon (the authoritiative one) has that functionality separated into a 'force-stop' method, so it makes sense for the recursor to follow suit. The authoritative one's control program, pdns_control, also does the right thing with regard to reading variable data from the configuration file. Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470994: mail_spool default mode is 0660
On Tue, Mar 18, 2008 at 09:50:09AM -0700, Russ Allbery wrote: Josip Rodin [EMAIL PROTECTED] writes: On Mon, Mar 17, 2008 at 09:56:52PM -0700, Russ Allbery wrote: I don't know what the original Debian rationale was, but the traditional UNIX rationale for group-writable user mail spools is so that you don't have to run your mail system as root and can instead run it as some other user in group mail. However, everyone seems to have given up on that or at least uses a setuid-root MDA, so I'm not sure it's serving any real purpose at this point. Or they don't use root at all for the MDA, instead setuid'ing to the user itself. See also #405584. In order to deliver mail as the user, *something* has to be either running as root or setuid. That's basically my point. That's why I said no root for MDA - it's there for the MTA :) Group-writable mail spools allow the entire mail delivery chain to never run as root (with the possible exception of binding to port 25 if you want to accept incoming SMTP traffic), as long as you don't care about forwarding to programs. I don't know if we care about supporting this, though. Right. I don't think I've ever actually seen such an implementation. So it doesn't seem to make sense to enforce this by way of a must directive in the policy manual, and at the expense of user privacy in case of security problems. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#248526: gman: Format PS output according to screen size
On Tue, May 11, 2004 at 10:06:09PM +0200, Pierre THIERRY wrote: Package: gman Version: 0.9.3-2 Severity: wishlist Would it be possible to have an entry in the View menu for a PS output that fit the screen (i.e. no need to scroll the page in gv, as it not very comfortable for the reader...)? I agree that it's not particularly convenient, but there's not much we can do in gman - it just uses man -t which in turn uses groff/troff to generate PostScript, but I can't seem to find a way to change the page size in those. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471250: maildrop: Maildrop hangs indefinitely on arm when compiled with optimizations
clone 471250 -1 reassign -1 g++ thanks On Sun, Mar 16, 2008 at 11:30:15PM +0100, Kurt Pruenner wrote: Package: maildrop Version: 2.0.4-3 Severity: important I've found lately that whenever I upgraded to a 2.0.4 version of maildrop from the 2.0.3 one that I was using maildrop would hang forever and chew up what little CPU there is on my NSLU2 instead of filing mails. Today, I've finally broken out gdb to take a closer look at what's going on. I've found that maildrop was endlessly spinning through the loop in Message::Rewind in message.C because in the second call to Rewind the value assigned to the counter variable n, maildrop.msginfo.msgoffset, was negative (somewhere around -26). Further debugging revealed that it was actually the inlined Message::tell() assigning that absurd value to msgoffset. The mailfilter file I was using consisted of a single to ./Maildir line, and the mail file I used had just a From:, To: and Subject: header and a single line of data saying Test. Since I was using an unstripped but still optimized package which made things hard to debug I recompiled maildrop (which only takes a bit over an hour on said hardware) with the noopt flag set, only to discover that now suddenly everything was working perfectly fine. As I really don't have the time nor the experience to hunt what seems to be an GCC ARM compiler bug - could you perhaps forward this compiler bug to the gcc maintainer team and in the meantime build maildrop on ARM without optimizations? Unless I'm really unlucky here I'm afraid I'd have to say that maildrop is currently non-functional on ARM... :( Hm, okay, let's clone the bug report to g++... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335411: man-db: 'man -Hfirefox man', can't see the image
Hi, LI Daobing wrote: when I use `man -Hfirefox man' to see manpage in firefox, I can't see the image. I think man delete the images right after the browser return. I just saw the same... it looks like the whole /tmp/tempdir goes missing the moment the browser is forked. The -H mode gets groff/troff/whatever to generate images for all the tables, and then that uses psselect from the psutils package and some pnm utilities from the netpbm package. Those missing dependencies could go into the Suggests: field. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#285812: gentoo: doesn't start from fbmenu, grun, xterm, - doesn't fit the screen
On Wed, Dec 15, 2004 at 11:03:20AM -0800, Mr. Jan Hearthstone wrote: Package: gentoo Version: 0.11.46-1 Severity: important I cannot start gentoo from grun, fbmenu, and xterm (without adding --root-ok). Well, don't use X as root. That's a general advice... Then, gentoo doesn't fit the screen--only the middle parts are visible. What is your screen resolution? I have been patching the default gentoorc file to use 800x600 as the window size. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411740: Incomplete debian/copyright file
On Tue, Feb 20, 2007 at 09:09:29PM +0300, Pavel 'Blaze' Vinogradov wrote: Package: gentoo Version: 0.11.55-1.1 Tags: patch Severity: minor Accorting to http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html debian/copyright file must conform to: - Its not enough to have the following two-liner: | On Debian systems, the complete text of the GNU General Public License | can be found in the `/usr/share/common-licenses/GPL' file. There are license headers, like the one used for GPL in the example below, you should use those. Actually, the original author of the software never included those license headers. I actually pasted his exact sentences from the README, which has this: LICENSING This software is Copyright (c) 1998-2002 by Emil Brink. You are free to distribute this software under the terms of the GNU General Public License, version 2. You should have received a copy of this license together with the software (in a file called COPYING). If not, and you have web access, check http://www.gnu.org/. It is important to realize that this software comes without ANY form of warranty. So, the copyright file is correct, even if the upstream author's style may not be. - Ideally you include a license statement for your Debian packaging also. I went with the implicit option - using the same licence as the software that is being patched (packaged). Can I close the bug? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#234620: gentoo: please add icon to debian menu item
On Tue, Feb 24, 2004 at 09:31:45PM +0100, Holger Leskien wrote: Package: gentoo Version: 0.11.34-2 Severity: wishlist Please add an icon to the Debian menu item by adding icon=/usr/share/gentoo/icons/gentoo.png to /usr/lib/menu/gentoo That can't be done, because it's a 55x55 PNG file, it has to be a 32x32 XPM. Do you like the attached xpm that I just converted? -- 2. That which causes joy or happiness. attachment: gentoo.xpm
Bug#470994: mail_spool default mode is 0660
reopen 470994 reassign 470994 debian-policy thanks On Sat, Mar 15, 2008 at 08:57:13AM +0100, Marc Haber wrote: On Sat, Mar 15, 2008 at 01:27:25AM +0100, Josip Rodin wrote: The package's /etc/exim4/conf.d/transport/30_exim4-config_mail_spool says: group = mail mode = 0660 mode_fail_narrower = false Why is this so, again? Policy 11.6, paragraph 4, a MUST directive. Closing this bug. Okay, given that I see no rationale for the sentence Mailboxes must be writable by group mail., I'm reassigning this to debian-policy. There is an ancient bug #24772 that was closed without a proper justification (it appears to have been rejected because it was in limbo with regard to the policy process). In June 1999, Brock Rozen mentioned that Pine 4.x series has issues with perms on mailboxes. Can someone please comment if this has any relevance today? Santiago, Asheesh? If anyone else can name an application that requires such permissions, please speak up... And to quote my original report again... The [Exim] manual says that the default is to use the Exim group and mode 0600. I can't remember any reason why the mail group would be necessary, for anything other than creating the dot locks in the /var/mail directory, and that is allowed already by the directory permissions (it's g+w mail). I suppose using group 'mail' just makes sense, but why would we let the said group read and write user mailboxes? I suppose there could be some software that could need it, but if the common uses like mutt and dovecot don't need it, and indeed it only serves for privilege escalations in those setups, shouldn't the default be changed back to the more secure settings? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470977: freeradius package lumps client software with the server
Package: freeradius Version: 1.1.3-3 Hi, It's currently impossible to get the RADIUS client software from the FreeRADIUS distribution without getting the server, which opens a network port, which is obviously bad for security when you just wanted a client, and if you disable the server you have to maintain a heap of needless software on the system and a conffile change, yadda yadda yadda. It's just wrong (against the spirit of the packaging system and the practice of every other client-server software package in Debian). The following binaries should be in a package called freeradius-client or something like that: /usr/bin/radclient /usr/bin/radeapclient /usr/bin/radtest They are all generic RADIUS client software that doesn't depend on a FreeRADIUS server in particular, and they don't depend on a RADIUS server on localhost either. The other /usr/bin binaries from the current freeradius package could also easily be split out into a separate package, let's say freeradius-utils. But most of them are inherently tied to the FreeRADIUS server, so I won't complain if they stay. Yet, the smbencrypt binary is a complete mystery to me - why in the heaven's name is this a user-runnable binary in the RADIUS server package? There's a number of other things that can generate the LM/NT password hashes, such as a trivial implementation of libcrypt-smbhash-perl... In any case - after the clients are split out, the freeradius package can still depend on the new package(s), so no functionality would be lost for the users. Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470994: mail_spool default mode is 0660
Package: exim4-config Hi, The package's /etc/exim4/conf.d/transport/30_exim4-config_mail_spool says: group = mail mode = 0660 mode_fail_narrower = false Why is this so, again? The manual says that the default is to use the Exim group and mode 0600. I can't remember any reason why the mail group would be necessary, for anything other than creating the dot locks in the /var/mail directory, and that is allowed already by the directory permissions (it's g+w mail). I suppose using group 'mail' just makes sense, but why would we let the said group read and write user mailboxes? I suppose there could be some software that could need it, but if the common uses like mutt and dovecot don't need it, and indeed it only serves for privilege escalations in those setups, shouldn't the default be changed back to the more secure settings? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458438: php-radius general issue
On Tue, Mar 11, 2008 at 12:35:11PM +0100, Roberto Lumbreras wrote: I'm working on it... if possible I'll upload it today. Great! One thing I noticed about it is that it includes a copy of the code from libradius1 (the FreeBSD RADIUS library). But you can package it as it is for now. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439527: mod_auth_radius-2.0.c and Apache 2.2.x
On Thu, Mar 06, 2008 at 03:36:27AM +0100, Josip Rodin wrote:
On Sat, Jul 21, 2007 at 06:08:23PM +0200, joy wrote:
Is the mod_auth_radius-2.0.c supposed to work properly with Apache 2.2.x?
I can compile it just fine, but can't get it to work on runtime.
Maybe, like LDAP, this module should become a an AuthBasicProvider?
I took a hint from mod_auth_xradius' changes for Apache 2.1+, and made the
patch which is attached... but it still doesn't work. Apache is so annoying
to debug, I need to compile the server with debugging symbols and run it
through gdb... :(
Okay, I debugged it a bit further (no help from gdb), and managed to produce
a working patch. The problem that threw me off was the early DECLINED
handling in the authenticate_basic_user() function, which got activated
both when the module was inactive and when the RADIUS server definition
was missing. However, these two conditions are functionally quite different,
so I split the handling in two, with the latter case leaving a warning
in the log file.
The working patch is attached. It allows people to define:
AuthBasicProvider radius
and everything appears to be working well after that.
--
2. That which causes joy or happiness.
--- libapache-mod-auth-radius-1.5.7.orig/mod_auth_radius-2.0.c
+++ libapache-mod-auth-radius-1.5.7/mod_auth_radius-2.0.c
@@ -300,6 +300,9 @@
#include apr_general.h
#include apr_tables.h
#include apr_strings.h
+/* Apache 2.1+ */
+#include ap_provider.h
+#include mod_auth.h
module AP_MODULE_DECLARE_DATA radius_auth_module;
@@ -1122,8 +1125,11 @@
* basic authentication...
*/
-static int
-authenticate_basic_user(request_rec *r)
+/* common stuff for both Apache 2.0 and 2.1+ */
+int
+authenticate_basic_user_common(request_rec *r,
+ const char* user,
+ const char* sent_pw)
{
radius_dir_config_rec *rec =
(radius_dir_config_rec *)ap_get_module_config (r-per_dir_config, radius_auth_module);
@@ -1131,21 +1137,25 @@
radius_server_config_rec *scr = (radius_server_config_rec *)
ap_get_module_config (s-module_config, radius_auth_module);
conn_rec *c = r-connection;
- const char *sent_pw;
char errstr[MAX_STRING_LEN];
- int res, min;
+ int min;
char *cookie;
char *state = NULL;
char message[256];
time_t expires;
struct stat buf;
- if (!rec-active || !scr-radius_ip) /* not active here, or no radius */
-return DECLINED;/* server declared, decline */
+ /* not active here, just decline */
+ if (!rec-active)
+return DECLINED;
+
+ /* no server declared, decline but note for debugging purposes -joy */
+ if (!scr-radius_ip) {
+ap_log_error(APLOG_MARK, APLOG_NOERRNO | APLOG_WARNING, 0, r-server,
+ AuthRadiusActive set, but no RADIUS server IP - missing AddRadiusAuth in this context?);
+return DECLINED;
+ }
- if ((res = ap_get_basic_auth_pw(r, sent_pw)))
-return res;
-
if (r-user[0] == 0) /* NUL users can never be let in */
return HTTP_UNAUTHORIZED;
@@ -1227,9 +1237,57 @@
return OK;
}
+/* Apache 2.1+ */
+static authn_status
+authenticate_basic_user_newargs(request_rec *r,
+const char *user,
+const char *password)
+{
+ int normalreturnvalue = authenticate_basic_user_common(r, user, password);
+
+ if (normalreturnvalue == OK)
+return AUTH_GRANTED;
+ else if (normalreturnvalue == HTTP_UNAUTHORIZED)
+return AUTH_DENIED;
+ else
+return AUTH_GENERAL_ERROR;
+ /* AUTH_USER_NOT_FOUND would be nice, but the typical RADIUS server
+ never gives any such information, it just sends an Access-Reject
+ packet, no reasons given
+ */
+}
+
+/* Apache 2.0 */
+static int
+authenticate_basic_user(request_rec *r)
+{
+ int res;
+ const char *sent_pw;
+
+ /* this used to say just if ((res=...)), which relied on the fact that
+ OK is defined as 0, and the other states are non-0, which is then
+ used in a typical C fashion... but it's a bad idea, really, we should
+ explicitly check if it's not OK, whatever that may be -joy
+ */
+ res = ap_get_basic_auth_pw(r, sent_pw);
+ if (res != OK)
+return res;
+
+ return authenticate_basic_user_common(r, r-user, sent_pw);
+}
+
+/* Apache 2.1+ */
+static const authn_provider authn_radius_provider = {
+authenticate_basic_user_newargs,
+NULL
+};
+
static void register_hooks(apr_pool_t *p)
{
-ap_hook_check_user_id(authenticate_basic_user,NULL,NULL,APR_HOOK_MIDDLE);
+/* Apache 2.1+ */
+static const char * const aszPost[]={ mod_authz_user.c, NULL };
+ap_register_provider(p, AUTHN_PROVIDER_GROUP, radius, 0, authn_radius_provider);
+ap_hook_check_user_id(authenticate_basic_user,NULL,aszPost,APR_HOOK_MIDDLE);
}
module AP_MODULE_DECLARE_DATA radius_auth_module =
Bug#436093: Please decide on the ownership of the developers reference
Hi, I just saw this bug report mentioned on -vote. Setting aside the brief scuffle that happened at the time this bug was filed, and in my capacity as one of the previous editors of developers-reference and several other documents, I'd like to say that the following two points: * the developer's reference is documentation common to the entire project and as such it can't really be assigned to a single maintainer * the developer's reference is a package, and as such can have a single maintainer ...don't exactly correlate to the following two: * documents that don't have a designated maintainer can become effectively unmaintained because nobody ever takes responsibility * documents that have a designated maintainer can become effectively unmaintained because that person can give up all too easily There is no straightforward way to resolve that matter, at least I haven't seen one lately... Usually what happens, in either situation really, is that someone starts contributing so much that they take things forward a lot, and during the next random period of time they are considered the leader. Then they go away for whatever reason, and after another random period of time someone else (or even the same person) repeats the process. IMO the only half-smart thing to do with this would be to make sure that the barrier of entry into maintaining a document never goes up, because that usually only ends up increasing that period of time it takes to get someone to take it next time the document becomes unmaintained. So, in that vein, tech-ctte should err on the side of caution and avoid deciding to assign maintainership of developers-reference to any single person. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469612: mirror submission for debian.prunk.si
On Fri, Mar 07, 2008 at 07:54:23PM +0100, Simon Paillard wrote: Archive-http: /debian/ IPv6: no Archive-upstream: ftp.hr.debian.org Updates: twice As said on IRC, you should contact Joy to setup push mirroring. Or even better, mirror from ftp.si.debian.org instead. -- Josip Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458438: php-radius general issue
On Mon, Dec 31, 2007 at 06:32:24PM +0100, Roberto Lumbreras wrote: I didn't know about the radius PECL module, it seems great! Next year I will give it a try and package it, or if it is already packaged by someone it is welcome. Do you need any help with that? We could fairly easily ship both this old PHP implementation and the PECL module in the same package. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439527: mod_auth_radius-2.0.c and Apache 2.2.x
On Sat, Jul 21, 2007 at 06:08:23PM +0200, joy wrote:
Hi,
Is the mod_auth_radius-2.0.c supposed to work properly with Apache 2.2.x?
I can compile it just fine, but can't get it to work on runtime. I loaded
auth_radius before auth_basic and used AuthBasicAuthoritative Off,
but it didn't work, I always get this error:
Internal error: pcfg_openfile() called with NULL filename
Maybe, like LDAP, this module should become a an AuthBasicProvider?
I took a hint from mod_auth_xradius' changes for Apache 2.1+, and made the
patch which is attached... but it still doesn't work. Apache is so annoying
to debug, I need to compile the server with debugging symbols and run it
through gdb... :(
Anyway, any information would be appreciated.
--
2. That which causes joy or happiness.
--- libapache-mod-auth-radius-1.5.7.orig/mod_auth_radius-2.0.c
+++ libapache-mod-auth-radius-1.5.7/mod_auth_radius-2.0.c
@@ -300,6 +300,9 @@
#include apr_general.h
#include apr_tables.h
#include apr_strings.h
+/* Apache 2.1+ */
+#include ap_provider.h
+#include mod_auth.h
module AP_MODULE_DECLARE_DATA radius_auth_module;
@@ -1122,8 +1125,11 @@
* basic authentication...
*/
-static int
-authenticate_basic_user(request_rec *r)
+/* common stuff for both Apache 2.0 and 2.1+ */
+int
+authenticate_basic_user_common(request_rec *r,
+ const char* user,
+ const char* sent_pw)
{
radius_dir_config_rec *rec =
(radius_dir_config_rec *)ap_get_module_config (r-per_dir_config, radius_auth_module);
@@ -1131,9 +1137,8 @@
radius_server_config_rec *scr = (radius_server_config_rec *)
ap_get_module_config (s-module_config, radius_auth_module);
conn_rec *c = r-connection;
- const char *sent_pw;
char errstr[MAX_STRING_LEN];
- int res, min;
+ int min;
char *cookie;
char *state = NULL;
char message[256];
@@ -1143,9 +1148,6 @@
if (!rec-active || !scr-radius_ip) /* not active here, or no radius */
return DECLINED;/* server declared, decline */
- if ((res = ap_get_basic_auth_pw(r, sent_pw)))
-return res;
-
if (r-user[0] == 0) /* NUL users can never be let in */
return HTTP_UNAUTHORIZED;
@@ -1227,9 +1229,58 @@
return OK;
}
+/* Apache 2.1+ */
+static authn_status
+authenticate_basic_user_newargs(request_rec *r,
+const char *user,
+const char *password)
+{
+ int normalreturnvalue = authenticate_basic_user_common(r, user, password);
+
+ if (normalreturnvalue == OK)
+return AUTH_GRANTED;
+ else if (normalreturnvalue == HTTP_UNAUTHORIZED)
+return AUTH_DENIED;
+ else
+return AUTH_GENERAL_ERROR;
+ /* AUTH_USER_NOT_FOUND would be nice, but the typical RADIUS server
+ never gives any such information, it just sends an Access-Reject
+ packet, no reasons given
+ */
+}
+
+/* Apache 2.0 */
+static int
+authenticate_basic_user(request_rec *r)
+{
+ int res;
+ const char *sent_pw;
+
+ /* this used to say just if ((res=...)), which relied on the fact that
+ OK is defined as 0, and the other states are non-0, which is then
+ used in a typical C fashion... but it's a bad idea, really, we should
+ explicitly check if it's not OK, whatever that may be -joy
+ */
+ res = ap_get_basic_auth_pw(r, sent_pw);
+ if (res != OK)
+return res;
+
+ return authenticate_basic_user_common(r, r-user, sent_pw);
+}
+
+/* Apache 2.1+ */
+static const authn_provider authn_radius_provider = {
+authenticate_basic_user_newargs,
+NULL
+};
+
static void register_hooks(apr_pool_t *p)
{
-ap_hook_check_user_id(authenticate_basic_user,NULL,NULL,APR_HOOK_MIDDLE);
+#if 0 /* Apache 2.0 */
+ap_hook_check_user_id(authenticate_basic_user_oldargs,NULL,NULL,APR_HOOK_MIDDLE);
+#else /* Apache 2.1+ */
+ap_register_provider(p, AUTHN_PROVIDER_GROUP, radius, 0, authn_radius_provider);
+#endif
}
module AP_MODULE_DECLARE_DATA radius_auth_module =
Bug#469209: bad change to maildrop [EMAIL PROTECTED] behaviour
Package: maildrop
- Forwarded message from Josip Rodin joy -
Date: Tue, 5 Feb 2008 00:13:26 +0100
From: Josip Rodin joy
To: Sam Varshavchik
Cc: Andres Salomon, [EMAIL PROTECTED]
Subject: bad change to maildrop to [EMAIL PROTECTED] behaviour
Hi,
Recently I noticed that a newer version of maildrop started forwarding
all mails to me from one particular filter setup using 'to !myaddress'
as - bounces.
I checked the $SENDMAIL and $FROM variables, and they are both all right
(/usr/sbin/sendmail -oi and the username, respectively). Yet, the log says
that maildrop passed the message to /usr/sbin/sendmail -oi -f ''
[recipients].
I went to look at the code, and maildrop/deliver.C says it's hardcoded:
if (*mailbox == '!')
{
b=SENDMAIL;
const char *sendmail=GetVarStr(b);
cmdbuf=sendmail;
cmdbuf += -f '' ;
cmdbuf += mailbox+1;
}
The maildropfilter(5) manual page showed no relevant change - it still
says that if everything is all right with $SENDMAIL and $FROM, the mail
should get forwarded normally.
I went looking for information in the changelog and CVS, and all I found was:
revision 1.14
date: 2005/05/12 14:45:57; author: mrsam; state: Exp; lines: +2 -2
Version 1.8.1
Index: deliver.C
===
RCS file: /cvsroot/courier/courier/maildrop/maildrop/deliver.C,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- deliver.C 30 Jan 2005 14:50:37 - 1.13
+++ deliver.C 12 May 2005 14:45:57 - 1.14
@@ -30,7 +30,7 @@
#endif
#include errno.h
-static const char rcsid[]=$Id: deliver.C,v 1.13 2005/01/30 14:50:37 mrsam Exp
$;
+static const char rcsid[]=$Id: deliver.C,v 1.14 2005/05/12 14:45:57 mrsam Exp
$;
///
//
@@ -64,7 +64,7 @@
cmdbuf=sendmail;
- cmdbuf += ' ';
+ cmdbuf += -f '' ;
cmdbuf += mailbox+1;
}
else
:( Can you please document these kinds of changes in the future?
I recommend that this is reverted, because it doesn't seem to make much
sense - the old behaviour, where the return-path is set to the user
generating this new mail, can't be flawed so much that we'd have to make
all such messages bounces.
The system processing the maildrop filter file containing such a setting
already has the ability to run maildrop and $SENDMAIL, so the assumption
that it can also receive bounces for mails it sends out isn't far-fetched.
Even if you were really keen on undoing that assumption, the proper way to
do so would be to make the behaviour configurable, rather than disabling
the old way completely.
--
2. That which causes joy or happiness.
- End forwarded message -
- Forwarded message from Josip Rodin joy -
Date: Tue, 5 Feb 2008 09:48:44 +0100
From: Josip Rodin
To: Sam Varshavchik
Cc: Andres Salomon, [EMAIL PROTECTED]
Subject: Re: bad change to maildrop to [EMAIL PROTECTED] behaviour
On Mon, Feb 04, 2008 at 07:57:39PM -0500, Sam Varshavchik wrote:
Josip Rodin writes:
The maildropfilter(5) manual page showed no relevant change - it still
says that if everything is all right with $SENDMAIL and $FROM, the mail
should get forwarded normally.
I find nothing in maildropfilter(5) that indicates that FROM gets preserved
for forwarded mail.
These parts:
FROM Message envelope sender. [...]
If the -f option is not given, maildrop looks for
the From_ line in the message. As the last resort, FROM defaults
to the userid which invoked maildrop. Note that FROM may be
empty - the message envelope sender is empty for bounce mes-
sages.
SENDMAIL
The mail delivery agent. When maildrop is instructed to deliver
the message to a mailbox whose name begins with the ! character,
this is interpreted as a request to forward the message. The
SENDMAIL command is executed to forward the message.
It doesn't say anywhere that forwarding mails will change the message
envelope sender to an empty one.
There's really no answer here that will make everyone happy. Preserving the
original return address in other situations may result in a mail loop, or
other issues.
You can always specify everything yourself:
to '| $SENDMAIL -f $FROM [EMAIL PROTECTED]'
Yes, but that forces the change from ! to |. With the old system, at least
the other group (those who *wanted* to generate bounces) wasn't as
disadvantaged - they could just explicitly set FROM to '' themselves
and have things work according to the manual.
Honouring the contents of the documented FROM variable sounds
Bug#444349: please build maildrop-mysql package also
On Thu, Sep 27, 2007 at 06:16:49PM -0400, Micah Anderson wrote: Package: maildrop Version: 2.0.3-1 Severity: wishlist If --without-db --enable-maildropmysql is added to the configure rules, then mysql support is built into maildrop, it would be really great if you could provide a second binary called maildrop-mysql that has this configuration. Hm, I'm not sure why you filed this against version 2.0.3, because all this functionality has been completely gone from maildrop since version 1.8.0 - instead it can access mysql and ldap through courier authlib...? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#6786: status
On Tue, Feb 26, 2008 at 08:59:27PM +0100, Josip Rodin wrote: On Sun, Dec 09, 2007 at 03:12:18PM +0100, Josip Rodin wrote: ftp.hk is having issues not only with this, but also with disk space, Roger So replied to us saying this is known and that we can remove the site. I've tried contacting people about this, to no avail... the site looks much better now, but I still haven't had any confirmation about the status of two-stage rsyncing. I've sent and re-sent more reminders :| OK, I found a mail saying ftp.hk rsyncs once a day, once per session. Unless this is fixed, it'll have to be removed, this is sub-par... -- Josip Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#6786: status
On Sun, Dec 09, 2007 at 03:12:18PM +0100, Josip Rodin wrote: ftp.hk is having issues not only with this, but also with disk space, Roger So replied to us saying this is known and that we can remove the site. I've tried contacting people about this, to no avail... the site looks much better now, but I still haven't had any confirmation about the status of two-stage rsyncing. I've sent and re-sent more reminders :| -- Josip Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467493: check_smtp only says Invalid SMTP response received from host
Package: nagios-plugins-basic
Version: 1.4.5-1etch1
Hi,
check_smtp.c around line 239 says:
if (!strstr (buffer, server_expect)) {
if (server_port == SMTP_PORT)
printf (_(Invalid SMTP response received from host\n));
In such a case, it makes sense to actually *print* what the server said
(different from SMTP_EXPECT, 220), because this error message is pretty
much useless for later debugging. Including the 'buffer' variable in
that output seems like a no-brainer.
Please fix this. TIA.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#254714: multisync(1)'s Nothing yet
Hi, multisync(1) is a poor man's lintian override or something? In general, it's confusing for users to have multisync (v0.82) and multisync0.90. It's impossible to properly decide which one to use... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465449: /etc/sysctl.conf /etc/network/options forwarding replacement faulty
Package: netbase Hi, I'm not sure if I'm filing this in the right place - please reassign where necessary. After the etch upgrade, my sysctl.conf was left with comments saying: ## # Functions previously found in netbase # ... # Uncomment the next line to enable packet forwarding for IPv4 net.ipv4.conf.default.forwarding=1 However, this isn't really the right replacement. This sysctl knob doesn't actually allow forwarding on my eth0, or rather, it doesn't do the same as net.ipv4.ip_forward, which was used by the old script and which is documented in /usr/share/doc/netbase/README.Debian Please replace the misleading comment. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464880: munin can't be updated every minute (or indeed anything other than every 5 minutes)
Package: munin,munin-node Version: 1.2.5-1 Severity: wishlist Hi, There's apparently no way to make munin update any way other than every five minutes. Even if you make the /etc/cron.d/munin script run munin-cron differently, the RRD files generated by munin-node all have 'step' set to 300 (seconds), so rrdtool update can't feed them data any more often than that. This RRD setting can't be tuned once the files are already generated, so this has to be done upon an initial creation, i.e. initial package installation. Please -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464881: munin-node-configure can't handle netmasks
Package: munin-node Version: 1.2.5-1 Hi, munin-node-configure [--suggest] --shell which is run by postinst runs the 'ip_' script to detect all addresses in iptables configuration from which to extract counters - but it doesn't see any problems with passing on netmasks (/xy), which contain a slash, and make the resulting ln(1) invocation invalid, because it has: /etc/munin/plugins/ip/mask and there is no ip subdirectory, obviously. This causes numerous ln error messages to be shown upon initial package installation. It should probably detect the slash character, in both modes (suggest and normal), and replace it with a plus character or something like that. Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464880: munin can't be updated every minute (or indeed anything other than every 5 minutes)
On Sat, Feb 09, 2008 at 04:58:53PM +0100, Josip Rodin wrote: There's apparently no way to make munin update any way other than every five minutes. Even if you make the /etc/cron.d/munin script run munin-cron differently, the RRD files generated by munin-node all have 'step' set to 300 (seconds), so rrdtool update can't feed them data any more often than that. This RRD setting can't be tuned once the files are already generated, so this has to be done upon an initial creation, i.e. initial package installation. Hmm. Maybe not - it's munin-update (part of the server package) which creates the RRD files, so it can even do some munging every time. /usr/share/munin/munin-update:905 contains the RRDs::create call which can be given the step parameter, and different settings for each archive. It could be made to support a per-minute update interval by adding an alternate path there, based on a new configuration file option. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464035: samba getpeername failed. error message
Package: samba
Version: 3.0.24-6etch9
Hi,
source/lib/util_sock.c's get_peer_addr() function does:
if (getpeername(fd, sa, length) 0) {
DEBUG(0,(getpeername failed. Error was %s\n, strerror(errno)
));
return addr_buf;
}
This is littering my log.smbd file, like this:
getpeername failed. Error was Transport endpoint is not connected
This apparent ENOTCONN is happening a couple of times every hour on one set
of my machines.
At first I thought it was harmless, just logged at the level 0 (always),
but looking more into the source, this should be getting generated after
the following sequence of call in source/smbd/server.c:
if (allowable_number_of_smbd_processes()
smbd_server_fd() != -1 sys_fork()==0) {
/* Child code ... */
/* close the listening socket(s) */
for(i = 0; i num_sockets; i++)
close(fd_listenset[i]);
/* close our standard file
descriptors */
close_low_fds(False);
am_parent = 0;
set_socket_options(smbd_server_fd(),SO_KEEPALIVE);
set_socket_options(smbd_server_fd(),user_socket_options);
/* this is needed so that we get decent entries
in smbstatus for port 445 connects */
set_remote_machine_name(get_peer_addr(smbd_server_fd()), False);
...
Perhaps it would be a good idea to test if smbd_server_fd() is returning
something which is dead there, because something else could be going wrong...
and I'd like to be able to know more about what is causing these.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457073: samba: Newer Samba client fails to join Etch Samba PDC
Hi, You wrote: On the Etch PDC, I get the following log : [2007/12/19 14:53:51, 0] rpc_server/srv_netlog_nt.c:get_md4pw(242) get_md4pw: Workstation ETCHTEST$: no account in domain [2007/12/19 14:53:51, 0] rpc_server/srv_netlog_nt.c:_net_auth_2(461) _net_auth2: failed to get machine password for account ETCHTEST$: NT_STATUS_ACCESS_DENIED This is a PDC with LDAP backend. The LDAP node associated to the machine seems to be created correctly. You're showing the log with the log level set to 0. Increase the log level to something higher (2, 5, 10), on the server, and see what it actually says. Samba logging sucks this way... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464030: smb.conf(5) fails to document log level classes
Package: samba Version: 3.0.24-6etch9 Hi, smb.conf manual page says that there are multiple debug classes, but omits an actual explanation of that, except for a small example. source/lib/debug.c defines a default table of class names, and there's additional logic to determine which classes are available on runtime (I think; I haven't read it in detail). The file also has a debug_dump_status() function, which shows this if the debug level is already set to five or higher: [2008/02/04 20:49:32, 5] lib/debug.c:debug_dump_status(391) INFO: Current debug levels: all: True/5 tdb: False/0 printdrivers: False/0 lanman: False/0 smb: False/0 rpc_parse: False/0 rpc_srv: False/0 rpc_cli: False/0 passdb: False/0 sam: False/0 auth: False/0 winbind: False/0 vfs: False/0 idmap: False/0 quota: False/0 acls: False/0 locking: False/0 msdfs: False/0 dmapi: False/0 A list of some sort needs to be included in the manual page, otherwise we're down to UTSL or semi-random fiddling with options. Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459545: maildrop: Tries to overwrite /usr/bin/makedat, which is also supplied by courier-base
On Mon, Jan 07, 2008 at 11:48:19AM +0100, Stefan Hornburg wrote:
Package: maildrop
Version: 2.0.3-1
Severity: serious
Justification: Policy 10.1
Upgrading maildrop from version 2.0.3 to the new version 2.0.4 in
unstable fails due to the new package trying to overwrite
/usr/bin/makedat which is already supplied by courier-base:
Stefan, we need to alternative-ize makedat, because Sam moved the makedat
program into the maildrop source build as well (apparently it used to be
disabled by mistake). I'll set up Conflicts at my end to handle the old
versions; can you do your bit, too, please.
Yes, of course.
Hm, you're actually shipping the symlink to the shell script:
lrwxrwxrwx root/root 0 2007-12-05 11:27 ./usr/bin/makedat -
../lib/courier/makedat
At this end, the install script installs both makedat and makedatprog
into /usr/bin.
The manual page is missing at this end, I'll fix that.
I'm adding an alternative for makedat{,.1} like the one for lockmail co.,
and a Replaces:, hopefully it will work and be sufficient.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416845: debian.mirror.ac.za outdated trace files, push-mirror ?
On Mon, Dec 24, 2007 at 10:33:55AM +0100, Simon Paillard wrote: Hello Andrew, http://debian.mirror.ac.za/debian/project/trace/ reports strange trace files, all outdated except your own trace file. Could you please look at your rsync logs and check all is ok ? Such outdated files maybe caused by a sync that cannot be finished, because of network issues for example. This looks like it's fixed now, Andrew also mentioned a new machine in another mail. Yet, there's still a small glitch - the trace file is called jhb-mirror.rouwkoop.local. Please change the HOSTNAME variable to say debian.mirror.ac.za. -- Josip Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459545: maildrop: Tries to overwrite /usr/bin/makedat, which is also supplied by courier-base
On Mon, Jan 07, 2008 at 10:06:05AM +0100, Kurt Pruenner wrote: Package: maildrop Version: 2.0.3-1 Severity: serious Justification: Policy 10.1 Upgrading maildrop from version 2.0.3 to the new version 2.0.4 in unstable fails due to the new package trying to overwrite /usr/bin/makedat which is already supplied by courier-base: Stefan, we need to alternative-ize makedat, because Sam moved the makedat program into the maildrop source build as well (apparently it used to be disabled by mistake). I'll set up Conflicts at my end to handle the old versions; can you do your bit, too, please. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454417:
On Fri, Jan 04, 2008 at 04:26:42PM +0100, Thijs Kinkhorst wrote: severity 454417 serious thanks Hi! Maildrop on Etch (at least on AMD64) is unable to run, because installation does not pull in a necessary dependency, namely courier-authlib. I experienced this aswell. On 6 Dec you downgraded this bug in severity, but to me this is a clear case of violating Debian policy 3.5, so I don't agree that it should not be of RC severity. The package should not be shipped with lenny with this bug unresolved. It should actually be fixed in etch as well, if you want to look at it like that... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445360: rxvt+mutt crash - new, smaller test case
On Thu, Jan 03, 2008 at 12:21:23PM +0100, Josip Rodin wrote: I've run into the bug again a few times, but most recently on a rather inconspicuous bit - just scrolling within one single message crashed rxvt. Because this message wasn't signed or anything, so not that many colors would be involved in the crash, I then also took a wild guess and reduced the .muttrc to just the ignore/unignore part, and that was the part that made the difference. With default etch mutt settings, it doesn't crash, with the attached muttrc, it does. I also obfuscated the text in the message to protect the guilty :) and to make it a bit more homogenous - and it still crashes on it. Steps to reproduce: * run rxvt * inside, run mutt -F rxvt-bug.muttrc -f rxvt-bug.mbox2 * press enter (show message) * press space (scroll one screen down) * poof I'll try to whip up the debugger now... Pretty much the same deal as the last time: (gdb) r Starting program: /home/joy/QA/rxvt/rxvt-2.6.4/src/rxvt-xterm Program received signal SIGTSTP, Stopped (user). 0x2ac494f33b35 in select () from /lib/libc.so.6 (gdb) p screen.text[TermWin.saveLines] $1 = ( text_t *) 0x54dfa0 i:Exit -:PrevPg Space:NextPg v:View Attachm. d:Del r:Reply j:Next ?:Help (gdb) watch (void *)screen.text[TermWin.saveLines] Hardware watchpoint 1: (void *) screen.text[TermWin.saveLines] (gdb) c Continuing. Program received signal SIGTSTP, Stopped (user). 0x2ac494f33b35 in select () from /lib/libc.so.6 (gdb) c Continuing. Hardware watchpoint 1: (void *) screen.text[TermWin.saveLines] Old value = (void *) 0x54dfa0 New value = (void *) 0x543d40 scroll_text (row1=0, row2=520, count=11, spec=0) at screen.c:803 803 screen.tlen[j] = screen.tlen[j + count]; (gdb) c Continuing. Program received signal SIGTSTP, Stopped (user). 0x004102e2 in scr_add_lines ( str=0x51cd3c X x xx xxx, xx xxx:\r\n\nx1: Xx: Xx xxx: xxx | -x xxx-xx-\r\n\033[0;1m\033(B\033[31m\033[40m+\033[0m\033([EMAIL PROTECTED] XXX xxx'x xxx x, x..., nlines=-10, len=98) at screen.c:1012 1012stp[screen.cur.col] = c; (gdb) bt full #0 0x004102e2 in scr_add_lines ( str=0x51cd3c X x xx xxx, xx xxx:\r\n\nx1: Xx: Xx xxx: xxx | -x xxx-xx-\r\n\033[0;1m\033(B\033[31m\033[40m+\033[0m\033([EMAIL PROTECTED] XXX xxx'x xxx x, x..., nlines=-10, len=98) at screen.c:1012 c = 88 'X' i = 1 j = 0 row = 510 last_col = 80 checksel = 1 clearsel = 0 stp = (text_t *) 0x0 srp = (u_int16_t *) 0x0 #1 0x00408d47 in main_loop () at command.c:3307 nlines = 3 ch = 27 '\033' str = ( unsigned char *) 0x51cd3c X x xx xxx, xx xxx:\r\n\nx1: Xx: Xx xxx: xxx | -x xxx-xx-\r\n\033[0;1m\033(B\033[31m\033[40m+\033[0m\033([EMAIL PROTECTED] XXX xxx'x xxx x, x... #2 0x0040cd40 in main (argc=1, argv=0x7fff15f595a8) at main.c:1434 ---Type return to continue, or q return to quit--- cmd_argv = (const char **) 0x0 (gdb) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445360: rxvt+mutt crash - new, smaller test case
Hi, I've run into the bug again a few times, but most recently on a rather inconspicuous bit - just scrolling within one single message crashed rxvt. Because this message wasn't signed or anything, so not that many colors would be involved in the crash, I then also took a wild guess and reduced the .muttrc to just the ignore/unignore part, and that was the part that made the difference. With default etch mutt settings, it doesn't crash, with the attached muttrc, it does. I also obfuscated the text in the message to protect the guilty :) and to make it a bit more homogenous - and it still crashes on it. Steps to reproduce: * run rxvt * inside, run mutt -F rxvt-bug.muttrc -f rxvt-bug.mbox2 * press enter (show message) * press space (scroll one screen down) * poof I'll try to whip up the debugger now... -- 2. That which causes joy or happiness. # list of header fields to weed when displaying ignore From Received X-Received Message-ID Return-Path Path Lines ignore Resent- Precedence References In-Reply-To Return-Receipt-To ignore Sender X-Sender X-X-Sender Original-Sender NNTP-Posting-Host ignore Status X-Status Content- MIME-Version Delivered-To Envelope-to ignore Originator X-Loop X-Mailing-List X-Listprocessor X-No-Archive ignore User-Agent Mailer X-Mailer X-Newsreader X-Submitted-Via ignore Priority X-Priority X-MSMail-Priority ignore X-MimeOLE ignore X-Envelope-To X-Envelope-Sender ignore X-Attribution X-Face ignore X-Debian-PR-Message X-Debian-PR-Keywords ignore List-Help List-Post List-Subscribe List-Unsubscribe List-Id List-Archive ignore X-BeenThere X-Mailman-Version ignore X-Mail-Format-Warning X-Spam-Status X-Spam-Checker-Version ignore Old-X-Spam-Status Old-X-Spam-Checker-Version ignore X-Reportbug-Version X-Katie ignore X-GPG X-GPG-Fingerprint X-GPG-key ignore X-PGP X-PGP-Fingerprint X-PGP-Key-ID ignore X-Operating-System X-OS X-Uptime X-System X-Editor ignore X-Signature-Color X-Signature-PRG X-URL # ignore X-Echelon X-Motto X-Yow X-ddate X-Unexpected-Header ignore X-ECS-MailScanner X-Virus-Scanned ignore Old-Return-Path # just in case unignore From: Date: Subject: To: Cc: From joy Thu Jan 3 11:31:45 2008 Return-path: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on .xx.xx X-Spam-Level: X-Spam-Status: No, score=-2.3 required=4.5 tests=AWL,BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.2.3 Envelope-to: [EMAIL PROTECTED] Delivery-date: Thu, 03 Jan 2008 11:31:41 +0100 Received: from xx.xx.xxx ([yy.yyy.yyy.yy]:40212) by .xx.xx with esmtp (Exim 4.63) (envelope-from [EMAIL PROTECTED]) id 1JANMQ-000132-Cz for [EMAIL PROTECTED]; Thu, 03 Jan 2008 11:31:41 +0100 Received: from .xx.xx ([yyy.yy.yyy.yy]) by xx.xx.xxx with esmtp (Exim 4.50) id 1JANMG-0001sQ-FM for [EMAIL PROTECTED]; Thu, 03 Jan 2008 10:31:28 + Received: from joy by .xx.xx with local (Exim 4.63) (envelope-from [EMAIL PROTECTED]) id 1JANMF-00012b-HB; Thu, 03 Jan 2008 11:31:27 +0100 Date: Thu, 3 Jan 2008 11:31:27 +0100 From: X X [EMAIL PROTECTED] To: Xxx Xx [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.5.13 (2006-08-11) Sender: X X [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-SA-Exim-Connect-IP: yy.yyy.yyy.yy Old-X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on .xx.xx Old-X-Spam-Status: No, score=-1.0 required=4.5 tests=BAYES_50,RCVD_IN_DNSWL_LOW autolearn=no version=3.2.3 Subject: Xx: xxx xx. Delivered-To: [EMAIL PROTECTED] Content-Length: 871 Lines: 30 Xx Xxx, Xxx 03, 2008 xx 11:19:48XX +0100, Xxx Xx x: Xx x , x xx xx xx x, xxx. Xxx xxx xxx? X'x xxx xx xxx xx x xxx-xx. X xxx-xx - x2.xx - x. Xx x'x x xx xxx x xxx xxx x x xx Xxxx :) Xxxx'x xxx xx x. Xx, xx, xx'x xxx, xxx x xxx xx'x: xxx-xx - x.xx - xxx - x X'xx x xxx x2xx:X1xxx2XxXxXxXXXxxXXxxx5x9x : , xx xx xxx. Xx. X x xx xxx, xx xxx: x1: Xx: Xx xxx: xxx | -x xxx-xx- [EMAIL PROTECTED] X XXX xxx'x xxx x, x xx Xxxx :) -- X X [EMAIL PROTECTED]
Bug#458436: php-pear doesn't warn when modules are upgradeable
Package: php-pear Hi, Upon a sarge-etch upgrade, nothing upgraded the PHP modules, which can break user scripts. The package should make some sort of an effort to warn that an upgrade is necessary, maybe have a debconf prompt that offers to run pear upgrade-all and pecl upgrade-all when modules with an old ABI version are detected. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458438: php-radius general issue
Package: php-radius Hi, This RADIUS authentication library which is packaged as php-radius is something implemented in PHP; there's actually a PECL module called radius[1] which would be better suited for this package name. This current implementation does appear to be a bit lacking - for one, it doesn't allow for servers or attributes to be normally specified, there's just one function that does PAP with a server location hardcoded in a separate configuration file. [1] http://www.php.net/radius http://pecl.php.net/package/radius -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457804: multipath-tools-boot gets started before module-init-tools, making modules useless
On Thu, Dec 27, 2007 at 09:59:15AM +0100, Guido Guenther wrote: On Wed, Dec 26, 2007 at 10:34:35PM +0100, Josip Rodin wrote: I suppose, although that's a much more general change that would have many more consequences. How was the current priority for multipath-tools-boot selected, is there a rationale for it being as high as 3 (now 4)? I can't say I can see the reason offhand. I suppose you want it to be before S30checkfs.sh and S35mountall.sh so that people can put multipath'd drives into fstab, but why would it run as early as 3 or 4? It was moved that early because it had to be started _before_ udev. Basti was maintaining the package back then (0.4.5-2) and the changelog doesn't give a reason why this was done. I moved it to start _after_ udev so the /dev/mapper entries get created correctly on the tmpfs (0.4.7-3). We can probably move it even later in the boot process but not after LVM cryptdisks and mdadm which would mean [21,24] if we also want to have it after module-init tools. But there might very well be something earlier that also wants access to block devices, who knows? There's S10checkroot.sh, but it should be safe to assume that if the system has already booted from the root partition, multipath can't change it anyway... right? Strange thing is, checkroot.sh also activates the swap devices found in /etc/fstab. I can't imagine a reason why someone would have the swap partition(s) behind a device which requires multipath, though. I don't think we should be missing anything, because I can't think of any extra packages that should mess with the priority space this early (20) and yet need multipath. The closest are ocfs2-tools and cman, which are at 60 in this runlevel (should be near 40, but that's another matter). 21 looks like a good choice but I wonder if we gain that much - you could always load necessary modules with modprobe module || treue in /etc/default/multipath-tools for your special requirements. In other cases an initramfs makes much more sense. Well, supporting kernel modules isn't generally considered a special requirement, they've been around since forever :) /etc/modules is used for specifying which kernel modules should be loaded at system boot time, it doesn't make sense from a maintenance standpoint for multipath to require a separate module loading method. Another point is the fact that the script multipath-tools-boot runs modprobe dm-multipath by default. We are already allowing for the idea that the multipath functionality exists as a kernel module, so there's no point in not allowing the idea that whatever is behind the device mapper can also be a kernel module. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457804: multipath-tools-boot gets started before module-init-tools, making modules useless
On Wed, Dec 26, 2007 at 05:17:44PM +0100, Guido Guenther wrote: Hi Josip, On Wed, Dec 26, 2007 at 01:11:18AM +0100, Josip Rodin wrote: S0(3|4)multipath-tools-boot needs to be moved to something like S21multipath-tools-boot, and after this, things work all right because /etc/modules loads qla2xxx and multipath runs fine. Wouldn't it make more sense to move module-init-tools more to the front? I can see other scripts with priorities 20 that might benefit from that. I suppose, although that's a much more general change that would have many more consequences. How was the current priority for multipath-tools-boot selected, is there a rationale for it being as high as 3 (now 4)? I can't say I can see the reason offhand. I suppose you want it to be before S30checkfs.sh and S35mountall.sh so that people can put multipath'd drives into fstab, but why would it run as early as 3 or 4? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457803: o2cb gets started before mountnfs.sh, making auto mounts impossible
Package: ocfs2-tools Version: 1.2.1-1.3, 1.2.4-1 Hi, The package installs the o2cb init script in the S runlevel at the position 60. This is after networking which is at position 40, which is good. However, mountnfs.sh is started at position 45 in the S runlevel, which means that OCFS2 services aren't running at the time that script starts, so there isn't any chance for it to mount ocfs2 filesystems on boot, you just get: mount.ocfs2: Unable to access cluster service Cannot initialize cluster S60o2cb needs to be moved to something like S41o2cb, and after this, things work. (The other prerequisite is setting ASYNCMOUNTNFS=no.) Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457804: multipath-tools-boot gets started before module-init-tools, making modules useless
Package: multipath-tools Version: 0.4.7-1.1, 0.4.8-5 Hi, The package installs the multipath-tools-boot init script in the S runlevel at the position 03 (etch) or 04 (sid). However, module-init-tools is started at position 20 in the S runlevel, which means that the kernel modules which aren't detected by udev aren't yet loaded at the time multipath is run. In my specific situation, the necessary module is qla2xxx. I don't want to compile this module into the kernel, both because of an inherent opposition to in-kernel PCI card drivers, and because this module is replaceable by another one (HP's supported qla2300 driver), and because the module requires /lib/firmware/ql2300_fw.bin, which would mean I have to use an initrd. It would simply be an unnecessary complication to have to compile this rather than use a module. S0(3|4)multipath-tools-boot needs to be moved to something like S21multipath-tools-boot, and after this, things work all right because /etc/modules loads qla2xxx and multipath runs fine. Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438179: RFC3484 s6 rule 9 should not apply
On Thu, Dec 06, 2007 at 09:52:51PM +0100, Andreas Barth wrote: * Aurelien Jarno ([EMAIL PROTECTED]) [071206 21:41]: Does this also apply to stable? The tech ctte didn't do a decision about stable, though it seems that most of us consider it appropriate. I think that you should explicitly decide for stable as well, if anything, because of security.d.o, whose main chunk of users still appear to be stable users: [EMAIL PROTECTED]:~]% lynx http://localhost/server-status -dump | egrep -c '(stable|etch)' 1113 [EMAIL PROTECTED]:~]% lynx http://localhost/server-status -dump | egrep -c '(testing|lenny)' 139 This isn't completely conclusive, but one can safely assume that the vast majority of pool/ traffic comes by way of Packages and Sources files. I've also run the same thing a few days ago, at another random time of day, and the score was 1379 : 162, so I have no real reason to doubt it. JFTR, the weekly bandwidth average is now: * steffani 12.44 MB/s * villa 4.80 MB/s * lobos 4.53 MB/s -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438179: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish
On Mon, Dec 17, 2007 at 01:15:10PM -0500, Noah Meyerhans wrote: If it were possible, (temporarily) adding a securty.d.o mirror in the 0.0.0.0 - 127.255.255.255 range would be helpful [...] Obviously finding a host that can deal with 13.53 MB/s of sustained traffic with a useful IP address to temporarily test this behaviour might be difficult. :) Quite. We might actually be able to help with this at MIT, where steffani is already hosted. MIT controls 18.0.0.0/8 and, while the lab where steffani is hosted doesn't usually use net 18 address space, we do have some available. I'd have to double check with the network admin, but it should be trivial to allocate an address for this purpose. Would it work to simply bring up a separate interface on steffani? Did you mention this to DSA, they'd have to configure it at this end? File an RT ticket? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438179: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish
On Tue, Dec 18, 2007 at 03:31:13PM +0100, Martin Schulze wrote: If it were possible, (temporarily) adding a securty.d.o mirror in the 0.0.0.0 - 127.255.255.255 range would be helpful [...] Obviously finding a host that can deal with 13.53 MB/s of sustained traffic with a useful IP address to temporarily test this behaviour might be difficult. :) Quite. We might actually be able to help with this Did you mention this to DSA, they'd have to configure it at this end? I may be dumb, but what would another IP address for an existing security mirror that is already the preferred one buy us? I would expect that a second machine in the 128.* zone would be able to spread the load better. See above - just temporary for purposes of demonstration. Though I think that the case is already clear, but to eliminate any doubt whatsoever... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438179: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish
On Mon, Dec 17, 2007 at 07:51:18PM +0100, Martin Schulze wrote: I've asked DSA for server-status already, and mentioned the logs too, we'll see (they haven't replied yet). Server status is configured on localhost. OK, so I started measuring that too, and the rates for the last half a day or so are: * villa: 20.4 rps, 6.18 Mbps * lobos: 18.9 rps, 6.23 Mbps * steffani: 40.0 rps, 15.92 Mbps The ratios for both parameters are matching the general bandwidth ratios, so the measurements should be correct. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438179: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish
On Sun, Dec 16, 2007 at 06:28:39PM +1000, Anthony Towns wrote: On Sun, Dec 16, 2007 at 03:45:37AM +0100, Josip Rodin wrote: After around 11 hours, we've had: * villa 4.29 MB/s * lobos 3.91 MB/s * steffani 14.86 MB/s The rule9 prediction was: [...] Anyway, hope that's of some use. Thanks for doing that. FWIW, the last reading is: * villa 5.33 MB/s * lobos 4.92 MB/s * steffani 14.58 MB/s Anyway, in light of all this, please comment again on those old conclusions: Which leaves as conclusions: - there's no available evidence of a problem from Debian server logs This should be fixed now, for security.d.o at least. I can go ask people maintaining servers in the other rotations for data if you think it's necessary, but it'll take some time. - the understanding of the issue we've got so far implies that this would only cause fairly minor load balancing problems for the current Debian hosts This disparity doesn't classify as a minor load balancing problem when we see one third of a rotation doing more than twice as much as other two thirds. It has been hard enough to get people to volunteer their sites into popular round-robins when we would promise they'd get a fair share of traffic... - ftp.us, http.us and security.d.o all seem to still be functioning from a user's perspective They are functioning now, but the higher the probability that we'll burden some sites with excess traffic, the higher the probability that the quality of service will suffer, and higher the probability that those sites will drop out of the rotation, and then others can start getting unexpectedly large amounts of traffic (after redistribution), then they might drop out, and then rinse repeat... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438179: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish
On Sat, Dec 15, 2007 at 03:38:01PM +0100, Josip Rodin wrote: Steve pointed me to http://lists.debian.org/debian-ctte/2007/12/msg00033.html BTW, if anyone reading has some time to do the math again (hi aj :) it would be good it was recalculated for ftp.us.debian.org again, which we've changed in the meantime. That round-robin is now composed of: % host ftp.us.debian.org ftp.us.debian.org A 35.9.37.225 ftp.us.debian.org A 64.50.236.52 ftp.us.debian.org A 128.30.2.36 ftp.us.debian.org A 204.152.191.39 At the same time, I should just get off my ass and go find the resolving code in the applications (apt-get, rsync, ...), and then just run it to see how it works... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438179: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish
On Thu, Nov 29, 2007 at 10:39:13PM +0100, Josip Rodin wrote: I've noticed that security.debian.org, which is composed of three hosts, appears to be resolved by apts so that only one of them, steffani, gets picked. I can't substantiate this with exact log evidence yet (there's an outstanding RT ticket for that), but the system load on that machine is consistently high and network speed low, whereas the other two machines are practically idling in comparison. Steve Langasek happened to ask me today to find some hard facts regarding the round-robin functionality, so I stopped procrastinating :) and finally set up tracking of the security.d.o machines' /proc/net/dev (I had previously asked DSA to share their own stats, but they chose to install rrdtool for me to use instead). The RRDs are now being generated every minute (in my home dir on those machines), and I have prepared a set of rrd.cgi instances that graph them (but not on those machines, because of various intricate prerequisites). Right now, with a small sample of just some 110 minutes, the machine eth0s have been averaging: * villa: 4.69 MB/s * lobos: 4.08 MB/s * steffani: 15.14 MB/s Steve pointed me to http://lists.debian.org/debian-ctte/2007/12/msg00033.html And this is starting to match, although not as precisely. But, again, this is too small a sample for a variety of reasons, so let's give it some time. I'd appreciate it if someone would send a reminder in a day or two so that I send over the data then. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438179: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish
On Sat, Dec 15, 2007 at 03:43:22PM +0100, Josip Rodin wrote: At the same time, I should just get off my ass and go find the resolving code in the applications (apt-get, rsync, ...), and then just run it to see how it works... I edited apt's methods/connect.cc:Connect() function after the line saying struct addrinfo *CurHost = LastHostAddr; to do: char hbuf[NI_MAXHOST], sbuf[NI_MAXSERV]; getnameinfo( CurHost-ai_addr, CurHost-ai_addrlen, hbuf, sizeof(hbuf), sbuf, sizeof(sbuf), NI_NUMERICHOST ); char *msg; sprintf(msg, \nUsing IP address: %s, with service %s\n, hbuf, sbuf); return _error-Error( msg ); Then I ran it with a minimal sources.list file including only security.d.o: % for i in $(seq 1 30); do LD_LIBRARY_PATH=bin bin/apt-get -o Dir::Etc::SourceList=$PWD/sources.list -o Dir::State::Lists=$PWD/foo -o Dir::Bin::Methods=$PWD/bin/methods update 2/dev/null | grep Using | sort -u; done | cut -d: -f2 | cut -d, -f1 | sort | uniq -c | sort -n 8 212.211.132.32 10 212.211.132.250 12 128.31.0.36 % for i in $(seq 1 30); do LD_LIBRARY_PATH=bin bin/apt-get -o Dir::Etc::SourceList=$PWD/sources.list -o Dir::State::Lists=$PWD/foo -o Dir::Bin::Methods=$PWD/bin/methods update 2/dev/null | grep Using | sort -u; done | cut -d: -f2 | cut -d, -f1 | sort | uniq -c | sort -n 7 128.31.0.36 11 212.211.132.250 12 212.211.132.32 % for i in $(seq 1 30); do LD_LIBRARY_PATH=bin bin/apt-get -o Dir::Etc::SourceList=$PWD/sources.list -o Dir::State::Lists=$PWD/foo -o Dir::Bin::Methods=$PWD/bin/methods update 2/dev/null | grep Using | sort -u; done | cut -d: -f2 | cut -d, -f1 | sort | uniq -c | sort -n 6 212.211.132.32 10 212.211.132.250 14 128.31.0.36 % for i in $(seq 1 30); do LD_LIBRARY_PATH=bin bin/apt-get -o Dir::Etc::SourceList=$PWD/sources.list -o Dir::State::Lists=$PWD/foo -o Dir::Bin::Methods=$PWD/bin/methods update 2/dev/null | grep Using | sort -u; done | cut -d: -f2 | cut -d, -f1 | sort | uniq -c | sort -n 7 128.31.0.36 11 212.211.132.32 12 212.211.132.250 % for i in $(seq 1 30); do LD_LIBRARY_PATH=bin bin/apt-get -o Dir::Etc::SourceList=$PWD/sources.list -o Dir::State::Lists=$PWD/foo -o Dir::Bin::Methods=$PWD/bin/methods update 2/dev/null | grep Using | sort -u; done | cut -d: -f2 | cut -d, -f1 | sort | uniq -c | sort -n 8 212.211.132.250 11 128.31.0.36 11 212.211.132.32 Screwy... let's try a larger sample: % for i in $(seq 1 99); do LD_LIBRARY_PATH=bin bin/apt-get -o Dir::Etc::SourceList=$PWD/sources.list -o Dir::State::Lists=$PWD/foo -o Dir::Bin::Methods=$PWD/bin/methods update 2/dev/null | grep Using | sort -u; done | cut -d: -f2 | cut -d, -f1 | sort | uniq -c | sort -n 30 212.211.132.250 33 212.211.132.32 36 128.31.0.36 % for i in $(seq 1 99); do LD_LIBRARY_PATH=bin bin/apt-get -o Dir::Etc::SourceList=$PWD/sources.list -o Dir::State::Lists=$PWD/foo -o Dir::Bin::Methods=$PWD/bin/methods update 2/dev/null | grep Using | sort -u; done | cut -d: -f2 | cut -d, -f1 | sort | uniq -c | sort -n 27 212.211.132.250 34 212.211.132.32 38 128.31.0.36 % for i in $(seq 1 99); do LD_LIBRARY_PATH=bin bin/apt-get -o Dir::Etc::SourceList=$PWD/sources.list -o Dir::State::Lists=$PWD/foo -o Dir::Bin::Methods=$PWD/bin/methods update 2/dev/null | grep Using | sort -u; done | cut -d: -f2 | cut -d, -f1 | sort | uniq -c | sort -n 32 212.211.132.250 33 128.31.0.36 34 212.211.132.32 % for i in $(seq 1 99); do LD_LIBRARY_PATH=bin bin/apt-get -o Dir::Etc::SourceList=$PWD/sources.list -o Dir::State::Lists=$PWD/foo -o Dir::Bin::Methods=$PWD/bin/methods update 2/dev/null | grep Using | sort -u; done | cut -d: -f2 | cut -d, -f1 | sort | uniq -c | sort -n 30 212.211.132.250 32 212.211.132.32 37 128.31.0.36 % for i in $(seq 1 99); do LD_LIBRARY_PATH=bin bin/apt-get -o Dir::Etc::SourceList=$PWD/sources.list -o Dir::State::Lists=$PWD/foo -o Dir::Bin::Methods=$PWD/bin/methods update 2/dev/null | grep Using | sort -u; done | cut -d: -f2 | cut -d, -f1 | sort | uniq -c | sort -n 31 212.211.132.32 32 212.211.132.250 36 128.31.0.36 That's a bit less screwy, although it's a bit more consistently tilting in the direction of steffani. On that note, let me update that other bit: Right now, with a small sample of just some 110 minutes, the machine eth0s have been averaging: * villa: 4.69 MB/s * lobos: 4.08 MB/s * steffani: 15.14 MB/s After around 11 hours, we've had: * villa 4.29 MB/s * lobos 3.91 MB/s * steffani 14.86 MB/s That would be 64% for steffani... :/ -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446615: obsolete README.non-US file should be removed from debian/
On Sun, Oct 14, 2007 at 02:54:52PM +0200, Josip Rodin wrote: Package: ftp.debian.org Hi, The debian-non-US archive has been obsolete since the release of sarge in 2005. Indeed, even for sarge users it doesn't make any difference because the package indices are empty. So, regardless of the fact that sarge as oldstable is still kept under debian/, it doesn't make sense any more to distribute a list of debian-non-US mirrors on the debian/ mirror sites. It just confuses the users and mirror administrators into thinking that non-US is still alive and related to the current debian/ archive, when it is not. Please rm $ftpdir/README.non-US and apply the following simple patch: --- /srv/ftp.debian.org/dak/scripts/debian/update-mirrorlists 2006-05-31 03:11:19.0 + +++ /srv/ftp.debian.org/dak/scripts/debian/update-mirrorlists 2007-10-14 12:48:12.0 + @@ -20,10 +20,5 @@ rm -f $ftpdir/README.mirrors.html $ftpdir/README.mirrors.txt $prog -m $masterlist -t html $ftpdir/README.mirrors.html $prog -m $masterlist -t text $ftpdir/README.mirrors.txt - if [ ! -f $ftpdir/README.non-US -o $masterlist -nt $ftpdir/README.non-US ] ; then - rm -f $ftpdir/README.non-US - $prog -m $masterlist -t nonus $ftpdir/README.non-US - install -m 664 $ftpdir/README.non-US $webdir - fi echo Updated archive version of mirrors file fi (We will keep the list on the web site, and the leftover data in Mirrors.masterlist.) Also, the reference to the same file in debian/README.html should be removed. It's a static file, AFAIR, so just ditch the paragraph saying: h2Software restricted in the U.S./h2 pFor more information about Debian packages of software that is restricted in the USA, please see a href=README.non-USREADME.non-US/a. br a href=http://www.debian.org/mirror/;Further information/a /p (Why is it taking two months to apply a trivial documentation patch...) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#6786: status
On Thu, Nov 08, 2007 at 02:39:18AM +0100, Josip Rodin wrote: This is the current status of setups for official mirrors: Updating most ...remaining ones :) And yet some more. And then some. This is another update. And another one. ftp.au has been replaced. ftp.hk is having issues not only with this, but also with disk space, Roger So replied to us saying this is known and that we can remove the site. If anyone has suggestions for a replacement, let us know, otherwise we're going to remove it. On related note, I wonder if Internet connections from Hong Kong to China are by and large good - if so, then we might work around this problem by assigning ftp.cn.d.o (and we have a decent candidate for that). -- Josip Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417858: rsync timezone (UTC) problem
retitle 417858 Strange time differential in the log thanks Hi, I've experienced this problem on several machines, and it's most annoying, it makes the logs unparsable. It didn't happen with syslogd in this case, so I'm removing that bit from the title. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438179: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish
On Thu, Nov 29, 2007 at 11:37:27PM +1000, Anthony Towns wrote: severity 438179 wishlist thanks On Tue, Nov 27, 2007 at 07:09:04PM +, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: severity 438179 serious Bug#438179: Please provide a way to override RFC3484 Severity set to `serious' from `wishlist' Josip, there's been absolutely no evidence that our mirrors are fucking up. If you've got some, please share it instead of taking your frustration out by playing with BTS serverities. Sorry, I was actually re-reading the bug log without noticing that it was no longer assigned to a package, rather it's now at the pseudo-package, where the severity doesn't make all that much sense. I've noticed that security.debian.org, which is composed of three hosts, appears to be resolved by apts so that only one of them, steffani, gets picked. I can't substantiate this with exact log evidence yet (there's an outstanding RT ticket for that), but the system load on that machine is consistently high and network speed low, whereas the other two machines are practically idling in comparison. I've also previously noticed that ftp.us.debian.org traffic seems to concentrate too much on one host, too, ike.egr.msu.edu, but I've got even less evidence there (that and other machines aren't under our control). -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445360: rxvt reproducibly crashes with certain mutt behaviour
On Mon, Nov 19, 2007 at 12:30:49AM +0100, Jan Christoph Nordholz wrote: 0x545060 Subject: ** PROBLEM alert - nekkar.CARNet.hr host is DOWN **, ' ' repeats 20 times, 0x545390 ' ' repeats 80 times, 0x0, 0x0, 0x0, 0x0, 0x0, 0x55c9f0 ' ' repeats 80 times, 0x55cb00 ' ' repeats 80 times, 0x55cc10 ' ' repeats 80 times, 0x55cd20 ' ' repeats 80 times, 0x55ce30 ' ' repeats 80 times, 0x5456c0 [-- The following data is signed --], ' ' repeats 44 times, Oh, we might have a difference in environment there. My mutt shows this: [-- PGP output follows (current time: Pon 19 Stu 2007 00:37:27) --] gpg: Signature made Ned 22 Srp 2007 15:10:18 CEST using DSA key ID 893FAD07 gpg: Can't check signature: public key not found [-- End of PGP output --] And on the last line it says: PGP signature could NOT be verified. At that point, I press 'j', and then rxvt crashes. How do I get gdb to work with this? I've tried running it until that point, and then Ctrl+Z it in gdb to be able to type commands, but then: Program received signal SIGTSTP, Stopped (user). 0x2afcc09c8a75 in select () from /lib/libc.so.6 (gdb) p TermWin.nrow Attempt to extract a component of a value that is not a structure. (gdb) p (text_t *[24])*(screen.text + TermWin.saveLines) No symbol text_t in current context. (gdb) p (int16_t [24])*(screen.tlen + TermWin.saveLines) No symbol int16_t in current context. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445360: rxvt crash
On Mon, Nov 19, 2007 at 01:22:48AM +0100, Jan Christoph Nordholz wrote: Ah, forgot one thing, to avoid a misunderstanding, because you quoted my gdb output: those NULL pointers are in _your_ session. I extracted that from your second core file. The contents of the display have already been partially replaced at the time of the crash... the lines above the five 0x0s are part of the second mail, the lines below belong to the first one, and the last line containing the status bar has already been cleared by mutt, too. In my tests I also get PGP sig could not be verified, but I don't have 0x0 pointers in the middle of the .text and .rend arrays. I'd be glad if I had, because then I had something to debug. ;) It occurs to me that you might be interested in the following settings of my .muttrc which relate to which parts of the message are output and how: ignore From Received X-Received Message-ID Return-Path Path Lines ignore Resent- Precedence References In-Reply-To Return-Receipt-To ignore Sender X-Sender X-X-Sender Original-Sender NNTP-Posting-Host ignore Status X-Status Content- MIME-Version Delivered-To Envelope-to ignore Originator X-Loop X-Mailing-List X-Listprocessor X-No-Archive ignore User-Agent Mailer X-Mailer X-Newsreader X-Submitted-Via ignore Priority X-Priority X-MSMail-Priority ignore X-MimeOLE ignore X-Envelope-To X-Envelope-Sender ignore X-Attribution X-Face ignore X-Debian-PR-Message X-Debian-PR-Keywords ignore List-Help List-Post List-Subscribe List-Unsubscribe List-Id List-Archive ignore X-BeenThere X-Mailman-Version ignore X-Mail-Format-Warning X-Spam-Status X-Spam-Checker-Version ignore Old-X-Spam-Status Old-X-Spam-Checker-Version ignore X-Reportbug-Version X-Katie ignore X-GPG X-GPG-Fingerprint X-GPG-key ignore X-PGP X-PGP-Fingerprint X-PGP-Key-ID ignore X-Operating-System X-OS X-Uptime X-System X-Editor ignore X-Signature-Color X-Signature-PRG X-URL ignore X-ECS-MailScanner X-Virus-Scanned ignore Old-Return-Path unignore From: Date: Subject: To: Cc: color indicator brightyellowred color status brightwhite blue color hdrdefault green black color header brightyellowblack ^from: color header brightgreen black ^subject: color header green black ^cc: color header green black ^to: color header green black ^reply-to: color bodybrightblue black ht|f)tps?)|mailto):(//)?[^\ \t]*|www\.[-a-z0-9.]+)[^\ .,;\t] color bodybrightmagenta black [EMAIL PROTECTED] color bodybrightyellowblack ^Good signature color bodybrightwhite red ^Bad signature from.* color quoted green black color attachment brightred black color signature cyanblack color treecyanblack color tilde brightmagenta black color markers brightred black color error brightred black monoheader bold^from: monoheader bold^subject: monobodyboldht|f)tps?)|mailto):(//)?[^\ \t]*|www\.[-a-z0-9.]+)[^\ .,;\t] monobodybold[EMAIL PROTECTED] monobodybold^Good signature monobodybold^Bad signature from.* monoerror bold Feel free to ask for the rest if you think it's relevant... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445360: rxvt reproducibly crashes with certain mutt behaviour
On Mon, Nov 19, 2007 at 01:57:04AM +0100, Jan Christoph Nordholz wrote: Now I have at least a faint idea what I should be looking for in the source code... maybe you could speed it up by setting a watchpoint? 1. start rxvt-xterm inside gdb 2. fire up mutt, open the first mail 3. CTRL+C... ] (gdb) p screen.text[TermWin.saveLines] // check: should be the top line of your window ] (gdb) watch (void *)screen.text[TermWin.saveLines] ] Hardware watchpoint 1: (void *)screen.text[TermWin.saveLines] ] (gdb) c ] Continuing. 4. Try to reproduce the crash. Now it should not get to the segfault, but interrupt somewhere in between (exactly at the position where those buffer pointers are altered). I guess I don't need a core file then - a 'bt full' should provide all that's necessary to guide my search. ;) Okay... (gdb) r Starting program: /home/joy/QA/rxvt/rxvt-2.6.4/src/rxvt-xterm Program received signal SIGTSTP, Stopped (user). 0x2b0ce3dd9a75 in select () from /lib/libc.so.6 (gdb) p screen.text[TermWin.saveLines] $1 = ( text_t *) 0x54dfa0 i:Exit -:PrevPg Space:NextPg v:View Attachm. d:Del r:Reply j:Next ?:Help (gdb) watch (void *)screen.text[TermWin.saveLines] Hardware watchpoint 1: (void *) screen.text[TermWin.saveLines] (gdb) c Continuing. Program received signal SIGTSTP, Stopped (user). 0x2b0ce3dd9a75 in select () from /lib/libc.so.6 (gdb) c Continuing. Hardware watchpoint 1: (void *) screen.text[TermWin.saveLines] Old value = (void *) 0x54dfa0 New value = (void *) 0x543a10 scroll_text (row1=0, row2=518, count=10, spec=0) at screen.c:803 803 screen.tlen[j] = screen.tlen[j + count]; (gdb) c Continuing. [here it's actually just stuck again... so I press Ctrl+Z] Program received signal SIGTSTP, Stopped (user). 0x004102e2 in scr_add_lines ( str=0x51cdcc * Nagios *\r\n\nNotification Type: PROBLEM\r\nHost: nekkar.CARNet.hr\r\nState: DOWN\r\nAddress: 161.53.160.239\r\nInfo:\r\n\nCRITICAL - Host Unreachable (161.53.160.239)\r\n\nDate/Time: Sun Jul 22 15:43:45 CE..., nlines=-4, len=207) at screen.c:1012 1012stp[screen.cur.col] = c; (gdb) bt full #0 0x004102e2 in scr_add_lines ( str=0x51cdcc * Nagios *\r\n\nNotification Type: PROBLEM\r\nHost: nekkar.CARNet.hr\r\nState: DOWN\r\nAddress: 161.53.160.239\r\nInfo:\r\n\nCRITICAL - Host Unreachable (161.53.160.239)\r\n\nDate/Time: Sun Jul 22 15:43:45 CE..., nlines=-4, len=207) at screen.c:1012 c = 42 '*' i = 1 j = 0 row = 509 last_col = 80 checksel = 0 clearsel = 0 stp = (text_t *) 0x0 srp = (u_int16_t *) 0x0 #1 0x00408d47 in main_loop () at command.c:3307 nlines = 10 ch = 27 '\033' str = ( unsigned char *) 0x51cdcc * Nagios *\r\n\nNotification Type: PROBLEM\r\nHost: nekkar.CARNet.hr\r\nState: DOWN\r\nAddress: 161.53.160.239\r\nInfo:\r\n\nCRITICAL - Host Unreachable (161.53.160.239)\r\n\nDate/Time: Sun Jul 22 15:43:45 CE... #2 0x0040cd40 in main (argc=1, argv=0x7fffc70b26d8) at main.c:1434 ---Type return to continue, or q return to quit--- cmd_argv = (const char **) 0x0 (gdb) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432664: Actually I wasn't signaling a bug but a mirror
On Sat, Nov 10, 2007 at 12:16:04PM +0100, Thomas Simon wrote: You didn't appear to see the message you were sent by Simon Paillard on July 19th (you can see it at http://bugs.debian.org/432664 ) Now, if your connection is 100 Mbps now, that basic concern can be dismissed. However, there are still major problems that prevent listing of your site: it looks like you're using debmirror or some other flawed method of mirroring Debian. This creates a mirror without source files, without dists/stable and other symlinks, and with a broken project/trace/ directory, among other things. Can you please switch to mirroring using the current version of our recommended mirroring script, at http://www.debian.org/mirror/anonftpsync If you have any questions or concerns, please don't hesitate to let us know. Thanks. It's okay i'm mirroring the archive with annonftpsync shall i register my mirror again ? Thank you for your time and informations. You don't have to register it again, but we'd like to see you update your mirror with anonftpsync. http://equanux.no-ip.org/debian/ is still debmirror-like. -- Josip Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419642: scope of -infrastructure-announce and -mirrors-announce ?
On Wed, Nov 07, 2007 at 05:09:09PM +0100, Simon Paillard wrote: On Tue, Nov 06, 2007 at 10:15:41PM +0100, Joey Schulze wrote: This mailing list targets both users and developers who are interested in status changes of public (and private) .debian.org infrastructure. [..] . downtime for important mirrors [..] Mirror administrators of important mirrors who are not registrated Debian developers are invited to contact Debian developers (e.g. via [EMAIL PROTECTED]) to pass announcements to users in case this is needed (e.g. for scheduled downtimes). I assume that in your view, debian-mirrors-announce would become a list with mirrors admins as only target ? That means that some mirrors-related messages will have to be cross-posted to both lists so that both users and leaf mirrors are informed about a change in a upstream Debian mirror. (it is not reasonable to ask all admins of debian mirrors for subscribing to a general list). Speaking of which, maybe we should post something about ries' current predicament to -mirrors-announce. How long is the downtime expected to last? -- Josip Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#6786: status
On Thu, Nov 01, 2007 at 10:59:30PM +0100, Josip Rodin wrote: On Sat, Oct 13, 2007 at 11:07:45AM +0200, Josip Rodin wrote: This is the current status of setups for official mirrors: Updating most ...remaining ones :) And yet some more. And then some. This is another update. And another one. ftp.ee is fixed now. Still no reply for ftp.au or ftp.hk. -- Josip Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445360: rxvt reproducibly crashes with certain mutt behaviour
On Sun, Nov 04, 2007 at 02:10:18PM +0100, Jan Christoph Nordholz wrote: Hi Josip, Certain niche actions in mutt have been reproducibly crashing my rxvt since I've upgraded to etch. Here's a test case: I can't reproduce that bug. Could you get me a core dump? It doesn't produce a core dump. % ulimit -c unlimited % rxvt [run the actions in the invoked rxvt until it crashes] zsh: segmentation fault rxvt What locale do you use? % locale LANG=hr_HR LC_CTYPE=hr_HR LC_NUMERIC=hr_HR LC_TIME=hr_HR LC_COLLATE=C LC_MONETARY=hr_HR LC_MESSAGES=en_US LC_PAPER=hr_HR LC_NAME=hr_HR LC_ADDRESS=hr_HR LC_TELEPHONE=hr_HR LC_MEASUREMENT=hr_HR LC_IDENTIFICATION=hr_HR LC_ALL= -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435514: [EMAIL PROTECTED]: Re: Bug#435514: mirror submission for ftp.cse.yzu.edu.tw]
- Forwarded message from cywang [EMAIL PROTECTED] - Delivery-date: Sat, 03 Nov 2007 05:26:42 +0100 Date: Sat, 3 Nov 2007 12:26:34 +0800 From: cywang [EMAIL PROTECTED] To: Josip Rodin [EMAIL PROTECTED] Subject: Re: Bug#435514: mirror submission for ftp.cse.yzu.edu.tw OK, I will check it 2007/11/3, Josip Rodin [EMAIL PROTECTED]: [...] -- ? (Cheng-Yu,Wang) Email : [EMAIL PROTECTED] ? ? 03-4638800 # 2369 #4051 - End forwarded message - - Forwarded message from cywang [EMAIL PROTECTED] - Delivery-date: Sat, 03 Nov 2007 12:31:42 +0100 Date: Sat, 3 Nov 2007 19:31:35 +0800 From: cywang [EMAIL PROTECTED] To: Josip Rodin [EMAIL PROTECTED] Subject: Re: Bug#435514: mirror submission for ftp.cse.yzu.edu.tw It's ok now, http://ftp.cse.yzu.edu.tw/pub/Linux/debian/debian/ any problem please email me 2007/11/3, Josip Rodin [EMAIL PROTECTED]: [...] -- ? (Cheng-Yu,Wang) Email : [EMAIL PROTECTED] ? ? 03-4638800 # 2369 #4051 - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435514: mirror submission for ftp.cse.yzu.edu.tw
On Sat, Nov 03, 2007 at 07:31:35PM +0800, cywang wrote: It's ok now, http://ftp.cse.yzu.edu.tw/pub/Linux/debian/debian/ any problem please email me Thanks! Did you set up a cron job to update the mirror regularly? It's good that your trace file now exists in http://ftp.cse.yzu.edu.tw/pub/Linux/debian/debian/project/trace/ But do you know how come it doesn't include the ftp.tw.debian.org trace file? -- Josip Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449100: [SPAM] - Bug#449100: erlang-base: /usr/bin/* with manual pages elsewhere - Bayesian Filter detected spam
On Sat, Nov 03, 2007 at 09:12:36AM +0100, Sergei Golovan wrote: On 11/3/07, Josip Rodin [EMAIL PROTECTED] wrote: Package: erlang-base Version: 1:11.b.2-4 Hi, The manual pages erl(1) and others are effectively missing from the erlang-base package. It would add a headache to sync the manual pages with erlang-manpages on any new erlang release since they come in a separate source package. I would like to keep these stub manual pages with links to real ones. You could at least split those five into erlang-base-manpages (generated from erlang-manpages source package), and then make erlang-base depend on erlang-base-manpages. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449100: bounce
Err... - Forwarded message from Mail Delivery System [EMAIL PROTECTED] - [...] This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] SMTP error from remote mail server after RCPT TO:[EMAIL PROTECTED]: host ASPMX.L.GOOGLE.COM [209.85.135.27]: 550 5.1.1 No such user i5si9473493mue [...] - End forwarded message - -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#207094: mirror.d.o help
Hi, I just changed dmc.pl to link the legend before every section, will add an explanation of the level freshness too if I can find a way to phrase that :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435514: mirror submission for ftp.cse.yzu.edu.tw
On Wed, Aug 01, 2007 at 10:05:22AM +, Cheng-Yu, Wang wrote: Package: mirrors Severity: wishlist Submission-Type: new Site: ftp.cse.yzu.edu.tw Aliases: ftp.oss.tw Type: leaf Archive-ftp: /pub/Linux/debian/debian/ Archive-http: /pub/Linux/debian/debian/ Your Debian mirror hasn't been updated with our recommended settings, and in addition, it hasn't been updated at all since October 17th. Can you please check up on it? -- Josip Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449097: pseudo-packages.{maintainers,description} files belong to the BTS
Package: ftp.debian.org,bugs.debian.org
Severity: minor
Hi,
I've noticed that the pseudo-packages.{maintainers,description} files
don't serve any particular purpose in dak on ries - there's a file
scripts/debian/mkmaintainers which does:
nonusmaint=$base/misc/Maintainers_Versions-non-US
if wget -T15 -q -O Maintainers_Versions-non-US.gz
http://non-us.debian.org/indices-non-US/Maintainers_Versions.gz; then
[...]
fi
cd $indices
dak make-maintainers $nonusmaint $configdir/pseudo-packages.maintainers | [...]
It just relies on the existence of that file, but it doesn't really care
where it came from - the non-US maintainers file is fetched from that
archive, so the analogous could easily be done with
pseudo-packages.maintainers. Also, this is an internal Debian file,
so it's good for dak in general to be able to get rid of it.
So, I propose that we:
* make the BTS hold the authoritative copyand export it via e.g.
http://bugs.debian.org/pseudo-packages.{maintainers,description}
(which I've just done)
* in case something other than the BTS actually uses those entries in
the debian/indices/Maintainers files, change the above script to have:
pseudomaint=$base/misc/pseudo-packages.maintainers
wget -T15 -q -O $pseudomaint
http://bugs.debian.org/pseudo-packages.maintainers
dak make-maintainers $nonusmaint $pseudomaint | [...]
* import the file into the version control system of the BTS,
remove config/debian/pseudo-packages.* from dak and its version control
* change the BTS scripts which build its maintainer indices to
include the local file without previously rsyncing it off ftp-master
* change the BTS the web site to fetch the files via HTTP rather than rsync
* remove the [masterfiles] rsyncd module from ftp-master
* (kick the reportbug maintainer to have reportbugs around the world
allow for the list of pseudo-packages to be updated in case it's
out of date by e.g. over a year :)
TIA.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449097: pseudo-packages.{maintainers,description} files belong to the BTS
On Sat, Nov 03, 2007 at 12:51:35AM +0100, Josip Rodin wrote:
* make the BTS hold the authoritative copyand export it via e.g.
http://bugs.debian.org/pseudo-packages.{maintainers,description}
(which I've just done)
BTW, this will also help the ftpmaster team easily do away with:
#119996: please make pseudo-packages.{description,maintainers} available
on the ftp site
#194206: [Pseudo-packages] Please add wiki.debian.net
#436152: [Pseudo-packages] Please add security-tracker
Solve one bug, get rid of three for free! :)
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449100: erlang-base: /usr/bin/* with manual pages elsewhere
Package: erlang-base Version: 1:11.b.2-4 Hi, The manual pages erl(1) and others are effectively missing from the erlang-base package. % dpkg -L erlang-base | grep /man/ | xargs zgrep full /usr/share/man/man1/erl_call.1.gz:The full \fIerl_call\fR manual page is included into \fIerlang-manpages\fR package. /usr/share/man/man1/run_erl.1.gz:The full \fIrun_erl\fR manual page is included into \fIerlang-manpages\fR package. /usr/share/man/man1/erlc.1.gz:The full \fIerlc\fR manual page is included into \fIerlang-manpages\fR package. /usr/share/man/man1/epmd.1.gz:The full \fIepmd\fR manual page is included into \fIerlang-manpages\fR package. /usr/share/man/man1/start.1.gz:The full \fIstart\fR manual page is included into \fIerlang-manpages\fR package. /usr/share/man/man1/erl.1.gz:The full \fIerl\fR manual page is included into \fIerlang-manpages\fR package. Since they document binaries in the erlang-base package, they belong to the erlang-base package, per Debian Policy 12.1. Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449099: erlang-base: /usr/bin/start is horrible namespace pollution
Package: erlang-base Version: 1:11.b.2-4 Hi, /usr/bin/start is polluting the namespace for the sake of what its manual page and comments inside describe as an example script. Since it is an example script, it belongs to /usr/share/doc/erlang-base/examples/, per Debian Policy 12.6. If nothing else, it's dangerously close to /usr/bin/startx which is from xbase-clients. If I even have to argue why that is bad, I'll just note that xbase-clients' popcon inst/vote scores are 51645/33843, as opposed to erlang-base's 1011/368. Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#6786: status
On Sat, Oct 13, 2007 at 11:07:45AM +0200, Josip Rodin wrote: This is the current status of setups for official mirrors: Updating most ...remaining ones :) And yet some more. And then some. This is another update. ftp.mx just got fixed a few days ago. The remaining mirrors that are definitely doing something screwy are: * ftp.ee - mirrors once, cron job * ftp.au - mirrors once, triggered * ftp.hk - mirrors once, cron job All have been contacted, some several times, and there has been no reply. :( -- Josip Rodin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
