Re: description writing guide
On 04-Dec-02, 13:01 (CST), David B Harris [EMAIL PROTECTED] wrote: Also, in the description template, two spaces are used after a period - is that standard nowadays? (Yes, I've read some of the other responses to this.) In standard typography, it is to have extra space after a period ending a sentence. For fixed-width fonts, this often shows up as two spaces, as is fairly ugly. For variable width fonts, it's often very subtle, especially as if the text is also justified, which has a strong effect on spacing. However, this is all on *output* (display, whatever). The input text should have just a single space. The text has to be reformatted to fit the screen (display area) anyway (even on a terminal), and it's the job of the reformatter/text renderer/whatever to get it right. In practice, of course, most of the common text-based package display programs (aptitude, apt-cache show) will not bother to attempt to figure out which periods end a sentence, and thus need extra spacing. OTOH a lot of people (IMO) would argue that the fixed-width two-space end of sentence is sufficiently ugly that we're better off without it. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: update alternatives priorities
On 03-Dec-02, 15:30 (CST), Michael Cardenas [EMAIL PROTECTED] wrote: I'm fixing our package for ibmjava2-jre, but the man page should be clarified. Are there any accepted values to use with update-alternatives? Is it listed in some other documentation somewhere that I just didn't see? Fixing? How, by raising the priority? What happens when the maintainer of some other jre/jdk package raises its? You've seen the problem, but are on the wrong track for the solution. What you need to do is negotiate with the other maintainers who use that alternative and agree on the relative priorities each will use. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: debconf template translations from ddtp
On 27-Nov-02, 11:04 (CST), Steve Langasek [EMAIL PROTECTED] wrote: [use the BTS to notify maintainers about debconf translation updates] What he said. An e-mail to the BTS (perhaps maint-only) with the attached po file would be exactly what I'd want. (The BTS suport MIME attachements now, right?) Steve (another one) -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Accepted cron 3.0pl1-73 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 4 Nov 2002 18:14:45 -0600 Source: cron Binary: cron Architecture: source i386 Version: 3.0pl1-73 Distribution: unstable Urgency: low Maintainer: Steve Greenland [EMAIL PROTECTED] Changed-By: Steve Greenland [EMAIL PROTECTED] Description: cron - management of regular background processing Closes: 13952 74524 79037 122358 123269 124523 129177 130079 135013 146224 147277 150591 151006 151601 157822 159912 162676 164966 Changes: cron (3.0pl1-73) unstable; urgency=low . * Fixed spelling error in control file (Hi, Matt!) (closes: #124523) * Check for existence of /etc/init.d/cron in prerm (closes:#151006) * Added conflict for ancient version of lockfile-progs (closes: #123269) * Added Mosix FS to list of excluded FS types in checksecurity.conf (closes: #129177) * chmod group.bak instead of passwd.bak twice (closes: #130079) * Added ext3 for lost+found searches (closes:#135013) * Finally fixed longstanding bug where cron doesn't recognize crontab changes until 1 minute later. I don't know what I was looking at before, as it was trivial. I apologize to all those bothered by this problem. (closes: #74524, #13952) * Remove debian/preinst, used only for a fix for a pre-slink development release. * Added support for invoke-rc.d, patch from Andreas Metzler (closes:#162676) * Finally figured out why some error messages weren't getting printed for the system crontabs (/etc/crontab, /etc/cron.d/*). Added new error printing function and use it when user.c calls load_entry(). (closes:#79037, #122358) * Remove -odi option from invocation of /usr/sbin/sendmail. (closes:#146224) * Don't run @monthly jobs every day. (closes: #150591). Ditto @yearly. (Isn't it funny that despite the big whinefest about how critically important the @whatever timespecs are, nobody previously noticed this serious bug in the entire 7+ years I've been maintaining cron?) * Fix grammatical here in the cron(8) manpage. (closes: 147277) * Fix spelling error in checksecurity.conf. (closes: #151601) * Fix check for nfs/afs mounts in checksecurity. (closes: #157822) * Replaced some tabs with spaces in crontab.5. (closes: #159912) * Fix cron Makefile to not hardcode '-s' in $(INSTALL) commands. (closes: #164966) Files: 2ea85579f46d13608babefd167795644 560 admin important cron_3.0pl1-73.dsc 9ddf6e1f41088c435827b2f571e139f3 42274 admin important cron_3.0pl1-73.diff.gz 71e58287ad4111340b160f3dd4c92892 56984 admin important cron_3.0pl1-73_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE9zUpFdiZsUPux21MRAm5GAJ9yfgJmjLlG7nplUtod6oNspJPezQCghGYH 2qJWbrj5yaUCvoxbkfCt3RI= =UM0b -END PGP SIGNATURE- Accepted: cron_3.0pl1-73.diff.gz to pool/main/c/cron/cron_3.0pl1-73.diff.gz cron_3.0pl1-73.dsc to pool/main/c/cron/cron_3.0pl1-73.dsc cron_3.0pl1-73_i386.deb to pool/main/c/cron/cron_3.0pl1-73_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg should prompt re missing conffiles [was Re: When bind9 reinstalls, no db.root]
On 24-Aug-02, 09:48 (CDT), Oliver Elphick olly@lfix.co.uk wrote: On Thu, 2002-08-22 at 21:40, Steve Greenland wrote: While I'll grant you that dangerous is probably not the correct adjective, the current behaviour is correct. Debian policy is that packages don't override admin modifications to configuration files. Removing a file is a modification. End of story. The problem is not that it doesn't override, which would not be desirable, but that it doesn't flag a missing conffile during upgrading. Deletion of a file should be regarded as a change, and should merit a question about whether the default package file should be installed. It does. But you are asked about replacing only if *both* of the following are true: A. You've modified the conffile. B. The maintainer has modified the conffile. If only A is true, the conffile is left alone with no question. If only B is true, then the conffile is replaced with no question. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: When bind9 reinstalls, no db.root
On 22-Aug-02, 11:12 (CDT), Bernd Eckenfels [EMAIL PROTECTED] wrote: On Wed, Aug 21, 2002 at 11:38:36PM -0700, Marc Singer wrote: The trouble with removing db.root is that it may not be obvious how to recover when it is missing. the questions to replace/diff/keep a modified conffile, why dont they apply to missing conffiles, too? Because you only get that question if the distributed version of the conffile is changed also. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: When bind9 reinstalls, no db.root
On 21-Aug-02, 14:42 (CDT), Josip Rodin [EMAIL PROTECTED] wrote: On Wed, Aug 21, 2002 at 12:32:00PM -0700, Marc Singer wrote: How could it be dangerous to install a *missing* configuration file? If the default configuration data in the file do something you don't want. To be, perhaps, a little more explicit: there are programs for which the existence of an empty configuration file means something completely different than a missing a configuration file[1]. Thus, for dpkg conffile handling, removing a configuration file is a legitimate edit. Steve [1] E.g. /etc/cron.allow (crontab(1)). -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: When bind9 reinstalls, no db.root
On 21-Aug-02, 15:10 (CDT), Marc Singer [EMAIL PROTECTED] wrote: It would help to have an example. I could have sworn I had a footnote about /etc/cron.allow, with a reference to the appropriate manpage :-). Okay, it's not the *best* example, because I don't actually ship a cron.allow, but the point is there: A missing cron.allow permits everybody to use crontab, while an empty cron.allow forbids use of crontab by anybody (except root, of course). Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#156407: ITP: free-java-sdk -- Complete Java SDK environment consising of free Java tools
On 12-Aug-02, 14:22 (CDT), Adam Heath [EMAIL PROTECTED] wrote: On 12 Aug 2002, Grzegorz Prokopski wrote: W li¶cie z pon, 12-08-2002, godz. 18:13, Adam Heath pisze: Er, you say free, but are restricting me to only use what is listed in the depends. So, what about kaffe? What about gcj? Why are you saying that sable is better than these others? Maybe he's experimented with them and discovered that sable is the best/easiest/whatever works for him. Maybe he likes the name. Maybe the sable people are paying him off. In any case, he's making the package and thus gets to make the choice. If you want something else, then make your own congolomeration. I, for one, would be grateful to have a all-in-one Java setup, instead of having to pick through and figure out which packages I need, and which work well together. If the package choices don't suit you, then don't install it. Isn't that easy? I don't use xdm, and prefer rxvt to xterm, but I don't try to tell Branden what packages to put in the x-window-system package. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#156407: ITP: free-java-sdk -- Complete Java SDK environment consising of free Java tools
On 12-Aug-02, 15:55 (CDT), Adam Heath [EMAIL PROTECTED] wrote: So use virtual packages, which other packages provide, and which this new package depends on. Then the user is back to having to figure out which one actually works with the rest of the software. If you do this (virtual packages) for all the components, then there's no point to it at all. Saying that Debian doesn't make choices for the user is bullshit. We do it all the time: the contents of the base packages, the task packages. Making choices and value judgements is a good thing. Having 30 irc clients is good for the expert user with particular preferernces, but it's horrible for the beginner who has no idea which one is suitable. When it's something like JDK, built out of disparate components, I *want* a (presumed) expert to put them together and say hey, this combo works for me. After some experience, I might decided that (e.g.) sable is not the JVM I want to use, and I'll replace it. It's no big deal. But nobody is being forced, or censored, or any other of the bad words that are thown about any time someone makes a decision around here. Just for the hell of it, I'll claim that making all the dependencies in jdk-free virtual is a violation of the Social Contract, as it puts an undue burden on the users. That seems to settle most discussions. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: problem with debconf and start-stop-daemon
On 11-Jan-02, 08:45 (CST), Stefan Hornburg (Racke) [EMAIL PROTECTED] wrote: Yeah, but it is really a bug that should be filed. The daemon will be killed by SAK otherwise (look at #92277 for further enlightenment). You can't, in general, close *all* open file descriptors. OPEN_MAX may not exist (and I would guess that it doesn't on the HURD). It's completely reasonable for a daemon to that doesn't open any extras to assume that only stdin, stdout, and stderr are open. Steve
Re: no space left on device: LVM, Gnus -- dpkg, apt-get ?
On 06-Jan-02, 01:51 (CST), Egon Willighagen [EMAIL PROTECTED] wrote: Now, I am facing the following problem (after making more space): - how can i determine which packages were updated yesterday? - how can i (semi)-automatically reinstall these packages? I see that it turned out that the problem was different, but what I've done in similar circumstances is 'find' to list all the directories in /usr/share/doc that have been updated in _time period_, and feed the output to 'apt-get --reinstall install'. Steve
Re: VIM features
On 01-Jan-02, 18:06 (CST), Steve Greenland [EMAIL PROTECTED] wrote: Also, vim is higher precedence than nvi. Ack. That's no longer true. Sorry. Steve
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On 06-Jan-02, 04:55 (CST), Adrian Bunk [EMAIL PROTECTED] wrote: You need to do this in a portable way so that it works on every system... No, the people who want modern code to run on their systems need to figure out how to support the standard. Why should every piece of code contain the work-arounds to support broken systems, rather than expecting the systems to solve their own problems? It's the choice of the author of a program whether he wants to support older systems or not - Exactly. It's not required, and shouldn't even be expected. I'd much rather an author spent time adding features, or writing docs, or even relaxing with Quake than waste it supporting the 1993 version of Piece-o'-Crap OS. But that's my opinion, and if some one feels the need, then that's up to them. I remember that e.g. many GNU programs still support pre-ANSI C compilers. Which is really sad. It makes the code harder to read, and provides ample opportunity for subtle bugs when the standard code path is updated, and the non-standard one isn't. The only thing that really needs to support pre-ansi compilers is gcc (and possibly GNU make). Anyway, I suppose this is off-topic enough. The original point was that most people don't even know how to write standard conforming code, much less adjust for supporting systems that aren't. Steve
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On 04-Jan-02, 09:09 (CST), Jim Meyering [EMAIL PROTECTED] wrote: If every system had up-to-date, standards-conforming ctype.h support, we wouldn't have to worry much at all. But even these days, pretty many systems with buggy macros are still in use. Then fix those systems. Pull the necessary stuff out of glibc and use it rather than the system headers/libc. FYI, as far as I know, the most portable way to use the ctype macros is to define wrapper macros (e.g., like those below, from fileutils/src/sys2.h) and then use only the wrappers (upper-case names) from your code. rant What an abomination. I spent way too much of my youth doing crap like this. I'm tired of it. The standard has been in place for 12 fscking years. If the vendors aren't going to support it, then those systems are dead. I've better things to do with my time than make ugly code to support systems that haven't been upgraded for over a decade. /rant Steve -- Steve Greenland
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On 31-Dec-01, 19:42 (CST), Ganesan R [EMAIL PROTECTED] wrote: Another thing that puzzles me since this whole debate started. If you look at the declaration of ctype.h functions (isalpha family), they take a int as an argument. The reason the argument for these is int is a relic of the dark ages, aka KR C. Before function prototypes, there was no way to pass a real char (or short) to a function: such arguments were promoted to int. (Likewise, float was promoted to double -- thus all the math.h functions taking double args.) I don't know that I agree about needing to pass them unsigned char, though. The char-int conversion should be value preserving. If you pass a negative value, then you are making a domain error, and deserve what you get. Steve
Re: VIM features
On 01-Jan-02, 17:22 (CST), Craig Dickson [EMAIL PROTECTED] wrote: Caleb Shay wrote: However, as was pointed out below, vim is NOT the default vi when you install, Only true if you install nvi (or some other higher-precedence vi clone), which isn't required. (g)vim is the only vi-like editor I have installed. Then you've gone out of your way to make it so. Nvi is standard, vim is optional. Also, vim is higher precedence than nvi. Steve
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On 31-Dec-01, 16:30 (CST), Peter Finderup Lund [EMAIL PROTECTED] wrote: On 31 Dec 2001, Colin Walters wrote: No, the C standard guarantees that a char is exactly a single byte; i.e. sizeof(char) == 1. I think he meant wider than one would think-character. A char didn't originally have to be 8 bits wide -- the first edition of K R The C Programming Language explicitly mentions an implementation with 9-bit chars. I think the newer standards say you have to use 8-bit chars but with some sort of cat flap clause that allows exceptions if the platform is a weird DSP or something like that. Nope, the standard says that 1. sizeof(char) == 1 2. the range of signed char is *at least* -127 - +127 3. the range of unsigned char is *at least* 0 - 255 4. plain char shall act like one of (2) or (3) The net effect is that chars are *at least* 8 bits wide, but may be wider. The macro CHAR_BIT in limits.h will tell if if you really need to know. There is no requirement that char be exactly 8 bits; no cat flap required. Steve
Re: bind9-chroot (was: questions on ITP)
On 25-Sep-01, 09:34 (CDT), Christian Kurz [EMAIL PROTECTED] wrote: On 01-09-25 Steve Greenland wrote: I am so tired of hearing things like this. Nobody is forcing anyone to do anything. We already force them to use 2.2 instead of still using 2.0. You want the functionality, you use the right tools. You want to Were exactly do we force them? Which debian packages do not work well with a 2.0.x kernel? The standard Debian distribution kernel is 2.2. stick with 2.2, then *you* deal with the issues. The maintainers have That's a nice attitude, which will lead to the situation that people, especially administrators, will move away from debian to either other distributions, a bsd flavour or other free operating systems. Why? Because we don't change every aspect of our default system to cater to their individual preferences? One of the reasons that there are so many Linux distributions is that every body has a different idea of the right way, and no single distribution can make everyone happy. That's fine. Steve -- Steve Greenland [EMAIL PROTECTED]
Re: lintian releases
On 25-Sep-01, 17:56 (CDT), Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote: a) you declare a relation on a package more than once i.e. Depends: foo, foo ( 2.0). Note this check assumes that '|' relations are sane, so Depends: foo | bar | baz, foo is ok. How is that sane? I'm parsing that as (foo OR bar OR baz) AND foo, which is the same as (bar OR baz) AND foo, right? If so, it should be flagged as an error. (Yes, the dependendcy resolver should reduce it correctly, but it should reduce foo, foo ( 2.0) to simply foo ( 2.0) as well.) Steve -- Steve Greenland [EMAIL PROTECTED]
Re: PROPOSED: slight change to wnpp procedures
On 25-Sep-01, 22:59 (CDT), Anthony Towns aj@azure.humbug.org.au wrote: and filing, what, a dozen new bugs against ftp.debian.org every week is something other than harassment [0]? How is it harrasment? It's a todo list. And won't the bug be closed automatically when the package is installed? So it's hardly any extra effort for the ftp maintainers, and it provides a public and consistent place to track the status of packages with problems. Steve -- Steve Greenland [EMAIL PROTECTED]
Mounts with fs type 'none'
I've a request to have checksecurity skip searching filesystems with type 'none' (not device 'none'). A brief check leads me to believe that these are result of mount --bind, which means that the mount in question is either searched or skipped in its real location, and need not be searched in its bind location. Is this correct? Are there other types of mounts that lead to type=none in the output of 'mount'? Thanks, Steve -- Steve Greenland [EMAIL PROTECTED]
Re: Mounts with fs type 'none'
On 26-Sep-01, 18:31 (CDT), Ethan Benson [EMAIL PROTECTED] wrote: On Wed, Sep 26, 2001 at 06:15:34PM -0500, Steve Greenland wrote: I've a request to have checksecurity skip searching filesystems with type 'none' (not device 'none'). A brief check leads me to believe that these are result of mount --bind, which means that the mount in question correct, mount --bind is just a shortcut for: mount -t none -o bind /somewhere /some/where/else Thanks. Does anything else use '-t none'? (And why does mount(8) document '--bind' but not '-t none' or '-o bind'?) Steve -- Steve Greenland [EMAIL PROTECTED]
Re: bind9-chroot (was: questions on ITP)
On 25-Sep-01, 03:12 (CDT), Christian Kurz [EMAIL PROTECTED] wrote: As I wrote in two emails before, this isn't a solution, since this forces an administrator to use kernel 2.4.x instead of maybe still using 2.2.x. I am so tired of hearing things like this. Nobody is forcing anyone to do anything. We already force them to use 2.2 instead of still using 2.0. You want the functionality, you use the right tools. You want to stick with 2.2, then *you* deal with the issues. The maintainers have suggested a reasonable solution. If you don't like that solution, then it's *your* problem, not theirs. Steve -- Steve Greenland [EMAIL PROTECTED]
Re: Purposely broken/uninstallable packages in archive
On 19-Sep-01, 18:16 (CDT), Ethan Benson [EMAIL PROTECTED] wrote: read the description for xfsprogs-bf and e2fsprogs-bf, your NOT SUPPOSED to install them. we need them for boot-floppies. Fine. Why are they in the main archive? If it's so that the bf can access them over the net, then they can and should go into a special archive. Steve -- Steve Greenland [EMAIL PROTECTED]
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On 15-Sep-01, 09:14 (CDT), Edward Betts [EMAIL PROTECTED] wrote: Steve Greenland [EMAIL PROTECTED] wrote: On 13-Sep-01, 18:37 (CDT), Edward Betts [EMAIL PROTECTED] wrote: Your scheme works, but at least tell the sys admin what is going on with a debconf note. If you don't want to be bugged change the debconf priority. I've got it set to high. Apparently a number of maintainers think that every little thing is of high importance. There is already a standard, reliable way of communicating package changes to the admin. Amazingly enough, it's called a changelog. I usually find them under /usr/share/doc/packagename/... Steve -- Steve Greenland [EMAIL PROTECTED]
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On 15-Sep-01, 13:24 (CDT), Josip Rodin [EMAIL PROTECTED] wrote: On Sat, Sep 15, 2001 at 11:11:20AM -0500, Steve Greenland wrote: There is already a standard, reliable way of communicating package changes to the admin. Amazingly enough, it's called a changelog. I usually find them under /usr/share/doc/packagename/... We can't really expect the admins to parse through hundreds of changelogs; But if it becomes common place to list changes in debconf notes, then the admins will be overwhelmed by them as well, if every upgrade leads to 50 new e-mails. Consider what we're talking about: A package is moving files from one directory to another, and replacing the original directory with a symlink to the new one (assuming that's what Elie decides to do). Why does every admin need to be notified? Nothing should break, and there's really nothing the admin needs to do. There's no harm in the symlink. What about this deserves anything more than a note in the changelog? Now if Elie decides that he does what to move the files, but not deal with the symlink, then yes, it does deserve more than a changelog note, because we can expect at least some people will have things stop working. No, I don't actually expect most users/admins to read every changelog: I certainly don't. But *any* channel that gets overused loses significance, I'd hate to see that happen to debconf. Steve -- Steve Greenland [EMAIL PROTECTED]
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On 13-Sep-01, 18:37 (CDT), Edward Betts [EMAIL PROTECTED] wrote: Debconf question: do you want a symlink. Please, no. The fact that debconf provides an easy, consistent way to interact with the user does not mean that every possible choice that a package makes needs to ask the user. If I wanted to make all the choices, I'll build from source :-). Either put in the symlink, or don't, but don't bug me about it. If you want to put in the symlink, but allow the admin to remove it permanently, do this: 1. If a new install, don't add symlink (no installed base). 2. If upgrading from a version that had /usr/lib/procmail-lib, put in symlink. 3. If upgrading from a (newer) version that did not have /usr/lib/procmail-lib, don't do anything (neither add nor remove symlink). This is easy by looking at the arguments to the postinst and using 'dpkg --compare-versions'. One of the reasons for debconf was to allow for non-interactive installs, but we seem to be going in the wrong direction sometimes. Steve
Re: Why isn't apt 0.5.4 moving to testing?
On 13-Sep-01, 17:50 (CDT), Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Christian Leutloff wrote: Is it really necessary that the package must be able to be upgraded on every architecture!? That's the whole purpose of testing, keep the brokenness to a minimum. So now we have the situation with testing having a buggy core tool (apt) on all architectures, to avoid having broken accessory tools on a few architectures? Yeah, that makes a lot of sense. We really (okay, you, Anthony :-)) really need to consider the idea of allowing architecture slips in testing, if, there's been a package that has been waiting more than (say) 10 days on a rebuild on fewer than (say) 30% of the architectures. That way, the affected packages wouldn't break on the recalcitrant architectures, they just won't be as current. Yes, that might have be tightened up as we approach release. But at least the packages would get more testing on the most used architectures. Now, if the package won't *build* on the problem architectures, that's a different problem. But if the autobuilders are just behind, then the people who want to support those architectures need to deal with the problem. Steve
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On 14-Sep-01, 10:18 (CDT), Steve M. Robbins [EMAIL PROTECTED] wrote: Err, why not just test for the existence of directory /usr/lib/procmail-lib ? Is there an advantage to checking the package version instead? Because by the time the postinst runs, /usr/lib/procmail-lib is gone. If it's not there, is it because: a) I'm upgrading from a version that had it (as a directory), and should create the symlink? or b) I'm upgrading from a version that didn't, and the sysadmin has removed the original link (created in case a, above), and I shouldn't create the symlink? You could check in the preinst and cache the result, I suppose, but checking the version is easy: if [ $1 = configure -a -n $2 ] dpkg --compare-versions $2 lt 3.0pl1-43 ; then (replacing 3.0pl1-43 with whatever the first version of procmail-lib is that moves the files from /usr/lib to /usr/share). And it's fast, dpkg doesn't read any of its files for this. Steve
Re: Bug#112020: ITP: keychain -- An OpenSSH key manager
On 12-Sep-01, 19:08 (CDT), Cesar Mendoza [EMAIL PROTECTED] wrote: I find the package useful and I'm also aware of the shortcomings of ssh-agent, but was your solution to cron job's that do rsync over ssh? and I don't think that pass phrase less keys is an option. Why not? Create a dedicated key for the job, and set the options on the key to minimize its functionality[1] to only that absolutely needed for the job (from=myhost.whatever, etc.). That, to my taste, seems a lot more secure than what keychain does. Admitted, that may be only my perception, but I doubt that it is an *less* secure. What you are doing is building a case against ssh-agent, keychain is just a wrapper around it. Ssh-agent can be used and abused. Keychain seems to encourage abuse. It adds an extra layer of things to go wrong. Steve
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On 13-Sep-01, 10:27 (CDT), Elie Rosenblum [EMAIL PROTECTED] wrote: On Thu, Sep 13, 2001 at 12:53:49AM -0400, Matt Zimmerman wrote: On Wed, Sep 12, 2001 at 10:51:04PM -0400, Elie Rosenblum wrote: Would turning /usr/lib/procmail-lib into a symlink to the appropriate location be acceptable? I would really rather avoid breaking every rcfile that currently uses any of these recipes. This, in particular, won't work, because dpkg won't replace a directory with a symlink. You could, however, replace the files themselves with symlinks, and if you decide that it is important enough to transparently preserve backward compatibility, I would recommend that you do that. Hmmm, I thought that had been fixed, but I may be thinking of something else. Good point, I hadn't gotten that far yet. Thanks. But what you can do is add the symlink in the postinst. This would mean failures while the install was processing, but then again, so would no symlink at all :-). -- Steve
Re: sysctl should disable ECN by default
On 05-Sep-01, 16:35 (CDT), Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Wed, 05 Sep 2001, T.Pospisek's MailLists wrote: But tell me *one* thing: Why is it so hard to change a few lines and have the default be set to *off* and let whoever feels like it enable it? Because apparently Xu feels equally strong about not allowing someone else's irresponsability (the router firmware writer's) to force him to disable something he believes is right (or force him to change the default kernel behaviour against upstream wishes, or whatever) ? 1. The default kernel behavior is that ECN is completely disabled. 2. While I happen to agree that ECN is a good thing, and that routers that screw it up *are* broken and violating old RFCs (reserved is reserved, not let's zero it out 'cause we don't know what it means), I can't help but think that if someone's first experience with Debian is that the network install fails silently because ECN is enabled and some router between him and the archive is broken then we have failed to meet our (implied?)commitment in the Social Contract. All the newbie is going to know is that it doesn't work. Boy, I'm glad we've made our political point. 3. ECN-broken routers are not equivalent to non-compliant IMAP clients. I don't know about you, but I don't have control over the path my packets take over the internet. If there's a broken router in that path, there's not a whole lot I can do about it. And for that matter, there are lots of clients and servers with code to accommodate broken-but-popular servers and clients (respectively). Steve
Re: reopening ECN bugreport/netbase
On 05-Sep-01, 18:14 (CDT), Neil T. Spring [EMAIL PROTECTED] wrote: 2. A configuration option, when you know concensus on this list is that there will be none; and that the default will be on. No, I don't think that's the concensus. I agree that the kernel package can't change another packages conffile, but that doesn't mean the issue cannot be worked around Debian users who have broken equipment will just have to be clueful enough to disable ECN if they find that their router violates RFC 791. Help them have a clue. The problem is not Debian user's with broken equipment. The problem is that if any router between them and the target system is broken, they get screwed. What do you suggest they do? And before you say contack the admin of the broken router, I suggest you try to a) find out who is responsible for an arbitrary router. b) find out how to contact said person. c) find out how far you get when you, internet newbie, try to tell them their equipment is broken. It's simply not a realistic answer for most people (i.e. those without existing contacts or a sufficiently high position/reputation.) Steve
Re: Finishing the FHS transition
On 06-May-01, 14:27 (CDT), Adrian Bunk [EMAIL PROTECTED] wrote: Policy says: -- snip -- In the source package's `Standards-Version' control field, you must specify the most recent version number of this policy document with which your package complies. The current version number is 3.5.4.0. This information may be used to file bug reports automatically if your package becomes too much out of date. -- snip -- Uhh, when did that become a must? In 3.5.2 the first paragraph says You should specify the most recent version of the packaging standards with which your package complies in the source package's `Standards-Version' field. Even in 3.5.4, towards the end of that section it says You should regularly, and especially if your package has become out of date, check for the newest Policy Manual available and update your package, if necessary. When your package complies with the new standards you should update the Standards-Version source package field and release it. It says nothing about uploading just to notify that you are still compliant. Hmmm, I don't remember a proposal to change this; I suspect the must slipped in during the recent rewrites, and as Chris Waters pointed out, it is certainly inconsistent with the intent of the field according to recent discussion. you must specify the most recent version number of this policy document with which your package complies: You must upgrade this field when your package complies with a more recent policy - and when your package does already comply with a more recent policy nothing more than an upload with an updated Standards-Version field is needed. Nonsense. I'm not going to upload new versions of packages simply to change that field. Lot's of policy updates have zero effect on most packages, and I doubt many of our users want to spend the time and money downloading and installing a new version of a package to confirm that. I would strongly object if (for example) Branden suddenly started uploading new versions of the X packages every time a new version of policy was released. I'll wait a few days for one of the policy editors to say Oops, that was an accident; if that's not the case, I need to propose an ammendent that clarifies reality, so that Adrian doesn't get mislead again :-). Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Many ports open by default
On 04-May-01, 07:49 (CDT), Turbo Fredriksson [EMAIL PROTECTED] wrote: Quoting [EMAIL PROTECTED]: On Mon, Apr 30, 2001 at 11:52:46PM +, Will Lowe wrote: I think it's safe to assume that your system MUST have a working MTA of some sort (even if it's local-only, which is supported by eximconfig). This is true, but does it need to be world-accessible? There should be a way to either have it listen on localhost only, or not listen on Sure, don't run the daemon at all. When you install exim, rm /etc/init.d/rc?.d/S*exim and it won't start. Local processes will be /etc/rc?.d/S*exim *beep, wrong* :) update-rc.d -f exim remove *beep*, *wrong* :) The problem with update-rc.d -f exim remove is that it removes *all* the links, not just the S*exim links. The next time exim is upgraded, it's postinst will re-install all the links. Just rm'ing the S*exim links will produce the desired affect. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: dpkg-statoverride: usage question.
On 02-May-01, 09:37 (CDT), Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Rob Browning wrote: I realized that maybe dpkg-statoverride was only intended for the local admin, and that I should just ship my file properly sgid mail. So which interpretation is correct? Neither :). The reason you always had to call suidregister was that that was also the moment an override was applied. With statoverride dpkg itself applies the override, so you only no to use dpkg-statoverride to add or remove an override. Specifying default permissions is also no longer needed since dpkg gets those from the package itself already. Okay, now *I'm* confused. If dpkg is getting the default permissions from the package itself, doesn't that imply that Rob needs to ship the file properly sgid mail? Or are you saying that by default nothing should be sgid? Also, I thought dpkg-statoverride is, in fact, intended only for the local admin. Puzzled by the Neither :), Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Proposing task-debian
On 01-May-01, 12:50 (CDT), Vince Mulhollon [EMAIL PROTECTED] wrote: On 05/01/2001 12:40:24 PM roland wrote: Vince Mulhollon wrote: From my poor memory, the generally agreed best idea is to setup two packages, vaguely like this: Package name: task-abc Conflicts: task-abc-remove Depends: abc, bcd, cde, def Package name: task-abc-remove Conflicts: task-abc, abc, bcd, cde, def Please, NO! This is a pretty ugly hack and there are better ways to do this, e.g. the debfoster aproach. I don't agree at all with you that this is the generally agreed best idea. Rather the opposite. Oh, I don't know if it's an ugly hack. Well, one reason it's ugly is that your -remove tasks will show up in the Task Selection dialog that runs before the initial install. I expect that many new users would be rather confused... Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Lightweight Web browsers
Omn 27-Apr-01, 15:46 (CDT), Christian Kurz [EMAIL PROTECTED] wrote: Not only me. It's just that the Gnome Libaries install a bunch of packages and also need quite some disk-space. Therefor I and I think some other people too would like to know before if the software depends on that bunch of libraries or not. apt-get install foo shows all the new packages it's going to install before doing anything, giving you plenty of time to stop it. What's the big deal? Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: simple g++-3.0 problem
On 27-Apr-01, 14:22 (CDT), Ulrich Eckhardt [EMAIL PROTECTED] wrote: On Friday 27 April 2001 20:49, Dale E Martin wrote: #include iostream.h nitpick use #include iostream /nitpick nitpickier Doesn't which of these you use depend on whether you want the old (ATT?) iostreams library or the C++ standardized version? Agreed, new code should use iostream, but I'm stuck maintaining a lot of old code that breaks with iostream, due (among other issues) to changes in the public/protected/private status of various methods and attributes. /nitpickier (Of course, I'm not using g++ on those systems, so maybe that doesn't apply here.) Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Curious e-mails from yucom.be
Today I received several e-mails that were near duplicates of interactions with the BTS last sunday, both from me and from others. The originals had headers like this (I've trimmed the extraneous stuff): Received: from gecko by master.debian.org with local (Exim 3.12 1 (Debian)) id 14rP8Z-0003SF-00; Sun, 22 Apr 2001 14:03:11 -0500 Received: via spool by [EMAIL PROTECTED] id=B79711.98796614612819 (code B ref 79711); Sun, 22 Apr 2001 19:03:08 GMT The duplicate has: Received: from btbntsys1.yucom.be (yucom.be) [212.8.180.1] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 14sj3f-00054p-00; Thu, 26 Apr 2001 05:31:35 -0500 Received: from mail pickup service by yucom.be with Microsoft SMTPSVC; Thu, 26 Apr 2001 12:27:07 +0200 Received: from murphy.debian.org ([216.234.231.6]) by yucom.be with Microsoft +SMTPSVC(5.5.1877.197.19); Sun, 22 Apr 2001 21:01:12 +0200 Received: (qmail 22943 invoked by uid 38); 22 Apr 2001 19:03:31 - Received: (qmail 22820 invoked from network); 22 Apr 2001 19:03:29 - Received: from master.debian.org ([EMAIL PROTECTED]) by murphy.debian.org with SMTP; 22 Apr 2001 19:03:29 - Received: from gecko by master.debian.org with local (Exim 3.12 1 (Debian)) id 14rP8Z-0003SF-00; Sun, 22 Apr 2001 14:03:11 -0500 Received: via spool by [EMAIL PROTECTED] id=B79711.98796614612819 (code B ref 79711); Sun, 22 Apr 2001 19:03:08 GMT Note that the message id is the same; it just went to yucom.be, who held it for a 4 days and then respewed it back to me at master. Any ideas what's going on? Or how I can make it stop? Thanks, Steve PS Notice that I refrained from making any snide comments about crappy Microsoft mail servers. -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Gnome bug 94684
On 26-Apr-01, 06:52 (CDT), Jaldhar H. Vyas [EMAIL PROTECTED] wrote: On 25 Apr 2001, Thomas Bushnell, BSG wrote: Second, I can't keep track of who upstream is for all the Debian packages. Why not? It's in the copyright file of each package. If it isn't--that's a bug. Zhaoway is right that you're a big boy and can talk to upstream developers without having to go through a middleman. Yes, Thomas *could* report the bug upstream. However, he shouldn't have to; one of the Debian developer's jobs is to deal with this kind of stuff, even if dealing with it is only forwarding it upstream and marking it as such in the BTS. Our user's have every right to expect this. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Referring what kernel-images to build to the technical committee?
Good summary, Sam. I'd like to add a couple extra points: On 25-Apr-01, 19:30 (CDT), Sam Hartman [EMAIL PROTECTED] wrote: Should build custom: Some argumed that users should build a custom kernel and the distribution was doing them a disservice by trying to provide kernels that met their needs. There was also a slightly different argument: That *if* the user needs the slight performance improvement offered by a CPU optimized kernel, then *probably* that user is both capable of building his/her own, *and* would gain further (and possibly more significant) performance benefits by many other choices one could make when configuring a kernel (module vs. non-module, etc.) Confusion: Adding 8 (or whatever it is) variations of each kernel version is going to make it harder to select the appropriate one. There is some fraction of the target audience who won't know what kind of CPU they have, and we don't want to have to add to the Debian installation instructions: Now open your computer's case, and locate the large chip with fans hanging off of it. Write down the numbers and letters on top of the chip. Now look them up in this table to determine the best kernel for your machine. How larget that fraction is I don't know, but I'd wager it was larger than 0. Archive Size: CD Size: Bandwith: Module Multiplication, size, bandwidth: Someone (sorry, forget who) proposed that instead of actually distributing a lot of different stock kernels, we distribute some sort kernel-tuner package that included the various config files and made it easy for a user to build a custom kernel that matched the Debian stock kernel except for CPU specificity (and one could extend this to a matrix of CPU/AGP/DRI choices). Perhaps it could present a menu of choices (pick the things you have) and then select (or generate) the appropriate config file, use make-kpkg to build the new kernel, and then install the new kernel.deb. Yes, it would take longer, but it doesn't have any of the negative impacts on the archive, and it starts the user on the path to custom kernel competency. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: NMUers: STOP BEING STUPID
On 23-Apr-01, 18:52 (CDT), Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote: This would prevent the NMUers from doing things like debhelper/debconfizing packages without the maintainer's consent, as well as keep NMU bugs down. NMUs should *never* change the build/install process to such an extent. NMUs are for fixing bugs in packages that are not being maintained (perhaps temporarily, while maintainer is on vacation). Until debhelper/debconf become required, such a substantial modification should be prohibited. This isn't a matter of oversight, simply common-sense. If the package has been unmaintained for so long that one person is effectively the full-time maintainer via NMUs, then they need to adopt the package. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: NMUers: STOP BEING STUPID
On 23-Apr-01, 17:26 (CDT), Hamish Moffatt [EMAIL PROTECTED] wrote: The NMU was buggy, but with all due respect it appears that the package had not been updated in a long time before that. The standards-version was really old and you were using pre-FHS path names. If the NMUer had followed procedure (attempted to contact maintainer, filed diff in BTS, etc.), this might be a legitimate counter-argument. Given that the bugs being fixed weren't RC, to introduce a new bugs (and not even subtle ones) seems particulary ill-advised. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: bugs + rant + constructive criticism (long)
On 04-Jan-01, 15:24 (CST), John Galt [EMAIL PROTECTED] wrote: On 4 Jan 2001, Manoj Srivastava wrote: MS He may have, as I do, intend to reply to the list, so everyone MS can see the conversation. (Quite properly, my MUA ignored the reply MS to on a list reply; had I cared to respond to you personally, the MS reply-to header would have been respected). Yeah, but he was making the point that the reply-to header broke things like listreplies. They still seem to work Manoj was correct about my intent. The point I was making was that munging Reply-To: to point to the list breaks *personal* replies. Sorry that wasn't clear. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: our broken man package
On 04-Jan-01, 12:32 (CST), Joey Hess [EMAIL PROTECTED] wrote: Lars Wirzenius wrote: And, anyway, caching might be done in a cronjob: look at the pagesa in manpath every night, check which ones have been accessed since the past run, and format those. Then delete anything older than N days in the cache. When displaying, use the cached version only if it is newer than the source. That's a good idea. The only (small) problem is that you don't cache the first day. Thus the sequence man bash try something man bash try something else man bash (etc...) results in the bash man page being formatted each time. (Yeah, if I *knew* was going to be looking at it several times, I'd save it myself, or use another window/console, but it never seems to work out that way.) Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: bugs + rant + constructive criticism (long)
On 03-Jan-01, 22:53 (CST), John Galt [EMAIL PROTECTED] wrote: On Wed, 3 Jan 2001, Branden Robinson wrote: I didn't say there was. Does Mail-Copies-To: begin with an X? RFC 822 this time: http://www.faqs.org/rfcs/rfc822.html and Mail-Copies-To: fails to rear it's ugly head, so really should be under user-defined fields, which are supposed to be X- Uh, there have been headers added since 822. Why should I, when it would be no different from my From: header? It would be in your case: Reply-to: debian-devel@lists.debian.org would avoid the unnecessary CCs, which is what I assume you want to do. Wrong. This would break my MUA so that reply no longer sends mail back to the originator, as it is supposed to do. The difference between pine and mutt is that you KNOW the overflows in pinemutt allegedly shares code with pine... Extremely unlikely, as it originated from elm. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
On 03-Jan-01, 07:41 (CST), Eray Ozkural (exa) [EMAIL PROTECTED] wrote: Peter Palfrader wrote: Did you do this first? No. I'm sending it here because I want it to be seen. Why not send it the package maintainer, who can actually do something about it, rather than whining to us? It is not unreasonable for a package maintainer to ask for more info. Yes, he can probably find it, but since you have presumably already done the work, why is it such a big deal to provide it? Yeah, closing the bug probably was bit much, but it got your attention, didn't it? Most of the time when I ask the original submitter for more info, I get ignored (and eventually close the bug). Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: bugs + rant + constructive criticism (long)
On 03-Jan-01, 13:26 (CST), Philip Brown [EMAIL PROTECTED] wrote: reply-to is meant to direct where you should send replies to. And in the case of the debian mailing lists, you should reply to the list. No, you shouldn't. (And there lies the crux of the issue. One side things a little extra effort to send a message to several hundred (thousand?) people is a good thing. The other thinks that any possible words they utter deserve viewing by those same hundreds (thousands?) of people. One can probably discern from my description which side I'm on. :-)) Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Bug#70269: automatic build fails for potato
On 31-Aug-00, 12:43 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote: On Thu, Aug 31, 2000 at 08:29:30PM +0300, Antti-Juhani Kaijanaho wrote: Which is just a stupid pain in the ass. I had to track through three different references and finally install the build-depends package to find out what I could leave out of by Build-Depends stanza. It would *much* easier for developers, if less ideologically pure, to just list the damn packages on the Developers Corner part of the website. Could we add this as a footnote to the relevant section in policy or the packaging manual (can't remember which offhand)? Um, the current note in policy manual is not sufficient? (It explicitly mentions the package build-essential.) I guess. Maybe he didn't look in the right place ;-) rant That would be cute if the right place wasn't so fucking hard to find. The policy manual says look in build-essential. The control file for Build-essential says look in policy manual, and includes two different list files, one of which is completely pointless, the other of which has the needed info buried in the middle of a bunch of definitions and syntax. This is all needless run-around. Just put the list on the website, and in the policy manual as a footnote. I *understand* that the list is not the official definition. Feel free to post the official definition, and the say the current list x, y, and z. But stop making people spend 15 minutes hunting for information that should be listed everywhere that that build-depends is mentioned. /rant Why are people determined to make information so hard to find? Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#70269: automatic build fails for potato
On 31-Aug-00, 16:52 (CDT), Manoj Srivastava [EMAIL PROTECTED] wrote: I think that you start with a particular version dependency, and then only update the dependency if you use new features not present in older helper packages. This can be tricky, as it is easy to use a new feature without realizing it, unless one digs through the changelog everytime one edits debian/rules. Arguably, though, that's a reasonable cost for using the helper package, so I'll concede. Actually, I do have versioned dependencies on dpkg-dev, and the process works as I outlined above -- older version of dpkg-dev broke for my packages, and I created a versioned dependency -- and have never had to change that, really. That's fine -- if there is a need for the dependency, add it. But forcing many developers to add a build-depends line solely in order to specify debhelper seems unnecessary. Well, I think that these customers are so few, and need to be quite competent, often have to have a list of packages that goes beyon just the build essentials. We should not need a policy and a package for just these consumers. The whole Build-Depends stuff originated from the need of the large scale auto-builders and architecture porters to be able to reliably build packages. Our differences seem to stem from this basic difference in opinion: whom is the build essentials package primarily for? And my take is that the primary consumers are the developers of the 5000+ packages, and additionally, a few buld daemons, most of whom need a core set that may not be reflected in build essentials. Your opinion, obviously, differs. I think I miswrote earlier: I wrote build-essentials when I should have written Build-Depends. And I'd wager that the vast majority of the Debian developers have no need at all for Build-Depends. The build-essentials list *is* needed to prevent them from going crazy *supporting* Build-Depends. But that's the only reason build-essentials exists -- without Build-Depends, there's no need. And if the auto-builder core set is not represented buy build-essentials, then I think there's something wrong. Note that I'm *not* saying Build-Depends is a bad thing: the porters do a incredible job, and anything that makes their lives easier is worth doing. But we ought to also minimize the cost to the other developers. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Free Pine?
On 01-Sep-00, 02:50 (CDT), Joseph Carter [EMAIL PROTECTED] wrote: Actually, we did get an answer - from Lori (Lori's last name escapes my memory, but it was the person who sent the message you forwarded) - saying that what we are doing with imapd is not against its license and if it turned out that it actually was, we were being given permission to do so. Of course, if the latter were necessary, imapd would still be non-free according to our guidelines. The former appears to be the case in our opinion, in Lori's, and from what I gather, yours in other contexts. I disagree with your last sentence; here's what Lori wrote: UW's intent has always been to allow others to modify the UW IMAPD for their own needs, or to redistribute the original version, without having to ask for permission. We do expect and appreciate folks to ask before re-distributing derivative works, but obtaining permission is not onerous. Many have asked and they've all received permission. We are happy and willing to work with Debian so that Debian may continue to distribute UW's IMAPD. First of all, by this message you have our permission to distribute a modified version of IMAPD. That to me says Debian has permission to re-distribute our modified version, but that people who recieve it from us do not, unless they too ask permission (We do expect and appreciate...). Non-free. If she had written just We appreciate... I'd be comfortable putting it in free. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#70269: automatic build fails for potato
On 01-Sep-00, 12:10 (CDT), Jaldhar H. Vyas [EMAIL PROTECTED] wrote: On Fri, 1 Sep 2000, Steve Greenland wrote: I think I miswrote earlier: I wrote build-essentials when I should have written Build-Depends. And I'd wager that the vast majority of the Debian developers have no need at all for Build-Depends. What about for users who want to rebuild the package for whatever reasons? Many times you get half way through some huge package and it craps out because you didn't have some esoteric header file or library. Build-depends is invluable for avoiding those kinds of annoyances. Those people would be equally well served by a note or check at the beginning of the debian/rules file; we didn't need policy and a new control file headers for that. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#70269: automatic build fails for potato
On 01-Sep-00, 15:04 (CDT), Jaldhar H. Vyas [EMAIL PROTECTED] wrote: On Fri, 1 Sep 2000, Steve Greenland wrote: Those people would be equally well served by a note or check at the beginning of the debian/rules file; we didn't need policy and a new control file headers for that. Alright. What if apt-get source was enhanced so it would pull down any packages needed to build? If you didn't have build-depends where would it get that information from? I didn't say that individual users couldn't benefit from Build-Depends, only that it isn't *necessary*. Once you've implemented it, yeah, enhancing other tools to support it makes good sense. But I don't think it would have been worth doing except (primarily) to support the porters/auto-builders. They (or at least some of them, I forget the details) were trying to maintain similar info in a central repository, which was a pain when the requirements of package changed. Requiring the individual maintainers to track this makes sense. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#70269: automatic build fails for potato
On 31-Aug-00, 07:18 (CDT), Manoj Srivastava [EMAIL PROTECTED] wrote: Firstly, build essential package is ot merrely for build daemaons. No, but I think that's the primary reason for it's existence. If it was mainly for humans, it would be sufficient to have checks in the in debian/rules, or a list of required packages somewhere in README.Debian. Therefore packages would need to specify the oldest version of the build package they can be built with (in the worst case, exactly the version they were built with), since not every machine they can be built on can be depended to ahve the altest version of the helper packages. So I'm supposed to go back and figure out if my packages can be successfully built with debhelper 2.0.58? If so, how can I -- is there a complete archive of all released debhelpers somewhere? I don't think this is going to happen. Instead, I'll just (probably automatically) update my build-depends line to the version of debhelper that's installed on my machine. So the de-facto requirement is going to be a nearly current version of debhelper. The same is true for the build-essential packages -- nobody is going to go back and check their stuff against old versions of gcc and make. Admittedly, those are much slower moving targets...but dpkg-dev isn't, necessarily. Indeed, none of may machines have _any_ helper packages installed. But you're not running a build daemon, or otherwise trying to build a significant number of packages from source. People doing so are the consumers of Build-depends. If you were, I don't think you'd object to being expected to having a helper package installed (well, you might object, but the helper packages *are* a reality, and *are* widely used). I think that since every package using a helper package seems to need a versioned dependency, addign debhelper to build essential shall not remove the burden from the packages. Mine don't. Or rather, the version needed is sufficiently old that I have no idea what it might be. Hmmm, let me ammend that. To comply with *current* policy, I need a (nearly) *current* version of debhelper. But my package builds won't fail with an older version, and someone with an older version is probably running an old system under old policy. One could argue that this is a *good* thing -- if someone wants to build a woody+1 version of cron on slink, isn't it better that they get slink-consistent handling of /usr/doc vs. /usr/share/doc? And auto build daemons can also augment the build environment beyond build essential, as they already do. Of course. My point is *exactly* that any build daemon (or other significant beneficiary of build-depends) *must* have debhelper installed, so why not make it build-essential? Am I missing the mark here? I think we may just have to different conclusions from the same base facts. This is not necessarily unreasonable. In particular, I don't buy into the debhelper requires versioned dependencies argument. I think *if* a package needs a specific version of debhelper it would be fine to put it into the build-depends list. I also think it's reasonable to say the current version of debhelper is build-essential. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Bug#70269: automatic build fails for potato
On 29-Aug-00, 16:05 (CDT), Buddha Buck [EMAIL PROTECTED] wrote: Would it make sense to make policy something like All official Debian auto-build machines will have installed this set of build packages: gcc, ..., and debhelper. Debian packages are not required to specify build dependencies on these packages. That's pretty much the definition (or at least the *use*) of Build-Essential: packages that may be assumed to be present, so that they need not be listed in Build-Depends. Repeating myself: listing a tool as build-essential does not mean that packages are required to use it, just that packages my assume that the tool is present. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Bug#70269: automatic build fails for potato
On 30-Aug-00, 04:21 (CDT), Richard Braakman [EMAIL PROTECTED] wrote: I don't know how the decision ended up being made, but the argument I presented at the time is that a dependency on debhelper is far more likely to be versioned than the others are. A package that makes use of a new feature of debhelper is going to have to declare its own build-depends anyway. It is not unreasonable to assume that the latest-and-greatest version of all the build-essential packages will be installed. If one is concerned about back-building (e.g. a woody package on a slink machine), then you need to worry about compiler and libc versions as well, so you might as well build everything. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Bug#70269: automatic build fails for potato
On 30-Aug-00, 12:51 (CDT), Antti-Juhani Kaijanaho [EMAIL PROTECTED] wrote: On 2830T112651-0500, Steve Greenland wrote: That's pretty much the definition (or at least the *use*) of Build-Essential: packages that may be assumed to be present, so that they need not be listed in Build-Depends. It's not the definition. Which is why I hedged with pretty much and *use*. :-) One of the explicit design goals for the current setup was that policy should not need to mention specific packages. Which is just a stupid pain in the ass. I had to track through three different references and finally install the build-depends package to find out what I could leave out of by Build-Depends stanza. It would *much* easier for developers, if less ideologically pure, to just list the damn packages on the Developers Corner part of the website. And yes, I followed the discussion and reasons. I didn't disagree at the time, but when the time came to use it, it was severely annoying. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Bug#70269: automatic build fails for potato
On 30-Aug-00, 15:08 (CDT), Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Steve Greenland wrote: It is not unreasonable to assume that the latest-and-greatest version of all the build-essential packages will be installed. I wonder what world you are living in. It is in reality a completely unreasonable assumption. Are you saying that someone running a build daemon is not going to keep up-to-date on build-essential packages? Why not? And if not, why is my (the maintainer's) job to keep changing the version numbers in my control file to force it to happen? Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Learning dpkg/apt
On 19-Aug-00, 18:56 (CDT), Ethan Benson [EMAIL PROTECTED] wrote: for things like querying (dpkg -s and such) install dlocate it solves that problem the Right Way. (unfortunatly it got removed from potato for less then critical bugs) man apt-cache. (Assuming you're using apt-get either directly or via dselect, and there is no reason not to!) Steve
Re: Implementing testing (was: Re: Potato now stable)
On 18-Aug-00, 06:26 (CDT), Anthony Towns aj@azure.humbug.org.au wrote: Supporting this, there's some Apt changes in CVS that'll let people choose a few packages from one distribution and leave the rest from another. To whoever implemented this feature: ThankyouThankyouThankyou -- it's something I've wanted to do for a long time. Steve
Re: Intent To Split: netbase
On 16-Aug-00, 23:43 (CDT), Branden Robinson [EMAIL PROTECTED] wrote: On Wed, Aug 16, 2000 at 05:48:11PM -0500, Steve Greenland wrote: What trouble is that? I don't consider having to type /sbin/traceroute or add /sbin to my path trouble. Obviously you haven't typed the actual path to traceroute in quite a while. Exactly. I put /sbin in my path and stopped worrying about it. There is policy on this topic. We say we will comply with the FHS. (We should probably say we will be compatible instead, else our distribution is literally riddled with FHS violations.) I think the location of traceroute is ambiguous. (I also agree that the FHS is itself confused on this topic, as has been pointed out elsewhere.) Steve
Re: policy changes toward Non-Interactive installation
On 16-Aug-00, 02:11 (CDT), Joey Hess [EMAIL PROTECTED] wrote: Belive it or not, I know how to safely manage temp files and protect sensitive information with unix permissions. I know you do, Joey, but my concern is that since the permission violation occurs in the backend, when the backend gets replaced by something else that the security by be inadvertently dropped. Would it make sense for the front-end(s) check the effective userid and refuse to run if it's not 0? Steve
Re: Intent To Split: netbase
On 15-Aug-00, 17:12 (CDT), Eray Ozkural [EMAIL PROTECTED] wrote: I was confused by not having ifconfig in my user path. On this machine, there's only a dial-up net connection, and it has some small connectivity problems. I need to check whether the line's really up. I found myself going super-user to issue the command rather than running /sbin/ifconfig. I can see that typing 'sudo ifconfig' might be easier than '/sbin/ifconfig', depending on how one's fingers are wired. What I cannot figure out is why typing 'ln -s /sbin/ifconfig ~/bin' *once* is not easier than either... Steve
Re: Intent To Split: netbase
On 16-Aug-00, 12:31 (CDT), Branden Robinson [EMAIL PROTECTED] wrote: Blindly following your fiat declarations about traceroute are getting us into trouble now. What trouble is that? I don't consider having to type /sbin/traceroute or add /sbin to my path trouble. The constitution clearly says that maintainers have control over their packages. We have agreed that we'll follow Debian policy. Given the lack of policy on this particular topic, Herbert is perfectly within his rights to determine the location of traceroute, unless overridden by the technical committee. Since I've yet to see a truly technical reason to move it, I hope the committee won't interfere. Yes, if we were starting from scratch, it probably makes more sense to put it in bin, but it's simply not that big a deal. FWIW, I hope that policy won't take this up...detailing the /sbin - /bin location of explicit programs is bound to be an exersize in frustration. Steve
Re: policy changes toward Non-Interactive installation
On 15-Aug-00, 02:54 (CDT), Brian May [EMAIL PROTECTED] wrote: As another example though, look at heimdal-kdc, which needs to ask for the password, which must be kept as secure as possible. Which reminds me, what sort of security is enabled in debconf? Can any user read the values from the database, or is it limited to root? An attempt to use db_get as a regular user, but only because the current backend tries to write a temporary file to var/lib/debconf (I think) (line 229 in ConfigDb.pm, potato version). Steve
Re: Intent To Split: netbase
On 15-Aug-00, 14:35 (CDT), paul [EMAIL PROTECTED] wrote: Why is it considered difficult for individual users adding /sbin and /usr/sbin to their path if they wish to? Because stating that it is difficult is seen as an valid argument by those who wish sbin would go away. The fact that it is obviously trivial is not valid. Is there some deeper principal of Unix or Linux philosophy being discussed here? No. Is there something to be gained that is somehow greater than can be achieved by changing one's own path? No. Is there something I am missing about this debate? There are people who think that the way *they* want things set up is de-facto the way everybody want things set up. All paths, program options and defaults should be pre-configured to be exactly what they want them. Modifying configuration files, adding symlinks, or whatever is too much effort, but requiring package maintainers to greatly complicate their (the maintainers) work to accomodate every possible use of a given package is no big deal. Of course, the fact that the do it my way people don't agree about *what* the default configurations should be doesn't seem to clue them in... Steve, tired of these types of arguments.
Re: ITP: sather-elisp
On 11-Aug-00, 19:04 (CDT), Herbert Xu [EMAIL PROTECTED] wrote: Steve Greenland [EMAIL PROTECTED] wrote: debview - Emacs mode for viewing Debian packages (And I, for one, would not object to debview being folded into dpkg.) As a vi user, I would. Why? Oh, I see, because it depends on (x)emacs...agreed. Hmm, there ought to be a (debian standard) way for packages to include pieces that enhance other programs without requiring them. Or is the the 24K that debview requires? Steve
NMU of debianutils (was: Re: (Bug horizon) Problem bugs)
On 30-Mar-00, 13:01 (CST), Steve Greenland [EMAIL PROTECTED] wrote: On 30-Mar-00, 05:43 (CST), Richard Braakman [EMAIL PROTECTED] wrote: Package: debianutils (debian/main). Maintainer: Guy Maor [EMAIL PROTECTED] 59121 run-parts hangs during /etc/cron.daily runs There's a reasonable looking explanation and patch associated with this bug. Guy, would you like me to do an NMU? Since I've not heard from Guy, I've prepared an NMU that applies Ingo Saitz's patch (thanks Ingo!) and placed it at http://www.debian.org/~stevegr/debutils/debianutils_1.13.3_i386.deb http://www.debian.org/~stevegr/debutils/debianutils_1.13.3_i386.changes http://www.debian.org/~stevegr/debutils/debianutils_1.13.3.tar.gz http://www.debian.org/~stevegr/debutils/debianutils_1.13.3.dsc Raphael and Ingo, if you get a chance, can you confirm I didn't screw this up? Rainer, I think this fixes your bug too (#57464). Guy, if you don't object by ~22:00 Tuesday, April 4th (CDT), I'm going to go ahead and upload it to Incoming. Regards, Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: RBL report..
On 29-Mar-00, 15:21 (CST), Lawrence Walton [EMAIL PROTECTED] wrote: Nils: you still need a DNS named, static, route-able IP to be your own host. I have DNS named, *dynamic*, routable IP -- thanks to the good folks at dyndns.org. The only bad thing is that the reverse DNS isn't consistent. I'm still not entirely comfortable getting e-mail sent directly to me, which is why I POP most of it. Branden: You might consider getting a static. That would be nice. Unfortunately, the choices at swbell (DSL) are either one dynamic IP ($40/month), or 5 (!) static IPs, at $80/month + $100 installation + $100 to set up the DNS (no, not register a domain, *just* to configure the DNS). (And yes, they want the $100 installation even though I already have everything set up and all they would have to do is allocate the IP addresses.) Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: (Bug horizon) Problem bugs
On 30-Mar-00, 05:43 (CST), Richard Braakman [EMAIL PROTECTED] wrote: The following packages have survived the bug horizon, in some cases twice, because they are too important to drop. These bugs will delay the release of potato. Package: debianutils (debian/main). Maintainer: Guy Maor [EMAIL PROTECTED] 59121 run-parts hangs during /etc/cron.daily runs There's a reasonable looking explanation and patch associated with this bug. Guy, would you like me to do an NMU? Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: RBL report..
On 29-Mar-00, 07:16 (CST), Alexander Koch [EMAIL PROTECTED] wrote: On Wed, 29 March 2000 01:57:45 -0800, Joseph Carter wrote: I'm not the only person here who thinks so. Make Debian use all the blacklists you want. You'll find users and developers dropping like flies. If everything else fails, this is the best argument to bring up, really. Tell me why I should listen to you. It's the way of argueing and (probably) not shouting and what not. You are making a fool of yourself for bringing up this argument, but that is just me. A. swbell has frequent problems with their mail-servers, both inbound (POP) and outbound (SMTP). I don't know (or care) what OS they run. B. When I got my DSL line, swbell was the *only* ISP possibile in houston. C. Even though it's now possible to get other ISPs, it would roughly double my current ISP bill. D. DUL is discrimination, pure and simple. If Debian chooses to add a warning header based on it (so that those who choose to can filter), that's fine. If Debian starts to reject list mail based on DUL, I'd strongly consider leaving the project. Joseph's arguments, while occasionally strident, are not foolish. I find it interesting that his opponents devolve into name calling and obscenity. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: first draft aptitude howto
On 29-Mar-00, 09:00 (CST), Robert Bihlmeyer [EMAIL PROTECTED] wrote: (I'm also a first-time aptitude user) Branden Robinson [EMAIL PROTECTED] writes: (Remark: I think I would find the overloading of the '-' key confusing. Please consider using a different key for hold operations. 'h' seems intuitive but might be pressed by novices as an attempt to get help. '!' seems like another possible candidate for hold, a la Stop! Wait! Achtung! :) ) After think about it like this, it was quite natural for me: + accelerates, goes forward. Packages that are standing still (held or simply not installed) will get in motion and move forward, if possible - brakes, goes back. Packages that would otherwise tend to get upgraded, will be held back by this; packages that are not in motion (already held, or up-to-date) will go backwards by being removed. I find this confusing. It seems to imply that I have to hit + twice to install a package and - twice to remove it. Very weird. What's wrong with '=' (keep the same)? -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
ITP: ddclient (dyndns.org IP address updater)
ddclient is used to update your (dynamic) IP address at dyndns.org. Questions: 1. Section net or admin? 2. The program can use a config file to store the hostname and dyndns.org username and password. This is convenient if one is running it automatically (when dhcpcd gets a new ip, for example). I've modified ddclient to only use the config file if it is unreadable by group and other. Is this sufficient? Any better ideas? (the admin can, of course, just run it by hand and specify the user/pwd on teh command line, there is no requirement that the configuration file be used.) Here's the control file: Source: ddclient Section: net Priority: extra Maintainer: Steve Greenland [EMAIL PROTECTED] Standards-Version: 3.1.1 Package: ddclient Architecture: all Depends: perl5, debconf Description: Update dynamic IP address at DynDNS.org A perl based client to update your dynamic IP address at DynDNS.org, thus allowing you and others to use a fixed hostname (myhost.dyndns.org) to access your machine. This client supports both the dynamic and (near) static services, MX setting, and alternative host. It caches the address, and only attempts the update if the address actually changes. For more information on DynDNS.org, see http://www.dyndns.org/. -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Release-critical Bugreport for March 24, 2000
On 24-Mar-00, 03:15 (CST), BugScan reporter [EMAIL PROTECTED] wrote: Package: nvi (debian/main) Maintainer: Steve Greenland [EMAIL PROTECTED] 61035 nvi munches database dump Fixed and in potato. -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: glibc-compat ???
On 23-Mar-00, 18:08 (CST), Andor Dirner [EMAIL PROTECTED] wrote: On Thu, 23 Mar 2000, Robert Varga wrote: The other one it breaks is Oracle 8.0, and one needs to convert Redhat compatibility libraries to be able install it, and a patch from Oracle. FWIW, I'm running Oracle 8i (SQL*Plus reports v 8.1.5) with the latest patches (as of a month ago) on a potato box with no obvious problems, I don't have any compatibility libs installed. steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: blue on black is unreadable
On 24-Mar-00, 03:22 (CST), Peter Cordes [EMAIL PROTECTED] wrote: From: Steve Greenland [EMAIL PROTECTED] Because that's what xterms do (by default) on every other single X implementation ever done? (Ok, that's probably an exageration...but not completely misleading, either.) Is that enough of a reason to not change it? Does it break any programs specifically? It doesn't break programs, particularly, but it breaks configurations -- people whove changed only the foreground or background, or people who've set up other program's coloring to work on a black-on-white xterm. (I assume you have a nice DIRCOLORS setting that fixes that, though.) No, I think colored ls is the spawn of the devil. :-) (Actually I find colored ls a huge distraction, and all the information I need is provided by the '-F' option of ls) (I wonder if the preference for light-on-dark vs dark-on-light depends on ambient light conditions?) I usually like to work in a relatively dark room. I think I'm nocturnal or something (looks at clock... :( And I tend to work in well lit rooms, even at night -- so from our amazing sample of two, there is a correlation! [*big snip*] You've got a lot of valid points; I agree that black-on-white xterms do glare a little, although I've never had a real problem with them (when I use other people's systems, I hardly ever mess with the colors, even for a few days of work.) But the current defaults are defensible: it's the world-wide X standard default. Anything else amounts to personal preference and will promote a continuous stream of bug reports and complaints. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: blue on black is unreadable
On 24-Mar-00, 10:19 (CST), Steve Greenland [EMAIL PROTECTED] wrote: (I wonder if the preference for light-on-dark vs dark-on-light depends on ambient light conditions?) I usually like to work in a relatively dark room. I think I'm nocturnal or something (looks at clock... :( And I tend to work in well lit rooms, even at night -- so from our amazing sample of two, there is a correlation! And the link (http://www.dgp.toronto.edu/people/ematias/faq/S/S-9.html) that someone else provided said this: In an experiment with light- or dark-adapted subjects identifying target letters within a letter string from positive or negative displays, I also found interactions between adaptation level and display polarity (Fischer, 1992). Thus, the display of choice probably depends on your workplace illumination. (presumably with a sample count of more than 2) It also said this: Saturated blue should not be used for the presentation of fine detail, because the central part of the fovea is relatively insensitive to that color. For similar reasons, blue is an excellent background color. (Of course, that promotes light-on-dark) sg -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: of bash and ...sbin/
On 22-Mar-00, 15:59 (CST), Jacob Kuntz [EMAIL PROTECTED] wrote: i think this tread started with someone wanting the sbin directories in the normal user's path by default. i see your point that moving those binaries would break a lot of scripts. i don't think appending to the default path would break anything. anyone have a problem with that? We discussed (and argued and flamed and ...) that to death. The objection is mostly due to potential confusion (there are a lot more potential targets for command completion, and most of them are *not* what the user is looking for) and inertia, and the expectation that a user who finds value in use of traceroute or ifconfig or whatever is also a user who is capable of modifying their path. sg -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: blue on black is unreadable
On 22-Mar-00, 21:41 (CST), Peter Cordes [EMAIL PROTECTED] wrote:
Actually, I took another look at the console. The ANSI bright-blue used by
ls for directories is actually quite easy to see. The normal blue used by
lynx is not great, but readable. I'm sure there is a way to set the colours
the kernel uses somewhere, so doing this would be the best option.
No, because you then break all my settings that use normal (dark) blue
and red as background colors.
Unless the darkish colours get used as alternate background colours, they
are wasted.
They do.
There only are 16 colours, so deciding to never use 4
({dark ,}{blue,red}) of them seems like a bad idea. Brightening them up so
they look good on a black background is good, since hardly anything uses
dark-but-not-black background colours.
No, you doen't use them. I use them a lot, to highlight urls and headers
in mutt, for example.
Is there a reason why /etc/X11/Xresources/xterm defaults to black on white
instead of gray90 on black?
Because that's what xterms do (by default) on every other single X
implementation ever done? (Ok, that's probably an exageration...but not
completely misleading, either.)
With my colour mods to make ls output visible, could the default
change to be gray90 on black? Most new users won't get around to
finding the xterm resources file for a long time, and I imagine they
would be happier with black bg xterms until they do.
I wouldn't. A lot of people I work with wouldn't. (Many would, of
course). I, for example, find it easier to read black text on light
backgrounds in xterms. My favorite is black on blanchedAlmond. I
don't, however, think that should be Debian's global default.
(I wonder if the preference for light-on-dark vs dark-on-light depends
on ambient light conditions?)
We should cater
to users who don't know where you change everything by having a nice set of
default colours. This isn't like keymaps and stuff, since it only looks
different, and isn't nearly so hard to get used to.
We do cater to them. We have window managers that support themes and
easy ways to change them.
We have a nice set of default colors. They are easy to modify (in the
xterm case, if you don't have the desire to mess with Xresources, -fg
and -bg work quite nicely). Are they they best possible defaults?
Probably not. But if you change them, probably for every person who you
made happier, there's another you've pissed off.
Why do so many people want to believe that their personal preferences
represent universal truth? I agree that demonstrably bad defaults
(dark-on-dark) should be changed. But the reality is that things like
color selection are such a personal-preference issue that *most* people
will eventually tweak them to their preference, and the best we can (and
should) do is use a *workable* default, and go on.
(If there is a 90% consensus that we change the xterm default to white
on black, and change the kernel definition (or whatever) of blue to
something lighter, then fine, do it. But I strongly believe that you
won't get anywhere near that much agreement.)
Steve
--
Steve Greenland [EMAIL PROTECTED]
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
Re: blue on black is unreadable
On 21-Mar-00, 20:06 (CST), Peter Cordes [EMAIL PROTECTED] wrote: The Linux text console is readable (barely), but xterm uses and even worse colour for ANSI blue. (assuming black background). The fix for this is to change the colour used by xterm for ANSI blue, instead of changing all apps to use a different ANSI colour escape code. That's a neat trick for xterms, but since even you admit that blue-on-black is only barely readable on the text console, wouldn't it be better to just not have default configurations use blue-on-black? (It shouldn't be a matter of changing apps, only default configs.) If you're setting up a default color scheme for an app, the basic rule is to use light colored text on dark backgrounds, and dark colored text on light backgrounds. The only other thing you need to know is that neither red nor blue are light colors. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: apt-get cron job
On 22-Mar-00, 10:56 (CST), Steve Robbins [EMAIL PROTECTED] wrote: One suggestion: for some people, it makes sense to use the `apt-move' package after downloading the .debs. Apt-move will move the .debs out of the cache into a Debian archive hierarchy naming convention. This is quite handy for folks that have another machine or two connected via a local net: you can point the second machine's apt at the local archive. Another way to accomplish the same thing is to install squid on one of the machines and have all your apt'ing machines use it. I found this to be easier to set up than apt-move (YMMV), and has the advantage (to me, at least) that it's order-independent and completely transparent (it doesn't matter what order which machines access the cache, one always gets the freshest stuff, and doesn't double-download anything.) Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: 5 days till Bug Horizon
On 22-Mar-00, 05:50 (CST), Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Richard Braakman wrote: Package: cvs (debian/main). Maintainer: Tom Lees [EMAIL PROTECTED] 59543 cvs: cvs-makerepos does not exist Isn't this just cvs init? 59909 cvs: cvs segfaults when commiting a dir FWIW, I e-mailed Tom on Monday offering help, and he replied that he had the RC stuff under control. sg -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Bug#60753: mutt: /etc/Muttrc should not use colors
On 20-Mar-00, 01:46 (CST), Nicolás Lichtmaier [EMAIL PROTECTED] wrote: Using the Space and the Backspace keys for up and down movement is absurd, it's even stupid. Backspace is back-space. Those keybindings where thought for keyboards without arrows, and those keyboards no longer exists... While I agree with most of what you wrote, you're wrong on this one. There's a *lot* of history of using the space bar to do the next thing in Unix console programs (more/less, most news readers and existing mail readers). And there's no reason *not* to use them -- what else would you bind to the space key? You're right: the defaults should cater to the new user, but there's no reason to deliberatly aggravate the experienced user. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Less interactive upgrades.
On 16-Mar-00, 21:33 (CST), Ben Collins [EMAIL PROTECTED] wrote: Like I said though, I am not messing with any of this until potato is released. Oh, absolutely. However, Wichert wrote woody+2, which seemed excessive (at current rate of release, that's about 2003.) -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Less interactive upgrades.
On 16-Mar-00, 18:02 (CST), Wichert Akkerman [EMAIL PROTECTED] wrote: Oh, and you still loose if people don't use apt. Well, there's a *lot* features one doesn't get unless one uses apt. So? There is already a patch to make dpkg log things using syslog. At some point I'ld like to generalize that, but we can't do that until debconf is used everywhere. Woody+2 I think. Uh, why not publish the tool/capability, and let those packages that can use it do so? Having it a available would be an incentive to update one's packages, and be of at least partial benefit to the users. Or am I missing a point? Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On 15-Mar-00, 01:06 (CST), Craig Sanders [EMAIL PROTECTED] wrote: DO NOT PUT WORDS IN MY MOUTH. your argument for want of a better term is obviously so poor that you have no choice but to misrepresent mine to make your points. Hmm, it's ok for you to misrepresent other people's arguments, but not the other way around, as follows: so why do you have a problem with infrastructure (i.e. package pools in one form or another) which makes it easier to build a snapshot image? do you have some kind of aversion to automating tedious and time-consuming tasks? DO NOT PUT WORDS IN MY MOUTH. your argument for want of a better term is obviously so poor that you have no choice but to misrepresent mine to make your points. (And you *are* mispresenting my point, because you completely ignored the next paragraph where I spoke favorably about package pools.) and fuck you too! how dare you fucking misrepresent my position and twist what i said in such a reprehensible manner? Why not? You do it to everybody else. In the meantime, plonk! Cheers, sg -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
that you wont be able to add another ICQ client to the +4000 packages in the distribution already. Sorry for suggesting that. if uploading a new icq client is all that someone can do, then what is wrong with that? how does it hurt the release cycle for someone to work on 'unstable' if the alternative is that they would not work on anything at all? If they *really* feel the need to upload that icq client, and can't until the release (or deep freeze), then they just might fix one (1) release critical bug. Nobody is _forcing_ them to do it. will you quit it with the bullshit that unstable is less stable than stable? it's not. in fact, over time it is vastly more stable and secure than the so-called 'stable' release. Over time, yes. An any given instance in time, often not. the name unstable does not mean that it is unreliable or flaky. it means that it is subject to rapid change, and that some of those changes will (temporarily) cause incompatibilities or problems. caveat ^^ emptor. Thus, unreliable and flaky. Craig, your definitions must be completely different than mine. I thank ghod you don't manage any of my production systems. similarly, stable does not mean that it is guaranteed to work or to be bug-free. it means that it has been tested reasonably thoroughly and that as far as we can tell, it works as an integrated system on a wide variety of machines. caveat emptor. That's a hell of lot stronger promise than could completely hose your system. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: So, what's up with the XFree86 4.0 .debs?
On 13-Mar-00, 16:55 (CST), Alex Yukhimets [EMAIL PROTECTED] wrote: I often find myself in the position when I use X libraries (Xt mostly) built by myself with some changes to allow debugging of my Xt widgets. I install new libs and headers in another directory and -I/this/new/dir and -L/that/new/dir allows for compilation and linkage with new version. If libs are in /usr/lib and headers in /usr/include (default locations) then this would not work. Why not? Have you read the compiler/linker docs? Adding -I/some/dir/inc and -L/some/dir/lib causes those directories to be searched *before* the default directories. I don't have an opinion about where the X stuff should go, but the above argument is completely bogus FUD. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Danger Will Robinson! Danger!
On 12-Mar-00, 10:56 (CST), Ron Farrer [EMAIL PROTECTED] wrote: I disagree! (surprise ;) I personally know of about ~4 people who were turned away from slink because GNOME and KDE were so OLD. I personally got around this by running potato (unstable then), but most people don't WANT to run unstable! Which is it? Do your friends want the newest bleeding edge stuff, or do they want stability? They can't have both at the same time! Oh, I see, the want the newest, but they want us to call it stable. Sigh. Why is is this basic distinction so hard to explain to people? Testing and reliability take time. During that time, new features are going to show up in various parts of the system. Along with those new features come compatibility and reliability problems. You can either have the new features, or you can have a tested, stable, reliable *system*. *YOU* *CAN'T* *HAVE* *BOTH*. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Danger Will Robinson! Danger!
On 12-Mar-00, 06:37 (CST), Michael Meskes [EMAIL PROTECTED] wrote: On Sat, Mar 11, 2000 at 11:14:56PM +0100, Marcus Brinkmann wrote: The simple fact you are missing is that Debian is not an industry. Which doesn't mean that all arguments are not valid. As Manoj pointed out, being outdated is not making us reach our technical goals. Let's see, we're going to release potato (I *hope*) before kernel 2.4.0 is released, but we're outdated. Hmmm. Somehow, I just don't get it. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: console-apt
On 06-Mar-00, 10:10 (CST), der.hans [EMAIL PROTECTED] wrote: Except you really need to use --purge in order to truely remove the full package. I don't read usenet, so removed all the news packages that came with the default install profile I chose. No biggie. Except I kept getting cron errors because one of the news packages wasn't configured correctly. purge wiped out the cron file in /etc/cron.daily/ and got rid of that. Report a bug against the package that owned the config file in cron.daily. Removed but not purged (i.e. config files only) is a legitimate, supported package state, and should not cause errors. Config files that are scripts should check before running. If remove is identical I would think that whatever install adds would be removed by remove. Didn't take me long, but I at least somewhat know what I'm doing. It hasn't kept me from using apt-get as my only interface to adding/removing packages either :). But the config files are not necessarily added by install. However, the description of remove in the apt-get man page could be more explicit. -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
vim/nvi priority Re: moving mutt to standard priority
On 05-Oct-99, 04:00 (CDT), Marco d'Itri [EMAIL PROTECTED] wrote: I agree... Why does it [vim] have a lower priority in alternatives than nvi? I don't know. That's not what I remember from the discussion amongst the various vi and editor maintainers when we set the relative priorities, but unfortunately I cleaned out that discusssion just a few months ago. If I remember correctly, Dale Sheetz guided that discussion, maybe he can post the final list. What I remember as a general concept is that the package that is installed by default (nvi, in this case), should have the *lowest* priority wrt update-alternatives, under the assumption that if the sysadmin goes to the effort to install an option vi clone, they probably prefer that one. As to why nvi is Standard and vim/elvis/etc. are Optional, it's because nvi is closest to a standard, classic, BSD Bill Joy vi, warts and all. Also, I think it's the smallest full-fledged vi. Certainly that choice can be argued, but I'm not really interested in discussing it: everybody has a favorite, and it's not worth changing. If there is *consensus* that vim or elvis should be Standard, and nvi Optional, I'm happy to change, but lacking that (and I don't forsee it happening, after various other x should be the standard y flamefests), I think things should stay as they are. (In the Standard vs. Optional debate, that is. I suspect the update-alternatives priority for vim should be looked at.) Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: dhcpcd procedure
On 01-Oct-99, 11:28 (CDT), Dpk [EMAIL PROTECTED] wrote: What would be the best way to check for this? A simple 'ps |grep dhcpcd' ? Would doing so make my package dependent on procps? or is there a convenient way to check the installed version of dhcpcd someway? As others have said, check the arguments to your postinst. Here's an example excerpt: if [ $1 = configure -a -n $2 ] dpkg --compare-versions $2 lt 3.0pl1-43 ; then echo This is an upgrade from an old version -- restart daemon fi Of course, you'd replace 3.0pl1-43 with the version number of the *first* version that *doesn't* need to perform the special action. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Problem with the latest potato update
On 30-Sep-99, 07:50 (CDT), Hirling Endre [EMAIL PROTECTED] wrote: On Thu, 30 Sep 1999, Matthew Vernon wrote: E: Malformed Priority line E: Error occured while processing aleph-dev (NewVersion1) The Priority: line is Priority: optionnal instead of Priority: optional File a critical bug, if no-one has yet done so. Against what? aleph? Okay, one bug against aleph, but IMHO an at least important bug should be filed against dinstall for not rejecting the package and thus letting it to screw the Packages file. And another against apt for allowing a trivial bug affecting one package to completely break it (if, in fact, it does -- I haven't tried it). It should just ignore the affected package(s). Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: a question about BTS severities
On 27-Sep-99, 11:33 (CDT), Joey Hess [EMAIL PROTECTED] wrote: grave makes the package in question unuseable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. I've noticed that in many of the cases where I think the bug has too high severity, the bug doesn't affect all users of the package. A specific example: I've a rvplayer bug saying that it segfaults, marked important. But since people have been using that binary for about 9 months, with general success (and since the package in question is only in stable, and has not changed in any way in that time period), the bug is clearly not affecting everyone, or even many people. It's clear to you, but perhaps not to the user who submitted it; for him/her, it makes the package in question unuseable. You look at it, realize that it's unique to that user, and send a message to [EMAIL PROTECTED] to re-priotize it. What's the big deal? I think we should clarify the description of important to note that the bug has to affect a large group of people to be important severity. Similarly, I don't think a bug is grave if it makes a package unusable by just one person in an odd sitution. On the other hand, I think all security and data loss bugs are grave, even if only a few people can trigger them. I agree with this conceptually, but again, it doesn't seem like that big a deal to me. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Status of new packages in Incoming?
On 27-Sep-99, 00:44 (CDT), Joey Hess [EMAIL PROTECTED] wrote: I think it should be possible to come up with a structure where ftp site maintainers need not be trusted. The key to doing so is making it possible for any change such a person makes to be logged, and reversable. The reason I think this is possible is because of things like the Bug Tracking System, and CVS. Anyone can manipulate bugs in the BTS, and that's generally ok, because the changes they make are reversable. People routinely give other write access to CVS repositiories without strenuous background checks on them. For example, anyone who expresses the willingness to translate can get CVS commit access to the debian web site. With CVS, this isn't a problem, because if someone does something bad, it's possible to revert their changes. It's also possible to identify who did it and deal with them if they're a repeat offender. I think the key difference is that if some one screws with the BTS or the Debian web site, it's not going to *me* any harm during the time it takes to discover and undo the damage. If someone installs a bad or malicious libc6 in the archive, a buncha people could get seriously screwed. Depending on mirror cycles and timing, I suspect it could take *days* to completely correct the damage in the archive and its mirrors, and who tells how long for the victims to correct their local situation. Note that this doesn't argue against the idea of having a reversible and logging interface to the archive, which might be a good thing anyway; just against allowing widespread access to the archive. -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Hosed system during package build
On 17-Sep-99, 04:35 (CDT), J.H.M. Dassen (Ray) [EMAIL PROTECTED] wrote: On Thu, Sep 16, 1999 at 20:26:15 -0500, Steve Greenland wrote: I saw much talk about fakeroot not working with the new glibc, much talk about it being difficult to fix, and no talk about it being fixed. Actually, AFAIK most of this talk was about /libtricks/ which was a new approach to doing what fakeroot does (it provided a fakeroot binary as well); that approach did turn out not to be usable for glibc2.1. The current fakeroot in potato is based on the old approach, and works fine. Aaah. Understanding is. Thanks, sg -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Announcing debconf, configuration management for debian
On 17-Sep-99, 13:23 (CDT), Joey Hess [EMAIL PROTECTED] wrote: This is a bit long, so I'll summarize: Debconf is a tool that packages can use to ask questions when they are installed. It allows various frontends, from dialog, to gtk to web pages to be used, and it also allows for non-interactive package installs, and allows packages to ask questions all at once, before any of them are even installed. Nice job, Joey. I've read (or at least skimmed) the tutorial you posted, and it looks like the various configuration variables are associated with a package via the template foo/variable. What about variables that are logically shared between packages, such as the default directory for the webservers, or news server name, and such. Is it acceptable for the group of affected maintainers to use the virtual package name as the variable package name? Or would some other way be better? -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
