Re: Packages should not Conflict on the basis of duplicate functionality
On Fri, Sep 24, 1999 at 05:12:00PM -0400, Clint Adams wrote:
If you want to run two httpd's, popd's or mta's, you'll probably have to
do more than the usual tweaking to the package setup anyway, so what is
really the big deal of having to:
1. `apt-get source foo`
2. edit various files, mostly in debian/
3. add an epoch to the package version
4. `fakeroot debian/rules binary`
5. `sudo dpkg -i foo.deb`
What's really the big deal of having to
1. apt-get install apache roxen
By putting an epoch in the version number you defeat the whole automatic
upgrade system.
If you must insist that these matters be resolved formally, then please be
so generous to provide us with some reference implementations of a generic
/usr/sbin/{httpd,popd,smtpd}-config.
I see absolutely no need for an httpd-config. I'm perfectly happy
with they way apache, apache-ssl, and roxen coexist.
And of course you can always do dpkg --force-conflicts. I believe that's what
the --force commands are really there for: special situations.
--
Colin Walters [EMAIL PROTECTED]
http://web.verbum.org/levanti
PGP Fingerprint: 2951 C835 FB23 82D4 3969 EDB5 08D9 B9EA 7D30 CC26
Re: possible problem with new perl, libc6 on Sep 23rd
Ben Collins wrote:
Now when dpkg first unpacks a package, it replaces binaries by first,
chmod 600 on the binary (I'm not sure why, but it does), then unlinking
it.
The reason why dpkg does this is because of a neat little hard link exploit.
[EMAIL PROTECTED]:/tmpln /usr/gamesxthrust
[EMAIL PROTECTED]:/tmpls -l xthrust
-rwxr-sr-x 2 root games 251984 Sep 20 20:45 xthrust*
Now if a bug is found in xthrust that lets me get access to the games group,
the sysadmin quickly fixes it by installing a new binary. But I already have
made a hard link to the old one (and note the hard link has the same
permissions), so I can log in and run it at my leisure later and exploit the
hole. Of course, this works for suid executables too.
The fix is to clear the suid and sgid bits of the binary before you delete
it. So when dpkg goes in and upgrades xthrust, it first chowns the old file,
and I end up with just this, which isn't helpful to me as a cracker:
[EMAIL PROTECTED]:/tmpls -l xthrust
-rw--- 2 root games 251984 Sep 20 20:45 xthrust
Now, what confuses me is why dpkg is doing this to perl, which isn't suid or
sgid at all. The dpkg code uses this:
int chmodsafe_unlink(const char *pathname) {
struct stat stab;
if (lstat(pathname,stab)) return -1;
if (S_ISREG(stab.st_mode) ? (stab.st_mode | 07000) :
!(S_ISLNK(stab.st_mode) || S_ISDIR(stab.st_mode) ||
S_ISFIFO(stab.st_mode) || S_ISSOCK(stab.st_mode))) {
/* We chmod it if it is 1. a sticky or set-id file, or 2. an unrecognised
* object (ie, not a file, link, directory, fifo or socket
*/
if (chmod(pathname,0600)) return -1;
}
if (unlink(pathname)) return -1;
return 0;
}
--
see shy jo
Re: Packages should not Conflict on the basis of duplicate functionality
And of course you can always do dpkg --force-conflicts. I believe that's what the --force commands are really there for: special situations. Broken situations. Sure, you can --force dpkg to overwrite files from another package. But Debian prefers to fix the problem instead.
ITP Network::ipv4addr and fwctl
Hello, I intend to make a Debian GNU/Linux Package from Fwctl. Therefore I will have to make 2 Packages, one for fwctl and one for libnetwork-ipv4address-perl. ipchains-perl is already a debian package. I have obtened both from http://indev.insu.com/Fwctl/ and will upload the files soon to the master debian FTP site. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: problems with the perl5 packages
Chip Salzenberg [EMAIL PROTECTED] writes: [2] Debian doesn't create this specific hard link, but it should. For example, my system has /usr/bin/perl5.00503. Well, we do have perl-5.X, sans subversion. Which is admittedly not exactly what you refer to, but I thought that changes in mandatory warnings was considered too significant a change for subversions, so we've got the same end result... Mike.
Re: strange behavior of dh_dhelp
From: Martin Bialasinski [EMAIL PROTECTED] Subject: Re: strange behavior of dh_dhelp Date: 24 Sep 1999 09:31:49 +0200 * Joey == Joey Hess [EMAIL PROTECTED] wrote: Joey You are under the mistaken impression that dh_dhelp is a Joey debhelper program. It's not. Don't use it. I found this was already filed in BTS. Sorry. dh_installdocs uses doc-base, which in turn registers documents for dwww and dhelp. Thous it is a superset and should be used, no? I tried this one (dh_installdocs) and it worked fine. But I noticed another problem of dhelp. - dhelp_parse registers index in /usr/share/doc/HTML - dhelp reads yet /usr/doc/HTML so newly registered documentation can not be seen with dhelp ! (This may be already well-known) 1999.9.25 -- Debian JP Developer - much more I18N of Debian Atsuhito Kohda [EMAIL PROTECTED] Department of Math., Tokushima Univ.
Re: anarchism_7.7-1.deb
On Fri, Sep 24, 1999 at 05:59:07PM -0400, Jaldhar H. Vyas wrote: The criterion should be utility. wrong. we've had this censorship discussion many times before. the only criteria for inclusion in debian is: - is it free? - could someone be bothered doing the work of packaging it? if the answer to both questions is yes, then there is no justification for refusing the package. The Bible as a literary and cultural foundation of Western civilization will be useful to a lot more people than the Anarchism package. 'utility' is a subjective thing. i personally would find the anarchist faq far more useful and interesting than (a bad translation of) religious texts. craig -- craig sanders
Re: Conference! - around the world with Debian
Or crossover cable. Dave Bristel On 24 Sep 1999, Ruud de Rooij wrote: Date: 24 Sep 1999 17:16:06 +0200 From: Ruud de Rooij [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: debian-devel@lists.debian.org Subject: Re: Conference! - around the world with Debian Resent-Date: 24 Sep 1999 15:16:16 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; Ben Pfaff [EMAIL PROTECTED] writes: Peter Makholm [EMAIL PROTECTED] writes: Russell Coker [EMAIL PROTECTED] writes: For those of us who attend in multiple countries we could book plane flights together (hopefully get a good deal), play network Quake in the plane, etc. Then we need a sponsor with a big wallet. ...or a battery-powered hub :-) Have people forgotten about coax? :-) - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problems with the perl5 packages
According to Michael Alan Dorman: Chip Salzenberg [EMAIL PROTECTED] writes: [2] Debian doesn't create this specific hard link, but it should. For example, my system has /usr/bin/perl5.00503. Well, we do have perl-5.X, sans subversion. That's good, but it breaks the upstream pattern of perl#.###. So I guess all I'd like to see is the deletion of that hyphen. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] When do you work? Whenever I'm not busy.
Re: anarchism_7.7-1.deb
In my understanding the bible packages belong into contrib *at best*, since it's value to the public is at least questionable if not offensive to muslims, buddhists(no not to them), hindus ... youre trying to be politically correct yuck ! i hoped for higher level of discusion than in equal-rights-for-black-jewish-not-so-proficient-women comittee of parliament As an alternative I might decide to get at a digital version of Karl Marx's Das Kapital or Mao's Little Red Book and package it for debian just for fun. Either have to go into non-us I presume :) bible is needed as sometimes usuful example of utility of browser browser is Good and shouldnt be thrown away from debian because of someone's ideology 'LIttle Red Book' is good idea I suggest also 'Mein Kampf' both books are under censure in many countries and we should give world some freedom more btw : im atheist Please define in private mail, dunno wether I'm atheist, antitheist, agnostic or simply a pagean. In our culture definitions of these terms mostly come from the other side. This means I think there is NO god at all nor anything similar
weekly policy summary
Here's what's been happening on debian-policy this week. Please let me know if you think any proposals have a consensus. Note: for details of the policy process, see http://www.debian.org/~srivasta/policy/ch3.html. Also, this summary is available on the web at http://kitenet.net/~joey/policy-weekly.html. Accepted Amendments Ammend contrib definition (#45318) * Consensus. * Proposed by Anthony Towns; seconded by Chris Lawrence, J.H.M. Dassen, Josip Rodin, Edward Betts, Marcus Brinkmann and Joseph Carter. * This proposes a new definition of the contrib section. It removes some of the things that would put a package in contrib, including packages that are too buggy, and packages that violate policy. Only licencing terms would determine if something goes in contrib. Virtual package 'ispell-dictionary' * Consensus. * Proposed by Santiago Vila; seconded by Julian Gilbey and Anthony Towns. * add ispell-dictionary to the list of virtual packages for Anything providing a dictionary suitable for ispell. /var/mail and /var/spool/mail (#42052) * Consensus. * Proposed by Joseph Carter; seconded by Gordon Matzigkeit, Joey Hess and Santiago Vila. * This outlines a migration path from /var/spool/mail to /var/mail. Old systems will have /var/spool/mail with /var/mail a symlink. New machines will have the reverse. Packages using /var/mail should depend on the version of base-files that implements this. Build-time dependencies on binary packages (#41232) * Consensus. * Proposed by Antti-Juhani Kaijanaho; seconded by Roman Hodek, Santiago Vila, Stefan Gybas and Ian Jackson. * Proposes the addition of four new fields to debian/control to specifiy different kinds of source dependancies (and conflicts, etc). Does't handle packages that need unpacked source of another package to build. ( Antti-Juhani Kaijanaho posted a final version and there were no objections to it. ) Add VISUAL when checking for user's editor (#41121) * Consensus. * Proposed by Steve Greenland; seconded by David Frey, Julian Gilbey and Chris Waters. * Programs may check VISUAL before EDITOR when trying to figure out what editor to use. sensible-editor already does this. Rewrite of Configuration files section (#40766) * Consensus. * Proposed by Steve Greenland; seconded by Joey Hess, Stefan Gybas and Kai Henningsen. * A replacement for section 4.7 that clarifies the different between configuration file and conffile and uses the two consitently. ( probably a consensus ) Wording cleanup w.r.t. conffile/configuration file (#40767) * Consensus. * Proposed by Steve Greenland; seconded by Joey Hess, Julian Gilbey and Kai Henningsen. * This cleans up references to conffiles and confuguration files throughout policy. Changelog.html.gz sanitization (#40934) * Consensus. * Proposed by Joey Hess; seconded by Roland Rosenfeld, Edward Betts and Manoj Srivastava. * A proposal to make a plain text dump of html changelogs available so changelogs are always available at a consitent location. The html changelog may optionally be included as changelog.html.gz Data section (#38902) * Consensus. * Proposed on 3 Jun 1999 by Darren O. Benham; seconded by Peter S Galbraith and Peter Makholm. * Since there is interest in packaging census data, maps, genome data and other huge datasets I and since most people agreed that dropping them in main or contrib is not a great idea, I propose the creation of a data section to reside along side of main, contrib and non-free. Includes rules about what goes in this section. Definition of extra priority (#33076) * Consensus. * Proposed on 8 Feb 1999 by Santiago Vila; seconded by Peter S Galbraith, M.C. Vernon, Jules Bean and Julian Gilbey. * Clarification of what the extra priority means. Amendments Config files must have manpages (#45406) * Under discussion. * Proposed by Nicolás Lichtmaier; seconded by Oliver Elphick and Josip Rodin. * Require every config file have a man page. Changing policy on compiling with -g .. a better way (#43787) * Stalled. * Proposed by Ben Collins; seconded by Sean 'Shaleh' Perry, Antti-Juhani Kaijanaho, Mike Goldman, Zephaniah E. Hull, Roman Hodek, Marcus Brinkmann and Aaron Van Couwenberg. * Instead of always requiring packages build with -g (only to strip it later), the proposal is that they may optionally only build with -g if the user specifies they do so (by setting DEB_BUILD_OPTIONS=debug). This should reduce overhead in normal build circumstances. FHS-compliant location of compiled examples (#42849) * Old. * Proposed by Joey Hess; seconded by Julian Gilbey and Chris Waters. * This
Re: Packages should not Conflict on the basis of duplicate functionality
On Fri, Sep 24, 1999 at 11:13:27AM -0400, Scott K. Ellis wrote: Okay, then solve the problem of which one should actually work on the standard port? You can't use update-alternatives if the software is launched in a different manner. If you have such an advanced setup, it isn't really that hard to build it yourself, or use --force. I do not believe that any network daemon should automatically start grabbing resources without asking. By installing a package, I only consent to commiting disk space and the resoureses needed to get it actually on the disk. Anything beyond that should be asked for. Some polite packages do ask nicely whether to use inetd or to start via an /etc/init.d file. Other ones ask which port to run on or even if to run at all. Why shouldn't *all* daemon packages ask these questions, and whether to even run *upon install*? I do not like the idea of a daemon starting up with a default configuration that I have not double checked upon installation. I consider automatically starting with no choice a misfeature. And as to the idea that if I run a 'complex' system, I should dl the package and recompile is not a good one. We have not defined 'complex' and 'simple' except trivially; if you do something that isn't possible with the current tools, then it is complex. We cannot afford that definition. It would hinder us. Running multiple daemons providing the same service is reasonable and expected in a production environment and *even* in the home of an enterprising user. The real question is not why not by how. Ciao! -- We is confronted with insurmountable opportunities. -- Walt Kelly, Pogo The Doctor What: Second Baseman http://docwhat.gerf.org/ [EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key) KF6VNC
Re: Packages should not Conflict on the basis of duplicate functionality
On Fri, Sep 24, 1999 at 11:34:28PM -0500, The Doctor What wrote: I do not like the idea of a daemon starting up with a default configuration that I have not double checked upon installation. I consider automatically starting with no choice a misfeature. I think I agree. I got a rude start today when I saw messages of the form: Sep 24 09:00:21 minion inetd[790]: linuxconf/tcp: unknown service [linuxconf was going to provide a tcp service to enable people to configure my machine and the only reason I stumbled across this was that I'd customized my /etc/services file and hadn't merged in changes from the .dpkg-dist copy?] Perhaps there are people who want a service enabled by default policy, and perhaps we should accomodate them. However, I'm not one of them and I don't want any services turned on on some of my machines without my explicit ok. Yes I'm aware that some of these services might not have any security bugs. So what? -- Raul
Re: Conference! - around the world with Debian
On Fri, Sep 24, 1999 at 04:26:27PM +0200, Sven LUTHER wrote: Also use of computer in planes is discouraged and prohibited during landfall and takeoff, as it interfer with the onboard radio equipement ... This is a fiction perpetrated by flight attendants because many of them are too dumb to tell the difference between electronic devices that may generate significant EMF at 108MHz or a little above and ones that don't. Hint: if it's got an FCC sticker on it, it's okay. The FCC is so ubelievably anal about radio transmissions, nothing they license could come close to interfering with a receiver even 10 feet away. But the airlines don't expect flight attendants to comprehend such things and don't have to, since their passengers don't raise enough fuss to get the policy changed. As portable computing devices become ever more ubiquitous, this may change. -- G. Branden Robinson | The only way to get rid of a temptation Debian GNU/Linux | is to yield to it. [EMAIL PROTECTED] | -- Oscar Wilde cartoon.ecn.purdue.edu/~branden/ | pgpAybQyVRk3J.pgp Description: PGP signature
Re: BTS feature comments
About security on the BTS: Don't introduce a system with `pre-security', let's use `post-security'... what do I mean? The following: Make every action undoable and advertised, e.g.: if someone manipulates a bug in any way the maintainer gets an email. I think that that's how it's working now, so... don't touch it.. =)
Re: sash
* Ruud de Rooij ([EMAIL PROTECTED]) [990924 08:40]: Michael Neuffer [EMAIL PROTECTED] writes: * Raul Miller ([EMAIL PROTECTED]) [990923 16:15]: On Thu, Sep 23, 1999 at 07:32:50AM -0500, Ashley Clark wrote: Couldn't sash include a PAM module that would change the password to match root's password whenever it was changed? Or am I oversimplifying things? I don't have enough confidence in Debian's pam, yet, to insist that everyone that wants to use sash must implement pam support before using sash. Depending on PAM would be a fatal mistake. sash is for situations when your system is FUBARed, therefore you can not assume that you will still have a working PAM subsystem either. It must be completely standalone without needing any external libraries. This is _not_ about the sash executable itself using PAM. It was a proposal to use the PAM functionality to ensure that the root and sashroot passwords remain in sync, i.e., whenever root's password is changed, change the sashroot password as well. Ooops. I understood it differently. I take my argument back. Mike
Re: Useless packages (was Re: anarchism_7.7-1.deb)
On Sat, Sep 25, 1999 at 07:28:57AM +, Lars Wirzenius wrote: David Starner [EMAIL PROTECTED]: Instead of each developer chose what packages are and aren't useful to them, why don't we look at the popularity contest? A simple, bias-free way of seperating programs on to the CD's, by actual use. That is what it was made for. http://www.debian.org/~apenwarr/popcon/ says *** THIS IS EXPERIMENTAL!! *** Try not to get upset if the results are incorrect, but be sure to e-mail me if you think there's something funny going on. I wouldn't base decisions on it yet. Is there any reason to think it's not correct? More importantly, even if it is somewhat wrong, is there any reason to think it's not better than what we have? Assuming it works, popcon takes into account dependencies (because if a depends on b, then at least as many people have b installed as have a installed.) If there are any standard packages that popcon wouldn't put on the first CD, I would question whether they really should be standard. The biggest problem with popcon is that it gives more weight to a program in Slink than to a program new with Potato (assuming there are a significant amount of people running popcon on straight Slink systems.) David Starner - [EMAIL PROTECTED]
Re^2: strange behavior of dh_dhelp
Am 24.09.99 schrieb joey # kitenet.net ... Moin Joey! JH dh_installdocs uses doc-base, which in turn registers documents for JH dwww and dhelp. Thous it is a superset and should be used, no? I would recommend using dwww and dhelp directly. dhelp#s parser is written in C and uses a database. So it#s a lot of faster than using doc-base, which is written in perl. Especially on old 486/586 CPUs using dhelp directly speeds up the installation process of packages dramatically. dhelp comes with a dhelp - dwww converter. So it#s no problem to support both system. JH Yes. Why? What is the advantage of using doc-base? cu, Marco P.S.: The latest dhelp 0.3.14 supports FHS *and* FSSTND :). -- Linux HOWTOs - Die besten Loesungen der Linuxgemeinde ISBN 3-8266-0498-9 Uni: [EMAIL PROTECTED] Fido: 2:240/6298.5 Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/
Re: Useless packages (was Re: anarchism_7.7-1.deb)
Excerpts from debian: 25-Sep-99 Re: Useless packages (was R.. by David [EMAIL PROTECTED] Is there any reason to think it's not correct? More importantly, even if it is somewhat wrong, is there any reason to think it's not better than what we have? Well, accurate for the data it gets doesn't neccessarily mean accurate for all debian users, and there's probably reason to believe that systems that installed popularity-contest or send out the emails would differ systematically in some ways from systems that didn't (For one, the computer would have to be on and on a network when the emails are sent, so most respondants are probably on and on a network continuosly..) In any case, it's probably a good thing to use, as long as its not taken too seriously..
Re: Packages should not Conflict on the basis of duplicate functionality
The Doctor What wrote: Why shouldn't *all* daemon packages ask these questions, and whether to even run *upon install*? Because we need to decrease the number of questions asked at install time, not increase it. -- see shy jo
Re: Packages should not Conflict on the basis of duplicate functionality
On Sat, Sep 25, 1999 at 01:02:44AM -0700, Joey Hess wrote: The Doctor What wrote: Why shouldn't *all* daemon packages ask these questions, and whether to even run *upon install*? Because we need to decrease the number of questions asked at install time, not increase it. How about add one question: Automatically start all daemons: [Y/n] If they answer yes, then no questions. If they answer no, ask as many questions as you want. :) Of course, the downside of this particular question is ... not *all* daemons should be automatically started. Some require configuration before being started. Perhaps a change of wording would improve my question. fwiw, $.02. -- Seth Arnold | http://www.willamette.edu/~sarnold/ Hate spam? See http://maps.vix.com/rbl/ for help Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: Re^2: strange behavior of dh_dhelp
[EMAIL PROTECTED] (Marco Budde) writes: Am 24.09.99 schrieb joey # kitenet.net ... Moin Joey! JH dh_installdocs uses doc-base, which in turn registers documents for JH dwww and dhelp. Thous it is a superset and should be used, no? I would recommend using dwww and dhelp directly. dhelp#s parser is written in C and uses a database. So it#s a lot of faster than using doc-base, which is written in perl. Especially on old 486/586 CPUs using dhelp directly speeds up the installation process of packages dramatically. dhelp comes with a dhelp - dwww converter. So it#s no problem to support both system. JH Yes. Why? What is the advantage of using doc-base? Because if in the future we get another documentation system in addition to dhelp and dwww, it will be automatically supported by every package using doc-base. Why do we have two Debian documentation systems in the first place? NIHS? - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: Packages should not Conflict on the basis of duplicate functionality
Also most daemons should fail binding to a port if multiple ones are installed and they automatically start. So unless they have conflicting files they shouldn't conflict. Instead of conflicting each package that suplies foo-daemon should just spit out an warning message on install saying that there are multiple packages installed that provide foo-daemon and each package that provides foo-daemon must be manually configured to receive predictable usage. I know at my day job we have development servers that maintain multiple versions of various packages, such as cobol, informix and internally written packages. While these aren't running on Debian or even linux in most cases most of these packages would have unpredictable usage if people didn't change environment variables or config files so they know which one they are using at any one instance. We also have a webserver that has three differemt webservers on it (even though they are all derived from apache.) Raz
Re: Packages should not Conflict on the basis of duplicate functionality
Seth R Arnold wrote: How about add one question: Automatically start all daemons: [Y/n] If they answer yes, then no questions. If they answer no, ask as many questions as you want. :) Of course, the downside of this particular question is ... not *all* daemons should be automatically started. Some require configuration before being started. Perhaps a change of wording would improve my question. That'd be workable. Ideally, if debconf were used, this one question would be asked the first time you install a daemon, and all other daemons would inherit it thereafter. Quite easily done with debconf.. -- see shy jo
Re: possible problem with new perl, libc6 on Sep 23rd
-BEGIN PGP SIGNED MESSAGE- Ben Collins [EMAIL PROTECTED], in an immanent manifestation of deity, wrote: More specifically it is dpkg doing the breaking, but it's perl's fault on how it is setting everything up. You will note that these two binaries are in the perl package itself [EMAIL PROTECTED](11:07am)-~]%l tmp/usr/bin/ total 1052 -rwxr-xr-x 2 collinbm collinbm 534844 Sep 22 03:32 perl-5.005.dist* -rwxr-xr-x 2 collinbm collinbm 534844 Sep 22 03:32 perl5.00503* However after configuration, perl-5.005.dist is hardlinked to perl-5.005, and then subsequently removed. So in actuallity we have a binary (/usr/bin/perl-5.005) that is not under control of the package system directly (bad idea IMO). Note also that this means that perl-5.005 is a hardlink to perl5.00503 (which is under package control). Why does perl need to do all this hardlink magic and also leave us with a binary that dpkg knows nothing about?! I inherited this when I inherited the package in November of 1995. It was setup this way so that after the removal of the previous Perl package and before the installation of a new Perl package, there was still a Perl available. Since we always needed a Perl, we wanted to avoid that small window. I notice that bash doesn't do any shenanigans like this. Is this a relic of bygone days and I don't need to do this funky stuff anymore? That would make things much easier for me. Darren - -- [EMAIL PROTECTED] http://www.daft.com/~torin [EMAIL PROTECTED] [EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996 @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @ @Make a little hot-tub in your soul. @ -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv Comment: Processed by Mailcrypt 3.5.1, an Emacs/PGP interface iQCVAwUBN+yZBI4wrq++1Ls5AQGUmgP8DCjE6sNWyfY+P1bbYrzqUI1B5LQ2mFRf oohd+1SQV7uFaRH8Sg4lHF62zgTyOyrBYKxgv6gysSqkKy4Tsb6lcoyxvju4Ha2y 5yDfCDcTpLcVGnZuPXGEEoRkhKOXjBCW2PfgjIrcDU6iqMHZd0dgMght0J/1WDTu 1xf4iDEH1cM= =O+D9 -END PGP SIGNATURE-
Re: XEmacs21 project status.
From: [EMAIL PROTECTED] (Karl M. Hegbloom) Subject: XEmacs21 project status. Date: 23 Sep 1999 14:40:37 -0700 As I mentioned, I will be returning to work soonish... within a week or two. I just verified that an anon CVS will work from master. If anyone would like to have a look (please do), you can copy my setup from master and see it. There's a script you'll need, ala Joey Hess' sshanoncvs. The server will stay here, and this is (right NOW) the current state. Make sure you pull in the right branch. ;-) I've just granced at it and found that all of my requests seems to be done. Thank you! But I found that *-mule-wnn and *-mule-canna-wnn packages are built with --with-wnn=yes, but it should be replaced by --with-wnn6=yes. The configure option --with-wnn=yes is for Wnn4/FreeWnn and --with-wnn6=yes is for Wnn6. Wnn6 is upper-compatible with Wnn4/FreeWnn and provides much functionality, so --with-wnn6=yes is better. In this case, you have to install wnn6-dev, not wnn-dev or freewnn-*-dev before building xemacs21. Just one more request: Could you set up an apt-able staging area or do an official upload? I'd like to test them as precompiled Debian packages as well. Was there a release while I was gone? :-( Wish I'd been ready in time. Dres has set up his apt-able area recently at deb http://va.debian.org/~dres/xemacs21/; (see also http://www.debian.org/Lists-Archives/debian-devel-9909/msg01575.html). I hope Dres's and yours are integrated and available in potato soon. -- Keita Maehara [EMAIL PROTECTED]
Re: possible problem with new perl, libc6 on Sep 23rd
Darren/Torin/Who Ever... wrote: I inherited this when I inherited the package in November of 1995. It was setup this way so that after the removal of the previous Perl package and before the installation of a new Perl package, there was still a Perl available. Since we always needed a Perl, we wanted to avoid that small window. I notice that bash doesn't do any shenanigans like this. Is this a relic of bygone days and I don't need to do this funky stuff anymore? That would make things much easier for me. It's my understanding that dpkg is (and always has been) designed so this kind of thing isn't necessary. As I understand it, when a package is upgraded, for each file, dpkg does this: - extracts new file as .dpkg-new - if it can, atomically overwrites the old file with the .dpkg-new file - if not (replacing directory with file, etc), renames the old file to .dpkg-old, and renames .dpkg-new to the final filename - removes .dpkg-old file Nowhere in there do I see any time at all when some version of the file is not available. -- see shy jo
Re: Useless packages (was Re: anarchism_7.7-1.deb)
On Sat, Sep 25, 1999 at 02:51:36AM -0500, David Starner wrote: On Sat, Sep 25, 1999 at 07:28:57AM +, Lars Wirzenius wrote: David Starner [EMAIL PROTECTED]: Instead of each developer chose what packages are and aren't useful to them, why don't we look at the popularity contest? A simple, bias-free way of seperating programs on to the CD's, by actual use. That is what it was made for. http://www.debian.org/~apenwarr/popcon/ says *** THIS IS EXPERIMENTAL!! *** Try not to get upset if the results are incorrect, but be sure to e-mail me if you think there's something funny going on. I wouldn't base decisions on it yet. i wouldn't base any decisions on it ever. that's not it's purpose. Is there any reason to think it's not correct? more to the point, is there any reason to think that it matters whether it is correct or not? the popularity contest is for informational (entertainment) purposes only, not for decision making. the usefulness of a package has nothing at all to do with it's popularity - it may be unpopular because it is an obscure and specialised tool but to those who know and need it, it is essential. the survey was never intended to be a means of deciding whether packages are useful or not. nor was it intended for deciding whether to include a package in debian or not. at most, it is a tool for *helping* to order packages on a CD (and even that is of limited use because it mostly shows the popularity of old packages in the last release but not new ones in the current unstable). craig -- craig sanders
Re: Release-critical Bugreport for September 24, 1999
On Fri, Sep 24, 1999 at 12:15:06AM -0500, BugScan reporter wrote: Package: bluefish (main) Maintainer: Antti-Juhani Kaijanaho [EMAIL PROTECTED] 45747 bluefish: This bug is about an alpha compilation error, which was diagnosed and fixed in July. The fix is not yet released, so I'm talking with upstream about getting out a release with the fix. If I can't get an upstream release soon, I'll patch the Debian package with the fix myself. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: sash
* Michael Neuffer said: * Raul Miller ([EMAIL PROTECTED]) [990923 16:15]: On Thu, Sep 23, 1999 at 07:32:50AM -0500, Ashley Clark wrote: Couldn't sash include a PAM module that would change the password to match root's password whenever it was changed? Or am I oversimplifying things? I don't have enough confidence in Debian's pam, yet, to insist that everyone that wants to use sash must implement pam support before using sash. Depending on PAM would be a fatal mistake. sash is for situations when your system is FUBARed, therefore you can not assume that you will still have a working PAM subsystem either. sash won't ever be linked with dynamic PAM libs since it's static by definition. The proposal, as I can see it, is to write a PAM module that could be added to /etc/pam.d/passwd to ask whether the just-changed root password should be cloned into the sashroot account. And that's a really elegant and clean solution, IMHO. marek pgpB0czxG4I45.pgp Description: PGP signature
Re: Conference! - around the world with Debian
On Sat, Sep 25, 1999 at 01:39:41AM -0400, Branden Robinson wrote: On Fri, Sep 24, 1999 at 04:26:27PM +0200, Sven LUTHER wrote: Also use of computer in planes is discouraged and prohibited during landfall and takeoff, as it interfer with the onboard radio equipement ... This is a fiction perpetrated by flight attendants because many of them are too dumb to tell the difference between electronic devices that may generate significant EMF at 108MHz or a little above and ones that don't. Hint: if it's got an FCC sticker on it, it's okay. The FCC is so Well, this is completely off-topic, but I wouldn't be so sure. I have plenty of electronic equipment here which generates an awful lot of interference to my sensitive radio receivers. Switch-mode power supplies in particular (although passengers won't be using those on the plane). Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome. pgpjNLpjI9kne.pgp Description: PGP signature
Re: building kernel 2.0.x under potato
Herbert Xu wrote:
You can easily override this on the command line or in the environment.
well...
Script started on Sat Sep 25 08:28:41 1999
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ ls -l /usr/bin/{,e}gcc
ls: /usr/bin/gcc: No such file or directory
-rwxr-xr-x 1 root root66924 Apr 7 12:35 /usr/bin/egcc
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ alias
alias ls='ls --color -a'
alias mv='mv -i'
alias psa='ps a'
alias sl='ls'
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ gcc
bash: gcc: command not found
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ echo $CC
egcc
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ make bzImage
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep
scripts/mkdep.c
make: gcc: Command not found
make: *** [scripts/mkdep] Error 127
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ export CC=/usr/bin/egcc
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ echo $CC
/usr/bin/egcc
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ make bzImage
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep
scripts/mkdep.c
make: gcc: Command not found
make: *** [scripts/mkdep] Error 127
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ alias gcc=egcc
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ make bzImage
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep
scripts/mkdep.c
make: gcc: Command not found
make: *** [scripts/mkdep] Error 127
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ exit
Script done on Sat Sep 25 08:29:51 1999
Doesn't seem to work for me then...
Regards.
Filip Van Raemdonck
Re: strange behavior of dh_dhelp
Marco Budde [EMAIL PROTECTED] wrote: Why? What is the advantage of using doc-base? You may want to read the documentation of doc-base... It is always a good idea to use a generic format which can automatically converted to all useful formats instead of using one special format. doc-base gives us the chance to add some other documentation system next to dwww and dhelp (both are horribly broken at the moment, so another one may be a good idea) without changing all the packages. If you think, that install-docs is too slow and dhelp-parse in combination with dhelp2dwww.pl is so much faster, why don't you simply rewrite install-docs in C? Then we have a generic and fast solution. P.S.: The latest dhelp 0.3.14 supports FHS *and* FSSTND :). I just installed it, but as far as I can see this doesn't integrate FHS and FSSTND in any way but creates two completely incompatible trees one next to the other. Now I can read parts of the documentation as http://localhost/doc/ (which points to /usr/doc/) and others as http://localhost/fhs/ (which points to /usr/share/doc/). But I would prefer these two trees to be merged. This should be possible for most packages, because the tech-ctte decided that every package that uses /usr/share/doc/pkg has to create a symlink /usr/doc/pkg pointing to /usr/share/doc/pkg. So all documentation should be available as /usr/doc/pkg. The only problem is, that dhelp doesn't support those links at the moment. My packages which follow the tech-ctte decision (using debhelper and dh_installdocs) are only visible in http://localhost/fhs/HTML/ but not in http://localhost/doc/HTML/. In the past we had two places where the user had to look for documentation on programs: http://localhost/doc/HTML/ and http://localhost/dwww/menu.html You new version of dhelp splits this to three places: http://localhost/doc/HTML/, http://localhost/fhs/HTML/ and http://localhost/dwww/menu.html and all three include different doc, see for example section graphics: - Sketch User's Guide dhelp/FHS dwww - Sketch Developer's Guide dwww - Imlib Programmer's Guide dhelp/FHS dwww - XFIG User Manual dhelp/FHS dwww - TIFF Software dhelp/FSSTND - pstoeditdhelp/FSSTND Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: building kernel 2.0.x under potato
On Sat, Sep 25, 1999 at 01:31:08PM +0200, Filip Van Raemdonck wrote:
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ alias gcc=egcc
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ make bzImage
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep
scripts/mkdep.c
make: gcc: Command not found
make: *** [scripts/mkdep] Error 127
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ exit
Script done on Sat Sep 25 08:29:51 1999
Doesn't seem to work for me then...
Of course not, if you want to change the compiler for stuff like dependencies,
you need to set HOSTCC. But for the problem at hand, which is compiling the
actual kernel with gcc272, CC works just fine.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: building kernel 2.0.x under potato
Herbert Xu wrote: Of course not, if you want to change the compiler for stuff like dependencies, you need to set HOSTCC. But for the problem at hand, which is compiling the actual kernel with gcc272, CC works just fine. Doesn't work either: lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ export HOSTCC=/usr/bin/egcc lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ echo $HOSTCC $CC /usr/bin/egcc /usr/bin/egcc lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ make bzimage make: *** No rule to make target `bzimage'. Stop. lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ make bzImage gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep scripts/mkdep.c make: gcc: Command not found make: *** [scripts/mkdep] Error 127 Filip Van Raemdonck
Re: building kernel 2.0.x under potato
On Sat, Sep 25, 1999 at 02:14:11PM +0200, Filip Van Raemdonck wrote:
Doesn't work either:
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ export
HOSTCC=/usr/bin/egcc
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ echo $HOSTCC $CC
/usr/bin/egcc /usr/bin/egcc
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ make bzimage
make: *** No rule to make target `bzimage'. Stop.
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ make bzImage
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep
scripts/mkdep.c
make: gcc: Command not found
make: *** [scripts/mkdep] Error 127
Yes it does,
make bzImage HOSTCC=/usr/bin/egcs
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: building kernel 2.0.x under potato
make bzImage HOSTCC=/usr/bin/egcs Indeed it does. I was too busy looking for a way to do it in the environment... Can one use this with make-kpkg as well? --- Filip Van Raemdonck [EMAIL PROTECTED] member of the fibo-systeam http://fibo.hogent.be | http://fibolite.hogent.be ---
experiemntal fwctl
Hello, just in case anybody is interested, i put the deb package for fwctl on my experimatel debian archive: http://sites.inka.de/lina/debian/ fwctl*deb (depends in libnetwork-ipv4add-perl) is a tool which can generate ipchains rules from a higher level config file. The package is not yet starting or auto-configuring the /etc/fwctl/ files. You can say fwctl flush to remove all rules and make your host non-firewalled. fwctl stop will stop your host to communicate with the world! Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: building kernel 2.0.x under potato
On Sat, Sep 25, 1999 at 02:23:42PM +0200, Filip Van Raemdonck wrote:
make bzImage HOSTCC=/usr/bin/egcs
Indeed it does. I was too busy looking for a way to do it in the
environment... Can one use this with make-kpkg as well?
Probably not, perhaps you can make a patch...
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: possible problem with new perl, libc6 on Sep 23rd
On Sat, Sep 25, 1999 at 02:42:28AM -0700, Darren/Torin/Who Ever... wrote: I notice that bash doesn't do any shenanigans like this. Is this a relic of bygone days and I don't need to do this funky stuff anymore? That would make things much easier for me. Nothing to do but test :) Ben
Re: possible problem with new perl, libc6 on Sep 23rd
On Sat, Sep 25, 1999 at 03:00:35AM -0700, Joey Hess wrote: Darren/Torin/Who Ever... wrote: I inherited this when I inherited the package in November of 1995. It was setup this way so that after the removal of the previous Perl package and before the installation of a new Perl package, there was still a Perl available. Since we always needed a Perl, we wanted to avoid that small window. I notice that bash doesn't do any shenanigans like this. Is this a relic of bygone days and I don't need to do this funky stuff anymore? That would make things much easier for me. It's my understanding that dpkg is (and always has been) designed so this kind of thing isn't necessary. As I understand it, when a package is upgraded, for each file, dpkg does this: - extracts new file as .dpkg-new - if it can, atomically overwrites the old file with the .dpkg-new file - if not (replacing directory with file, etc), renames the old file to .dpkg-old, and renames .dpkg-new to the final filename - removes .dpkg-old file Nowhere in there do I see any time at all when some version of the file is not available. Yeah, obviously /lib/libc.so.6 is a good example of this. If we were left with any period without it, there would obviously be problems. Ben
Re: Packages should not Conflict on the basis of duplicate functionality
On Sat, Sep 25, 1999 at 01:02:44AM -0700, Joey Hess wrote: The Doctor What wrote: Why shouldn't *all* daemon packages ask these questions, and whether to even run *upon install*? Because we need to decrease the number of questions asked at install time, not increase it. Bzzt. Security is more important than usability. We're not building windows 2000 here... Mike Stone pgpgs1yPXXsXw.pgp Description: PGP signature
POR UN MUNDO DE VERDAD - 1º Parte
Estimado Amigo y Hermano: Cierto da una voz en mi interior me pidi hacer algo por este mundo, el nico mundo donde podemos vivir. Quiero pedirte en nombre de todos los nios y las personas que sufren el dolor de perder a sus seres queridos, como estoy seguro debes entender, pases este mail a todos aquellos que conozcas con el nico objetivo de llegar al corazn de las persona para que juntos luchemos por Un Mundo Mejor. Un da de paz, 1 de enero del 2000. Esta es la propuesta: Que durante 24 horas ningn arma sea disparada en la Tierra incluso en la televisin. Qu pasara si, por 24 horas, cualquiera que estuviese en una guerra en diciembre de 1999, acordara no disparar una sola arma en todo el da? Qu pasara si los jefes de programacin de televisin del mundo acordaran NO emitir ningn programa con contenido violento? Qu pasara si los Presidentes de cada Nacin acordaran desarmar todas las armas de guerra e invirtieran todo ese dinero en el bienestar Social de cada persona en el mundo?. Que pasara si el ser Humano que tiene la capacidad para razonar y pensar decidiera perdonar y ayudar a sus semejantes? Actualmente, esta propuesta de UN DIA DE PAZ esta circulando cada vez entre mas gente. Podras ayudar a que esta propuesta se convierta en realidad hacindola circular entre los tuyos? Esto es como un pensamiento en oleada, cuanta mas gente haga suyo este deseo mas posibilidades hay de que se haga realidad. UN DIA DE PAZ 1 DE ENERO DEL 2000. JORGE FERNANDO CORDBA ARIAS 0387-156055075 image/gif
PARIS GNU/LINUX EXPO UPDATES FEV 2000
http://www.linux-expo.com/international/index.html bst regards. Frederic.
Re: Funding for a Crazy Idea
Hello again Joey, On Fri, 24 Sep 1999, Joey Hess wrote: Helen McCall wrote: In the meanwhile; If you are prepared to accept funding from such a source, there is always NATO. They fund many such things if they are giving good participation to what NATO calls Sensitive Areas. Weird. Yes! That is what I thought some years ago when I first learnt of this. I have just been looking at the NATO web site, and they appear to have changed for the better in recent years. Now they make no reference to sensitive areas. Their science and technology programmes are now more generally aimed at promoting world peace! The NATO website can be found here: http://www.nato.int/science/cst.htm It looks very promising. I read through a lot of the details and it may be that a conference/workshop on the development of Debian Gnu/Linux and Debian Gnu/Hurd fits into the NATO guidelines. You would need to organise it as an Advanced Research Workshop (ARW). There is scope in the guidelines for projects doing technical development of existing operating systems like Debian. You need to read through all the documentation carefully. One part of the documentation, preparing the actual application for an ARW, may be found in the following PDF file: http://www.nato.int/science/bestpractice/arw.pdf Such areas include Portugal, Greece, Turkey, etc. Do you have any developers in these countries? A full list of such countries can be obtained from the NATO web site (forgotten the address). I'd be surprised if we don't, but I don't really know offhand. Anyone? What is needed is for someone to compile a list of all Debian Developers and their geographical addresses. This is something you have said yourself before. Volunteers? Best wishes, Helen McCall E-Mail: [EMAIL PROTECTED] Tel: 01752 342675 Fax: 08700 525850 ---
Re: apt-get source fails for some packages
Previously Atsuhito Kohda wrote: From: Josip Rodin [EMAIL PROTECTED] This bug is already known, reported, and is promised to be fixed in the next dpkg(-source) upload. I uploaded dpkg 1.4.1.11 yesterday which fixes this. It is currently sitting in Incoming, so keep a close look at your mirror so see when it arrives.. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpyqWlby64ot.pgp Description: PGP signature
Re: Packages should not Conflict on the basis of duplicate functionality
* Michael == Michael Stone [EMAIL PROTECTED] wrote: Michael On Sat, Sep 25, 1999 at 01:02:44AM -0700, Joey Hess wrote: The Doctor What wrote: Why shouldn't *all* daemon packages ask these questions, and whether to even run *upon install*? Because we need to decrease the number of questions asked at install time, not increase it. Michael Bzzt. Security is more important than usability. We're not Michael building windows 2000 here... Ii I install a daemon, I want to use it. So it is the obvious step to automatically activate it. Debian packages installed should be usable without further manual steps. This is why no program may depend on environment variables. This is why any programm has to ship a default config if possible. If you fear for security, then the default config of this package is not good enough, not the fact that it is shipped in a ready to use condition. Ciao, Martin
Re: sash
On Sat, Sep 25, 1999 at 01:27:51PM +0200, Marek Habersack wrote: The proposal, as I can see it, is to write a PAM module that could be added to /etc/pam.d/passwd to ask whether the just-changed root password should be cloned into the sashroot account. And that's a really elegant and clean solution, IMHO. If someone wants to write such a module, I'd be more than happy to include it in the sash package. Aside: currently sashroot is optional, and I also offer the option to change sashroot's password every time sash is reconfigured. Other options include the option to set root's password to be sash and the option to not touch the password file at all. I agree that a pam solution would be elegant, but at the moment it's not an urgent thing for me. -- Raul
Re: Packages should not Conflict on the basis of duplicate functionality
On Sat, Sep 25, 1999 at 03:32:25PM +0200, Martin Bialasinski wrote: Michael Stone [EMAIL PROTECTED] wrote: Bzzt. Security is more important than usability. We're not building windows 2000 here... Ii I install a daemon, I want to use it. That doesn't account for daemons installed by default or daemons installed by accident by people who are trying to install everything because they're not sure what they want. If what you said was true, the various imap and mountd exploits that have given linux such a bad rep would never have been the problem that they are. If you fear for security, then the default config of this package is not good enough, not the fact that it is shipped in a ready to use condition. Yes. The default config of activating a bunch of stuff by default is not good enough. Mike Stone pgpqPcuqZ5xa0.pgp Description: PGP signature
Re: Funding for a Crazy Idea
On Sat, Sep 25, 1999 at 13:59:16 +0100, Helen McCall wrote: What is needed is for someone to compile a list of all Debian Developers and their geographical addresses. We're already doing that - see https://db.debian.org . Ray -- Cyberspace, a final frontier. These are the voyages of my messages, on a lightspeed mission to explore strange new systems and to boldly go where no data has gone before.
Re: Conference! - around the world with Debian
On Sat, Sep 25, 1999 at 09:29:35PM +1000, Hamish Moffatt wrote: On Sat, Sep 25, 1999 at 01:39:41AM -0400, Branden Robinson wrote: On Fri, Sep 24, 1999 at 04:26:27PM +0200, Sven LUTHER wrote: Also use of computer in planes is discouraged and prohibited during landfall and takeoff, as it interfer with the onboard radio equipement ... This is a fiction perpetrated by flight attendants because many of them are too dumb to tell the difference between electronic devices that may generate significant EMF at 108MHz or a little above and ones that don't. Hint: if it's got an FCC sticker on it, it's okay. The FCC is so Well, this is completely off-topic, but I wouldn't be so sure. I have plenty of electronic equipment here which generates an awful lot of interference to my sensitive radio receivers. Switch-mode power supplies in particular (although passengers won't be using those on the plane). This is common. The problem is that while FCC requirements are quite high, manufacturing standards are not, causing an awful lot of equipment out there to create interference. Jay Treacy
Re: sash
* Raul Miller said: On Sat, Sep 25, 1999 at 01:27:51PM +0200, Marek Habersack wrote: The proposal, as I can see it, is to write a PAM module that could be added to /etc/pam.d/passwd to ask whether the just-changed root password should be cloned into the sashroot account. And that's a really elegant and clean solution, IMHO. If someone wants to write such a module, I'd be more than happy to include it in the sash package. I would be willing to do so if nobody has volunteered yet. marek pgp4qaCoCHHAU.pgp Description: PGP signature
Re: anarchism_7.7-1.deb
Jaldhar H. Vyas [EMAIL PROTECTED] writes: On 24 Sep 1999, Siggy Brentrup wrote: In my understanding the bible packages belong into contrib *at best*, since it's value to the public is at least questionable if not offensive to muslims, buddhists(no not to them), hindus ... Um, I'm a Hindu, a Shastri (Hindu priest) actually. And I find nothing offensive or questionable about the Bible. If this debate is going to degenerate into prejudice (and history shows it will) kindly stick to your own prejudices and don't try and speak for others. That's what Christians are often accused of! :-) You might equally well consider this for yourself. Other people (including other people belonging to your particular religion) might regard different things as offensive than you do. Just compare the two statements: 'People of religion X might find religion Y's documents offensive.' 'This is what Christians always do.' And then, please, try to figure out, who should be told to stick to his own prejudices and stop trying to speak for other people. The criterion should be utility. The Bible as a literary and cultural foundation of Western civilization will be useful to a lot more people than the Anarchism package. You don't try to speak for me again, do you? There's a nice (though somewhat rude) proverb in Germany about the validity of arguments by greater numbers like this: Shit must be something great to eat. Millions of flies just can't be wrong. Rainer -- - sig lost -
Re: Packages should not Conflict on the basis of duplicate functionality
On Sat, Sep 25, 1999 at 10:11:17AM -0400, Michael Stone wrote: Ii I install a daemon, I want to use it. Do you want it for personal use, or do you want it available as a public service? -- Raul
Re: Packages should not Conflict on the basis of duplicate functionality
Joey Hess writes: Ideally, if debconf were used, this one question would be asked the first time you install a daemon, and all other daemons would inherit it thereafter. Quite easily done with debconf.. That's the ideal, but what is the policy now? Should chrony ask a question in its postinst or start up chronyd without permission? Right now policy seems to me to strongly oppose questions but say nothing about starting daemons. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Useless packages (was Re: anarchism_7.7-1.deb)
On Sat, Sep 25, 1999 at 08:18:04PM +1000, Craig Sanders wrote: On Sat, Sep 25, 1999 at 02:51:36AM -0500, David Starner wrote: On Sat, Sep 25, 1999 at 07:28:57AM +, Lars Wirzenius wrote: David Starner [EMAIL PROTECTED]: Instead of each developer chose what packages are and aren't useful to them, why don't we look at the popularity contest? A simple, bias-free way of seperating programs on to the CD's, by actual use. That is what it was made for. http://www.debian.org/~apenwarr/popcon/ says *** THIS IS EXPERIMENTAL!! *** Try not to get upset if the results are incorrect, but be sure to e-mail me if you think there's something funny going on. I wouldn't base decisions on it yet. i wouldn't base any decisions on it ever. that's not it's purpose. IIRC, it was designed in part to simplify the decision of what packages to put on which CD. Is there any reason to think it's not correct? more to the point, is there any reason to think that it matters whether it is correct or not? the popularity contest is for informational (entertainment) purposes only, not for decision making. the usefulness of a package has nothing at all to do with it's popularity - it may be unpopular because it is an obscure and specialised tool but to those who know and need it, it is essential. Okay, if you need the complete suite of geda tools, you're probably going to need the full set of Debian CD's. That's life. Almost every program is going to be essential to someone, and putting all the games on the last CD is not going to go over well. the survey was never intended to be a means of deciding whether packages are useful or not. nor was it intended for deciding whether to include a package in debian or not. I wasn't claiming anything of the sort. at most, it is a tool for *helping* to order packages on a CD It's a nice way to order the packages with little to no arbitary decisions, and it's much harder to argue your favorite program was left off arbitrarily. You could set up goals for the CD instead (all Emacsen and a complete Gnome setup on the first CD, for instance), but think about the amount of arguing _those_ goals could cause. (and even that is of limited use because it mostly shows the popularity of old packages in the last release but not new ones in the current unstable). Over half the people who report are running Potato (libstdc++2.9-glibc2.1 is installed by 355 people, while textutils (the top of base) is installed by 612). Still, many of the people who install by CD are running Slink, and would appreciate having the upgraded versions of their current programs on the CD. Does any one have a script to produce a CD listing from the popularity contest? That might produce interesting fuel for the discussion. David Starner - [EMAIL PROTECTED]
PAM/login troubles in newest Potato
Greetings, I originally send this message to debian-powerpc and was informed that this was a general problem. Any help would be appreciated. --- Forwarded Message From: 'Dread Pirate' Nick Rusnov [EMAIL PROTECTED] Resent-Message-ID: [EMAIL PROTECTED] Resent-From: debian-powerpc@lists.debian.org X-Mailing-List: debian-powerpc@lists.debian.org archive/latest/2174 X-Loop: debian-powerpc@lists.debian.org Precedence: list Resent-Sender: [EMAIL PROTECTED] Greetings, I'm having a bit of trouble with non-root user accounts on my freshly installed Potato. I created a new account, eg nick with useradd, and logged into it, at which time I was prompted for a new password. Fine I thought, makes sense. I changed it, and then logged into another console, and was prompted to change my password again! Well, no matter what I do it seems to always require me to change my password on login; I tried mucking with the expiries, I tried changing the password with passwd both as root and as nick.. and yet it still claims that the password has expired after /one use/. any hints? thanks. as always, nick-r [EMAIL PROTECTED] Have you driven a fnord lately?
Re: Packages should not Conflict on the basis of duplicate functionality
* Raul == Raul Miller [EMAIL PROTECTED] wrote: Raul On Sat, Sep 25, 1999 at 10:11:17AM -0400, Michael Stone wrote: Ii I install a daemon, I want to use it. Raul Do you want it for personal use, or do you want it available as a Raul public service? If I install a finger daemon, I want it running with secure defaults at once. I do not want it to give information only on me and only to me. If I need a more specific setup, I change the config. I expect a package I install to be fully functional at once. I don't want to set some environment variables, I don't want to edit a config file, if a good default is possible (and I find this the case on most Debian packages). For daemons. I expect then to be operating right after apt-get install. YMMV. Ciao, Martin
Re: A few changes
On Fri, 24 September 1999 09:12:31 +0100, Matthew Vernon wrote: This is all very well, except for those of us who email from work, and have their PGP key at home... Best point of all. At work even on a private box my co-workers also have root on it. I don't dare having my private key there... Alexander -- Lies, damn lies, and computer documentation. Alexander Koch - - WWJD - aka Efraim - PGP 0xE7694969 - ARGH-RIPE
ITP: Country Codes
Country Codes is an ISO 3166 country code finder. I'll upload it as countrycodes. Here is some example output: % iso3166 -d ftp.chiark.greenend.org.uk Domain name : ftp.chiark.greenend.org.uk Top domain : uk (Great Bretain (iso 3166 code is gb)) Sub domain #1: org (Organizations) Sub domain #2: greenend (Unknown) Sub domain #3: chiark (Unknown) Sub domain #4: ftp (File Transfer Protocol) % iso3166 jp Country 2 letter 3 letter Number - Japanjp jpn 392 Copyright: GPL -- Keita Maehara [EMAIL PROTECTED]
Re: Funding for a Crazy Idea
Helen McCall [EMAIL PROTECTED] writes: I have just been looking at the NATO web site, and they appear to have changed for the better in recent years. Now they make no reference to sensitive areas. Their science and technology programmes are now more generally aimed at promoting world peace! Uhm, they did just bomb Yugoslavia into the stone age, and basically force an occupation of Kosovo, failed to disarm the KLA, and are now just handing over the horrible mess THEY made in the region to the U.N. right as winter sets in. To top it all off the continental European partners are none to pleased with the U.S. and it's lapdog the U.K. and many see NATO as a brain-dead buearocracy just about to go into death throes as the alliance falls apart. The idea that NATO is all about world peace is ludicrous. You'd have to be willingly blind to nearly everything they have ever done in order to actually believe that bit of propoganda. Are you so out of it that you believe a website more than history? I hope that Debian does not resort to begging bald-faced lying war powers for cash. -- Craig Brozefsky [EMAIL PROTECTED] Free Scheme/Lisp Software http://www.red-bean.com/~craig riot shields. voodoo economics. its just business. cattle prods and the IMF. - Radiohead, OK Computer, Electioneering
Re: Funding for a Crazy Idea
On 25 Sep 1999, Craig Brozef wrote: Uhm, they did just bomb Yugoslavia into the stone age... and I hope that Debian does not resort to begging bald-faced liars. Would it not be better if the money is spent on Debian than if on warfare? --free software, not bombs-- ciao
Re: scanning my ports
-BEGIN PGP SIGNED MESSAGE- On Fri, 24 Sep 1999, John Lapeyre wrote: : Dear Security Staff: :I received 2086 connection attempts at several ports on September 22. : The attempts were made from IP address pavlov.midco.net [24.220.0.13] : The machine whose ports were scanned is 128.196.189.45 . : Please make sure that this port scanning does not happen again. : : Here are the first and last connection attempts : : Sep 22 02:01:23 homey tcplogd: auth connection attempt from pavlov.midco.net [24.220.0.13] : Sep 22 21:20:18 homey tcplogd: port 24011 connection attempt from pavlov.midco.net [24.220.0.13] : : Thanks for your cooperation. Mr. Lapeyre, You do realise that pavlov.midco.net is part of the DNS rotation http.us.debian.org? [EMAIL PROTECTED]:~ $ host pavlov.midco.net pavlov.midco.netA 24.220.0.13 ^^^ [EMAIL PROTECTED]:~ $ host http.us.debian.org http.us.debian.org A 206.187.92.15 http.us.debian.org A 207.69.194.216 http.us.debian.org A 209.249.97.234 http.us.debian.org A 141.213.4.21 http.us.debian.org A 24.220.0.13 ^^^ I see no evidence in the logs that you are being port scanned - I feel it's more likely that your use of the mirror here is at issue. You may of course disagree. Nevertheless, I will shut down the mirror here and rebuild this machine from scratch, implementing draconian and paranoid security measures. If I receive further complaints of abuse from Debian project participants, I will be forced to remove the mirror entirely. Complaints to [EMAIL PROTECTED] are viewed by members of the management team as well as members of the technical staff, and I regret to inform you that one of the members of the management team has reacted to your complaint in an abusive and non-productive manner that will certainly impact our ability to help Debian in the future. I regret the shoot the messenger tone of this email; understandably security is important and potential abuses should be dealt with swiftly and forcefully, given the state of the Internet today. Nevertheless, common sense can and should be exercised whenever possible. I reiterate that today I remove pavlov.midco.net from the mirror rotation http.us.debian.org. HTTP, FTP, and RSYNC access to this machine will be turned off upon completion of this email. The machine will be shut down and rebuilt from scratch. Mirror services *may* be restored at that point, if I can convince management that the benefits of hosting a mirror outweigh the liabilities. Sincerely, - -- Nathan Norman - Network Specialistmailto:[EMAIL PROTECTED] High Speed Internet Accesshttp://www.midco.net finger [EMAIL PROTECTED] for PGP Key ID: (0xA33B86E9) -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBN+0ovAXl8N+jO4bpAQGTmQP9Eyff8etuyzQkYx3kKry2QJTlpP5KGTj4 hiIkViV2d3T6rOJ1paeESYjMrzycNLBBdqSNMvmnBYMzSC3fY9ykdNBSC/wUEBfq Q4oCG+OYOovDJDQXxurDj0/HgZzoIGPt8lx3ODDox34jris/hhu3qruE9RlHcT13 0sgwXKTBcp8= =fgR7 -END PGP SIGNATURE-
Status of GNOME in potato
Now that GNOME 1.0.40 is out for beta testing, I had a look at what needs
to be updated in potato.
Needless to say it would be great to have an up to date GNOME in potato
before the freeze...
==
Prerequisites for the gnome libraries
audiofile-0.1.9.tar.gz Audio file format library
* current Debian version: 0.1.7-2
esound-0.2.14.tar.gzSound server
* current Debian version: 0.2.10
glib-1.2.5.tar.gz Utility routines
* current Debian version: 1.2.4-1
ORBit-0.4.95.tar.gz CORBA implementation
* current Debian version: 0.4.94-0.1
Prerequisites for the main GNOME modules
gnome-libs-1.0.40.tar.gzThe main GNOME libraries
* current Debian version: 1.0.10-3 [NMU of 1.0.40-0.1 is in Incoming/]
libgtop-1.0.4.tar.gzPortable system status access library
* current Debian version: 1.0.1-2
The main GNOME modules
gnome-core-1.0.41.tar.gzPanel, help browser, session manager
* current Debian version: 1.0.9-0.1
mc-4.5.39.tar.gzFile manager
* current Debian version: 4.5.38-4
control-center-1.0.40.tar.gzGraphical configuration for user settings
* current Debian version: 1.0.5-2
Prerequisities for some of the apps
libglade-0.6.tar.gz GUI builder library
* current Debian version: 0.4-1
Cool applications and add-ons
ee-0.3.10.tar.gzImage viewer
* current Debian version: 0.3.9-1
gtop-1.0.4.tar.gz CPU memory usage monitoring
* current Debian version: 1.0.2-1
gtk-engines-0.6.tar.gz More themes
* current Debian version: 0.5-2
xchat-1.2.1.tar.gz IRC client
* current Debian version: 1.2.0-1
Development tools
glade-0.5.3.tar.gz GUI builder
* current Debian version: 0.4.1-1
gnome-objc-1.0.40.tar.gzObjective C language bindings
* current Debian version: 1.0.2-2
Up to date Packages
libxml-1.4.0.tar.gz XML library
* 1.4.0-1 [OK]
gtk+-1.2.5.tar.gz Widget set
* 1.2.5-1 [OK]
imlib-1.9.7.tar.gz Image loading and manipulation library
* 1.9.7-2 [OK]
libghttp-1.0.4.tar.gz HTTP access library
* 1.0.4-1 [OK]
gdm-2.0beta3.tar.gz Graphical login screen
* 2.0-0.beta3 [OK]
gnome-print-0.8.tar.gz GNOME printing library
* 0.8-1 [OK]
gnome-media-1.0.41.tar.gz CD player, volume control, sound visualizer
* 1.0.41-1 [OK]
gnome-pim-1.0.10.tar.gz Calendar, addressbook
* 1.0.10-1 [OK]
gnome-utils-1.0.13.tar.gz Small utilities (hex editor, system info, ...)
* 1.0.13-1 [OK]
gnumeric-0.38.tar.gzSpreadsheet
* 0.38-1 [OK]
gnome-python-1.0.4.tar.gz Python language bindings
* 1.0.4-2 [OK]
Gtk---1.0.2.tar.gz C++ language bindings
* 1.0.2-1 [OK]
==
--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux: http://www.openhardware.orgExecutive Linux: -
- http://www.fr.debian.org Open Hardware: http://www.exelinux.com -
---
J'adore la France :
c'est un pays superbe et surtout il n'y a pas d'Anglais. [Mick Jagger]
Re: scanning my ports
*Nathan E Norman wrote: Mr. Lapeyre, You do realise that pavlov.midco.net is part of the DNS rotation http.us.debian.org? No, I didn't. I was using the mirror. I am in error. Obviously the connections to several ports on my machine were a legitmate part of the transfer of data to my machine. I made the accusations out of ignorance. I see no evidence in the logs that you are being port scanned - I feel it's more likely that your use of the mirror here is at issue. You may of course disagree. No, I agree. The connection attempts in my log were made to transfer data that I requested. Nevertheless, I will shut down the mirror here and rebuild this machine from scratch, implementing draconian and paranoid security measures. Please don't do this. I don't see any need to do this. If I receive further complaints of abuse from Debian project participants, I will be forced to remove the mirror entirely. Complaints to [EMAIL PROTECTED] are viewed by members of the management team as well as members of the technical staff, and I regret to inform you that one of the members of the management team has reacted to your complaint in an abusive and non-productive manner that will certainly impact our ability to help Debian in the future. I feel sorry for this person. I regret the shoot the messenger tone of this email; understandably security is important and potential abuses should be dealt with swiftly and forcefully, given the state of the Internet today. Nevertheless, common sense can and should be exercised whenever possible. I made a mistake, and made a false accusation. I am very sorry to have wasted the time of your security team. Maybe you can avoid further waste of time, by accepting my retraction of accusations and realizing that now there is no evidence and no accusation of a security problem, and therefore, no reason to take action on a suspected security problem I apologize to the project for throwing a wrench in the mirroring system. -- John Lapeyre [EMAIL PROTECTED], [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre pgp2l3B2xdxlN.pgp Description: PGP signature
GIF [partial] alternative : alpha + english version
Hello, We can do, without GIF, animations and we can generate images from within the JavaScript source file ( no need to send tons of requests). The technique has been successfully tested with Navigator 3.0x, 4.0x and 4.6, and with Internet Explorer 4.0. This MAY work with Opera ( JavaScript 1.1 compatible) but this is untested. This SHOULD work with Mozilla, but there are problems not related to the library ( the generation of the images is done, but the document is a mess - perhaps some difficulties with the DOM specifications implementation?). ImaJin ( *Ima*ges generated with *J*avascript from with*in* the source file) provides the following features : - A Perl script that takes an xbm file format and generates a string to assign to a JavaScript variable ( with RLE basic compression); - The library ImaJin_0.5a : - Functions to generate the internal format; - Functions to draw a pixel, a vertical or horizontal line, to negativize an image, to rotate an image, to buttonize an image; - Function to generate the format to communicate to the browser: - Explanations in french and english; - Examples. The licence is GPL. This is an alpha version and was meant to be prototypage ( this actually works, and you can see the result running on my web site). This has been 95% of research, test, swearwords, and 5% coding. This is open software so you are allowed to ... open your mouth : critics, suggestions, improvements, questions ( but ...RTMF !), bug reports are welcome. You can start by the explanations at the following URL : http://www.polynum.com/cgi-bin/index.cgi?/docs/bdi/langage/interprete/javascript/manuel/js_xbm.html and you can download the stuff via ftp here : ftp.polynum.com/pub/produits/ImaJin/ImaJin_0.5a-1.tar.gz BTW, this is only an ( incomplete) first step. I will introduce a new graphical format ( vectorial and multi-files), and the xbm technique will be use for prototypage in black and white. And for this format, I have had the following idea about a new licence : a new contaminating licence more liberal. The contamination is put in the highest level : the algorithms, the principles. You can use these principles without any fee, even for commercial work that is sold, even if you don't make the sources publicly available ( but you MUST give the source code to your customers), even if you don't allow derived work from your code, as long as the algorithms, principles, formats, API ( etc...) used with these ones are made publicly available, under a licence that CAN'T be more restrictive than this one. Then, if in the country, patent are illegal, just send this one to /dev/null ( this is OK because this is what we want), and if the patent is legal, then create new principles that in the future nobody can avoid to use : this is an offensive licence, a patent boomerang one ( and when I speak about new principles that nobody can avoid to use, I don't speak about my own stuff :-) but there is, in the free software community, some great persons that have undoubtly these capacities). I call this licence DQM licence ( the logo already exists, do you know ?). Just a thought ... Best regs. -- Thierry LARONDE [EMAIL PROTECTED] website : http://www.polynum.com unctuous : used about somebody who pretends to put balm on your wounds, when, at the very time, by way of preliminaries, he's just oiling your arse. Adrien Herryolt, Le glossaire des Précieuses
Re: Running daemons without asking for permission on install
This is also a very big issue for those who install groups of packages during the install. I know that I was recently bitten by this when I chose to install a number of groups of packages, and didn't realize that the masquerading and redirecting versions of inetd were installed. It took some investigation to figure out what was happening. Dave Bristel On Sat, 25 Sep 1999, Lars Wirzenius wrote: Date: Sat, 25 Sep 1999 22:01:29 GMT From: Lars Wirzenius [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: Running daemons without asking for permission on install Resent-Date: 25 Sep 1999 22:03:47 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; Martin Bialasinski [EMAIL PROTECTED]: [If] I install a daemon, I want to use it. However, if you install a daemon by mistake, or without knowing it, it would be nice to be alerted to this fact. Such things might happen because you didn't know that, say, linuxconf or Gnome run daemons, or because the program you want to install requires a daemon to be running. I'm not sure if the correct solution to this is to ask a question on install, but at least it's better than to do things without warning. Which reminds me, it might be nice for Debian to run something akin to a port scanner locally from cron.daily or something, so that the sysadmin will notice such problems better. (Optionally, and not reporting ports that the sysadmin knows are OK.) -- Stupid little mailer under construction, sorry for any problems. pgpWaiabG9l7H.pgp Description: PGP signature
ssh keys in ldap
Hi all,
I would like a couple people to look over this patch I have made to SSH.
It creates a new option that allows ssh to lookup RSA authentication keys
in a global file modeled after the shadow password file. The intent is to
allow users to place their RSA ssh key into the ldap directory and then
have that key replicated automatically to all machines and used by ssh.
Checking of the global key file is done after looking at the users
.ssh/authorizes_key file and the global file is keyed to each maintainer.
LDAP entries would look like this:
sshrsaauthkey=1024 35
13188913800864665310056145282172752809896969986210687776638992421269538682667499807562325681722264279958572627924253677904887346542958562754647616248471798299277451202136815142932982865314941795877586991831796183279248323438349823299332680534314763423857547649263063185581654408646481264156574330001283021
[EMAIL PROTECTED]
And I would probably put a PGP mail gateway to set new keys. [ie gpg
--clearsign .ssh/identity.pub | mail [EMAIL PROTECTED]
The advantage would be that everyone can use their ssh key uniformly on
all the machines. If someone looses their key or needs to revoke it due to
a compromise it can be done quickly and correctly.
If nobody can see why this would be a bad idea I will deploy this system
on db.debian.org and the debian.org machines in the near future. I hope
that when lsh becomes usable a similar patch to it can be made.
Thanks,
Jason
diff -ur ssh-1.2.27/auth-rsa.c ssh-1.2.27+jgg/auth-rsa.c
--- ssh-1.2.27/auth-rsa.c Wed May 12 05:19:24 1999
+++ ssh-1.2.27+jgg/auth-rsa.c Sat Sep 25 14:25:40 1999
@@ -211,7 +211,7 @@
successful. This may exit if there is a serious protocol violation. */
int auth_rsa(struct passwd *pw, MP_INT *client_n, RandomState *state,
- int strict_modes)
+ int strict_modes,int global)
{
char line[8192];
int authenticated;
@@ -220,61 +220,93 @@
UserFile uf;
unsigned long linenum = 0;
struct stat st;
-
- /* Check permissions owner of user's .ssh directory */
- snprintf(line, sizeof(line), %.500s/%.100s, pw-pw_dir, SSH_USER_DIR);
-
- /* Check permissions owner of user's home directory */
- if (strict_modes !userfile_check_owner_permissions(pw, pw-pw_dir))
-{
- log_msg(Rsa authentication refused for %.100s: bad modes for %.200s,
- pw-pw_name, pw-pw_dir);
- packet_send_debug(Bad file modes for %.200s, pw-pw_dir);
- return 0;
-}
-
- /* Check if user have .ssh directory */
- if (userfile_stat(pw-pw_uid, line, st) 0)
-{
- log_msg(Rsa authentication refused for %.100s: no %.200s directory,
- pw-pw_name, line);
- packet_send_debug(Rsa authentication refused, no %.200s directory,
-line);
- return 0;
-}
-
- if (strict_modes !userfile_check_owner_permissions(pw, line))
-{
- log_msg(Rsa authentication refused for %.100s: bad modes for %.200s,
- pw-pw_name, line);
- packet_send_debug(Bad file modes for %.200s, line);
- return 0;
-}
+ const char *keyfile = 0;
+
+ if (global == 0)
+ {
+ /* Check permissions owner of user's .ssh directory */
+ snprintf(line, sizeof(line), %.500s/%.100s, pw-pw_dir, SSH_USER_DIR);
+
+ /* Check permissions owner of user's home directory */
+ if (strict_modes !userfile_check_owner_permissions(pw, pw-pw_dir))
+ {
+ log_msg(Rsa authentication refused for %.100s: bad modes for %.200s,
+ pw-pw_name, pw-pw_dir);
+ packet_send_debug(Bad file modes for %.200s, pw-pw_dir);
+ return 0;
+ }
+
+ /* Check if user have .ssh directory */
+ if (userfile_stat(pw-pw_uid, line, st) 0)
+ {
+ log_msg(Rsa authentication refused for %.100s: no %.200s directory,
+ pw-pw_name, line);
+ packet_send_debug(Rsa authentication refused, no %.200s directory,
+ line);
+ return 0;
+ }
+
+ if (strict_modes !userfile_check_owner_permissions(pw, line))
+ {
+ log_msg(Rsa authentication refused for %.100s: bad modes for %.200s,
+ pw-pw_name, line);
+ packet_send_debug(Bad file modes for %.200s, line);
+ return 0;
+ }
+
+ /* Check permissions owner of user's authorized keys file */
+ snprintf(line, sizeof(line),
+ %.500s/%.100s, pw-pw_dir, SSH_USER_PERMITTED_KEYS);
+
+ /* Open the file containing the authorized keys. */
+ if (userfile_stat(pw-pw_uid, line, st) 0)
+ return 0;
+
+ if (strict_modes !userfile_check_owner_permissions(pw, line))
+ {
+ log_msg(Rsa authentication refused for %.100s: bad modes for %.200s,
+ pw-pw_name, line);
+ packet_send_debug(Bad file modes for %.200s, line);
+ return 0;
+ }
+
+ uf = userfile_open(pw-pw_uid, line, O_RDONLY, 0);
+ if (uf == NULL)
+ {
+ packet_send_debug(Could not open %.900s for
