Re: Unsatisfied depends in slink main
On Thu, 21 Jan 1999, Dale Scheetz wrote: > Since the recent discussion with Richard Stallman about the unsatisfied > suggests message, I have undertaken the examination of the main archives. > > The script that I am working on unpacks all of the .deb files it finds and > collects Package:, Provides:, Pre-Depends:, Depends:, Recommends:, and > Suggests: field information and deterines several things. You do realize that is why we have a 'Packages' file? In any event your script is not handling virtual pacakges, ppp is a virtual package. Here is a list of all unmet deps in main: Package chameleon version 1.0-2 has an unmet dep: Depends: libglib1.1.12 (>= 1.1.12-1) Depends: libgtk1.1.12 (>= 1.1.12-1) (Ehm? This one is new, someone should fix it) A list of unmet suggests/recommends in main is too long to include here. Jason
Re: getting kernel 2.2 into slink
On Thu, 21 Jan 1999, David Welton wrote: >I think we should include it, as a service to people who don't want to >download the whole thing, but attach a note saying "As 2.2 was >released just before we released slink, we are including it, but there >may be problems, it might eat your computer... we are not responsible >for anything at all..." I hate to sound like another "me too"-er, but I like that idea. I'm running linux 2.2 on my slink box, and haven't had any problems -- but we certainly don't have the time to test it extensively enough to make it an official part of the distro (and the Deep Freeze would definitely make it impossible). I'm sure including the image and source wouldn't violate the Deep Freeze with a little bit of law-bending :) -ed
Re: Unsatisfied depends in slink main
>> "DS" == Dale Scheetz <[EMAIL PROTECTED]> writes: DS> The most interesting problem looks like ppp, for which there isn't DS> a package. This looks like a problem in your script, I would say. http://www.debian.org/Packages/frozen/base/ppp.html shows it, and I can happily download it from ftp.debian.org It is also present in unstable. DS> CGI-modules faqomatic The complete field is: Depends: rcs, perl, perl (>= 5.004) | CGI-modules so obviuosly, perl >= 5.004 contains the functionality CGI-modules provided, no? Maybe it should Provide: CGI-modules ? DS> libglib1.1.12 (>= 1.1.12-1) chameleon DS> libgtk1.1.12 (>= 1.1.12-1)chameleon The 1.1.12 are present in unstable. DS> libmagick4g-lzw imagemagick DS> libmagick4g-lzw perlmagick It is in non-free. The packages Depend on libmagick4g | libmagick4g-lzw DS> ppp (=2.3.5-2)ppp-pam DS> ppp (>= 2.2.0f-20)dunc DS> ppp (>= 2.3) masqdialer DS> ppp (>= 2.3) pppconfig DS> ppp (>= 2.3.0)wvdial DS> ppp (>>2.2) diald DS> ppp pppupd DS> ppp pptp-linux ppp is in the distribution. DS> ssh rstart DS> ssh rstartd Hmm. ssh is non-free and non-us DS> tcl74 dotfile DS> tcl75 dotfile DS> tclx emacspeak DS> tclx74emacspeak DS> tclx75emacspeak DS> tk40 dotfile DS> tk40 x10-automate DS> tk41 dotfile DS> tk41 x10-automate I believe these versions have been superceded by tcl8.0 and tk8.0. Some inconsistency, but looks like easy to solve (don't know for the tcl/tk stuff). Ciao, Martin
Re: getting kernel 2.2 into slink
On Thu, Jan 21, 1999 at 05:23:22PM -0600, David Welton wrote: > On Thu, Jan 21, 1999 at 03:17:26PM -0800, Brent Fulgham wrote: > > I say let's make the 2.2 image a high-profile aspect of slink's release. > > The kernel is very stable, and I've been running my Debian system on it > > The kernel is stable, but is the kernel + debian stable? No one > knows. All 4 of the Debian systems I run use 2.1.13x or 2.2.0-prex without any changes to the basic setup. 3 of these are slink, one is potato. So i say yes, it is stable with Debian. -- --- - - --- - - - --- Ben Collins <[EMAIL PROTECTED]> Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
RE: getting kernel 2.2 into slink
How close to 3.0 does the 2.2 kernel get Debian? - Bruce -- On Thu, 21 Jan 1999, Brent Fulgham wrote: > I say let's make the 2.2 image a high-profile aspect of slink's release. > The kernel is very stable, and I've been running my Debian system on it > since 2.1.120. Plus, it would be a great "technical" feature of our > distribution that might give us some bragging rights over the other > distros. > > -Brent
Re: getting kernel 2.2 into slink
On Thu, Jan 21, 1999 at 07:32:02PM -0500, Ben Collins wrote: > > The kernel is stable, but is the kernel + debian stable? No one > > knows. > > All 4 of the Debian systems I run use 2.1.13x or 2.2.0-prex without any > changes to the basic setup. 3 of these are slink, one is potato. So i > say yes, it is stable with Debian. I agree. My desktop system here at BNL is running pre5 with no problems, and all the machines at buoy.com except the terminal server (which has 273 days uptime, and I can't bear to reboot it) are running one of the preX versions. Our news server gets the snot beat out of it since it runs innd AND squid, so yeah, it's stable. Tim -- (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps "Why not go out on a limb? Isn't that where the fruit is?" -- Frank Scully ** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.**
Re: getting kernel 2.2 into slink
On 1999-01-21 19:32, Ben Collins wrote: > All 4 of the Debian systems I run use 2.1.13x or 2.2.0-prex without any > changes to the basic setup. 3 of these are slink, one is potato. So i > say yes, it is stable with Debian. Most ppl. need a printer and /dev/lp changed radically betewen 2.0 and 2.2. diald/ppp in slink does not work with 2.2.0-pre7 (on my box, at least). I am sure that there are other things as well. /Allan -- Allan M. Wind Phone: 781.938.5272 (home) 687 Main St., 2nd fl. Fax:781.938.6641 (home) Woburn, MA 01801Email: [EMAIL PROTECTED] (home)
Re: getting kernel 2.2 into slink
On Thu, Jan 21, 1999 at 08:24:37PM -0500, Allan M. Wind wrote: > On 1999-01-21 19:32, Ben Collins wrote: > > > All 4 of the Debian systems I run use 2.1.13x or 2.2.0-prex without any > > changes to the basic setup. 3 of these are slink, one is potato. So i > > say yes, it is stable with Debian. > > Most ppl. need a printer and /dev/lp changed radically betewen 2.0 and While the internals did change radically, the only thing most people need concern themselves with is that the /dev/lp? number changed by one digit. I hardly call that a "radical" change > 2.2. diald/ppp in slink does not work with 2.2.0-pre7 (on my box, at > least). I am sure that there are other things as well. I've used ppp with late 2.1.x kernels with no big trouble.
Re: getting kernel 2.2 into slink
> 2.2. diald/ppp in slink does not work with 2.2.0-pre7 (on my box, at > least). I am sure that there are other things as well. I'm sure you were aware that you have to upgrade your pppd to work with any of the higher-order 2.1.X kernels? You might want to check the kernel source's Documents/CHANGES file. -Brent
slink's chameleon 1.0-2 depends on libgtk1.1.12, which is not in slink
> "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes: Dale> Since the recent discussion with Richard Stallman about the Dale> unsatisfied suggests message, I have undertaken the Dale> examination of the main archives. Dale> Dale> The script that I am working on unpacks all of the .deb Dale> files it finds and collects Package:, Provides:, Dale> Pre-Depends:, Depends:, Recommends:, and Suggests: field Dale> information and deterines several things. Jason> You do realize that is why we have a 'Packages' file? Jason> In any event your script is not handling virtual pacakges, Jason> ppp is a virtual package. Jason> Here is a list of all unmet deps in main: Jason> Package chameleon version 1.0-2 has an unmet dep: Depends: Jason> libglib1.1.12 (>= 1.1.12-1) Depends: libgtk1.1.12 (>= Jason> 1.1.12-1) Jason> (Ehm? This one is new, someone should fix it) Ugh. chameleon 1.0-2 must either be removed from the archive or recompiled against the libglib1.1/libgtk1.1 (note the lack of a .blah) -dev packages in slink. Ben -- Brought to you by the letters P and B and the number 1. "Yasashisani tsutsumaretanara, kitto.. meni utsuru.." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.
Re: Bug#27050 (fdutils): A cause for security concern?
Previously John Hasler wrote: > As I noted, there are no calls to system or its ilk. That's good. > I know how to fix the sprintf's. My plan now is to analyze the path > followed by strings from input to consumption. It might be much easier to just replace them with snprintf's. Also check for things like strcpy(), insecure handling of files, etc. 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/ pgpD9vb5l6WkV.pgp Description: PGP signature
Re: Dpkg Update Proposal
First of all: please use a standard textwidth of at most 76. Right now your mail frankly looks horrible. Only due to vim's awesome reformating power is sending a reply doable :) Previously fantumn Steven Baker" wrote: > Package Naming Scheme > --- > The current naming scheme of many packages is a mess, to say the > leasy. This, of course applies almost exclusively applies to > libraries, but there are some other packages that could use some help > (Electric Eyes, and Easy Editor come to mind). Reading forward I never see why those two are mentioned here.. > The problem is inconsistency. Some package names, speaking about > libraries here, are prefixed with the word 'lib', as in libgtk, and > some are not, as in Imlib. Generally speaking all libraries are prefixed with `lib' and include their soname. This isn't policy, although it might be a nice addition. > My solution, after long thought and working out, is to simply modify > the Debian Package Management system to allow multiple versions of > packages to be installed. I really dislike this approach. Having multiple version of a package makes very little sense, but any discussion depends on how you define a package. Are libc5 and libc6 the same package, since both implement the standard C library and runtime-code, or are they different packages since they different packages since they are completely (binary in this case) incompatible? This is where RH and Debian seem to differ: for RH they become the same package, and you need multiple versions of the same package to support all applications. This is probably why they need hacks like dependencies on files to get this working. For Debian we use different packages, which makes the process much more transparent. We seperate the packages by (again, using libraries as an example) adding the soname of the library to the packagename, which explains the occasionally weird-looking packagenames. > Another feature that I would like to see implemented, is something > that would check all dependencies for dead libraries "ie, libraries > that aren't used", perhaps this would be done by a program seperate > to dpkg. This should definitely not be in dpkg, but in a frontend such as apt or dselect. 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/ pgpPLskLjIyca.pgp Description: PGP signature
Re: Unsatisfied depends in slink main
Previously Dale Scheetz wrote: > The script that I am working on unpacks all of the .deb files it finds and > collects Package:, Provides:, Pre-Depends:, Depends:, Recommends:, and > Suggests: field information and deterines several things. You do know we have a packages file, don't you? And you do know this is already being done by apt-cache, lintian and my relscan (output at http://master.debian.org/~wakkerma/unmet.html, regenerated every 12 hours)? 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/ pgpVBUhe9PgF6.pgp Description: PGP signature
Unmet deps again
Ack people: Package wdm version 1.0-5 has an unmet dep: Depends: libwraster1 (>= 0.50.2) Package chameleon version 1.0-2 has an unmet dep: Depends: libglib1.1.12 (>= 1.1.12-1) Depends: libgtk1.1.12 (>= 1.1.12-1) Package licq version 0.44-2 has an unmet dep: Depends: qt1g (>= 1.41-2) Package qtscape version 5.0.19980408-1 has an unmet dep: Depends: qt1-snapshot (>= 1.39.19980414-1) Package stunnel version 2.1-2 has an unmet dep: Depends: libssl09 This was down to almost no packages a mear few days ago. Jason
Help setting up Linux
I just installed Debian Linux - just the kernal and the core system, no XWindows, no frills. So where can someone new to Linux (indeed Unix) find answers to very basic questions like "how do I mount a floppy drive," "can I read a FAT32 partition," and "why does my boot floppy get destroyed when I try to alter boot video mode using rdev or vidmode?" Any help greatly appreciated. Greg Hedger
Re: getting kernel 2.2 into slink
Previously Ben Collins wrote: > All 4 of the Debian systems I run use 2.1.13x or 2.2.0-prex without any > changes to the basic setup. Just to give this some counterweight: I just tried 2.1.132 with the OSS sound modules and they failed horribly. I've never seem them like this before. Luckily I have ALSA working :) 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/ pgp6jgynJb8vw.pgp Description: PGP signature
Re: getting kernel 2.2 into slink
Wichert Akkerman <[EMAIL PROTECTED]> writes: Previously Ben Collins wrote: > All 4 of the Debian systems I run use 2.1.13x or 2.2.0-prex without any > changes to the basic setup. Just to give this some counterweight: I just tried 2.1.132 with the OSS sound modules and they failed horribly. I've never seem them like this before. Luckily I have ALSA working :) You do know that the OSS modules in 2.1.x are drastically changed, right? You need to provide them with the IRQs and ports that they need on the command-line, for instance. I have the following in my conf.modules for that reason: options sb io=0x220 dma=1 dma16=5 irq=5
Re: Intent to package rolldice, blackjack
On Thu, Jan 21, 1999 at 02:31:10PM -0500, Stevie Strickland wrote: > > Just wondering, what's the output like and does it return for d10 0-9 or > > 1-10? Does it handle "d%"? Is the number of dice optional or must one > > feed it "1d8" for example? Does it return the results of each die or the > > total rolled or both? Can you give it something like "2d8 d12 3d6" and > > get a nice formatted output? Am I asking too many questions? => > > Eek! Let me see if I can answer your questions in order... ;> > Returns 1-10 (I add 1 to num_sides * (rand() / (RAND_MAX + 1.0)) :) > Handles d%? Oh, just put in d100 for right now, but I'll add that in :) > Number of dice right now is not optional, but could easily be fixed to > default to one... :) Cool => > Just total, decided that was the important part (if you ask for 3d6, > you're only interested in the result, unless you're doing something > like method IV of rolling characters in AD&D (I believe), in which you > roll 4d6 and take the highest three, in which case do 4x1d6 :) > > No, only handles the first string, I think... let me try it: > midkemia:~$ rolldice 2d8 1d12 3d6 > 13 In that case, may I suggest output like (goes digging to unbury his dice): $ rolldice 2d8 d12 3d6 2d8: 5 6 (11) d12: 2 3d6: 6 4 2 (12) You could optionally have a line giving a total if more than one set of dice are rolled, in this case something like: Total: 25 Or if you're really crazy, you could allow optional + or - to affect the total, if that were -d12 above the total would be 21 for example.. If it doesn't do EVERYTHING by that point, what more can be said? => > Nope, only first string, but I could just have it loop through the > non-option arguments, as well :) I'll go away before I scare you off from writing a dice roller, much less anything more important.. => > For your final question... no, I'm always glad to answer them, especially > since they usually give me things to think about as to new features :) Well I'm sure you have that by now.. => -- "I'm working in the dark here." "Yeah well rumor has it you do your best work in the dark." -- Earth: Final Conflict
Re: Dpkg Update Proposal
On Wed, Jan 20, 1999 at 11:36:00PM -0500, Andrew Pimlott wrote:
> On Wed, Jan 20, 1999 at 04:03:26PM -0500, fantumn Steven Baker" wrote:
> > Package Naming Scheme
>
> The problem is superficial. Sure, names should be more uniform, but all
> this requires is 1) ratifying naming standards and 2) ensuring that the
> packaging system handles name changes gracefully.
i agree. in fact, it's more like a solution searching for a problem than
even a superficial problem.
from the descriptions that have been posted of how rpm handles
installing multiple versions of a package, i am *very* glad that debian
doesn't do anything even remotely similar. that way lies madness (and a
broken system).
IMO, debian's de-facto method of handling this (i.e. different package
names) is much better - it puts the responsibility for ensuring that
differing versions of a package are compatible squarely where it
belongs: with the package maintainer.
to illustrate the point:
the following are currently installed on my workstation.
ii libgtk1 1.0.6-2The GIMP Toolkit set of widgets for X
ii libgtk1.1 1.1.2-2The GIMP Toolkit set of widgets for X, unsta
ii libgtk1.1.111.1.11-1 The GIMP Toolkit set of widgets for X, unsta
ii libgtk1.1.121.1.12-1 The GIMP Toolkit set of widgets for X, unsta
ii libgtk1.1.12-de 1.1.12-1 Development files for the GIMP Toolkit, unst
ii libgtk1.1.12-do 1.1.12-1 Documentation for the GIMP Toolkit, unstable
ii libgtk1.1.5 1.1.5-2The GIMP Toolkit set of widgets for X, unsta
ii libgtk1.1.6 1.1.6-1The GIMP Toolkit set of widgets for X, unsta
ii libgtk1.1.9 1.1.9-1The GIMP Toolkit set of widgets for X, unsta
libgtk1 really is a different package from libgtk1.1 - it provides
shared lib support for binaries linked to that particular version of
libgtk, whereas libgtk1.1 provides support for binaries linked against
it's version.
ditto for libgtk1.1.{5,6,9,11,12}.
the libgtk* versions are compatible with each other. the libgtk*-dev
versions, are not (it would be possible to make it so by installing
header files in /usr/include/gtk-VERSION, but you'd still have to modify
every source file that #included it. in other words, it could be done
but probably isn't worth the effort unless it's done upstream as well).
fortunately, the -dev packages conflict with earlier versions, so it's
not a problem.
debian's way of handling this allows for all versions of libgtk to be
installed simultaneously, allowing progress AND backwards compatibility
without conflict.
BTW, this is only a "problem" because the upstream libgtk1.1.x changes
the programming interface without changing the .so number. they've got
valid reasons for doing so (and they do advertise that fact), so there's
really no need to come up with a general solution to a specific problem
with one or two unstable/rapid development upstream packages.
as soon as libgtk stabilises, the problem will go away of it's own
accord. in the meantime, we can live with a few extra packages in our
unstable dist.
craig
--
craig sanders
Re: getting kernel 2.2 into slink
> Would anyone object if kernel 2.2 were packaged up at least as a > kernel-source package for slink? 2.0.3x would remain slink's default kernel, > would be used on the boot disks, etc, but this would let people get ahold of > kernel 2.2 easily on a debian cdrom, and it would let us say that debian > supports 2.2. (I was at a LUG meeting the other day, and I was asked about > this very thing a couple of times; people obviously care about it.) Not that it matters, really. My only worry is that if somebody compiles the kernel, they will expect it to work. I think it's best to leave 2.2 completely in unstable. It's still available there and will have better support. Brian ( [EMAIL PROTECTED] ) --- Tired of spam? See what you can do to fight it at: http://www.cauce.org/
Re: getting kernel 2.2 into slink
> On Thu, Jan 21, 1999 at 12:34:57PM -0800, Joey Hess wrote: > > Would anyone object if kernel 2.2 were packaged up at least as a > > kernel-source package for slink? 2.0.3x would remain slink's default kernel, > > I'de really like to see a kernel-image too, atleast for the non-i386 ports > to use. The 2.2 kernels work much better for them than the 2.0.3x kernels, > and requires less (usually none) patching to get them to compile. For > example, the 2.0.35 sparc-kernel patch in slink right now is 2.8 megs > (compressed). I've been able to compile straight from the pristine source > for 2.1.128 to 2.1.132 (one small header fix in 132). I'm going to try the > 2.2.0pre9 and see if I get the same results. No. We had enough problems upgrading from 2.0.35 to 2.0.36. This would be a major change and have corresponding reprocussions. I'm sure it's very stable, but it will have incompatibilities. Brian ( [EMAIL PROTECTED] ) --- Management should work for the engineers, not the other way around.
Intent to package wmheadlines, wmglobe, and IglooFTP
Time to start earning my keep =) WMheadlines is a suite of windowmaker menu plugins that let you see the current headlines on news sites such as freshmeat, slashdot, segfault, and linuxtoday. You click on a menu item and the news item is opened in netscape. wmglobe is an xearth hack that fits in the dock; a nice constant reminder of the global linux community. IglooFTP is a promising new gtk1.1.x based ftp client. All programs are GPL'ed and none rely on nonfree components. If anyone is already maintaining these, please notify me. Cheers, C. Thomas -- I can't understand why people are frightened of new ideas. I'm frightened of the old ones. -- John Cage
Re: Where does 'www-data' come from?
On Fri, Jan 22, 1999 at 09:39:18AM +1100, Brian May wrote: > > The only thing my proposal changed was the UID and the GID of the web > server, so that the web server doesn't have write access to the web > files. It most cases, it is not required that the web server have > write access to its files, and in those cases where it is required > (eg if CGI scripts need to be able to modify HTML files), then > you can change the UID and/or GID of those individual files. But shouldn't it be www:www-data? Or at least put www into group www-data by default if you want to change it. Then you can just chmod g+w if you want write access to some HTML-Files/directories. And the httpd server should be able to read his HTML-files if you ask me :-) even if they are not world-readable. cu, Lars -- Unix is the worst operating system; except for all others. (Berry Kercheval) pgpe7xZddePS0.pgp Description: PGP signature
Re: Unsatisfied depends in slink main
Dale Sheetz writes: ... > >Package not in archives Package which depends on > Package not in archives > ... >tclx emacspeak >tclx74emacspeak >tclx75emacspeak Here's the actual dependency for emacspeak: Depends: tclx76|tclx75|tclx74|tclx, emacs20 We have /debian/dists/unstable/main/binary-i386/oldlibs/tclx76_7.6.0-3.deb in slink, but older packages would also suffice. What's wrong with this? - Jim Van Zandt
Re: slink's chameleon 1.0-2 depends on libgtk1.1.12, which is not in slink
Will do that in the next couple of days.
Re: jdk doesn't work at all - is anyone on it?
> "Dale" == Dale E Martin <[EMAIL PROTECTED]> writes: Dale> I'd say it's grave too - despite being non-free, this _is_ Dale> the only decent java virtual machine available and java Dale> isn't exactly unpopular. I'm here... and there are a couple of other problems with jdk that I only discovered when testing a hamm -> slink upgrade. New version sometime tomoroow I hope. -- Stephen (jdk maintainer) --- It should be illegal to yell "Y2K" in a crowded economy. :-) -- Larry Wall
Re: Unsatisfied depends in slink main
Dale Scheetz <[EMAIL PROTECTED]> writes: > giflib3g-dev gdk-imlib-dev > giflib3g-dev imlib-dev > giflib3g-dev libfnlib-dev The full dependencies for these is more like: libungif3g-dev | giflib3g-dev Basically, the unfree giflib stuff has to be in the depends field, because it's in an "or" relationship with the equivalent free package. Cheers, - Jim
Re: Help setting up Linux
Greg Hedger <[EMAIL PROTECTED]> writes: > I just installed Debian Linux - just the kernal and the core system, no > XWindows, no frills. So where can someone new to Linux (indeed Unix) > find answers to very basic questions like "how do I mount a floppy > drive," "can I read a FAT32 partition," and "why does my boot floppy get > destroyed when I try to alter boot video mode using rdev or vidmode?" debian-user@lists.debian.org is an appropriate place to ask those questions. The Linux Installation and Getting Started guide is very good: http://metalab.unc.edu/LDP/LDP/gs/gs.html To mount a floppy drive: mount /dev/fd0 /floppy (see "man mount" for details) FAT32 support has been included in the Linux kernel for quite a while. You can find this out by reading the kernel sources and documentation, or by reading the change summaries at http://linuxhq.com/ . I'm not sure why your boot floppy is getting destroyed. Cheers, - Jim
Re: Intent to package rolldice, blackjack
On Thu, Jan 21, 1999 at 04:04:20AM -0500, Stevie Strickland wrote: > rolldice is a virtual dice roller that takes in a string on the > command line in the format used by some fantasy role playing games > like Advanced Dungeons & Dragons[1] and returns the result of the dice > rolls. i wrote some dice-rolling routines several years ago (when i still had time to play RoleMaster, long before i got into linux). it handled all the standard dice-rolling conventions, as well as the high/low/both open-ended rolls used by RM (roll d100, if 01-05 then roll again and subtract, if 96-00 then roll again and add. keep on rolling and adding/subtracting if you get >96) i wrote a bunch of related stuff too. was basically writing myself a GM's reference chart/character gen/campaign notebook/dice-roller/etc for RM, but never got around to finishing it, and then moved to another state and never found time to start a campaign again or find players. that's the good news. the bad news is that it was all done in turbo pascal. however, the algorithms were clean and readable, so easily ported to C. if you're interested, i'll dig up the files (i still have them on tape somewhere...i think. dusty old code from the early 90s :-) and mail them to you. i'll GPL them first, so you can do what you want with them. craig -- craig sanders
Re: getting kernel 2.2 into slink
On 1999-01-21 19:32, John Goerzen wrote: > While the internals did change radically, the only thing most people need > concern themselves with is that the /dev/lp? number changed by one digit. I > hardly call that a "radical" change Well, it of course depends on how you define radical. I had two printer ports and they were switched. Also, I it took me a bit to figure that conf.modules needed changed due to the broadning of scope (parport_pc): > > 2.2. diald/ppp in slink does not work with 2.2.0-pre7 (on my box, at > > least). I am sure that there are other things as well. > > I've used ppp with late 2.1.x kernels with no big trouble. There should be _no_ (known) problems when shipped in stable (IMHO). Your favorite newbie has problems enough configurating ppp... dealing with ppp problems on top of that is not going to be well perceived. /Allan -- Allan M. Wind Phone: 781.938.5272 (home) 687 Main St., 2nd fl. Fax:781.938.6641 (home) Woburn, MA 01801Email: [EMAIL PROTECTED] (home)
Re: getting kernel 2.2 into slink
Previously Ben Pfaff wrote: > You do know that the OSS modules in 2.1.x are drastically changed, > right? Sure, I browse linux-kernel on occasion. > You need to provide them with the IRQs and ports that they need on the > command-line, for instance. I noticed, otherwise you get some weird resource busy-error. Didn't help though. My hardware isn't evil special.. (standard sb16 clone) > I have the following in my conf.modules for that reason: I do hope you put that somewhere in /etc/modutils/ as well so it doesn't get overriden when update-modules is called. 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/ pgpx3AWu4iLqw.pgp Description: PGP signature
Re: Intent to package rolldice, blackjack
Joseph Carter wrote: > Or if you're really crazy, you could allow optional + or - to affect the > total, if that were -d12 above the total would be 21 for example.. If it > doesn't do EVERYTHING by that point, what more can be said? => Yes, I think it needs to include a calculator things like "3d6 + 1" and "10d6/d4" work. ;-) -- se shy jo
Re: getting kernel 2.2 into slink
On 1999-01-21 17:36, Brent Fulgham wrote: > > 2.2. diald/ppp in slink does not work with 2.2.0-pre7 (on my box, at > > least). I am sure that there are other things as well. > > I'm sure you were aware that you have to upgrade your pppd to work with any > of the higher-order 2.1.X kernels? You might want to check the kernel > source's Documents/CHANGES file. It's "Changes" and yes I have read it: master:/home/wind# pppd -v pppd: unrecognized option '-v' pppd version 2.3 patch level 5 The issue being that there IS a problem - e.g. are we going to provide ppp1 and ppp2? That sounds like trouble to me. /Allan -- Allan M. Wind Phone: 781.938.5272 (home) 687 Main St., 2nd fl. Fax:781.938.6641 (home) Woburn, MA 01801Email: [EMAIL PROTECTED] (home)
Re: getting kernel 2.2 into slink
Wichert Akkerman wrote: > I noticed, otherwise you get some weird resource busy-error. Didn't help > though. My hardware isn't evil special.. (standard sb16 clone) Unfortunatly, this is as evil as it gets. According to the current kernel docs, there is no such thing as a SB 16 clone. There are a lot of boards that can run in sb emulation in 8 bit mode, that claim to be SB 16 or SB pro clones. Most boards that you think are a SB clone really have the Windows Sound System chips in them. I have 2 machines that I had set up as SB clones for the 2.0.x kernels, and they worked in 8 bit mode and were generally crappy. With the newer kernels I have reconfigured both machines to use the proper Windows Sound System drivers (the ad1848 chip), and they work much better than I've ever seen them, and in 16 bit mode at last. I ended up just adding the following to /etc/modultils/local to get my card working: options ad1848 io=0x530 irq=7 dma=1 options opl3 io=0x388 -- see shy jo
Re: getting kernel 2.2 into slink
Brian White wrote: [kernel image] > No. We had enough problems upgrading from 2.0.35 to 2.0.36. This would > be a major change and have corresponding reprocussions. I'm sure it's > very stable, but it will have incompatibilities. No-one's saying this would be the default kernel. I think including a kernel image would be nice... but if that is too much I'd at least like to see the source package get in. -- see shy jo
RE: getting kernel 2.2 into slink
> It's "Changes" and yes I have read it: > > master:/home/wind# pppd -v > pppd: unrecognized option '-v' > pppd version 2.3 patch level 5 > > The issue being that there IS a problem - e.g. are we going to provide > ppp1 and ppp2? That sounds like trouble to me. > Real Question (not a snipe): Is there any reason everyone couldn't use a current pppd that would be compatible with the new kernel image? Why have two packages? -Brent
Re: how rpm does it (Re: Dpkg Update Proposal)
Joey Hess <[EMAIL PROTECTED]> writes: > As I said before, rpm does have the capability to install 2 different > versions of a package simulantaneously. Here's how it works, to the best of > my knowledge. > User interface: > Rpm differentiates between installing a package and upgrading a package. > Installing a package (rpm -i) simply unpacks the rpm file, registers it in > the database of installed packages, etc. If an old version of the package is > present, it will not be removed. > Upgrading a package (rpm -u) means that the old version of the package that > was installed (if any) is removed at the same time the new one is installed. That's "rpm -U". > So rpm's method of upgrading is the same as dpkg -i, whereas dpkg has nothing > equivilant to rpm's method of just installing a package. > Oh and by the way, this user interface tends to confuse new users (at least > it did me) who accidentially install many versions of the same package > because they arn't aware they should be upgrading it instead. Buried in the Maximum RPM book is a suggestion that you always use -U (which also installs new packages. > I forget how rpm allows removing of one version of a package while leaving > another version of it installed. You can specify packagename or packagename-version to query and remove operations. If you just specify "packagename" to a query op, it will list all versions. Dunno about the delete operation. > Back end: > I don't know much about this. I can intuit some things. > Rpm can keep track of multiple versions of the same package that are all > installed. Presumably, this means its package database indexes the installed > packages by both package name and version, instead of just by package name > as dpkg does. > What happens if you try to install version bar of a package while version > foo of that same package, which contains files of the same name, is > installed? Rpm will happily overwrite version foo's files. rpm will complain if files conflict with another package, and won't let you install the new one unless you force it with --force. > What happens if you then remove version foo? I'm not sure, it's been a while > ;-). I can say that rpm doesn't deal with this very well. It either has to > leave version bar's files around, or delete them, either action leaves the > installed version foo in an inconsitent state. What does dpkg do if you turn on --force-overwrite? > Given the above, it's clear that rpm's method of doing this is really only > useful for library packages, in which 2 different versions contain files > with entirely different names. (You might ask, what about /usr/doc, wouldn't > it be the same in both versions of a library package. The answer is that rpm > packages use /usr/doc/package-version/ as the doc directory.) But it does > work tolerably well for those library packages. Of course, if redhat had > anything like update-alternatives, it could be more useful for other > packages too. I've suggested to Red Hat in the past that they adopt our package naming scheme. There are a few packages that use the seperate packagename for seperate version scheme. (If you look at the "gnome" directory, you'll find glib10 and gtk10 packages containing older versions of glib and gtk.) > Applying this to dpkg: > User interface: > If we wanted to make dpkg have this capability, we could add a new command > line flag, say "--keep-old-version" that makes "dpkg --keep-old-version -i" > behave like rpm -i does. > We would have to come up with some method to allow dpkg to remove one > version of a package while leaving another version of that package installed. I like our current method of naming the packages after the soname of the library. We should make it explicit policy for packages that contain shared libraries used by other packages. > Back end: > Dpkg would have to change how it parses the status file, and presumably how > it stores the information about installed packages in memory, so it in > effect considers different versions of a package as different packages, if > --keep-old-version were passed to it. > Dpkg already doesn't allow 2 packages to be installed that contain the same > files (unless --force-overwrite is on), so it doesn't run into the problem > rpm runs into with installing multiple versions of a package that contain > the same files. (Or does it? The same issues seem to apply with > --force-overwrite. But I guess dpkg does the Right Thing, whatever that is. > ;-) RPM also requires you use --force. (This forces everything but dependencies.) > Applying this to deb packages: > For library packages, which contain different files from version to version, > we really need do nothing special. > For packages like ncftp and ncftp2, update-alternatives can be used (as it > is now) to ensure that the 2 packages contain only differnet files. > However, both these cases do leave us with the problem of > /usr/doc/. We would have to either change that
Re: mc bug? or i've not read the manuals
The bits get lost because both mc and emacs rename originalfile to originalfile~ (e.g.) and create a new originalfile, without preserving the original ownership/permissions. (n)vi does not suffer from this problem, but neither does it create backups. --Jeff
Re: getting kernel 2.2 into slink
> > No. We had enough problems upgrading from 2.0.35 to 2.0.36. This would > > be a major change and have corresponding reprocussions. I'm sure it's > > very stable, but it will have incompatibilities. > > No-one's saying this would be the default kernel. I think including a kernel > image would be nice... but if that is too much I'd at least like to see the > source package get in. I understand what you're saying, but default or not doesn't make any difference. Both will show up in dselect and it would be trivial for someone to install the new kernel... and then wonder why things don't work. Since it is assured that some packages will have to be patched by a user that wants to use the new kernel, making those users go through a little bit more effort to get the new kernel is more than offset by reducing the amount of problems encountered by other users. Brian ( [EMAIL PROTECTED] ) --- Management should work for the engineers, not the other way around.
Re: getting kernel 2.2 into slink
On Thu, Jan 21, 1999 at 10:02:52PM -0500, Brian White wrote: > No. We had enough problems upgrading from 2.0.35 to 2.0.36. This would > be a major change and have corresponding reprocussions. I'm sure it's > very stable, but it will have incompatibilities. I'm using nothing but packages from slink/sparc and I see no incompatibilities. Then again the box isn't running X, any of the other sparc devs out there have any input on which kernel provides the 'safest' X for sparc? -- --- - - --- - - - --- Ben Collins <[EMAIL PROTECTED]> Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
Re: getting kernel 2.2 into slink
On Thu, Jan 21, 1999 at 10:43:23PM -0500, Allan M. Wind wrote: > On 1999-01-21 17:36, Brent Fulgham wrote: > > > > 2.2. diald/ppp in slink does not work with 2.2.0-pre7 (on my box, at > > > least). I am sure that there are other things as well. > > > > I'm sure you were aware that you have to upgrade your pppd to work with any > > of the higher-order 2.1.X kernels? You might want to check the kernel > > source's Documents/CHANGES file. > > It's "Changes" and yes I have read it: > > master:/home/wind# pppd -v > pppd: unrecognized option '-v' > pppd version 2.3 patch level 5 > > The issue being that there IS a problem - e.g. are we going to provide > ppp1 and ppp2? That sounds like trouble to me. The current ppp in slink works with the latest kernels. -- --- - - --- - - - --- Ben Collins <[EMAIL PROTECTED]> Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
Re: Intent to package rolldice, blackjack
On Fri, Jan 22, 1999 at 02:37:47PM +1100, Craig Sanders wrote: > that's the good news. the bad news is that it was all done in turbo > pascal. however, the algorithms were clean and readable, so easily > ported to C. Hehe, you know there's a GNU Pascal? (package gpc) I haven't looked into it but it says it supports some Turbo Pascal stuff, haven't done anything with pascal in years *grin*. -- Rafael Kitover [EMAIL PROTECTED] pgpmqbwYZw56p.pgp Description: PGP signature
Re: Bug#27050 (fdutils): A cause for security concern?
Wichert Akkerman writes: > It might be much easier to just replace them with snprintf's. That is what I meant when I said I know how to fix them. > Also check for things like strcpy()... I'd rather trace out the input string handling than just grep for dangerous functions. There isn't that much of it. The few strcpy's I found look safe, but I can think of ways to overrun a buffer without using any functions known to be dangerous. > insecure handling of files, etc. No files. What there is, however, is a password being sent in a udp packet. I haven't finished figuring out how he handles it, but it looks sniffable to me. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Intent to package rolldice, blackjack
On Thu, Jan 21, 1999 at 07:37:18PM -0800, Joey Hess wrote: > > Or if you're really crazy, you could allow optional + or - to affect the > > total, if that were -d12 above the total would be 21 for example.. If it > > doesn't do EVERYTHING by that point, what more can be said? => > > Yes, I think it needs to include a calculator things like "3d6 + 1" and > "10d6/d4" work. ;-) Oh how evil! => -- "I'm working in the dark here." "Yeah well rumor has it you do your best work in the dark." -- Earth: Final Conflict
Re: KDE status?
On Thu, Jan 21, 1999 at 09:18:50PM +, Jules Bean wrote: > > Sure no problem. I had no intention of doing so. I was just curious as > > to the status. There will be no argument from me, especially since I > > agreed with Debian's stance on the matter. :) > > Brief summary, then: > > KDE will not be in slink. > KDE will be in potato if > > a) KDE change their license (in which case it can go into contrib) > b) Qt change their license (in which case they may both be able to go into > free) > > b) is the likely outcome, since troll are designing a new Qt license, > which Joseph Carter <[EMAIL PROTECTED]) is looking at with a view to > making it both DFSG-free (which it almost certainly will be) and > GPL-compatible (trickier). Seems most likely we'll get c. Both of them change licenses and the net result goes into main. -- "I'm working in the dark here." "Yeah well rumor has it you do your best work in the dark." -- Earth: Final Conflict
Re: getting kernel 2.2 into slink
On Thu, Jan 21, 1999 at 12:34:57PM -0800, Joey Hess wrote: > Would anyone object if kernel 2.2 were packaged up at least as a > kernel-source package for slink? 2.0.3x would remain slink's default kernel, > would be used on the boot disks, etc, but this would let people get ahold of > kernel 2.2 easily on a debian cdrom, and it would let us say that debian > supports 2.2. (I was at a LUG meeting the other day, and I was asked about > this very thing a couple of times; people obviously care about it.) > > Brian, would this be too grave a violation of your "no new code" rule? > > (For those not yet in the know -- kernel 2.2 will probably be released next > week.) There is precedent for this as there is a 2.1.125 package in slink now. I think it's not a big deal if there are big disclaimers attached that slink is not a 2.2 targetted dist. -- "I'm working in the dark here." "Yeah well rumor has it you do your best work in the dark." -- Earth: Final Conflict
Re: getting kernel 2.2 into slink
Joseph Carter wrote: (B> (B> On Thu, Jan 21, 1999 at 12:34:57PM -0800, Joey Hess wrote: (B> > Would anyone object if kernel 2.2 were packaged up at least as a (B> > kernel-source package for slink? 2.0.3x would remain slink's default kernel, (B> > would be used on the boot disks, etc, but this would let people get ahold of (B> > kernel 2.2 easily on a debian cdrom, and it would let us say that debian (B> > supports 2.2. (I was at a LUG meeting the other day, and I was asked about (B> > this very thing a couple of times; people obviously care about it.) (B> > (B> > Brian, would this be too grave a violation of your "no new code" rule? (B> > (B> > (For those not yet in the know -- kernel 2.2 will probably be released next (B> > week.) (B> (B> There is precedent for this as there is a 2.1.125 package in slink now. (B> I think it's not a big deal if there are big disclaimers attached that (B> slink is not a 2.2 targetted dist. (B> (BCan you put 2.2 at least in potato ? I am using here 2.1.131 but didn't (Btry to upgrade to 2.2.preX as I have understood that there were some (Bproblems. Are the problems solved ? Can I safely grab the kernel, build (Bit with kernel-package and install the result ? (BAre there many system configuration changes to be done to get 2.2.pre (Bkernels working ? (B (BTIA, (B (BIonutz
Re: getting kernel 2.2 into slink
"Brian" == Brian White <[EMAIL PROTECTED]> writes: Brian> make any difference. Both will show up in dselect and it would Brian> be trivial for someone to install the new kernel... and then Heh, thats the idea. :-) Brian> wonder why things don't work. Little things that few notice, apparently -- I would've sworn slink and 2.2.0-final work perfectly until someone pointed out that /usr/sbin/procinfo complains. Been running 2.1.1xx in production with frozen for months. I'd say at least include a source package for whatever 2.2.0 is available at the moment of release, so we get the bragging rights. :-) A deb would be even more impressive. Brian> Since it is assured that some packages will have to be patched Brian> by a user that wants to use the new kernel, making those users Brian> go through a little bit more effort to get the new kernel is Brian> more than offset by reducing the amount of problems encountered Brian> by other users. It may be hopeless fantasy, but I'd like to believe our users aren't this helpless. - PGP E4 70 6E 59 80 6A F5 78 63 32 BC FB 7A 08 53 4C __ _Debian GNU Johnie Ingram <[EMAIL PROTECTED]> mm mm / /(_)_ __ _ ___ __"netgod" irc.debian.org mm mm / / | | '_ \| | | \ \/ / m m m / /__| | | | | |_| |> < Yes, I'm Linus, and I am your God. mm mm \/_|_| |_|\__,_/_/\_\ -- Linus, keynote address, Expo 98 GO BLUE
Re: Bug#27050 (fdutils): A cause for security concern?
Hello Ben, Avery and Wichert!
On Wed, Jan 20, 1999 at 12:50:59AM +0100, Wichert Akkerman wrote:
> Previously Anthony Fok wrote:
> > As the Slink deep freeze and release are impending, I would like to ask your
> > advice: Should I follow the suggestion given by the bug reporter Thomas
> > Roessler?
>
> I think so. For people who want to mount floppies without being root
> you can also use a line in /etc/fstab like this:
>
> /dev/fd0 /floppyauto noauto,noexec,nodev,user 0 0
Yes, I already have something similar in my /etc/fstab. The problem is
that fdmount is independent of mount. It doesn't even touch
/etc/fstab.
Unfortunately, the suggestion "chown root.floppy" and "chmod [12]754"
won't work either because fdmount.c has this check in it:
if (geteuid()!=0)
die("Must run with EUID=root");
I am a little bit tempted to comment that line out, but it's probably
there for a reason, and I am definitely not qualified to hack
fdmount.c, so for now I should probably add a /usr/sbin/fdutilsconfig
as Thomas has suggested.
> fdmount should probably be audited so we really know if it's secure. You
> could submit it to the security-auditing list
> ([EMAIL PROTECTED]).
Thanks for the info!
> > If so, should I fix this bug before Slink is out?
>
> Yes. I would hate to discover a vulnerability and release an advisory
> days after we release slink..
Okay, I will try to do it soon then. Hopefully I will have my school
assignments finished before the end of the weekend. :-)
Thanks a lot for all your advice and suggestions!
Anthony
--
Anthony Fok Tung-LingCivil and Environmental Engineering
[EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada
[EMAIL PROTECTED] Keep smiling! *^_^*
Come visit Our Lady of Victory Camp -- http://www.olvc.ddns.org/
or http://www.ualberta.ca/~foka/OLVC/
Re: Bug#27050 (fdutils): A cause for security concern?
> "AF" == Anthony Fok <[EMAIL PROTECTED]> writes:
AF> if (geteuid()!=0) die("Must run with EUID=root");
AF> I am a little bit tempted to comment that line out, but it's
AF> probably there for a reason, and I am definitely not qualified
AF> to hack fdmount.c, so for now I should probably add a
AF> /usr/sbin/fdutilsconfig as Thomas has suggested.
This sort of thing should be shot on sight. It will need to be
removed one way or another when we move to a capability based
system. The downside is that the reason things like this exist is the
complete lack of any error handling in the rest of the code.
If you need something to do, dike it out. If it's run as root, it
will work as expected. If not, then it can't do any real damage,
right? ;)
m.
Re: Bug#27050 (fdutils): A cause for security concern?
Ben Collins wrote: > Any program that is suid or sgid for no reason what-so-ever is always a > reason for a bug report, especially if it's suid root...we need some > automatic catch for new packages that have suid or sgid binaries in > them, or call suidregister. Lintian can serve as a check for the former case. See http://master.debian.org/~dark/lintian/reports/Tsetuid-binary.html I don't think it handles suidmanager yet. -- see shy jo
Re: Intent to package rolldice, blackjack
-BEGIN PGP SIGNED MESSAGE- > > Just total, decided that was the important part (if you ask for 3d6, > > you're only interested in the result, unless you're doing something > > like method IV of rolling characters in AD&D (I believe), in which you > > roll 4d6 and take the highest three, in which case do 4x1d6 :) > > > > No, only handles the first string, I think... let me try it: > > midkemia:~$ rolldice 2d8 1d12 3d6 > > 13 > > In that case, may I suggest output like (goes digging to unbury his dice): > > $ rolldice 2d8 d12 3d6 > 2d8: 5 6 (11) > d12: 2 > 3d6: 6 4 2 (12) > > You could optionally have a line giving a total if more than one set of > dice are rolled, in this case something like: > > Total: 25 > > Or if you're really crazy, you could allow optional + or - to affect the > total, if that were -d12 above the total would be 21 for example.. If it > doesn't do EVERYTHING by that point, what more can be said? => Ummm... I'm not sure exactly what you mean by the last part... first part I understand perfectly, and will start working on tomorrow (gotta still study for German :p), but I already have constant modifiers, and what games ask you for variable modifiers (that you couldn't just roll on the next line and subtract? :) > > Nope, only first string, but I could just have it loop through the > > non-option arguments, as well :) > > I'll go away before I scare you off from writing a dice roller, much less > anything more important.. => You'll never do that... too much interest has been shown already for me to dump this... and if I can't do this, how can I ever do anything like help with the kernel? > > For your final question... no, I'm always glad to answer them, especially > > since they usually give me things to think about as to new features :) > > Well I'm sure you have that by now.. => Sehr richtig! And trust me, I plan to use these ideas to the utmost... thanks! :) Stevie - -- Stevie Strickland (PGP ID = 23A6D909) 325912 Georgia Tech Station [EMAIL PROTECTED] Georgia Institute of Technology http://computersprache.net/~sstricklAtlanta, GA 30332 PGP Key fingerprint = 84 52 C7 EA E6 DB A1 C5 6A C9 D6 B9 88 26 74 FC -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNqgXlIXKvMsjptkJAQHj7AQAvHx4kVri/B+qgX8KzpgfXIpIha9VOdTV cx/a2v6KEs9HAk2/ohdUfPG4yazdoSTlZvumq4+HGJde7hNcd82Nre4lxIaRnZ8z Fcc8j2ncDRCf/0AAbpeEMFHQiuAHmHQdngLkW/E5L0bUy30tJ9PGxYCeT7vFArXi SHcw9I/tKtU= =tG/1 -END PGP SIGNATURE-
Re: Intent to package rolldice, blackjack
-BEGIN PGP SIGNED MESSAGE- > Joseph Carter wrote: > > Or if you're really crazy, you could allow optional + or - to affect the > > total, if that were -d12 above the total would be 21 for example.. If it > > doesn't do EVERYTHING by that point, what more can be said? => > > Yes, I think it needs to include a calculator things like "3d6 + 1" and > "10d6/d4" work. ;-) Well, 3d6+1 *does* work! Just the latter that's the problem, but you can always roll both and do the division yourself :) Stevie - -- Stevie Strickland (PGP ID = 23A6D909) 325912 Georgia Tech Station [EMAIL PROTECTED] Georgia Institute of Technology http://computersprache.net/~sstricklAtlanta, GA 30332 PGP Key fingerprint = 84 52 C7 EA E6 DB A1 C5 6A C9 D6 B9 88 26 74 FC -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNqgX14XKvMsjptkJAQH+UAP/YCHl9IuJYwHmGHmBFbKHBT8RETm9cgPV de3XG63p+nKI23BZHIlqOeIDFwWj0c98qIVPG/Ne0DMzzn2BL/dglyj9E2T8+ULf v+2FkbOWFTdiCjSyGMpHkuE9Yu8GXPzMVI08dwivHqJXOdV0Q2zVcY+5mB2rFcGD jWA6BcX+eRk= =TDG0 -END PGP SIGNATURE-
Re: getting kernel 2.2 into slink
On Thu, Jan 21, 1999 at 08:24:37PM -0500, Allan M. Wind wrote: > Most ppl. need a printer and /dev/lp changed radically betewen 2.0 and > 2.2. diald/ppp in slink does not work with 2.2.0-pre7 (on my box, at > least). I am sure that there are other things as well. ---end quoted text--- I think it's your system..(or very few..) I have had no problems on 6 systems I run (ranging from personal home workstation to laptop to work server's running anywhere from plain samba to web servers to print servers. But you are right that there may be issues we haven't seen. That's why it should be an *added* bonus and not the main image. IMHO Ivan -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ivan E. Moore II Rev. Krusty http://www.tdyc.com [EMAIL PROTECTED] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Imagination is more important than knowledge - Albert Einstien -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- GPG KeyID=0E1A75E3 GPG Fingerprint=3291 F65F 01C9 A4EC DD46 C6AB FBBC D7FF 0E1A 75E3 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: getting kernel 2.2 into slink
Joey Hess <[EMAIL PROTECTED]> writes: > Wichert Akkerman wrote: > > I noticed, otherwise you get some weird resource busy-error. Didn't help > > though. My hardware isn't evil special.. (standard sb16 clone) > > Unfortunatly, this is as evil as it gets. According to the current kernel > docs, there is no such thing as a SB 16 clone. That part of the documentation is inaccurate, and has been for quite some time. There are SB16 clones, based on the ALS007 and ALS100 chips by Avance Logic. The proof is in drivers/sound/sb_common.c and Documentation/sound/ALS007. The ALS007 is apparently a SB16-alike except for the mixer, and the ALS100 is even closer (it uses the SB16 code unchanged). My /proc/sound reads, in part: Audio Devices: 0: Sound Blaster 16 (ALS-100) (4.2) (DUPLEX) and I get 16-bit input and output without difficulty. I've been successfully using this card with Linux since the summer of 1997; the card itself was purchased in November 1996. Admittedly, these cards are probably nowhere near as common as the average cheap WSS card, and it's likely that the previous poster doesn't have one, but they DO exist... --Rob -- Rob Tillotson N9MTB <[EMAIL PROTECTED]>
Re: Intent to package rolldice, blackjack
-BEGIN PGP SIGNED MESSAGE- On Fri, 22 Jan 1999, Craig Sanders wrote: > that's the good news. the bad news is that it was all done in turbo > pascal. however, the algorithms were clean and readable, so easily > ported to C. > > if you're interested, i'll dig up the files (i still have them on tape > somewhere...i think. dusty old code from the early 90s :-) and mail them > to you. i'll GPL them first, so you can do what you want with them. Cool! I'd always be glad to look at them (especially since I need a much better parser)... anyway, eventually I want to make a librolldice so that anyone can actually make the front end... and your code could definitely help, because I'm no good at parsers, and that would be one of the most important part of the library... :p As well, my roommate and I were going to also make a character sheet program (hence the reason for making the rolldice stuff a library), so we could just enter the data, and either save it to a file or go ahead and print it out... my roommate has been working on GTK+ for the occasion Stevie - -- Stevie Strickland (PGP ID = 23A6D909) 325912 Georgia Tech Station [EMAIL PROTECTED] Georgia Institute of Technology http://computersprache.net/~sstricklAtlanta, GA 30332 PGP Key fingerprint = 84 52 C7 EA E6 DB A1 C5 6A C9 D6 B9 88 26 74 FC -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNqgZM4XKvMsjptkJAQFhrgQAyHVq05FiRgv6RLl6s4UrSYSL9jb16rlt AlFAhXFc1p6rVABpX+W/vRmFUTkWyqfLYTlTytQMBTYOyrJCYlapPawMAq7QKtF7 YrBXByDvIxgnCwTrM3Nvu4M+o2RREoP8sFYa1YdOZRzUUgPXs2ecMUf91hyDBE+O 7KdmzhNe/D0= =SaXZ -END PGP SIGNATURE-
Re: getting kernel 2.2 into slink
On Thu, 21 Jan 1999, Brent Fulgham wrote: > > 2.2. diald/ppp in slink does not work with 2.2.0-pre7 (on my box, at > > least). I am sure that there are other things as well. > > I'm sure you were aware that you have to upgrade your pppd to work with any > of the higher-order 2.1.X kernels? You might want to check the kernel > source's Documents/CHANGES file. I also was unable to get ppp or diald to work with a later 2.1.x kernel in a hamm system. Documentation/Changes says the required version of ppp is 2.3.5 and hamm, slink and potato all have this version. Bob Bob Nielsen Internet: [EMAIL PROTECTED] Tucson, AZ AMPRnet: [EMAIL PROTECTED] DM42nh http://www.primenet.com/~nielsen
pppd 2.3.5 (was RE: getting kernel 2.2 into slink)
On Thu, 21 Jan 1999, Brent Fulgham wrote: >> The issue being that there IS a problem - e.g. are we going to provide >> ppp1 and ppp2? That sounds like trouble to me. >> >Real Question (not a snipe): Is there any reason everyone couldn't use a >current pppd that would be compatible with the new kernel image? Why have >two packages? I don't see a problem at all: slink includes pppd version 3.3.5, which is fully compatible with the 2.2 series of kernels. This being the case, the kernel-2.2.0 package would simply need to depend on slink's pppd. Not a big deal in the least... anyone running slink would have the required pppd anyway! -ed
Re: getting kernel 2.2 into slink
On Fri, Jan 22, 1999 at 04:00:50AM +0100, Wichert Akkerman wrote: > Previously Ben Pfaff wrote: > > You do know that the OSS modules in 2.1.x are drastically changed, > > right? > > Sure, I browse linux-kernel on occasion. > > > You need to provide them with the IRQs and ports that they need on the > > command-line, for instance. > > I noticed, otherwise you get some weird resource busy-error. Didn't help > though. My hardware isn't evil special.. (standard sb16 clone) 2.2.0-pre6 works fine here, on my genuine SB16C (pnp). options sb io=0x220 irq=5 dma=1 mpu_io=0x330 dma16=5 options opl3 io=0x388 Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org pgpJkR4oOUBCM.pgp Description: PGP signature
Re: Dpkg Update Proposal
Wichert Akkerman wrote: > case) incompatible? This is where RH and Debian seem to differ: for RH > they become the same package, and you need multiple versions of the same > package to support all applications. This is probably why they need > hacks like dependencies on files to get this working. No, this is why both deb _and_ rpm have versioned dependancies. -- see shy jo
intent to package: sattrack
I am about to upload sattrack. I have previously announced this on debian-hams ... It is a sattelite tracking program. It is quite non-free (section non-free/hamradio) but I have obtained permission from the author to create a package, and have included that email in the copyright file. 73, Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: Unmet Deps revisted
Enrique Zanardi writes: >On Wed, Jan 20, 1999 at 10:22:39AM +, Steve McIntyre wrote: >> Am I missing something here? Where does it say that users should be able >> to install _all_ optional packages? > >The policy manual suggests that: > >"2.2 Priorities >[...] > optional > (In a sense everything is optional that isn't required, but > that's not what is meant here.) This is all the software that > you might reasonably want to install if you didn't know what it > was or don't have specialised requirements. This is a much > larger system and includes X11, a full TeX distribution, and > lots of applications. > > extra > This contains packages that conflict with others with higher > priorities, or are only likely to be useful if you already know > what they are or have specialised requirements. >" > >By the definition of optional, a user may install all optional packages >if she doesn't know what they are (!) or don't have specialised >requirements. > >If there are optional packages that conflict with each other, we should >choose one to stay in optional and move the others to extra. (Or change/ >clarify the definition on the policy manual). The manual should be fixed IMHO - there are lots of places where this is bogus. Consider the xserver packages, for example... -- Steve McIntyre, CURS CCE, Cambridge, UK. [EMAIL PROTECTED] Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: xxgdb should get pulled
On Thu, Jan 21, 1999 at 11:28:29 -0500, Daniel Martin wrote: > Is my only other choice for a graphical debugger the "lesstif-induced > segfault" ddd? Glad to see my work is appreciated. Perhaps this is where I need to point you to the power of having the source? You could e.g. try fixing LessTif and/or DDD rather than bitch about it, fix xxgdb, package up UPS, gdbtk, tgdb, or deet; or (if you're not fully on the straight and narrow) use Motif-linked DDD binaries, or buy Motif and build a Motif-linked DDD for Debian, or package up KDbg, or Code Medic. Ray -- POPULATION EXPLOSION Unique in human experience, an event which happened yesterday but which everyone swears won't happen until tomorrow. - The Hipcrime Vocab by Chad C. Mulligan
Re: Dpkg Update Proposal
Craig Sanders wrote: > i agree. in fact, it's more like a solution searching for a problem than > even a superficial problem. It's a problem that is only evident to people who haven't lived with it for years. That doesn't mean it's not a problem. > from the descriptions that have been posted of how rpm handles > installing multiple versions of a package, i am *very* glad that debian > doesn't do anything even remotely similar. that way lies madness (and a > broken system). Just because rpm does it wrong doesn't mean dpkg couldn't do it right. > the following are currently installed on my workstation. > > ii libgtk1 1.0.6-2The GIMP Toolkit set of widgets for X > ii libgtk1.1 1.1.2-2The GIMP Toolkit set of widgets for X, > unsta > ii libgtk1.1.111.1.11-1 The GIMP Toolkit set of widgets for X, > unsta > ii libgtk1.1.121.1.12-1 The GIMP Toolkit set of widgets for X, > unsta > ii libgtk1.1.12-de 1.1.12-1 Development files for the GIMP Toolkit, > unst > ii libgtk1.1.12-do 1.1.12-1 Documentation for the GIMP Toolkit, > unstable ^^^ By the way, this also illistrates another facet of the problem. Dpkg wasn't even designed with package names this long in mind. > debian's way of handling this allows for all versions of libgtk to be > installed simultaneously, allowing progress AND backwards compatibility > without conflict. And there's no reason installing multiple versions of a package and using versioned dependancies and conflicts wouldn't allow the same things. > BTW, this is only a "problem" because the upstream libgtk1.1.x changes > the programming interface without changing the .so number. they've got > valid reasons for doing so (and they do advertise that fact), so there's > really no need to come up with a general solution to a specific problem > with one or two unstable/rapid development upstream packages. > > as soon as libgtk stabilises, the problem will go away of it's own > accord. in the meantime, we can live with a few extra packages in our > unstable dist. This isn't just something that affects a few developmental packages. It affects packages like these: libc5 libc6 procmeter procmeter3 ncftp ncftp2 gimp gimp1 communicator-base-406 communicator-base-407 communicator-base-45 By my crude count there are over 300 packages like these in the distribution that have to mangle their names to differentiate versions. -- see shy jo
Re: Debian booth at LinuxTag '99?
On Wed, 20 Jan 1999, Christian Weisgerber wrote: >In article <[EMAIL PROTECTED]>, >Federico Di Gregorio <[EMAIL PROTECTED]> wrote: > >> I am thinking about being there (I'll come from italy). If you >> find something, Wichert, can you please let me know... I CAN'T >> read german (hope conference language will be english, at least in >> part). > >The conference language will be German. In particular, all presentations >will be in German. Sorry. I'm not entirely happy with this, but the bulk >of the target audience are unsophisticated users who would be >discouraged by English (even if they wouldn't admit it). It's a >trade-off; we would probably not be able to attract more people from >throughout Europe than we would lose from the nearby 100km radius. >Feedback to the contrary will be given due consideration for LinuxTag >2000. ;-) > >Of course you can talk to the various exhibitors in English, and the >mentioned Debian BOF/developers meeting could be done in English, too. I am considering flying over from London to visit the conference, if only to hang out with other people from outside Germany. More support for non-German speakers would ensure that I would be there. -- I am in London and would like to meet any Linux users here. I plan to work in London for 3 - 6 months...
Re: Dpkg Update Proposal
On Fri, Jan 22, 1999 at 12:02:55AM -0800, Joey Hess wrote: > Craig Sanders wrote: > > i agree. in fact, it's more like a solution searching for a problem than > > even a superficial problem. > > It's a problem that is only evident to people who haven't lived with it for > years. That doesn't mean it's not a problem. took me a minute to figure out what you meant. ok, i'll sort-of agree with that. i don't think it's a problem in itself, but it points out a documentation problem. > > from the descriptions that have been posted of how rpm handles > > installing multiple versions of a package, i am *very* glad that > > debian doesn't do anything even remotely similar. that way lies > > madness (and a broken system). > > Just because rpm does it wrong doesn't mean dpkg couldn't do it right. true. but i think that the right way of doing it is pretty much the way we are doing it, by putting the soname or version number in the package name to distinguish it from other versions. >>ii libgtk1.1.12-de 1.1.12-1 Development files for the GIMP Toolkit, unst >>ii libgtk1.1.12-do 1.1.12-1 Documentation for the GIMP Toolkit, unstable > ^^^ > By the way, this also illistrates another facet of the problem. Dpkg wasn't > even designed with package names this long in mind. yes, that's a bug in dpkg's output routines. it's hard-coded for 80 column displays. it doesn't affect debian's handling of long package names, just the output of 'dpkg -l'. i think i reported this as a bug a long time ago. > > debian's way of handling this allows for all versions of libgtk > > to be installed simultaneously, allowing progress AND backwards > > compatibility without conflict. > > And there's no reason installing multiple versions of a package and > using versioned dependancies and conflicts wouldn't allow the same > things. why risk adding complication when what we have works? i think dpkg's existing problems should be fixed before features of doubtful merit are added. > This isn't just something that affects a few developmental packages. It > affects packages like these: > > libc5 libc6 > procmeter procmeter3 > ncftp ncftp2 > gimp gimp1 > communicator-base-406 communicator-base-407 communicator-base-45 [ above list edited slightly from original to minimise line-count ] libc5 and libc6 ARE different packages. ncftp and ncftp2 appear to be a mainline and a forked version. gimp is the stable release, gimp1 is the unstable beta. the various versions of communicator and navigator conflict with each other. don't know about procmeter/procmeter3. > By my crude count there are over 300 packages like these in the distribution > that have to mangle their names to differentiate versions. 300 sounds like a lot...are you including all shared libs and -dev and -altdev packages? in any case, i don't see it as a problem. IMO, the fact that they have different package names is USEFUL information. it tells me that there's something possibly weird or dangerous going on and i should be extra careful before i select it in dselect...maybe even switch to another shell and investigate further by unpacking the package in /tmp and reading the changelog or readme.Debian before installing it. craig -- craig sanders
the Great X Reorganization, package splits, and renaming
Just thought I would bring this up one more time and run it by everyone.
This can be considered a draft of what I'd like to put in the release
notes. The person managing that document has my permission to edit this
down a little bit.
***
The Great X Reorganization happened at version 3.3.2.3a-2, which was a
Debian 2.1 ("slink") release.
xbase used to be a catch-all package, containing all kinds of miscellaneous
data, programs, and documentation. That is no longer the case. Its
contents have been redistributed among other packages, and in many cases,
completely new packages have been created.
New packages were created for a variety of reasons:
1) In some cases, there were undeclared dependencies on other programs.
For instance, the rstart and rstartd programs depend on rsh.
2) There are several programs which are daemons and should be split out
for easier management. This includes xdm and xfs. I believe the
programs provided in xproxy (new package) would also work well this
way, but they are not yet handled like other daemons in Debian.
3) Some of the X clients provided in the former xbase package, like twm,
xmh, and xterm, have very popular replacements, and may just be a
waste of disk space for some people. (It's worth keeping in mind that
all of the X source code, even the libraries, was originally intended
to be only a "sample implementation" of various standards.)
4) It is desirable to have a common foundation for both systems designed
to be X terminals (which run all their X clients from a remote
machine) and for application servers which may not need to run X
servers on their own display hardware. That is the purpose of the new
xfree86-common package. It also simplifies the task of dealing with
any large changes in the X directory namespace that may arise in the
future (e.g., X11R7, or simply putting all of X in /usr).
The new packages in the Debian XFree86 distribution are rstart, rstartd, twm,
xbase-clients, xdm, xfree86-common, xfs, xmh, xproxy, xserver-common, xsm,
and xterm. Some files from the old xbase package were also placed in
xlib6g (XKB and locale data) and xlib6g-dev (development tools).
xbase is now an effectively empty package that exists only to have the
package management system automatically "pull in" the new packages (and the
latest versions of the X libraries). Once it has been upgraded, it may be
safely removed.
Furthermore, the X font and static library packages have been renamed. The
following list summarizes these changes:
xfntbase->xfonts-base
xfnt75 ->xfonts-75dpi
xfnt100 ->xfonts-100dpi
xfntscl ->xfonts-scalable
xfntbig ->xfonts-cjk
xfntcyr ->xfonts-cyrillic
xfntpex ->xfonts-pex
xslib ->xlib6-static
xslibg ->xlib6g-static
I believe the new names are less cryptic. Note, however, that the old
packages may not necessarily be automatically upgraded to the new versions.
This is because their names have changed, and as yet there is no easy way
to tell the packaging system that a package has changed its name. However,
there are no serious consequences of leaving the old X fonts and static
libraries around. The contents of these packages have not changed. The X
font server, for instance, formerly in xbase but now in its own package,
works just as well with xfntbase as with xfonts-base.
Still, it is advisable to install the renamed versions of these packages as
soon as is convenient, in the event that their contents do change in the
future.
--
G. Branden Robinson |I have a truly elegant proof of the
Debian GNU/Linux |above, but it is too long to fit into
[EMAIL PROTECTED] |this .signature file.
cartoon.ecn.purdue.edu/~branden/ |
pgpUOwUrQMK6I.pgp
Description: PGP signature
Re: getting kernel 2.2 into slink
On Thu, 21 Jan 1999, David Welton wrote: > The kernel is stable, but is the kernel + debian stable? No one > knows. Well, assuming it's an improvement on the pre-release ones, we can make a pretty good guess :) > I think we should include it, as a service to people who don't want to > download the whole thing, but attach a note saying "As 2.2 was > released just before we released slink, we are including it, but there > may be problems, it might eat your computer... we are not responsible > for anything at all..." But we say that anyway! I don't think there's any need to FUD 2.2, but we could perhaps include the fact that it is relatively untested on debian at the time of release, and to check bugs.debian.org Matthew -- Elen sila lumenn' omentielvo Steward of the Cambridge Tolkien Society Selwyn College Computer Support http://www.geocities.com/Area51/Chamber/8841/ http://www.cam.ac.uk/CambUniv/Societies/tolkien/ http://pick.sel.cam.ac.uk/
Re: Debian goes big business?
On Wed, Jan 20, 1999 at 06:12:14PM -0500, Ben Pfaff wrote: > Laurent Martelli <[EMAIL PROTECTED]> writes: > >> "ChL" == Christian Lavoie <[EMAIL PROTECTED]> writes: > >ChL> Bottom line: Debian should remain developer controlled. > >What about non-developper users ? Shouldn't they have a word to say, >even if they can't or do not have the time to contribute with code ? > > They should have `a word to say', and they do--they can subscribe to > Debian lists and give their feedback and advice, which developers are > free to follow or ignore. But they do not, and should not, IMO, have > the privilege of voting or otherwise setting policy. Users are not > developers and shouldn't presume to be. i mostly agree but wouldn't put it anywhere near that strongly. users are not developers, but they might be one day. one of the good things about debian is that users who are willing to put in some work CAN join up as developers. i started that way a few years ago, and i'll bet that most debian developers did too. craig -- craig sanders
Re: Debian goes big business?
On Fri, Jan 22, 1999 at 20:26:12 +1100, Craig Sanders wrote: > On Wed, Jan 20, 1999 at 06:12:14PM -0500, Ben Pfaff wrote: > > Laurent Martelli <[EMAIL PROTECTED]> writes: > >What about non-developper users ? Shouldn't they have a word to say, > >even if they can't or do not have the time to contribute with code ? > > > > They should have `a word to say', and they do--they can subscribe to > > Debian lists and give their feedback and advice, which developers are > > free to follow or ignore. But they do not, and should not, IMO, have > > the privilege of voting or otherwise setting policy. Users are not > > developers and shouldn't presume to be. > > i mostly agree but wouldn't put it anywhere near that strongly. I would. Ben's phrasing strongly reminds me of Robert A. Heinlein; especially of the concept of TANSTAAFL and the political system he describes in "Starship Troopers", where the right to vote must be earned through a tour of duty of public (not necessary military) service. In the case of Debian, users do not have the right of vote, but can earn it by becoming developers (i.e. by maintaining packages, but also by writing documentation, maintaining the website etc.). Ray -- POPULATION EXPLOSION Unique in human experience, an event which happened yesterday but which everyone swears won't happen until tomorrow. - The Hipcrime Vocab by Chad C. Mulligan
Re: Unmet deps again
On Thu, Jan 21, 1999 at 07:32:27PM -0700, Jason Gunthorpe wrote: > Package stunnel version 2.1-2 has an unmet dep: > Depends: libssl09 Stunnel is in potato, libssl09 in slink: I guess this is the CSOBNS again (continuing saga of broken non-us). lupus -- "The number of UNIX installations has grown to 10, with more expected." - _The UNIX Programmer's Manual_, Second Edition, June, 1972.
mark bug #31824 (html2ps: can't execute) as critical?
Hi, shouldn't we mark #31824 (html2ps: can't execute) as critical? html2ps does not work at all with this bug. Fortunately the bug can be fixed by deleting an erroneous character in the script. Cheers, Thomas
Re: getting kernel 2.2 into slink
hi Ship's Log, Lt. Ivan E. Moore II, Stardate 210199.1558: > > > > Brian, would this be too grave a violation of your "no new code" rule? > > probably... :( I'd say this should only apply to a not-more-then-a-month-freeze :) until potato get's out debian would get kinda out-of-date. On the other hand, when slink will get out somewhen in the next 2 weeks including 2.2 it'll be very up2date. So, I'll encurrage this li'll break-of-rools Geetings -- Alexander N. Benner - 1st year grad. physicsstudent and creationist - | > The great unification theory reduces matter to two particles T & V < | | > That stands for the Hebrew words Tohu and Vohu - formless and void. < | GEN 1:2 And the earth was without form, and void; and darkness was upon the face of the deep. And the Spirit of God moved upon the face of the waters.
Re: Debian goes big business?
On Wed, 20 Jan 1999, Christian Lavoie wrote: >DISCLAIMER: These are notes, and can have technical impossibilites >(especially concerning '.deb'ianizing of StarOffice) > >- Provide single user free of charge support through internet. >(email/newsgroups/knowledge base/whatever) >- Provide corporate support, at a cost (cause they think it's better >to pay it anyway), with the usual things sucha thing includes >(on-site, 24 hours a day, programmation capable team to adapt a >product) Also have the corporate support subsidise any expenses that may be incurred providing user support. >- Work head-to-head against RedHat/Caldera/SuSE for publicity on >Debian and promoting .deb packaging of things like >StarOffice/WordPerfect No! We don't want to compete with Rad Hat, Caldera, or SuSE. We want to co-operate with them and share the market to put the squeeze on closed-source companies that sell low quality software that they don't support (I'm sure you know who I'm thinking of). Also different users have different requirements. If someone finds that Debian doesn't satisfy them then we want them to go try Red Hat, we don't want them to give up on Linux! -- I am in London and would like to meet any Linux users here. I plan to work in London for 3 - 6 months...
Re: Dpkg Update Proposal
On Fri, 22 Jan 1999, Craig Sanders wrote: > the libgtk* versions are compatible with each other. the libgtk*-dev > versions, are not (it would be possible to make it so by installing > header files in /usr/include/gtk-VERSION, but you'd still have to modify > every source file that #included it. in other words, it could be done > but probably isn't worth the effort unless it's done upstream as well). > > fortunately, the -dev packages conflict with earlier versions, so it's > not a problem. > > debian's way of handling this allows for all versions of libgtk to be > installed simultaneously, allowing progress AND backwards compatibility > without conflict. Actually, we could acheive concurrent dev packages with use of the alternatives mechanism and the (upstream) gtk-config programs. > BTW, this is only a "problem" because the upstream libgtk1.1.x changes > the programming interface without changing the .so number. they've got > valid reasons for doing so (and they do advertise that fact), so there's > really no need to come up with a general solution to a specific problem > with one or two unstable/rapid development upstream packages. There's no law (AFAIK) that it has to be the major number that changes to signify API changes. It's simply the way you choose to organise your symlinks. And it's consistent to name the package after the API version. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Unmet deps again
On Fri, Jan 22, 1999 at 10:45:42AM +0100, Paolo Molaro wrote: > On Thu, Jan 21, 1999 at 07:32:27PM -0700, Jason Gunthorpe wrote: > > Package stunnel version 2.1-2 has an unmet dep: > > Depends: libssl09 > > Stunnel is in potato, libssl09 in slink: I guess this is the > CSOBNS again (continuing saga of broken non-us). Some stuff happens with it; the other day, a whole lot of slink stuff was replaced in one hit. A few days earlier, all of /slink was moved to /dists/slink for no obvious reason. Unfortunately we pay for bandwidth in Australia and these big mirror hits were costing me a lot, so I had to kill it. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: Debian goes big business?
On Wed, 20 Jan 1999, Laurent Martelli wrote: >> "ChL" == Christian Lavoie <[EMAIL PROTECTED]> writes: > >ChL> Bottom line: Debian should remain developer controlled. > >What about non-developper users ? Shouldn't they have a word to say, >even if they can't or do not have the time to contribute with code ? Their input is best appreciated in the bug tracking system. ;) -- I am in London and would like to meet any Linux users here. I plan to work in London for 3 - 6 months...
Re: Unsatisfied depends in slink main
On Thu, 21 Jan 1999, Jason Gunthorpe wrote: > > On Thu, 21 Jan 1999, Dale Scheetz wrote: > > > Since the recent discussion with Richard Stallman about the unsatisfied > > suggests message, I have undertaken the examination of the main archives. > > > > The script that I am working on unpacks all of the .deb files it finds and > > collects Package:, Provides:, Pre-Depends:, Depends:, Recommends:, and > > Suggests: field information and deterines several things. > > You do realize that is why we have a 'Packages' file? Yes, and the current packages file indicates that ppp is in base, but it isn't there. The whole reason for scanning the archives was to catch such errors. > > In any event your script is not handling virtual pacakges, ppp is a > virtual package. > I add all Provides: to the list of "available" packages that I use. So if some package provides ppp it isn't indicating that fact. > Here is a list of all unmet deps in main: > > Package chameleon version 1.0-2 has an unmet dep: > Depends: libglib1.1.12 (>= 1.1.12-1) > Depends: libgtk1.1.12 (>= 1.1.12-1) > > (Ehm? This one is new, someone should fix it) > > A list of unmet suggests/recommends in main is too long to include here. > Actually my lists are not much worse than the depends. If I get a chance to work on this today, I'll put the other lists together. Thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
bzip2 compressed files
Would it be possible to have files such as Contents*.gz also provided in bzip2 format to reduce download times when using slow links?
Re: Debian goes big business?
Craig Sanders <[EMAIL PROTECTED]> writes: On Wed, Jan 20, 1999 at 06:12:14PM -0500, Ben Pfaff wrote: > They should have `a word to say', and they do--they can subscribe to > Debian lists and give their feedback and advice, which developers are > free to follow or ignore. But they do not, and should not, IMO, have > the privilege of voting or otherwise setting policy. Users are not > developers and shouldn't presume to be. i mostly agree but wouldn't put it anywhere near that strongly. users are not developers, but they might be one day. one of the good things about debian is that users who are willing to put in some work CAN join up as developers. I guess that that's the corollary to what I'm saying. If users want to have a stronger in say in whether their advice is followed, they should be become developers. It's not that hard, and doesn't take that long. -- "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." --Daniel Pead
Re: Unmet Deps revisted
On Fri, 22 Jan 1999, Steve McIntyre wrote: > >If there are optional packages that conflict with each other, we should > >choose one to stay in optional and move the others to extra. (Or change/ > >clarify the definition on the policy manual). > > The manual should be fixed IMHO - there are lots of places where this is > bogus. Consider the xserver packages, for example... This is not a good example. The xserver packages do not conflict at each other. You can install all of them. -- "ab1fe6591d2b31988b4d95c5752b8fe7" (a truly random sig)
Re: bzip2 compressed files
On Fri, Jan 22, 1999 at 01:22:56PM +, Russell Coker wrote: > Would it be possible to have files such as Contents*.gz also provided in bzip2 > format to reduce download times when using slow links? Good idea. And Packages files too. But that would need implementation in dselect, and will only work if bzip2 is already installed. Bzip2 package is not in base IIRC, and that would require a bit more changing, like adding another 180.6k to base_2.2.tgz. I'm sure that there are more problems... Is there a way to manually download the Packages.bz2, unpack it somewhere and make dselect use it? I remember something like /var/lib/dpkg/methods/ftp/packages_something but I'm not sure. -- enJoy -*/\*- http://jagor.srce.hr/~jrodin/
The days of mSQL are counted
WHO needs the mSQL database? For quite a while I'm very unhappy with it. For half a year I have worked actively in moving to a different db. Yesterday I ported the last remaining program at home which was based on mSQL to PostgreSQL though a general SQL API. There are however some programs left at work but the decision has already been made to move them to a better database. So, at the day I ported the last program I use at the office, I will drop maintenance of mSQL and request its removal - unless somebody steps in and takes over the package. Regards, Joey -- *** Fatal Error: Found [MS-Windows], repartitioning Disk for Linux ... Please always Cc to me when replying to me on the lists.
Re: getting kernel 2.2 into slink
At 11:32 PM 1/21/99 -0700, you wrote: >On Thu, 21 Jan 1999, Brent Fulgham wrote: > >> > 2.2. diald/ppp in slink does not work with 2.2.0-pre7 (on my box, at >> > least). I am sure that there are other things as well. >> >> I'm sure you were aware that you have to upgrade your pppd to work with any >> of the higher-order 2.1.X kernels? You might want to check the kernel >> source's Documents/CHANGES file. > >I also was unable to get ppp or diald to work with a later 2.1.x kernel in >a hamm system. > >Documentation/Changes says the required version of ppp is 2.3.5 and hamm, >slink and potato all have this version. > >Bob I've had trouble with dhcpd working with the 2.1.xxx kernels, haven't done much troubleshooting but it may be cause for concern.
Re: Unmet Deps revisted
On Fri, 22 Jan 1999, Santiago Vila wrote: >On Fri, 22 Jan 1999, Steve McIntyre wrote: > >> >If there are optional packages that conflict with each other, we should >> >choose one to stay in optional and move the others to extra. (Or change/ >> >clarify the definition on the policy manual). >> >> The manual should be fixed IMHO - there are lots of places where this is >> bogus. Consider the xserver packages, for example... > >This is not a good example. >The xserver packages do not conflict at each other. >You can install all of them. Hmmm, guess so. My mistake. But surely there are some optional packages that can legitimately conflict...? And I'm still not convinced this is a major issue... -- Steve McIntyre, Allstor Software [EMAIL PROTECTED] Oh My God! They Killed init! You Bastards! "Can't keep my eyes from the circling sky, "Tongue-tied & twisted, Just an earth-bound misfit, I..."
Re: mark bug #31824 (html2ps: can't execute) as critical?
severity 31824 important thanks Thomas Gebhardt wrote: > shouldn't we mark #31824 (html2ps: can't execute) as critical? > html2ps does not work at all with this bug. Fortunately the bug > can be fixed by deleting an erroneous character in the script. I believe we should. netgod will upload a new pkg, I hope. Regards, Joey -- *** Fatal Error: Found [MS-Windows], repartitioning Disk for Linux ... Please always Cc to me when replying to me on the lists.
Re: getting kernel 2.2 into slink
> > Would anyone object if kernel 2.2 were packaged up at least as a > > kernel-source package for slink? 2.0.3x would remain slink's default kernel, > > would be used on the boot disks, etc, but this would let people get ahold of > > kernel 2.2 easily on a debian cdrom, and it would let us say that debian > > supports 2.2. (I was at a LUG meeting the other day, and I was asked about > > this very thing a couple of times; people obviously care about it.) > > > > Brian, would this be too grave a violation of your "no new code" rule? > > > > (For those not yet in the know -- kernel 2.2 will probably be released next > > week.) > > There is precedent for this as there is a 2.1.125 package in slink now. > I think it's not a big deal if there are big disclaimers attached that > slink is not a 2.2 targetted dist. Disclamers are of marginal use. It will appear as installable and tell people to "install me" just as an elevator buttun tells people "push me". Adding a disclaimer is like taking a door with a big, "pull me" handle and putting a "push" sign above it. The "affordance" of the handle talks far more loudly than the sign. There is good reason to have new kernels in "unstable", but we're talking "stable", here. Brian ( [EMAIL PROTECTED] ) --- Only half the people in the world are above average intelligence.
Re: mark bug #31824 (html2ps: can't execute) as critical?
On Fri, 22 Jan 1999, Thomas Gebhardt wrote: > shouldn't we mark #31824 (html2ps: can't execute) as critical? > html2ps does not work at all with this bug. Not "critical" but "grave", since it "makes the package in question unuseable or mostly so". > Fortunately the bug > can be fixed by deleting an erroneous character in the script. I hope Brian will accept the fix, then. -- "e39e05de54d08bad06d9dbf728bff73d" (a truly random sig)
Re: getting kernel 2.2 into slink
> Brian> make any difference. Both will show up in dselect and it would > Brian> be trivial for someone to install the new kernel... and then > > Heh, thats the idea. :-) > > Brian> wonder why things don't work. > > Little things that few notice, apparently -- I would've sworn slink > and 2.2.0-final work perfectly until someone pointed out that > /usr/sbin/procinfo complains. Been running 2.1.1xx in production > with frozen for months. People swore to me that 2.0.36 would "drop in" without a problem. They were wrong. > I'd say at least include a source package for whatever 2.2.0 is > available at the moment of release, so we get the bragging rights. > :-) A deb would be even more impressive. Including the source package I could be convinced of. At least then people have to think about what they're doing before causing potential problems. > Brian> Since it is assured that some packages will have to be patched > Brian> by a user that wants to use the new kernel, making those users > Brian> go through a little bit more effort to get the new kernel is > Brian> more than offset by reducing the amount of problems encountered > Brian> by other users. > > It may be hopeless fantasy, but I'd like to believe our users aren't > this helpless. I'll share that fantasy. As linux becomes more and more mainstream, it's going to be even more difficult to dream. Of course, the reality is that most users don't need the 2.2 kernel anyway. Brian ( [EMAIL PROTECTED] ) --- He who laughs last usually make a backup.
Re: getting kernel 2.2 into slink
On Fri, Jan 22, 1999 at 09:25:14AM -0500, Brian White wrote: > > There is precedent for this as there is a 2.1.125 package in slink now. > > I think it's not a big deal if there are big disclaimers attached that > > slink is not a 2.2 targetted dist. > > Disclamers are of marginal use. It will appear as installable and tell > people to "install me" just as an elevator buttun tells people "push me". > Adding a disclaimer is like taking a door with a big, "pull me" handle > and putting a "push" sign above it. The "affordance" of the handle > talks far more loudly than the sign. > > There is good reason to have new kernels in "unstable", but we're > talking "stable", here. Perhaps the 2.1.125 kernel source should be removed from archs which don't use it then? -- "I'm working in the dark here." "Yeah well rumor has it you do your best work in the dark." -- Earth: Final Conflict
Re: the Great X Reorganization, package splits, and renaming
On Fri, 22 Jan 1999, Branden Robinson wrote: > Just thought I would bring this up one more time and run it by everyone. > This can be considered a draft of what I'd like to put in the release > notes. [...] > Furthermore, the X font and static library packages have been renamed. The > following list summarizes these changes: > > xfntbase->xfonts-base > xfnt75 ->xfonts-75dpi > xfnt100 ->xfonts-100dpi > xfntscl ->xfonts-scalable > xfntbig ->xfonts-cjk > xfntcyr ->xfonts-cyrillic > xfntpex ->xfonts-pex > xslib ->xlib6-static > xslibg ->xlib6g-static > > I believe the new names are less cryptic. Note, however, that the old > packages may not necessarily be automatically upgraded to the new versions. > This is because their names have changed, and as yet there is no easy way > to tell the packaging system that a package has changed its name. I agree that we don't have an *elegant* way of telling the package system that a package has changed its name. But we have a very simple way, without adding new features to the packaging system, to avoid the problem that X packages are not upgraded automatically, namely, just make xfntbase an empty package which depends on xfonts-base (and so on for the other packages). I can't believe that this is not easy to do. It would be just a matter of making some empty packages, they could be generated from the same source package, and of course the source package would not have to be the same source package which is used for all the other X real packages (I'm sure the X source package is already quite complex). If the problem is that you don't have enough time for both the X packages and the dummy ones required for smoothly upgrading the font packages, no problem. We are more than 300 developers and I'm sure that there will be someone who would help you in this if you need help. [ If nobody is interested in this, I would volunteer ]. > However, there are no serious consequences of leaving the old X fonts > and static libraries around. Debian would be failing to the (documented everywhere) promise of smooth upgrades if we decide not to make the X upgrade smooth, being it such a popular set of packages. I think failing to this fundamental promise would be indeed a serious consequence. > The contents of these packages have not changed. The X > font server, for instance, formerly in xbase but now in its own package, > works just as well with xfntbase as with xfonts-base. > > Still, it is advisable to install the renamed versions of these packages as > soon as is convenient, in the event that their contents do change in the > future. This would just postpone the problem until there is a real difference between the old packages and the new ones, but would not make the problem to disappear. It would be just a clock bomb. Imagine the following scenario: --Oh, I upgraded from Debian 2.1 to Debian 2.2 and now my font packages do not work. --Did you read the release notes for the X packages in Debian 2.1. --What for? Debian claims to have smooth upgrades. Why it should be so important to read the release notes? I have proposed a very simple solution, which, in addition to the empty xbase (I applaud that you accepted this idea), would make the X upgrades *completely* smooth. I think this solution would be very easy to implement, it will avoid problems in the future, and I have not heard yet a good reason *not* to implement it. I really hope you reconsider about these few extra dummy packages. Thanks. -- "7149ffdc7f830ccf71b4766c69ac4bf4" (a truly random sig)
Re: Debian booth at LinuxTag '99?
On Thu, Jan 21, 1999 at 03:45:46PM +0100, Philipp Frauenfelder wrote: > Btw, how much is a "stone throw"? According to the map I used it's 62.5 km (if you go by plane). By train it will take 1.5 h . Christoph -- * Christoph Baumann * * [EMAIL PROTECTED] * * www.rzuser.uni-heidelberg.de/~cbauman1/welcome.html* * "External Error : INTELLIGENCE not found !"* pgpkMBE9N0Qh9.pgp Description: PGP signature
Re: Unmet Deps revisted
On Fri, 22 Jan 1999, Steve McIntyre wrote: > On Fri, 22 Jan 1999, Santiago Vila wrote: > > >On Fri, 22 Jan 1999, Steve McIntyre wrote: > > > >> >If there are optional packages that conflict with each other, we should > >> >choose one to stay in optional and move the others to extra. (Or change/ > >> >clarify the definition on the policy manual). > >> > >> The manual should be fixed IMHO - there are lots of places where this is > >> bogus. Consider the xserver packages, for example... > > > >This is not a good example. > >The xserver packages do not conflict at each other. > >You can install all of them. > > Hmmm, guess so. My mistake. But surely there are some optional packages > that can legitimately conflict...? Please define "legitimately". The way I read the definition of optional and extra, a conflict between two optional packages is never "legitimate". Please note that a suboptimal packaging does not legitimate the conflict. For example, my unzip and unzip-crypt packages do conflict at each other, and they are optional, so I should probably make them compatible, like pgp-i and pgp-us, for example. [ And of course, I will not mind that unzip-crypt is demoted to extra until I repackage them ]. (Yeah, I put my own packages as examples of suboptimal packaging! I hope the pgp-i and pgp-us example will help you to see that surely most of these conflicts are gratuituous). -- "de678b3c48777bfcbc98fe1bb004351d" (a truly random sig)
Re: getting kernel 2.2 into slink
On Fri, 22 Jan 1999, Brian White wrote: > I'll share that fantasy. As linux becomes more and more mainstream, it's > going to be even more difficult to dream. Of course, the reality is that > most users don't need the 2.2 kernel anyway. unfortunately (maybe) for Debian, very few inexperienced users choose it (since they don't know about it), and instead choose Red Hat or another commercial vendor in the limelight. -tl .. please forgive my abrupt ending hre - but my conection is xtrememleyyhiclmelyey BAD hiccuppy etc must sign off - EF D8 33 68 B3 E3 E9 D2 C1 3E 51 22 8A AA 7B 98
anybody from Dortmund / Germany or around?
Is anybody from Dortmund / Germany or around here? I'd like to become a maintainer and need somebody to sign my PGP key.
Re: getting kernel 2.2 into slink
On Fri, 22 Jan 1999, Brian White wrote: > Including the source package I could be convinced of. At least then > people have to think about what they're doing before causing potential > problems. This "think about what they are doing" thing is precisely one of the reasons the "extra" priority does exist. According to this it should be fine to include it as an "extra" package. Thanks. -- "217e87fb4c104713e650fd2423353a7a" (a truly random sig)
Re: Intent to package rolldice, blackjack
On Fri, Jan 22, 1999 at 01:22:32AM -0500, Stevie Strickland wrote: > > that's the good news. the bad news is that it was all done in turbo > > pascal. however, the algorithms were clean and readable, so easily > > ported to C. > > > > if you're interested, i'll dig up the files (i still have them on tape > > somewhere...i think. dusty old code from the early 90s :-) and mail them > > to you. i'll GPL them first, so you can do what you want with them. > > Cool! I'd always be glad to look at them (especially since I need a much > better parser)... anyway, eventually I want to make a librolldice so that > anyone can actually make the front end... and your code could definitely > help, because I'm no good at parsers, and that would be one of the most > important part of the library... :p I'm not certain why this should be a lib actually, even if you build a bigger program. But hey, if you wanna build a lib, build a lib, we won't complain much.. => > As well, my roommate and I were going to also make a character sheet > program (hence the reason for making the rolldice stuff a library), so we > could just enter the data, and either save it to a file or go ahead and > print it out... my roommate has been working on GTK+ for the occasion Why do I get the idea I should bring up once again my hope to gather a sizable group of people to build a game system which is released under free license and available to anyone with a web browser and the like? => -- "I'm working in the dark here." "Yeah well rumor has it you do your best work in the dark." -- Earth: Final Conflict
Re: getting kernel 2.2 into slink
> > > There is precedent for this as there is a 2.1.125 package in slink now. > > > I think it's not a big deal if there are big disclaimers attached that > > > slink is not a 2.2 targetted dist. > > > > Disclamers are of marginal use. It will appear as installable and tell > > people to "install me" just as an elevator buttun tells people "push me". > > Adding a disclaimer is like taking a door with a big, "pull me" handle > > and putting a "push" sign above it. The "affordance" of the handle > > talks far more loudly than the sign. > > > > There is good reason to have new kernels in "unstable", but we're > > talking "stable", here. > > Perhaps the 2.1.125 kernel source should be removed from archs which > don't use it then? The more I think about it, the less objection I have to a source package. They're nice to have, require thought before installing, and give some extra "bragging rights", as someone put it. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: getting kernel 2.2 into slink
> > Including the source package I could be convinced of. At least then > > people have to think about what they're doing before causing potential > > problems. > > This "think about what they are doing" thing is precisely one of the > reasons the "extra" priority does exist. > > According to this it should be fine to include it as an "extra" package. Perhaps that is a reason for "extra", but it's really pointless. If it can be installed, people will install it regardless of its priority. I'd bet most people don't even think about a package's priority, largely because many don't know what the priorities mean. Brian ( [EMAIL PROTECTED] ) --- 80% of people surveyed think they are above average drivers
Re: Intent to package rolldice, blackjack
-BEGIN PGP SIGNED MESSAGE- > > > if you're interested, i'll dig up the files (i still have them on tape > > > somewhere...i think. dusty old code from the early 90s :-) and mail them > > > to you. i'll GPL them first, so you can do what you want with them. > > > > Cool! I'd always be glad to look at them (especially since I need a much > > better parser)... anyway, eventually I want to make a librolldice so that > > anyone can actually make the front end... and your code could definitely > > help, because I'm no good at parsers, and that would be one of the most > > important part of the library... :p > > I'm not certain why this should be a lib actually, even if you build a > bigger program. But hey, if you wanna build a lib, build a lib, we won't > complain much.. => I'm bored, and I know how to package a "single binary" using dh_make... time to test out a shared library... :) > > As well, my roommate and I were going to also make a character sheet > > program (hence the reason for making the rolldice stuff a library), so we > > could just enter the data, and either save it to a file or go ahead and > > print it out... my roommate has been working on GTK+ for the occasion > > Why do I get the idea I should bring up once again my hope to gather a > sizable group of people to build a game system which is released under > free license and available to anyone with a web browser and the like? => I'm all for it! How about it, anyone else interested? :) Stevie - -- Stevie Strickland (PGP ID = 23A6D909) 325912 Georgia Tech Station [EMAIL PROTECTED] Georgia Institute of Technology http://computersprache.net/~sstricklAtlanta, GA 30332 PGP Key fingerprint = 84 52 C7 EA E6 DB A1 C5 6A C9 D6 B9 88 26 74 FC -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNqiUDoXKvMsjptkJAQGi4gQAzhmMyEQcqhfbGyRkG9Nw7PlMu87CUCdh vPCFSSCQpbRwrhBZjnTCQKx9cl9nQ+ts5mDK6bMLNnvLZCk4gIYcxlGbvb3H4BFB PvJcT6/Up/LtlbbdySHrygjVDhpG+gwwrC1lBw9nZgJqzqOUH5UPvOW8YDbPwgat cKz0jvJMAxg= =JFeQ -END PGP SIGNATURE-
