Debian-Talk List Downtime
Hi folks, this list is not very active so no one would have noticed that the debian-talk incarnation of majordomo was not working for the last few weeks. Hehe, we installed debian on the list servers host... and, in short, messed up with the lists we are carrying in the changeover. All I have is an earlier list with about half the members, so, if you don't want to be on debian-talk then please unsubcribe again, and the grandest of apologies for any inconvenience. To: [EMAIL PROTECTED] Subject: nada unsubscribe debian-talk OR, use this web interface; http://www.vv.com.au/cgi-bin/vv/mailserv/majordomo -- Mark Constable (+61 7 55275724) http://vv.com.au
Re: 'unsupported packages' (was Re: uugetty?)
Kevin M Bealer wrote: > How about a debian-hacker@ or debian-guru@ mailing list where programmers > debian can all take a crack at problems as they arise for unsupported > packages? I think a lot of people would contribute who otherwise don't have > the flexibility/confidence to fully maintain packages... and people on the > list would probably, in time, start 'graduating' into maintaining packages. I fall into this catergory. I would like to maintain a package, or two, but lack the time to carve out how to do it myself, just yet some discussion and hints and tips would allow me to cover ground quicker. That was sorta the idea behind what became [EMAIL PROTECTED] I can appreciate that debian-user needs to focus on the userbase usage problems and that discussion just creates distracting noise. However I feel there needs to be some chanel(s) available to thrash out new ideas and perhaps go over old ones with fresh input. debian-talk could be used for this, or any purpose, and help keep the current chanels clear. So, by all means, use debian-talk if needed. It is also gated to a local newsgroup for those not inclined to be on YAML (yet another mailing-list). mailto:[EMAIL PROTECTED] (with "subscribe" in the body) news://news.ion.com.au/debian.talk -- Mark Constable (+61 7 55275724) mailto:[EMAIL PROTECTED] http://vv.com.au/mc
Re: more mirror questions
I just did some quick checking on the timestamp of the same file at 1/2 dozen sites... the target being "debian-manual.txt"; Mar 6 15:46 -> ftp.tower.net.au (GMT +8 hrs) Mar 6 23:46 -> ftp.debian.org Mar 6 23:46 -> ftp.ion.com.au(GMT +10 hrs) Mar 6 22:46 -> ftp.lh.umu.se Mar 7 06:46 -> ftp.caldera.com Mar 6 18:46 -> tsx-11.mit.edu So if one does not do a "mirror -T site" first then you stand the distinct possibility of re-fetching or losing all your current files if you do not check first. I can't really afford the overhead of of "mirror -n site" then a "mirror -T site" then the actual mirror run itself.. and that would cause 3 lots of global "ls -ltR" execs on the remote site, quite expensive. Anyone have some ideas or suggestions about streamlining this process ? --markc
Re: more mirror questions
[EMAIL PROTECTED] wrote: > That has been bugging me as well when I switched from ftp.debian.org to some > other mirror during the hick-ups at ftp.debian.org. It would be really nice > if we could store files dates in UTC (GMT) rather than in localtime. If we > can't persuade mirror(1) (haven't checked man page or code), maybe someone > could hack a script that "touch"es files with the info from the debian/ls-laR > file. Opinions? I've been plagued by this too, and have lost all 455 megs a week ago because of careless and frustrated swapping of source archives without checking first. Lesson learnt, I now do a mirror -T first to sync the timestamps. # man mirror use_timelocal Time-stamp files to local time zone. If false, the time zone is set to offset 0 (compatible with older versions of mirror). [true] I've tried the above but haven't done enough consistant checking to peg down just how it works. I'd also be interested in any suggestions. I exclude debian-bugs and -lists and I notice that when mirror does the compares with a mirror -d -d that it takes quite a long time to go thru all the files in debian-lists... just to figure out to ignore them. Would the below option skip over any exclude_patt dirs altogether ? recurse_hard Have to generate remote ls by doing cwd and ls for each subdirectory. In this case remote_dir must be absolute (begin with a /) not relative. Use the pwd command in ftp to find the path for the start of the remote archive area. (Not available if remote_fs is vms.) [false] -- Mark Constable (+61 7 55275724) mailto:[EMAIL PROTECTED] http://vv.com.au/mc
