Re: new virtual package: ups-monitor
In article <[EMAIL PROTECTED]>, Joey Hess <[EMAIL PROTECTED]> writes: > I don't think wish is the right name. Unless you're familiar with tk (as > opposed to just trying to get it installed), you may not know that the tk > interperter is named wish. You don't need to. As a user, you install tk7.6 or whatever; on the other hand a package maintainer, having first determined that his program will work with any version of Tk, can simply depend on wish. One assumes someone maintaining a package that depends on Tk will be familiar with it to at least that extent. Although it would clearly be better to have more obvious names, and tk-interpreter seems like a perfectly good one, it is not terribly important for virtual packages to have obvious names.
Re: a.s.r manpages
In article <[EMAIL PROTECTED]>, Joey Hess <[EMAIL PROTECTED]> writes: > Look at it this way: I don't think any of the man pages mention ASR at all. > So the only person who is going to connect ASR with the package is someone > who looks at the package description. Who's most likly to do that? The > sysadmin who installs it [1]. Seems appropriate... But with linux you get lusers playing at being sysadmins. Could we just have a description as "Joke manpages"; a package name of "asrman" should be enough for existing a.s.r readers to know what it is, while others will just be slightly puzzled by the name, if they notice it at all. (Not that I care, I don't read a.s.r, though I do read bofh.* occasionally)
Re: default file perms
In article <[EMAIL PROTECTED]>, Amos Shapira <[EMAIL PROTECTED]> writes: > PLEASE PLEASE PLEASE! If you are allready at it - it would be nice to > be able to find files which do NOT come from any package. This will > make it much easier for the person in charge to find sniffer log files > and binaries, and make it harder on the cracker to conceal them. Less paranoid-ly, it will also be useful for people upgrading to debian from another distribution.
Re: long list of give away or orphaned packages
In article <[EMAIL PROTECTED]>, Charles Briscoe-Smith <[EMAIL PROTECTED]> writes: > Hi! I subscribed a few days ago, (and have been somewhat overwhelmed > by the quantity of mail on this list; is there a digestified version?) > and would like to propose that I package up Inform, Frotz, and some of > the associated games. I've already made an inform package. It will get uploaded as soon as I get an account on master. There is one interpreter already packaged, I can't remember which but it's not a terribly good one. My favourite is jzip which I might package up some time.
Re: Problems with inittab
In article <[EMAIL PROTECTED]>, Goswin Brederlow <[EMAIL PROTECTED]> writes: > > Short question inbetween: > > Why is the Debian /etc/inittab different from one use on Watchtower? Why should it be the same? I don't know what the Watchtower one was like (I've never had the misfortune to run Watchtower), but there's no reason why it should be the same. It depends on what gettys etc you want to start (you can also get inittab to start your X server for you, although the debian inittab doesn't do this by default) and what kind of boot scripts should be run. Look in inittab(5) for more information.
Re: gdbm and libc6
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> writes: > - what is the status of lib gdbm and libc6 ? . Htdig uses gdbm but > libc6 provides db and sometime ago I'seen a post of Ulrich Drepper (glibc > maintener), he said that he was unable to find a maintainer for ligdbm. So > is gdbm offcialy dropped for hamm ? should I port htdig to use db instead? It's not officially dropped, it's just not currently maintained; I don't think there's any plan to drop it totally. I believe db has a dbm compatibility mode, and porting htdig to use that should be fairly easy; getting it to use db's native mode is a little more effort but may be worthwhile.
Re: Debian FTP Installation through Internet (fwd)
In article <[EMAIL PROTECTED]>, "Boris D. Beletsky" <[EMAIL PROTECTED]> writes: > Can somebody help this guy. Problem is that pppd tells him that > kernel lacks PPP support - I told him that he should recompile the > kernel but seems like it didn't work. I think I remember that there > was some other reason that pppd would act that way. I seem to remember this is what you get if you use an old version of pppd with a new kernel: is his one a debian version or is it left over from his slackware install?
Re: Infocom Games (Was: long list of give away or orphaned packages)
In article <[EMAIL PROTECTED]>, Brian White <[EMAIL PROTECTED]> writes: >> If we had Frotz, it would be simple to package up a large(ish) number >> of the games available. > > Just so you know, I've already packaged up an Infocom parser (called > "infocom") package. Yes, but it's crap. There are several better ones around which should be packaged for debian. We need a virtual package name, infocom-interpreter perhaps. > None of the Infocom games can be distributed, however. You have to > buy them. None of the ones by infocom can be distributed. There are lots of infocom-format games by other people, mostly produced by the inform compiler. In general the source code is not available (because that would make the games too easy :) so as Charles said, they would have to be in contrib.
Re: cygwin.dll license (was Re: FreeQt ?)
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Kai Henningsen) writes: >> Can't be linked dynamically either... read the GPL. > > Can too. Read the law. > > The GPL _cannot_ restrict someone from doing that, regardless of what they > put in it. Although they _can_ restrict you from using the header files.
Re: points on future installation disks development
In article <[EMAIL PROTECTED]>, Vincent Renardias <[EMAIL PROTECTED]> writes: > Just think about it: consider Windows95, OS/2, AIX, MacOS, Linux. > Linux is the only one to ask "what's your DNS IP addr?, etc..." in the middle > of the installation. Possibly because linux is the only one that supports install by NFS or ftp? It's a bit difficult to do that without doing the network configuration first.
Re: Bug#10516: gs-aladdin: Depends on svgalib1 (>= 1.210-1) which does not allow svgalib-dummy to fulfill the dependency
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (joost witteveen) writes: >> Because they want to run remote X Sessions. > So it will at least not just be a web-server. But anyway, I get your > point. So it could be just a web server that people want to maintain using a GUI editor.
Re: Proposed new virtual package: zcode-interpreter (long)
In article <[EMAIL PROTECTED]>, Charles Briscoe-Smith <[EMAIL PROTECTED]> writes: > I've been putting together a few packages of Z-code stuff, following my > previous posting, and want to use a virtual package, > `zcode-interpreter'... I'd like to put the appropriate man-page before > you all for approval. (It describes the use of the virtual package, > among other things.) I've packaged inform (the compiler), and an interpreter xzip (which uses Charles' scripts). > I haven't got a master account yet, so I can't upload them, but the Nor have I, despite having applied for one (with a signed key) nearly three weeks ago. :( My packages are on ftp://mnb20.pet.cam.ac.uk/pub/debian
Re: Hamm: Exim + Chos standard?
In article <[EMAIL PROTECTED]>, Santiago Vila Doncel <[EMAIL PROTECTED]> writes: > BTW: There will be a completely GPLed procmail in hamm soon. Could we make > it the "standard MDA" as well? :-) [ Red-Hat *already* does this ] Not if we adopt exim as the standard MTA: although exim works very well with procmail, almost all the features of procmail are built in to exim so forcing everyone to use procmail would seem a little silly.
Re: Koules now only for X?????
In article <[EMAIL PROTECTED]>, SirDibos <[EMAIL PROTECTED]> writes: >> We need X versions too (I'm not going anywhere near svgalib or other console >> stuff, I've been forced to reboot too many times, which isn't very funny >> when I've also got other users logged in). > > Umm. My system is a home system. Why were you running full console > games on a production system anyways? It's not a production system. It's my home system, but I provide various services on it as well because I'm just such a nice guy :) (I have a network connection in my college room... there are advantages to being at uni) > My enemies are right, Unix isnt a gaming system when its being used > for production at the same time. However, for a home system, its perfect > for a game system. Just dont mix 'em up, and you'll be fine. But I can mix X games with everything else, no problem. I can even play quake without affecting anything else. > Everyone, if you want to play console games and have stability at the same > time, just pray that Linus will one day wake up, smell the coffee, and > sanction GGI. I agree that GGI looks interesting.
Re: Koules now only for X?????
In article <[EMAIL PROTECTED]>, SirDibos <[EMAIL PROTECTED]> writes: > Why is Koules only available for X??? I *loved* the variety of console > games that came with Debian. Now one by one they are being X'ised from > the distribution =( We need X versions too (I'm not going anywhere near svgalib or other console stuff, I've been forced to reboot too many times, which isn't very funny when I've also got other users logged in). I agree that having svgalib versions as well would be nice. Personally I'd prefer to have separate packages rather than binaries that do both, although the svgalibdummy package someone mentioned in another thread should help here.
Re: Hamm: Exim + Chos standard?
In article <[EMAIL PROTECTED]>, Christoph Lameter <[EMAIL PROTECTED]> writes: > It might be good if we would replace smail in hamm with exim. I agree entirely. Though we should keep smail for people who use smail elsewhere and don't want to switch. > - Exim is scalable from running from inetd to delivering hundredths of > thousands of messages a day I thought you had problems on one of your list servers and switched to zmailer instead? > Also we might think about replacing lilo with chos as the standard boot > loader from harddisk. lilo always is a difficulty for newbies, chos > offers: > > - Menudriven Boot Loader (Cryptic Prompt only on demand) Can it still load straight into linux without any menus or prompts or anything? If not, it shouldn't be the default IMO. (A nice menu that pops up if you hold down shift or something would be nice though) > - Simple configuration in passwd style file /etc/chos.conf So it uses libext2 or whatever it's called to read directly from the filesystem at boot time, or is it compiled into the boot sector in the same way as lilo is?
Re: Hamm: Exim + Chos standard?
In article <[EMAIL PROTECTED]>, Alexander Koch <[EMAIL PROTECTED]> writes: > Both qmail (which proved insecure ) and Exim are not capable > of UUCP or even bang paths! So a lot of those guys in countries where phone > costs are terrible (like in Germany) still use it and they WILL have a problem > then. Exim is not capable of bang paths, true, but not many people still use them. It _is_ capable of uucp so long as you use domain addressing. Admittedly it is not obvious how to set it up to do so. In any case, I don't see anyone suggesting we get rid of smail or sendmail from the distribution entirely.
Re: Hamm: Exim + Chos standard?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Kai Henningsen) writes: > I seem to remember reading somewhere in the exim docs that some simple > bang addresses are understood by exim. Not sure about that. You can cope with host!user by using a rewrite rule, not anything much more than that though.
Re: Simple policy question...
In article <[EMAIL PROTECTED]>, Alex Yukhimets <[EMAIL PROTECTED]> writes: > The most solid ground not to switch to libc6 is not instability from the > user's point of view (may be libc6 is not that bad), but from the point of > view of developer who's using different kind of commercial developmental > suits. No, that's a good reason not to install libc6 development stuff. It's not a good reason to not install the libc6 runtime and programs that use it, which is what we were talking about. > Unfortunately, as far as I can see, there is no clean way to > have both developmental trees (libc5 and libc6) on the same machine. There cannot be a really good way, but I think they altdev packages are about as good as possible.
Re: Hamm: Exim + Chos standard?
In article <[EMAIL PROTECTED]>, Heiko Schlittermann <[EMAIL PROTECTED]> writes: >: It might be good if we would replace smail in hamm with exim. Exim should >: be the standard mailer for hamm: > > ... hmmm, ``never change a running system'', and smail _is_ running. No-one's suggesting changing running systems. We're suggesting that future installs of debian should use exim instead of smail. Currently both are in debian and both work well, but smail is the default one, it's only the default that will be changed.
Re: Hamm: Exim + Chos standard?
In article <[EMAIL PROTECTED]>, "Christian Hudon" <[EMAIL PROTECTED]> writes: > And yes, I think it'd be a good idea, assuming that exim's .forward syntax > is backward-compatible with sendmail/smail's syntax. Yes and no. Exim will understand ones from sendmail or smail; obviously once you start putting in filtering they will not understand the files from exim, which look something like this # Exim filter if $return_path contains owner-fishnchips then save $home/mail/fishnchips endif
Re: Status of Debian Policy
In article <[EMAIL PROTECTED]>,
Christian Schwarz <[EMAIL PROTECTED]> writes:
> All packages that provide HTML documentation should register these
> documents to the menu system, too. Check out section section 4.1, `Web
> servers and applications' for details.
Is that as well as registering with dwww?
Currently some packages do one and some the other.
> 2. Build a shared library ``libdebian'', that contains
> functions to lock, unlock, and test a file according to the
> locking method we want to use. This library should simplify
> the work of the MUA and MTA maintainers that need to adopt
> their packages. They should link their programs against
> this library and call the appropriate functions.
Would programs _have_ to use this library, or is implementing the same thing
in acceptable? The latter has problems in that it forces us to keep the same
method, but I don't want to see lots of #ifdef debian appearing in the
original source; apart from anything else it doesn't look good being
non-standard even if what we do is superior.
> If we have a consensus about this, we could include a ``good example''
> for a ``/usr/doc/*/README.debian'' file.
>
> I propose that the following infos are listed in this file:
>
> - Name and email address of current Debian maintainer
> - specification about where to get the upstream sources
> - short description of all major changes to the program
>(for example, new command line options, changed locking
>mechanism, major bug fixes, etc.)
> - URL of ``official home page'' if there is one (optional)
Most of this is included in the /usr/doc/${package}/copyright files; why
duplicate it in another file? I can't see any point in a README.debian
except to describe major user visible changes.
> IMHO, we should give some guidelines about how to install cron jobs,
> i.e.
> - don't touch /var/spool/cron/crontabs
> - don't touch /etc/crontab
> - you may install files in /etc/cron.{daily,weekly,monthly}
>if certain rules are fulfilled (cf. bug #8814)
What should you do if you want your job to run at an interval other than
daily weekly or monthly?
> - .info files can be converted into HTML on-the-fly by the CGI
>script "info2www". However, the output of ``texi2html'' is
>much better. Should we ship only HTML by default and put
>.info in a seperate package? (cf. bug #7890)
I'd prefer to see HTML ones in a separate package and info included by
default. Like it or not, info is the standard now; I don't want my hard disc
full of HTML copies of info documents.
> - how "large" may doc files be until they are moved into a
>seperate package?
I don't think just the size should be the deciding factor, so much as how
difficult it is to use the package without documentation. Obviously size is
a factor but I don't think simply putting a limit on the size is very
useful.
Re: locale errors
In article <[EMAIL PROTECTED]>,
Erv Walter <[EMAIL PROTECTED]> writes:
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LC_ALL = (unset),
> LANG = "us"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
I got that (with perl only) before I installed debian; it doesn't like
locale settings that other programs seem to get on with OK. Try removing the
LANG variable and it ought to work. Is whatever sets LANG (your .bashrc?)
something you copied off another system?
Re: Installing XF86 3.3-1 crashed XEmacs 19.15-3
In article <[EMAIL PROTECTED]>, Mark Eichin <[EMAIL PROTECTED]> writes: > I've seen this reported elsewhere; if the xemacs maintainer has > vanished, perhaps someone could grab the debian sources and rebuild a > non-maintainer release using the 3.3 libs? Or at least look into the > problem? (Xemacs has more dependencies on X than emacs does -- the > current emacs works fine with the 3.3 libs even though it was built > against 3.2...) I've never tried it with 19.15, but before I upgraded to debian I used xemacs 19.14 with R6.3 (compiled with R6.1) quite happily, so either it's something introduced in 19.15 or it's something that's been added to X after the XC release of R6.3 (either a bug-fix to the X code itself or something in one of the drivers I suppose).
Re: Hamm: Exim + Chos standard?
In article <[EMAIL PROTECTED]>, David Frey <[EMAIL PROTECTED]> writes: > exim should be able to parse simple bang-paths IMO (host!user), since most > > UUCP paths It can read them with rewriting; it can't rewrite them but you could probably use a perl script or something to generate them on mail sent out using rmail (and you don't need to use them at all with batch smtp) > documented in the package (Conflicts: uucp or something like that) No, because it doesn't conflict with uucp. It works if you use batched smtp over uucp and even if it didn't, it doesn't actually conflict with it, in that the uucp package itself will work just as well when you've got exim installed.
Re: Debian-Policy Manual
In article <[EMAIL PROTECTED]>,
David Frey <[EMAIL PROTECTED]> writes:
>>TOPIC 4: editor/pager policy
> What is the benefit of /usr/bin/sensible-{editor,pager}?
> Why don't we just default to EDITOR=/usr/bin/vi and PAGER=/usr/bin/more
> if both variables are unset? (auch, don't beat me)
That might enable us to get rid of /usr/bin/{editor,pager} though it's an
inferior solution to what we're doing at the moment. It won't enable us to
get rid of /usr/bin/sensible-{editor,pager} which are for progams that don't
understand EDITOR and PAGER.
Re: Status of Debian Policy
In article <[EMAIL PROTECTED]>, Christian Schwarz <[EMAIL PROTECTED]> writes: > The current structure (of packages installed on my system) is: > > Miscellaneous > Development > Document Preparation > Information > Emacs > Programming > teTeX > Graphics > Games > General Commands Is this the best order? Really the first one should be that for info itself, followed by the linux and debian FAQs. What goes after that I don't know, but I find the current one difficult to navigate. > I'm sure the info docs will be available in the future! The question of > topic 11 was which format the .deb's should ship: > >- only info; html in extra .deb >- only html; info in extra .deb >- html _and_ info I think either only info, or neither; I don't want to fill my hard disc with HTML when there's perfectly good info documentation available. (HTML will be as good as info once it's got previous, next and up commands built into the browser: this is possible with HTML 3 but I don't know of any browsers that implement it)
Re: (bogus mailing list message)
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: > I hope he has good arguments for it, since I would not like to have two > concurring menu systems in Debian: menu and dwww. I think it shouldn't be > too hard to change the menu package to dwww's needs, if this should be > necessary. It already does; in the past dwww had it's own menu system _as well_ using ..dwww-lib files in the /usr/doc directories. This is definitely a bad thing as it leads to documents being split into two menus, one generated by the menu package and one from dwww itself.
Re: When will bash 2.01 be packaged?
In article <[EMAIL PROTECTED]>, Christian Schwarz <[EMAIL PROTECTED]> writes: > Guy Maor is the current maintainer of the "bash" package. However, he told > us that he is offline for about 4 weeks. So I think someone else should > grab it and upload a non-maintainer (interim) release. Is that necessary just to work round a (long standing) bug in another program?
Re: locale errors
In article <[EMAIL PROTECTED]>, Tomislav Vujec <[EMAIL PROTECTED]> writes: > But setting LANG to _correct_ value (e.g. en or en_US) might help. perl was giving me errors when I had it set to en_GB (before I installed debian).
Re: GNU stow
In article <[EMAIL PROTECTED]>, Charles Briscoe-Smith <[EMAIL PROTECTED]> writes: > It's at ftp://pcsw104b.ukc.ac.uk/pub/cpb4/>, and I will upload it > as and when. Incidentally, there's a package there called 'curses', Assuming that's the game by Graham Nelson, great, I like being able to delete stuff from usr/local :)
Re: Taking my leave/Packages available
In article <[EMAIL PROTECTED]>, "Larry 'Daffy' Daffner" <[EMAIL PROTECTED]> writes: > svgalib (svgalib1, svgalib1-bin, svgalib1-dev, aout-svgalib which > probably doesn't need any further updates) > zgv I don't want those because I avoid svgalib and everything to do with it. > xcolorsel > pdksh I'll take these two though. However I don't use pdksh myself so if someone who uses it regularly wants it that might be better.
Re: Bug#10676: RFC: Virtual Package Name List (was bug #10676)
In article <[EMAIL PROTECTED]>, Christian Schwarz <[EMAIL PROTECTED]> writes: > There is a virtual package "imap-client" which is "suggested" by imap-4 > (Suggests: pine | imap-client) but no package seems to provide it. Thus, I > suggest to remove this entry, too: > > imap-client Any mail reader capable of accessing remote mail > folders using the IMAP protocol (e.g. Pine) No, leave it. There are other imap clients (I didn't know about this package: I'll have to add it to TkRat). Without it, we'll just have suggests: pine, which is silly when any other imap client is just as good. I suggest we keep it, and file bugs against pine, tkrat and any others, and then remove the Suggests: pine from imap-4. Otherwise, everything you say that I know enough about to comment on looks fine.
Re: leap second
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Kai Henningsen) writes: > Consider a system using "real" time. On June 31, its idea of time would be > wrong until the next software upgrade. No. Using real time, the system clock increments normally, and correctly measures the time since the epoch. The conversion from system time to local time changes every time there is a leap second. > Then, all time stamps would suddenly change by one second (possibly > causing FTP server remirroring and other unpleasant effects). No, because they are based on the system time which is consistent. This would be a good thing. As it is, we use POSIX time, which means that the system time follows GMT. When there is a leap second the time itself is changed; the timezone information does not need to. > This is completely unacceptable. OS time must be predictable. Which is why real time would be much better than POSIX time. Unfortunately we have to use POSIX time, so we're compatible with other computers on the network :(
Re: Correct path for upgrading to libc6-dev?
In article <[EMAIL PROTECTED]>, Ben Gertzfield <[EMAIL PROTECTED]> writes: >> You should certainly remove libdb-dev, since libc6-dev replaces it (as >> libc6 includes libdb.) I haven't done a libdb-altdev, and unless >> someone asks probably won't bother (the libgdbm* packages are already >> uploaded though.) > > Oh, okay. Do you know anything about the others? For libg++, I'd wait until there's a libg++272 package, and install the development stuff from that; for ncurses there are libc6 versions of the library itself, I'm not sure about the development stuff but a force-depends seems to work (the header files aren't changed). I don't know about slang.
Re: Experiences with compiling Debian
On Sun, 22 Jun 1997, Lars Wirzenius wrote: > - having a central repository for autoconf test result might speed things > up (I think autoconf supports this; someone should investigate) Yes; I do it. You need to set the environment variable CONFIG_SITE to the name of a file---I use /etc/config.site---which includes the line cache_file="/var/config.cache" or whatever path you want. Note that installing libraries will require the cache to be cleared (in general; frequently it won't but I wouldn't like to get a computer program to decide when), but so long as you're just compiling and not installing the packages things would be OK. > - source dependencies would be nice, but are not absolutely necessary Two types: where you need another packages source (are there any like that?) and where you need other packages such as -dev packages installed. > - the build process is too verbose, it is difficult to see any warnings > and errors in the voluminous output Mostly just what make always does. To disable it use the -s (or --silent or --quiet) option to make: you can set the MAKEFLAGS environment variable. There's also some other output from dpkg-buildpackage, I don't know whether that can be disabled or not. > - idea: developers upload source only, central machine(s) build > .debs, so that everything uses the same libs, etc Not when, as at present, all of debian/rules has to be run as root. > g77: needs gcc source code to build Yes, but the alternative is for the source package to be much bigger than it needs to be. A better solution would be to merge the source packages. > java-lex: needs a java compiler (javac), which isn't part of bo > proper (theres jdk in non-free, kaffe in contrib) (is kaffe in contrib only because it needs non-free libraries?)
Re: Experiences with compiling Debian
On Mon, 23 Jun 1997, joost witteveen wrote: > (in fakt so much, that I may be tempted to write it myself. You > don't need that many changes). Well, you need to write your own version of make that looks for any attempt to run chmod, chown etc, and then fakes all the ownership and modes in the resulting tar. I'm not sure whether it's possible in general even then, what if the package tries to set the ownership of a file from within another shell script or a perl script; how can you intercept that so it works properly? With a few minor changes in the way packages are made---having tars all made as any user, and chowns done after the package is installed, either in the postinst or by dpkg first (the former would have the advantage of running on existing systems)---we could build as non-root. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
On 24 Jun 1997, Mark Eichin wrote: > > 0.5.21, gpc is 2.something, who knows about gnat... > > gnat is 3.09, 3.10a is in test and might be released some > time... in any case, while merging gcc/g77/gpc into one release > probably makes a lot of sense, gnat is "not like the others" -- > because it's *written* in Ada, not C, so you need the most recent > previous release installed in order to compile it. At least the patches to gcc need to be included, so we don't have the ridiculous situation of another copy of gcc just for ada (Do we still? We did last time I looked) > So keeping that seperate might make sense even if you merge in the > others... Yes, that is a good reason; however it means you still need to download two lots of source to compile ada. > [I can understand if it is too *expensive* to do so, if you pay for > dialup service. But if you don't, then it's a mere matter of hours > when you're asleep [or at work] anyway :-)] If you can saturate the modem with it it would be about two hours I think; that would be less than two UKP here, though I understand German phone charges are rather higher. However, the speed of some of the connections to master I've got recently, it would take rather longer than that. I suppose I should read the docs on uploading via chiark some time. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
On Tue, 24 Jun 1997, Philip Hands wrote: > I think we should aim to get all documentation into separate packages. > > Would it not be possible to make the package building tools (deb-make, debstd > etc.) assume a simplest case of ``single binary, and single docs package'' > rather than the current ``single binary'' ? Anything with info or html docs or significant other files I can agree with; many programs only have a couple of readme files and a man page, and putting them in a separate package seems a little silly. (and at least the readme file definitely should be in the main package even if there is a separate documentation package) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RfD: Debian is not randomly installing services
On Fri, 27 Jun 1997, Martin Schulze wrote: > Therefore I recommend changing our policy slightly. I'll write down a > paragraph for our policy later (or would you like to step forward, > Christian?). > > If a package contains both a server and a client, and the server > opens another possibility to reach the system (via network, modem, > radio &c.) the server will not be enabled without asking the user > for his permission. > > The situation looks completely different if the server has its own > package, like `msqld' for the server and `msql' for the client. Why not just disallow having servers and clients in the same package (an exception would perhaps be things like multiuser games where the server is started by the game when you run it; the worst security flaw there is that someone might cheat at the game)? Those people who install the server package would presumably want it installed, even if there is a possible security flaw. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
On Tue, 24 Jun 1997, Joey Hess wrote: > I haven't been following this thread closely (catching up on mail backlog > after vacation), but the reason I've heard why it's not acceptable to ship > only info files and convert to html on the fly is because the converter in > dwww that does this produces crappy output. Why not just replace it with a > better converter? This dicussion smells to me of making policy to work > around a technical problem. The problem with info is that it is already formatted, with hard line breaks; an algorithm to convert this to another format nicely is very difficult - how can you tell what can be rewrapped and what is a code fragment? Whereas if you go back to the original .texi file, it can be wrapped nicely, and you can even use different fonts. Lynx users like me will hardly notice the difference but in a graphical browser there is a difference in that the one generated from the .texi can use proportional fonts etc. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: question about dpkg-source : why does it create a copy of the orig.tar.gz file ?
On Sat, 28 Jun 1997, Andreas Jellinghaus wrote: > dpkg-source -x /some/path/to/file_version-rev.dsc > > creates not only file_version/, but also file_version.orig.tar.gz. > why ? So that once you've modified it you can easily package up your changed version. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dc and bc in Important?
On Sat, 28 Jun 1997, Erik Andersen wrote: > iThis is correct, but has the unfortunate side effect of not being portable, > since not all /bin/sh happin to be bash. No, it also works with ksh. I believe posix.2 specifies that /bin/sh has to provide various features---basically to be a clone of ksh. Although it would be nice for scripts to work on all versions of /bin/sh, I can't see supporting non-POSIX machines is terribly important compared to easier to read scripts. (If I'm wrong, and POSIX only specifies that ksh has to do all that, then maybe we should make ksh a symlink to bash so our scipts can use that for everything?) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Sub-categorizing the /usr/doc directory.
On Sun, 29 Jun 1997, Joey Hess wrote: > > The directory is very large when you have a lot of packages > > installed, and it takes a lot of processing to open it with a file > > manager, web browser, or dired. > > I completly agree. I have 434 items in /usr/doc, and that's too many. > Splitting it up by package section is a very good idea. I disagree. I rarely need to list the directory as I know roughly what's in it, but I very often want to type in the name; splitting it up would only mean more keystrokes for me. Am I right in thinking that taking ages to list full directories is a particular problem with linux? Will the current changes to the VFS code in 2.1.x help? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ISDN in UK
On Sun, 29 Jun 1997, Andreas Jellinghaus wrote: > > I know that ISDN here is implemented differently from the way it > > is in the USA and I believe it is also different from that in Europe. > > > > Does anyone use ISDN in the UK with Linux? > > i don't know, but i don't think so (at least there is no documentation > in the FAQ). I suspect there is; try asking in uk.telecom, uk.comp.os.linux, or demon.ip.support.unix (demon include ISDN in their basic service, and they have a lot of linux users, so the probability of one of their customers using both together is very high) > > Which of the equipment advertised in the UK is supported by isdnutils > > and the 2.0.30 kernel? I don't know anything about linux specifically here, but I did hear that it's worth getting stuff from Germany or somewhere, as some of the stuff sold in the UK is to American standards and won't work with the Euro-IDSN stuff that most other UK people use. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: linux/unix to NT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Mariusz Pagowski) writes: > I learned about samba package allowing me to access disks > on NT machine from unix/linux. Actually the other way round; samba lets you turn your unix box into a windows network compatible fileserver. There is a client (which would do what you describe) for linux, called smbfs. > But does samba allow me to login/telnet to NT machine from linux/unix and > run remotely a program on it? No it doesn't. > If not is there some software which would allow me to do it? One of the service packs for NT includes a telnet daemon; install that and you can telnet in to do simple things. It's of somewhat limited use, though, since most NT programs try to do graphics and NT doesn't support X.
Re: Need someone to take some of my packages.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Dale Scheetz) writes: > The one that is desperate for a new home is imap-4. I have never been able > to adequately test this package. There are several outstanding bugs that I > have been unable to come to terms with and for this reason alone the > package would be better off in more skilled hands. I had a look at it a week or so ago. I can't get it to support shadow passwords properly: the code that's supposed to support them for linux doesn't compile (under libc6, I haven't tried it on a libc5 system). Since the code is virtually unintelligible anyway, the best solution is probably to write it from scratch or copy it from a program that gets it right.
Re: bo-updates packages
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Adam P. Harris) writes: > The issue of keeping Debian bo crunchy and fresh w/o inhibiting the bold > experimentalism of the hamm lineage is critical to Debian's success. It hopefully won't be a problem once hamm is released. With a completely new set of libraries it is not possible to run hamm packages on a bo system, but hopefully debian 2.1 packages will run on a hamm system correctly; I can't see much point in going to a lot of effort to fix a temporary problem.
Re: BS in rxvt+ncurses
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Brian Mays) writes: > Okay. I'm building a new unstable version of rxvt with backspace set > to ^H. From this point on, Debian's rxvt policy will be to use ^H as > backspace by default. Couldn't you force it to ^? instead? That would be far more sensible. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: crontab
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Miquel van Smoorenburg) writes: > that do this, and file a bug report against them. You should mention that > tail +4 is dangerous since the behaviour of crontab -l might change , and > recommend something like: > > crontab -l | sed -e '/^#.*\(DO NOT EDIT\|Cron version\|installed on\).*$/d' Yes, that seems like a good solution. > instead. Then wait for Debian 2.2 or so, so you can be reasonably sure > everybody has upgraded all those packages at least once and release > a new cron. Once that is done the packages can remove the sed completely (and depend on the new cron). -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: random numbers
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (G John Lapeyre) writes: > Recipes generators and the linux system 'random', which is the longer Do you mean the library call random? No, that isn't brilliant, though if you try other unixes you'll probably find them worse. Apparently /dev/random is very good. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Anyone working on new lyx version?
On Tue, Jan 06, 1998 at 01:26:22PM +0100, Michael Meskes wrote: > Did anyone take over lyx? It seems as if we're close the release of a new > stable version. I took it over. I haven't done anything to it until now, because of the lack of a libc6-based xforms (and you (IIRC) beat me to it once there was one). -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: imap4
On Sat, Jan 10, 1998 at 03:00:17PM -0500, Jaldhar H. Vyas wrote: > Thanks but I was able to solve the pw_encrypt problem on my own. > Apparently in libc6 you can just replace it with crypt(). I tried that and it didn't work: have you tested it? Maybe I just did something silly. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Are we shipping 2.0 with ipmasq in the default kernel?
On Wed, Apr 15, 1998 at 05:02:39PM +, Rev. Joseph Carter wrote: > > The thing is that I had a prefectly working IPmasq setup, with rules > > changed in ip-up and ip-down. > > hmm, now there's an idea. Since I don't use diald or similar, I just set > the rules static. I do use diald, and set the rules static (if I didn't do so, then other computers wouldn't be able to get the computer to dial, which seems to ruin the whole point to me). You might need to change the rules in the ip-up if you have dynamic IP, but only the ones concerned with spoofing protection; the basic ones don't need to know about your real IP address. FWIW I never got those rules to work anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [gtk-list] ANNOUNCE: GTK+ 1.0.0 Released!
On Tue, Apr 14, 1998 at 05:32:17PM -0800, Ben Gertzfield wrote: > Marcus> Did the interface change (e.g. do we need to upload new > Marcus> versions of related packages) ? > > No, the API has not changed since 0.99.4. There are still some packages > using the old API though, I believe. What about the binary interface? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fltk and XForms compliance
On Fri, Apr 17, 1998 at 11:56:02AM +0100, Enrique Zanardi wrote: > > That will be a problem with lyx as the upstream side is thinking about a > > switch anyway, but qt is the leading candidate there. > > Someone should tell them about GTK, now that version 1.0 has been released. > A little bit of info about the distribution problems they will face if > the choose Qt Unfortunately they've already chosen Qt. And done all the work to port it. Have a look at http://www-pu.informatik.uni-tuebingen.de/users/ettrich/klyx.html It's a shame he chose to use a non-free toolkit, as klyx looks very nice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: base-files etc.
On Sun, Apr 26, 1998 at 09:30:04AM -0400, Avery Pennarun wrote:
> Incidentally, I've always wondered why there is no /etc/bashrc and
> /etc/bash_profile. They would be ideal for this.
In the default mode, which files to run at startup is hard-coded into bash,
and doesn't include those.
I always use bash in the POSIX startup mode, where it only executes
/etc/ENV, which then runs any other files necessary, for example mine is:
--
# /etc/ENV: Posix conformant startup script for /bin/sh
#
# A Posix conformant shell will read this file if environment variable ENV
# is set to /etc/ENV.
#
# This currently does almost but not quite like what bash does by
# default - the differences are the reading of root's .bashrc, for
# use with su, and the default bashrc if the user doesn't have one.
#
# Mark Baker - 31 October 1996
#
case "${--}" in *i*)
# Shell is interactive - no scripts used otherwise
# Check if it's a login shell. If so, read /etc/profile,
# then the users .profile
case "${0##*/}" in
-*)
if [ -f "/etc/profile" ]; then
# source /etc/profile
. /etc/profile
fi
if [ -n "${HOME-}" ] && [ -f "$HOME/.profile" ]; then
# source ~/.profile
. "$HOME/.profile"
fi
;;
esac
# For all shells, read the bashrc.
# If it's root, read root's one. On an su, this isn't
# $HOME/.bashrc, but I think it's desirable to use
# root's one anyway, if only to get a different prompt
if [ $(whoami) = "root" ] && [ -f ~root/.bashrc ]; then
. ~root/.bashrc
# Otherwise, look for a ~/.bashrc
elif [ -n "${HOME-}" ] && [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
# If that fails, look for a system default one
elif [ -f "/etc/bashrc" ]; then
. /etc/bashrc
fi
;;
esac
--
To get this to work I had to patch my bash so I could enable this startup
mode without all the other POSIX (mis-)features.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
On Mon, Apr 27, 1998 at 01:49:33PM -0500, Manoj Srivastava wrote: > I understand that one may want a little more leeway than say > the policy documents are writ in stone (I personally prefer that), > but to deny that and make no mention of any mechanism of enforcement > of policy is disquieting. Ian didn't mention an enforcement policy, because that is already clearly mentioned in the constitution---the technical committee. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed Constitution
On Mon, Apr 27, 1998 at 06:05:51PM -0400, Bob Hilliard wrote: > include the plural". Then all of the clumsy constructions using > plural pronouns (they, their) to refer to singular entities (Leader, > Secretary, etc.) should be changed to use singular masculine pronouns > (him, his). "They" is not only a singular, it is also widely accepted as a singular pronoun, and has been used as such by not only ordinary people but also great writers for hundreds of years. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X and Window Mangers
On Tue, Apr 28, 1998 at 01:26:37AM -0500, Branden Robinson wrote: > 1) ship an empty /etc/X11/window-managers with xbase > 2) mark it as a conffile So you don't think other packages---such as the window managers---should modify it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How Debian Linux could be made more secure
On Tue, Apr 28, 1998 at 04:50:45PM +0200, Thomas Roessler wrote: > Today, I reported two bugs in debian packages which > install binaries suid root. Both bugs were avoidable: There's a third one too---we install xterm suid root, which isn't necessary (the alternative is to use a wrapper program to do pty allocation and utmp entry). This was mentioned on one of these lists a couple of months ago. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CERT* VB-98.04: Vulnerabilities in xterm and Xaw
On Tue, Apr 28, 1998 at 05:57:55PM +0200, A Mennucc wrote: > > Vulnerabilities exist in the terminal emulator xterm(1), and the Xaw > > library distributed in various MIT X Consortium; X Consortium, Inc.; > > and The Open Group X Project Team releases. These vulnerabilities may > > be exploited by an intruder to gain root access. > > the only solutions seems to > > chmod 0755 `which xterm` Or to apply a patch that TOG sent to their members, but didn't think to do anything useful like include it in the alert itself. It's probably not free anyway :( Since a program as complicated as xterm is always likely to contain security problems, we probably should leave it un-suid anyway, even once we have patched it to fix the bugs mentioned. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CERT* VB-98.04: Vulnerabilities in xterm and Xaw
On Tue, Apr 28, 1998 at 12:45:33PM -0500, Branden Robinson wrote: > Well, the reason xterm is setuid is because it needs privileged access to > the utmp file. However, this is presently a problem under some > circumstances (see bug #20685). I understand it also needs it to allocate a pty. > XFree86 3.3.2-4 is shipping with an /etc/X11/XResources that sets > XTerm*utmpInhibit to true. Is it the consensus of the project that xterm > should have its setuid removed until this bug (#20685) is fixed? There's a good fix for that bug, which also removes any security holes. I've dug up the URL for the wrapper I mentioned. http://www-uxsup.csx.cam.ac.uk/~pjb1008/project/xterm-wrapper/ > Let me know quickly (especially if any of you know any additional reason > xterm is setuid). If I turn it off then I will want to do so for -5, which > I'd like to release within the next 24 hours. Yes, do turn it off. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PROPOSAL: Services, inetd and xinetd
On Tue, Apr 28, 1998 at 10:59:49AM +0200, Andreas Jellinghaus wrote: > btw: in my opinion debian needs a general resource database (something like > windows nt registry, but with a better, unixlike implementation). We have one. It's called /etc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: interest in xfstt package
On Mon, Apr 20, 1998 at 10:24:33PM -0500, Branden Robinson wrote: > After hamm is released I'm going to be re-engineering XFree86 a bit. An > xserver-common package will be created, I understand that will be necessary (or at least highly desirable) in future anyway, since new releases of XFree86 will have a single server binary with loadable modules for the different drivers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Yet another Linux distribution! :-)
On Fri, May 01, 1998 at 11:10:39PM -0700, Jim Pick wrote: > - targetted towards desktop use only, no server apps, just a few games > > - minimal size - optimized for installation via 28.8k modem via FTP, >which will be the primary distribution mechanism (not CD). These don't seem consistent to me. If people are the wrong side of a dialup link, they need to have a local MTA (actually most people ought to have that even if they're not, although the configuration is significantly simpler if they're on a permanent fast network connection and so don't need local mailboxes) and a local news server. Other than that, it sounds good---not for me, and probably not for the majority of Debian's existing users, of course, but for people who want a simple desktop OS that's easier to use than Windows. Good luck. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 11:36:28AM -0700, John Labovitz wrote: > have you looked at ssmtp? i just took a quick look at the source, and > it seems that it's *extremely* simple -- sounds like a good one for a > send-only MTA. But this is aimed at dialup users! You don't want a send-only MTA, as dialup users presumably want to store their mail locally. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Yet another Linux distribution! :-)
On Sun, May 03, 1998 at 01:37:28AM +1000, Hamish Moffatt wrote: > things (like different alias files per domain). exim and smail are both > easy to set up with the provided configuration programs though > (which seem pretty much identical in my limited experience). eximconfig was originally based on smailconfig. Both I and the previous maintainer have changed it quite a lot, but nonetheless it retains much of the original structure. > > You DON'T need a news server. slrn is a good thing here! > > Any newsreader, for that matter -- rtin, for example. No, that's useless on dialup links, which I understand is a large part of the market Jim wants to aim for. You need either an offline reader like slrn, or a simple news-server (and I'd recommend leafnode for this). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Yet another Linux distribution! :-)
On Sat, May 02, 1998 at 10:52:48PM +, Rev. Joseph Carter wrote: > > But this is aimed at dialup users! You don't want a send-only MTA, as dialup > > users presumably want to store their mail locally. > > Their mail isn't gonna get delivered by smtp No? I know several dialup ISPs that do provide SMTP, including one with 170,000 customers. > unless maybe fetchmail delivers it by smtp. Exactly: surely everyone who uses an inferior ISP is going to run fetchmail instead? So everyone wants to run an MTA locally. The alternative would be to force people to use an MUA with POP built-in, which is far from ideal, because that doesn't include some very nice MUAs, and requires you to go online at the time you read your mail rather than setting up a cron job, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Fwd: Bug#387557: pcre3: Please ship pcre_internal.h]
What do people think about this? Personally I feel that the "internal" in the name really should have been a big enough clue, and I don't want to include a file that's not meant to be used just because some idiots have written software that needs it. I'm not even sure it will work; what is it that emboss wants it for? --- Begin Message --- Package: pcre3 Severity: wishlist Dear Mark, I am building packages for EMBOSS, the European Molecular Biology Software Suite (www.emboss.org). They ship an old version of pcre, and build against it. As a result, the package contains files wich conflict with Debian's pcre3. I am trying to solve this by building EMBOSS against Debian's pcre packages, but EMBOSS uses pcre_internal.h, which is not shipped. Do you think that you could add them to your packages? Ahemm... and as I am trying to finish the packaging before the freeze, do you think that you could add the pcre_internal.h to pcre3 before the freeze too? Do you need me to submit a patch? Thanks a lot, and have a nice day, -- Charles Plessy Debian-Med packaging team --- End Message ---
Re: sendmail/smail with relaying blocks?
In article <[EMAIL PROTECTED]>, Chris Walker <[EMAIL PROTECTED]> writes: >> My exim package currently allows relaying; as Craig points out below, what >> you allow relaying to/from is extremely site-dependent. > > I beg to differ. I think what is the sensible default depends on the > usage of the machine. For departmental mail servers, then you are > correct relaying is more sensible, No it isn't. Only relaying from machines in the department is sensible. > but for "Satellite" systems, it is more sensible to block it. Should the satellite systems be accepting connections from systems other than themselves (and possibly, depending on how the system is set up, the departmental server) > Could you ask a question at configuration time, probably defaulting to > not allowing relaying. If you want to be really clever, you could make a > guess based on earlier answers. Better still would be to ask what domains to allow relaying for (allowing all and none as options of course).
Re: Imminent Checker upgrade release
In article <[EMAIL PROTECTED]>, Tom Lees <[EMAIL PROTECTED]> writes: >> (I actually had to install an extra hard drive in order to build this >> package. It takes over 200MB of hard disk space to build--is that a >> record?) > > No, IIRC the just the XFree86 sources take ~250MB :> The X consortium sources (which are basically the same; they also include sources for Xsun and a few others that probably aren't in the xfree source but are small anyway) are about 120 Mb uncompiled; compiling them takes just under 200 IIRC.
Re: Bug#9813: rxvt 2.20-4 : Bad setting of TERM environ variable
In article <[EMAIL PROTECTED]>, Bart Schuller <[EMAIL PROTECTED]> writes: > Also, I'd hope that if xterm now does color as standard, that fact is > reflected in its terminfo entry. No, because if you do that, programs like slrn will try to use colour, which means they are almost impossible to read and leave you with silly colours like white on black when you quit. (on a vconsole, slrn's colours are easier and white on black is normal so it doesn't matter that that's what you get when you quit) If they (and presumably all slang programs) are fixed to do something sensible with colours, then maybe.
Re: list of bashisms
In article <[EMAIL PROTECTED]>, Andy Mortimer <[EMAIL PROTECTED]> writes: > There has just been a long list of bugs against packages using `bashisms' > in their scripts, and I can certainly remember this issue coming up > before. But I don't know about anyone else, but I certainly have no idea > what features are available in the `original sh'. Lots. The small handful of features that are in bash and not in ksh93 should not be used, but I can't see any reason to stay compatible with ten year old versions of sh when the posix standard isn't exactly new anymore.
Re: dselect/diety audit trail
In article <[EMAIL PROTECTED]>, "Karl M. Hegbloom" <[EMAIL PROTECTED]> writes: > So do I. It would make it a lot easier to do bug reports when things > fail at installation or upgrade time. I agree, but I'm puzzled by what you chose for the subject line. This sort of functionality belongs in dpkg, not dselect (I'm not sure whether the current plan is for deity to replace just dselect or both, but the consensus I got from the last time it came up was that there would be a libdpkg and everything would be based on that, so presumably the audit trail would be implemented at that level)
Re: Upcoming Debian Releases
In article <[EMAIL PROTECTED]>, Andreas Jellinghaus <[EMAIL PROTECTED]> writes: > b) change policy to _not_ allow config information in /etc scripts I disagree strongly. A script without config information doesn't belong in /etc at all. Having your database seems like a reasonable idea, but it needs to be plain text which might be slow; a db file would be faster but I want to be able to change it in a text editor.
Re: Upcoming Debian Releases
On Sat, 24 May 1997, Vincent Renardias wrote: > As a compromise it could use the same system than the sendmail aliases: > The user make changes in a plain text file (/etc/aliases), but the > application 'compiles' this file as a db database (/etc/aliases.db)? Can you rely on all applications that use the database doing this? (presumably if they didn't do it themselves but used another tool to get the information for them you could) If so, then that would be acceptable. I don't want a situation where you have to remember to compile it yourself. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
In article <[EMAIL PROTECTED]>, Tom Lees <[EMAIL PROTECTED]> writes: >> the other solution is to have a small utility that stores these values, >> can change them and gives the values to the scripts. > > The third solution, which I prefer is a utility which modifies the > variables within the scripts - it's faster, it is more "backwards > compatible" with sysadmins from other Unices, and generally it's nicer > (less dependant on the cfgtool at boot-time). And if you're not very careful it does silly things if the scripts have been modified significantly.
Re: GOAL: Consistent Keyboard Configuration
In article <[EMAIL PROTECTED]>, Manoj Srivastava <[EMAIL PROTECTED]> writes: > See, I think this is buggy. I have been using Emacs for nearly > a decade now, and nobody takes my C-H default away from me (in other > words, people have had exposure to applications like emacs on other > Unix platforms (and other distributions of Linux), and they should > not have to change their expectations of finding help on C-H just > because they run Debian) But newbies don't expect backspace to give help. (and, except in X, backspace and C-h are rather difficult to separate). In X everyone is happy, of course, with C-h doing help and backspace doing backspace. It's a lot easier for experienced users to put C-h back to help than it is for newbies to make it do backspace. (Of course the real solution is to get a time machine and go back and kill whoever decided that using C-h for a delete key was a smart idea. Anyone got one?)
Re: May I remove a "feature" from man? [was: Bug#10039]
In article <[EMAIL PROTECTED]>, Fabrizio Polacco <[EMAIL PROTECTED]> writes: > Bug#10039 exposed a problem with the "feature" of man to index all the > 'man' and 'MAN' subdirectory it finds in the HOME and current directory, > when it is invoked. I can see automatically supporting $HOME/man could be useful, though it's nothing you can't do manually using $MANPATH. I can see no reason whatsoever for ./man and I agree that you should get rid of it.
Re: May I remove a "feature" from man? [was: Bug#10039]
In article <[EMAIL PROTECTED]>, Fabrizio Polacco <[EMAIL PROTECTED]> writes: > Anyway, the whole feature seems strange to me, because usually man > hierarchies are at the same level of binary dirs, not under them. I agree; remove it completely. If it looked in a more sensible place for the man pages, it would save a little bit of typing but that's all; as it stands it's completely useless as far as I can see.
Re: ssh and default home directory permissions (revisited?)
In article <[EMAIL PROTECTED]>, Carey Evans <[EMAIL PROTECTED]> writes: > I've removed group write permissions from my home dir because of the > programs like qmail and ssh which don't like it. I don't think > anything would break because of removing these permissions, so maybe > adduser should make home directories mode 755 (or 750)? 755 sounds OK. Not 750 by default; people who are that paranoid can set it themselves (perhaps an option for adduser if there isn't one already?), and it does cause problems with various things. 751 is a little better - at least web servers work, and you can have .plan and .project files.
pcre
I've just uploaded version 3 of libpcre. I've put it in a new package, libpcre3, and given it a new soname. I'm not sure if this was strictly necessary or not: the upstream documentation doesn't mention binary compatibility with the old version, probably because older versions weren't intended to be built as shared libraries at all. I intend to stop maintaining libpcre1 (not that I've touched it in the last year as it is) and think it should be removed from debian; I will continue to fix any bugs in libpcre2 but would like to see as much as possible migrating to using libpcre3 instead; this should just be a recompile for most things. I'll package a new version of exim tomorrow which will be linked against libpcre3. Once this is uploaded, I'll request for libpcre3 to be made standard priority and libpcre2, currently standard, to be made optional. Please Cc me on any replies as I don't normally read this list.
Re: IPv6 support in Debian
On Wed, Jan 03, 2001 at 02:00:07PM +1100, Dancer Vesperman wrote: > Certainly we have things like exim, lftp, ssh that work 'out of the box' > with v6...and apps that work with v6 work (equally) flawlessly in > v4-only environments. That's not necessarily the case. There were lots of problems with the IPv6 support in exim breaking things for IPV4-only users, mostly in obscure cases such as with subtly broken DNS. I believe they're all ironed out now, but they caused a lot of problems. Admittedly, very few things are as complicated as an MTA, and I wouldn't expect any client software to break as a result of adding IPv4 support.
Bug in test suite for pcre 4.3
Andreas Metzler wrote:
Mark has uploaded it yesterday in the evening. The bad news is that
4.3 seems to be broken on m68k, ia64 and alpha, "make test" fails.
I do not believe it is actually broken, at least not on alpha; I'm
assuming the problems on the other architectures are similar.
It does not look like a compiler/packaging related issue, I've
doublechecked on escher (alpha) using its woody installation and the
sid chroot: 3.9 compiles/tests fine (both with Mark's handcrafted
Makefile and the one shipped by upstream, 4.3 does not. - Both on
woody (gcc 2.95) and sid (gcc 3.2.something).
The tests for pcre consist of running a test program, and then comparing
its output against an expected output. One thing that the program does
is the following:
new_info(re, extra, PCRE_INFO_STUDYSIZE, &size);
[...]
fprintf(outfile, "Study size = %d\n", size);
and this is what is different here. Now, although the size is returned
from a function that's gets information about a particular regex, it's
actually a constant, which is the size of the pcre_study_data structure.
This structure:
typedef struct pcre_study_data {
size_t size; /* Total that was malloced */
uschar options;
uschar start_bits[32];
} pcre_study_data;
is 48 bytes on alpha, 40 bytes on i386 and most other platforms. These
are the figues that appear in the test failure report. I haven't tried
ia64 or m68k, the other ones that failed, but I guess it's 48 on ia64;
I'm not sure about 68k.
The main difference is that size_t is 8 bytes on alpha, being a 64-bit
platform. I guess the other four bytes are padding.
Clearly, this test failure is nothing to worry about, but unfortunately
the debian packages will not successfully build without all tests
passing. I can release a fixed package that either ignores the result of
this test, or has an altered pcretest.c that cheats.
Philip, I have CC'd you on this mail as the upstream author, because I
believe this counts as a bug in pcre. I would suggest as a minimum
removing the printing of the study size from the test.
Re: Bug#209116: exim daemon does not restart after last two security upgrades
Zygo Blaxell wrote: I have exim configured in daemon mode and I use xinetd instead of inetd. The last two security updates left me with no running exim daemon and nothing listening in port 25. The latest one was nice enough to create an /etc/inetd.conf that was empty except for this line: smtpstream tcp nowait mail/usr/sbin/exim exim -bs That is expected behaviour. The postinst runs update-inetd to install in inetd.conf if it isn't there already. It can't tell that you've deliberately deleted it, so helpfully creates one for you. The startup script for the daemon only runs it if it isn't running from inetd, in order that you don't get both trying to run. I suppose I could check that inetd is running, though that would only work if exim starts before inetd (which by default it will, but I wouldn't want to rely on that always being the case, especially since there's no obvious reason why it should matter). Had you left an inetd.conf file with a commented-out exim entry, all would be well. Having said that the behaviour is expected, that doesn't mean that it's nice. Partly this is due to what I would consider to be flaws in the design of update-inetd, partly due to an inevitable result of using inetd, and probably also partly my fault. I wish I had never supported using inetd, but it's a bit late to change that now. The exim package is nearing the end of its life (it will remain in the next debian release, but will no longer be the default mailer, as exim4 will replace it), This means that a) I'm not inclined to put a lot of effort into changes to the package, and b) I don't want to do anything that increases the risks of upgrade. So I don't want to force people to run as a daemon or any other major change like that. However, I am open to suggestions for minor changes that will make things easier for users like this, which is why I've copied this to debian-devel. One I am considering is only running "update-inetd --add" on a new install, and just "update-inetd --enable" on an upgade. I think this should solve this particular problem; what do people think of it? The other common problem, which it wouldn't solve, is people who think that using update-inetd to disable something is a good idea - update-inetd should only be used by maintainer scripts, but this isn't made clear enough to users. So they disable something using it, and then are surprised when it comes back on an upgade. [Debian-devel: note that this is also copied to the bug report. Leave this in or take it out of your replies as appropriate. Please leave me in anyway as I don't normally read debian-devel. Oh, and thanks in advance for your help]
Re: exim 3.00-1 (source i386) available for testing
On Sat, May 15, 1999 at 10:26:35AM +0100, James Troup wrote: > >* OS/Makefile-Default: Enabled IPv6 support (this therefore requires > > glibc 2.1) > > Bah, this will break exim for m68k. :( So will everything else network-related then, since we're hoping to get as much as possible using IPv6.
