Re: dpkg: dpkg-divert syntax error
> Unfortunately, dselect itself also seems broken---when I select the > 'U'pdate menu item, dselect exits with the following message: > > dselect: failed to getch in main menu: Success ObAOL: ME TOO111 Every item in dselect's main menu die()s with that message. Hmmm. >clickity-click< - chad
Re: upgrade nightmare from slink to potato
On Fri, Mar 10, 2000 at 07:03:03PM +0100, Bjoern Brill wrote: [...] > I also had to forcibly reinstall with dpkg some "severly broken" packages, > but I think this was only because I ran out of disk space in > mid-upgrade (aaargh!). [...] Ah, yes. I know the woes of this well. Low disk space can severely break a system, when changing software. Maybe I'll stop moaning and fix it, soon, when I have free time. (Ha!) In any case, failure should be nicer. Prompt me to remove the package, or leave the fragment still installed. Here's a not-entirely-related idea: FTPing every selection, and then installing everything in another pass wastes time and disk space. We can retreive and install at the same time (not the same thing, of course). If we divide a selection list into chunks by their interrelation, we can make a process get a lump of packages. When it's finished, it flags those packages as installable, and an installer does its thing (keeping the user busy with the usual questions) and cleans up those package files at the end, meanwhile the FTPer is transferring the next lump. If a package FTP fails, then we don't try to install its lump, and we grab the user's attention when the installer's finished with it. This way, one doesn't need half of your disk space free when upgrading-dist, e.g.. - chad
Caution Will Robinson! Caution!
On Sat, Mar 11, 2000 at 04:06:01PM -0500, Jacob Kuntz wrote: > what do you folks think [about 2.4.0 in potato]? Gak! I hope not. As a distro, we should be very conservative in what we put our 'good enough for you' stamp on. 2.3.$bignum/2.4.0 is feature-rich, but not tested enough to be in debian. Hell, I'm just (as ~.10) beginning to trust 2.2 kernels enough to put it in a locked closet a thousand miles away. I think it's very appropriate that our dev cycle nearly parallels the kernel's dev cycle. I say, let the kernels mature! 2.2 is just now[*] ripe enough for us to say to Joe User, ``this will work for you.'' - chad * Actually, it was a month ago. So, we're behind, but not by much.
of bash and ...sbin/
I like that debian's bash package has different paths for users and the superuser, but it's caused me to question ideas behind the placement of some programs in 'sbin' directories. For instance, a program joeuser uses often is 'traceroute' (which is in /usr/sbin). Other (questionable) ones might be /usr/sbin/fbset or /usr/sbin/lpc . Which is wrong? Is it bash' assumption that "only the superuser executes stuff in sbin," or that "these programs should be in sbin?" Essentially, by question boils down to "To which packages should I apply a bug report -- bash or the others?" This discussion might belong in debian-policy, depending on your answer. - chad ref'd... traceroute-nanog: /usr/sbin/traceroute lprng: /usr/sbin/lpc fbset: /usr/sbin/fbset
Re: of bash and ...sbin/
Gak! I'd like to unask the question (and I do promise to have myself flogged soon) except for Jacob's sub-topic: On Wed, Mar 22, 2000 at 11:52:37AM -0500, Jacob Kuntz wrote: > at the risk of reigniting a flame war, how is traceroute in a different > catagory that ping? That, I think, is a good question, and hopefully has an equally good answer. I suspect we'll point to Upstream, tho. Tho I know it doesn't mean a whole lot, really, the FHS notes that... # Deciding what things go in sbin directories is simple: If a user will # need to run it, then it should go somewhere else. If it will only be run # by system administrators or as root from system management scripts, then # it should go in /sbin (or in /usr/sbin or /usr/local/sbin if the item is # not vital to system operation). and ping, traceroute, and lpc aren't for administration of _this_ system (unless you count the print queue, in in which case, "/usr/bin/mailq, eh?") but it is for troubleshooting of the outside network or other machines. OTOH, i would leave ifconfig in /sbin, as it _is_ about this system, and it doesn't provide (much) information that DNS doesn't, unless there's sysadminning to be done. (There's also a huge amount of inertia that it be in /sbin/ .) (Don't reply without including the below, to help kill this thread!) NOW, having said all of that, the "Inertia says leave it be!" argument is _very_ compelling, at least for the near term. For woody (or woody+1), moving is likely a Good thing. That's far off, though. Potato must ship. So, sorry to have brought it up, and IAN-even-ADD. I will file no bug reports, until $release+2 . - chad
test -d /usr/man && mail submit@bugs
I noticed that the FHS2.1 doesn't have /usr/man -- only /usr/share/man.
On this box, there are...
$ find /usr/man -exec dpkg -S {} \; |cut -d: -f1 |grep -v , |sort |uniq
dpkg
catdoc
cdcd
cflow
dvidvi
electric-fence
fakeroot
hfsutils
libgdbmg1-dev
liblockfile1
libmime-base64-perl
lsof-2.2
m4
macutils
mailx
manpages
mime-support
mingetty
minicom
mpg123
pwgen
sc
sgml-base
sysklogd
untex
update
vim-perl
wenglish
wfrench
wvdial
...several packages that install stuff in /usr/man . Do these warrant bug
reports?
- chad
--
Chad Miller <[EMAIL PROTECTED]> URL: http://web.chad.org/ (GPG)
"Any technology distinguishable from magic is insufficiently advanced".
First corollary to Clarke's Third Law (Jargon File, v4.2.0, 'magic')
Re: test -d /usr/man && mail submit@bugs
On Thu, Dec 28, 2000 at 04:17:20PM +0100, Wichert Akkerman wrote:
> Previously Chad Miller wrote:
> > dpkg
>
> Looking at the changelog the dpkg manpage were moved to /usr/share/man
> in version 1.4.1.5, released Tue, 13 Jul 1999. I just checked and I
> have dpkg manpage in /usr/share/man on my system.
Ha! That's a bug/unexpected-feature of dpkg. Its errors look a lot like
the output of -S:
[EMAIL PROTECTED]:~$ ls -l /usr/man/man1/editor.1.gz
lrwxrwxrwx1 root root 29 Jun 29 2000
/usr/man/man1/editor.1.gz -> /etc/alternatives/editor.1.gz (bad symlink)
[EMAIL PROTECTED]:~$ dpkg -S /usr/man/man1/editor.1.gz
dpkg: /usr/man/man1/editor.1.gz not found.
[EMAIL PROTECTED]:~$ dpkg -S /badfilename
dpkg: /badfilename not found.
dpkg is fine.
- chad
--
Chad Miller <[EMAIL PROTECTED]> URL: http://web.chad.org/ (GPG)
"Any technology distinguishable from magic is insufficiently advanced".
First corollary to Clarke's Third Law (Jargon File, v4.2.0, 'magic')
Re: test -d /usr/man && mail submit@bugs
I don't suppose there's a easy way to submit a batch of bug reports, eh? - chad -- Chad Miller <[EMAIL PROTECTED]> URL: http://web.chad.org/ (GPG) "Any technology distinguishable from magic is insufficiently advanced". First corollary to Clarke's Third Law (Jargon File, v4.2.0, 'magic')
Re: test -d /usr/man && mail submit@bugs
> Chad Miller <[EMAIL PROTECTED]> writes: > > I don't suppose there's a easy way to submit a batch of bug reports, eh? On Thu, Dec 28, 2000 at 05:17:40PM +0100, Peter Makholm wrote: > Just do a > > for package in dpkg apt libc gpg bplay etc ; do > sed [...] bug.template | mail ; > done > > where sed do the right thing. That is an easy way, right? (say yes!) It's easy enough, but I link the word 'batch' and the BTS mentally for some reason -- one not justifiable by searching the web site. I think I've read ``here's how, but your almost certainly shouldn't be doing it because....'' Oh well. - chad -- Chad Miller <[EMAIL PROTECTED]> URL: http://web.chad.org/ (GPG) "Any technology distinguishable from magic is insufficiently advanced". First corollary to Clarke's Third Law (Jargon File, v4.2.0, 'magic')
Re: test -d /usr/man && ( mail submit@bugs; apology; )
On Sat, Dec 30, 2000 at 02:00:29AM +1100, Hamish Moffatt wrote:
> How many emails are we talking about? [...]
It was about thirty. I'm trully sorry about the whole ordeal.
It was stupid of me in several respects. At midday, I just abandoned
work until I had a full 8 hours sleep. If I could undo almost every
event of yesterday, I would.
At any rate, those bug reports are for only the packages I noticed.
I'm sure there are _many_ more that install /usr/man/ than I feebly
reported.
What's wrong with the reports: No version number. The problem may be
already fixed -- I checked against woody, and not sid!
What's right: The severity prolly should be 'serious'. (The latest
policy says to use FHS, and the BTS says policy violations are
'serious'. It's true that the worst that happens is broken alternatives
symlinks for man pages, tho. Release critical? Unlikely.)
- chad
--
Chad Miller <[EMAIL PROTECTED]> URL: http://web.chad.org/ (GPG)
"Any technology distinguishable from magic is insufficiently advanced".
First corollary to Clarke's Third Law (Jargon File, v4.2.0, 'magic')
Re: Path modification
> Jon Eisenstein <[EMAIL PROTECTED]> writes: > > I recently filed a bug report (80092) against the nmh package regarding > > the location of its program files. It installs files into /usr/bin/mh, > > which isn't in the path, making running the program difficult until the > > reason is found. MH is like that on every platform I've ever seen. MH users should be accustomed to altering their paths. Folks who don't use or know of MH can't accidentally screw themselves by typing 'import' (or whatever). > > A suggestion was made by the maintainer to file a report against > > base-files to add that to the default path Golly, I hope it's not. On Wed, Jan 10, 2001 at 11:03:53AM +0900, Miles Bader wrote: > I thought the reason for putting mh commands into a separate directory > was to avoid gratitous namespace pollution for the majority that doesn't > use mh (given that mh uses a lot of commands with overly generic names). > > If the mh bin directory is in the default path, what's the point? Agreed. - chad -- Chad Miller <[EMAIL PROTECTED]> URL: http://web.chad.org/ (GPG) "Any technology distinguishable from magic is insufficiently advanced". First corollary to Clarke's Third Law (Jargon File, v4.2.0, 'magic')
Re: radiusd-freeradius history and future
On Tue, Nov 11, 2003 at 10:13:22AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote: > On Sun, Jan 12, 2003 at 01:21:53PM -0500, Chad Miller wrote: > > [cc debian-devel] > > > > On Sun, Jan 12, 2003 at 05:07:41PM +0100, Toni Mueller wrote: > > > [...] Who withdrew [radiusd-freeradius] or caused it's > > > withdrewal, then? Curious minds want to know, and also, it's a bit > > > misty right now... > (...) > > > > A few months ago, the Sarge release coordinator swept all gravely-buggy- > > older-than-3?-months packages from sid, including radiusd-freeradius. > > Wichert immediately asked for the package to be added back, but someone > > noted that freeradius, a GPL program, linked against libssl, so it > > couldn't go back in. > > What is the current status of this issue? There are yet no > radiusd-freeradius (or freeradius) packages either in sid or (even) in > ftp://ftp.freeradius.org/pub/radius/. The issue on SSL linking (described > in DWN [1]) doesn't look as it is has been fixed and the debian/ directory > in the CVS has not seen any change for quite some time (+5 months) Hi Javi. I don't use RADIUS servers any more, so I've lost interest in maintaining FreeRADIUS. Someone in the freeradius-devel list (I don't remember who, atm) seemed interested in packaging it, at least with a sponsor. - chad -- Chad Miller GPG: 9E6947D9Jabber: [EMAIL PROTECTED] (not email) et c. @ http://wiki.chad.org/ChadMiller pgp9Fp0QOOPsN.pgp Description: PGP signature
Re: Hardware Compatibility List for Woody (exist)?
> [EMAIL PROTECTED] wrote: > > Is there any kind of Hardware Compatibility List for Debian(Woody)? On Mon, Apr 14, 2003 at 04:19:59PM +0200, Martin Schulze wrote: > Boot a Knoppix CD. If it detects and runs your hardware, it is supported. > If it doesn't, it isn't. [...] > Wasn't there a hardware database at linux.com or linux.org? I can't > find it anymore and I didn't really care before. Ya know, a reporting program along the lines of "popularity-contest" might be pretty useful. Add a simple interface to allow users to assert that some hardware does or doesn't work to some degree, to override "autodetection". An up-to-date compatibility list might be a snapshot of the past month's reports. Perhaps searching for some hardware could suggest the best boot image to use (matching reported kernel version to image version). It might assist the d-installer folks in seeing the "best common practice" of kernels and modules for some hardware. Anyway, I'm just "thinking out loud", not volunteering to write it. - chad pgp4WI1dzUr7e.pgp Description: PGP signature
