too funny to not pass on...
from debian-freshmeat, where we are talking about setting up the new DFMR (Debian Freshmeat Repository) Seth: b) apt-get able, so it's a ftp and/or http site, and a single line to stick into etc/apt/sources.list Jeff Covey of freshmeat: this would rock. we'll have to work with the apt coding crew to get ready for the day osdn decides they could be selling ad space here. # apt-get install mod_foo Reading Package Lists... Done Building Dependency Tree... Done Contacting ad server... Done /\ | This download is brought to you by Cisco Systems.| | BUY OUR ROUTERS! BUY OUR ROUTERS! BUY OUR ROUTERS! BUY OUR ROUTERS! | | http://www.cisco.com/ | \/ Seth again: Debian was brought to you today by the letters J, K, and the number 5. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: spong
At 07:26 PM 09/13/2000 +0300, Pekka Aleksi Knuutila wrote: Spong is a simple systems and network monitoring package. It does not compete with Tivoli, OpenView, UniCenter, or any other commercial packages. It is not SNMP based, it communcates via simple TCP based messages. It is written in perl and easily modifiable. [etc] * Big Brother BBSERVER emulation to allow Big Brother Clients to be used Very cool. I'll check the package out. I've got the ITP for big brother, and plan on filing one for big sister (a perl GPL clone of BB), since the author is excited about it being packaged for Debian. Hopefully, we can make all of these play nice with each other, and replaceable with each other. Maybe we can define a 'provides' like 'bbclient' or 'bbserver' so we can use any of the possible combos. feel free to write me offlist, Seth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE2 - nice demolition job ...
> BTW, the rant has been a long time coming - this just keyed it. > > Purpose of Rant: Stir up the coals ... Hey erik, grow up. Debian has enough flamewars without you stirring the coals intentionally. 'The broken update happened 20 minutes before the rant' HUH? Geez. Seth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE2 - nice demolition job ...
On Mon, 11 Sep 2000, erik wrote: > I just can't keep my mouth shut about this any longer and the > unnecassary divisions (read demolitions) of KDE packages are the last > straw: I've been tracking the development of KDE2 for months and running > it quite successfully using "unofficial" debs (cheers to the folks at > kde.tdyc for bucking authority!) [and this drivel continues and continues for paragraphs] You _do_ realize that the same guy who packaged it for kde.tdyc _is_ the same guy who is packaging it for Debian proper? > I think this is a pretty blatant example of the obvious failings of an > aging and inflexible beuracratic empire that cares more for its protocols > and levels of "authority" heh. Excuse, but as one future developer, I have to say that I see Debian as the group that cares the _most_ for doing things right. We may argue about _how_ to implement stuff, or even _why_ or _if_, but that's because the people involved care. Yes, there are petty bickers, and factions, and so on, but Debian is still the only distribution that exists on the scale it does and work well. > minutia and complaining about how there is too much to be done while > keeping "outsiders" waiting for months to even recieve acknowledgement of > reciept of application to voluteer (Oh, Yes, You too can help with > the Debian Project - just jump through these thirty complicated hoops and > apply to be a "developer" and wait around for a year or so and then if we > think you're cool ... garbage, why bother?). That's not true at all. So far, I'm in the new maintainer queue, and have a number of offers from sponsors to upload packages whenever they are ready. If you want to package something, at this point, yes, you should get into the queue, but finding a sponsor isn't very hard. Debian is about participation, and if you participate, you see results. > And try not to prove my point with condescending flames - its not > attractive. My flame isn't condescending. It's based on the fact that a) Ivan is doing a fine job of getting KDE re-packaged, give him some time. b) complaining about the new maintainer queue isn't productive, so go do something productive with that energy. and finally c) you really come off whiny. If you don't like the manual, help write a better one. If you don't like the way Debian deals with new users, help change it, by setting an example. File bug reports if nothing else. Etc. another happy Debian user, Seth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
digest version broken?
I was getting both user and devel as digests, and both went quiet. I subscribed to both as digest again, in case I'd been knocked off the list, and still nothing, so I subscribed as non-digest and I'm getting email, enough that it should have kicked out a digest, but still no digest. Looks like digests are broken, could someone fix please? Seth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: GUI tools for common Debian admin tasks
At 10:13 PM 09/07/2000 +, you wrote: I don't object to a web-browser, personally. I do object to having to install and configure a Web server (!!) to set up the machine, for the same reason I object to needing a Web server to view documentation (eg, doc-central depends on apache). Webmin has it's own webserver built in (via perl). No external webserver required. In fact, I believe that a base system will provide everything needed. Jaldhar said he's changed the package to remove the libnet-ssleay-perl depends. which leaves (and I don't have his current version to check) Depends: perl5, debconf any reason it can't use debconf-tiny? I don't see why not... No reason a small webmin stripped down to just Debian configuration requirements couldn't fire up and allow complete remote configuration of a box. Imagine, you stick in a boot floppy/CD, it grabs the base-package from the net, unpacks it, and then goes into 'configure me' mode, by running mini-webmin. You could add users, configs, more stuff via apt, etc, all from a remote machine. You might never have to log in at the console EVER, if it's a server. In fact, with a scripty boot floppy/CD, you wouldn't need a monitor or a keyboard to ever be hooked up. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: GUI tools for common Debian admin tasks
> This is good for Debian, since we want something cross-platform, and > possibly even cross-kernel (Hurd, anyone?). Adding a network config for > Debian, Rene Mayrhofer said he was making a start on this. He's away for a few weeks, when he gets back, I'll find out how far he's come. > a dpkg/apt module, Someone pointed out to me that dpkg is already part of the standard software package module. No apt module though. Seth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: GUI tools for common Debian admin tasks
On Thu, 7 Sep 2000, Nate Duehr wrote: > Linuxconf is very broken (and it's documented in the Readme's provided > with the .deb) on Debian, and it mangles perfectly good config files > into nasty-looking ones that sysadmins who prefer vi usually dislike > reading. Another point in webmin's favor. I was pleasantly surprised when I discovered that editing mail aliases in webmin _didn't_ blow up my heavily commented /etc/aliases file. In fact, it respected the # signs, understood that they were disabled entries, and left everything intact. I personally use an line editor on it, but this way, someone can, if need be, add an alias and NOT screw my systems up. Another thing in webmin's favor: it currently supports BSD and Solaris and more: Operating system Supported versions Sun Solaris 2.5 , 2.5.1 , 2.6 , 7 , 8 Caldera OpenLinux eServer 2.3 Caldera OpenLinux 2.3 , 2.4 Redhat Linux 4.0 , 4.1 , 4.2 , 5.0 , 5.1 , 5.2 , 6.0 , 6.1 , 6.2 Slackware Linux 3.2 , 3.3 , 3.4 , 3.5 , 3.6 , 4.0 , 7.0 Debian Linux 1.3 , 2.0 , 2.1 , 2.2 SuSE Linux5.1 , 5.2 , 5.3 , 6.0 , 6.1 , 6.2 , 6.3 , 6.4 Corel Linux 1.0 , 1.1 TurboLinux4.0 , 6.0 Cobalt Linux 2.2 , 5.0 Mandrake Linux5.3 , 6.0 , 6.1 , 7.0 , 7.1 Delix DLD Linux 5.2 , 5.3 , 6.0 MkLinux DR2.1 , DR3 XLinux1.0 LinuxPL 1.0 Linux From Scratch2.2 FreeBSD 2.1 , 2.2 , 3.0 , 3.1 , 3.2 , 3.3 , 3.4 , 4.0 , 5.0 OpenBSD 2.5 , 2.6 , 2.7 BSDI 3.0 , 3.1 , 4.0 HP/UX 10.01 , 10.10 , 10.20 , 10.30 , 11 SGI Irix 6.0 , 6.1 , 6.2 DEC/Compaq OSF/1 4.0 IBM AIX 4.3 SCO UnixWare 7 , 2 SCO OpenServer5 MacOS Server X1.0 , 1.2 This is good for Debian, since we want something cross-platform, and possibly even cross-kernel (Hurd, anyone?). Adding a network config for Debian, a dpkg/apt module, and a debconf module, I think we'd be all set... Jaldhar, can you pry yourself away from imap for a few minutes and get the webmin stuff uploaded to incoming? :) I'd like to see what's you've changed... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Webmin works... was Re: RFC: GUI tools for common Debian admin tasks
On Thu, 7 Sep 2000, Frederic Peters wrote: > > Agreed. If you want to do something USEFUL, write a better webmin, debconf > > or linuxconf module. > - webmin: I think it is useful (and nice) not to have to launch mozilla >to add an user or change a password. Excuse me? if you don't want to launch a browser (and NOT mozilla thank you... ANY browser, even lynx will (mostly) work), then you should use a command line tool: adduser and passwd are fine for any user who is smart enough to know how. For the rest, a web pointandclick is one of the only interfaces they not only _should_ know how to use, but is also remote controlable easily (yes, true sysadmins can telnet/ssh/remoteX, but we are talking newbies here), so Windows/Mac/whatever users with a Linux server to admin can fix things from a remote machine. Webmin is _really_ well done, and VERY customizable. I have given users access to only certain sections, because that is all I have had time to train them on, and I don't want them messing with other settings. It's secure... it uses ssl if you want. It's supported by a strong mailing list, developers, and outside vendors it's been _packaged_ already. It requires NO httpd, just perl (so it will run on a base-floppies system, without X or anything else) Daniel suggested this list: (a) set up a printer. (b) Add/delete users (c) Install and configure hardware devices and modules (d) Manage fstab and partitions? (e) package management stuff (f) Set up a PPP connection. (g) See available documentation (h) Display network configuration (IP address) as well as modifying it. Every one of these can be done right _now_ by webmin, I believe, with the possible exception of (e), because I think there is an RPM but not a dpkg/apt module. I bet coding an apt-get module would be trivial. The nice thing is that if you want to write a module for it, it's easy. If you do anything Debian specific, great, webmin is smart enough to know the OS it runs on, and will use that module. If you haven't tried webmin, please do. http://www.webmin.com Last time I looked, webmin packages were sitting in incoming, but rejected due to the ssl option (Jaldhar wanted it in main, and James bounced it over the ssl linking). The deb installed fine for me from http://incoming.debian.org/REJECT/ If you want to create a new tool, please _don't_. After trying all of the horrible ones like yast & linuxconf, and installing hundreds of systems for people at LUG meetings, I'm convinced that if you want something that makes sense to new users, just spend your energy improving webmin. Mandrake did. They wanted something that looked nicer, so they created new icons for it and contributed to development (wrote a postfix module among others). Caldera is sponsoring it at this point, also. Instead of creating yet another rift, let's add true Debian support to it. A single frontend makes much more sense than tons of incompatible, non-similar frontends. A non-power user who switches from Mandrake or Caldera or RedHat or whatever to Debian (and I have many at our local LUG who are doing just that...) shouldn't have to learn a whole new frontend, when something like webmin can handle the cross distributional differences, which it can and does well right now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: GUI tools for common Debian admin tasks
So, yes, why reinvent the wheel, if there are allready n^x conftools around with a new one popping up monthly (webmin, COAS, linuxconf, debconf, yast, ..., ..., ...) ? It's not going to make anything easier. Agreed. If you want to do something USEFUL, write a better webmin, debconf or linuxconf module. Webmin is really easy to write for, and it has no current Debian network config. Writing one would be VERY useful, the upstream is very supportive, and it's a nice package for newbies and advanced users alike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Offtopic: Re: FW: Firewall Project
Offtopic, very much so. But the answer is, it's totally suitable... and commericial Linux based solutions exist, if they don't want to roll their own (for liability reasons, they might not). Try www.watchguard.com for one such answer. please follow up via email... this list is not the right forum for this. Seth The "technical" leadership at my wife's work are back-pedalling from using a Linux firewall between an AS/400 system and remotely-connected PC's based on the following argument: > To all Network Administrators: > > Problem: AS/400 can only communicate with active packets to and from the > client. Any type of passive packet exchange will result in a loss of > connectivity and invoke a Winsock error. > > Solution: Use an active firewall scheme > This "active" firewall will most likely consist of a windows-based solution. Can anyone comment on why Linux would be unsuitable for firewall use in this configuration? Thanks, -Brent
Re: ITP: Biomail - automated medical searcher
> > Author is excited about getting this packaged for Debian. > > Homepage is http://biomail.sourceforge.net > NIce news. This saves me some work I wanted to do since I visited > the lession about BioMail on the conference in Bordeaux. Go for it! > > > I think this will go into contrib, since it uses PubMed's database, > > and it is pretty useless without access to their database. The code itself > Hmmm, but you don't have to install this database on your own box! > You just access it via http, if I'm not completely wrong. You are correct. My error, since I didn't check the definition of contrib. So long as it's not a package, the dependance on the external website is ok. I thought any external dependances made it non-main. But it's GPL, so it's DFSG compliant 100%. Ok, it'l be in main then. Are there plans to make the new science subsection soon? This would fit in there nicely. > I would sponsor the package. thanks, Seth
ITP: Biomail - automated medical searcher
Package: wnpp Version: N/A; reported 2000-08-19 Severity: important Author is excited about getting this packaged for Debian. Homepage is http://biomail.sourceforge.net License is GPL I think this will go into contrib, since it uses PubMed's database, and it is pretty useless without access to their database. The code itself is free, and I think someone could easily modify this into doing many other similar database searches. Imagine if someone tweaked this to do searches on common web sites, so it would email you anytime the topic you desired was mentioned. I'm still waiting in the new maintainer queue, but I'm sure I can get this uploaded via sponsorship. BioMail is a small web-based application for medical researchers, biologists, and anyone who wants to know the latest information about a disease or a biological phenomenon. It is written to automate searching for recent scientific papers in the PubMed Medline database. BioMail is free and will stay free. What does BioMail do? Periodically BioMail does a user-customized Medline search and sends all matching articles recently added to Medline to the users' e-mail address. HTML-formatted e-mails generated by BioMail can be used to view selected references in medline format (compatible with most reference manager programs). Why is BioMail helpful? If you use Medline, it may be hard to remember when you did your last search. Often you must scan titles you have already seen to be certain you didn't miss an important reference. BioMail will perform routine searches for you. This program alerts users to all new papers in their fields automatically. It also helps the user to 'refine' search patterns once and for all. There is no need to wonder: 'What was that great search pattern I used last Saturday?'. All patterns are safe in the database and can be accessed, tuned, or deleted any time. It is also useful for countries where access to the Internet is not yet widely available. If a person has a permanent e-mail address, but only sporadic www access, she/he only needs to fill out a BioMail form once and then will receive new references from Medline continually. License It is released under GNU GPL license. This means it can be freely used, distributed, modified and redistributed as a new application, or it can even be sold for money, as long as the original or modified source codes remain freely available (and a little respect to the author is shown). Requirements BioMail was written in Perl for Linux. It was also checked under San Solaris7, Irix 6.5 (on SGI), Tru64 Unix 4.OE (on Digital alpha), and should be fine for other Unix OSes. BioMail requires a standard Perl distribution and two additional Perl modules from CPAN -- LWP::Simple and Mail::Mailer. Code by Dmitry Mozzherin ([EMAIL PROTECTED])
Re: Subpackaging
On Fri, 18 Aug 2000, Anthony Towns wrote:
> It's not *entirely* clear that including the above in the .deb itself
> is even the best way of doing things though. Everything in the above
> is entirely package-independent except for the "doc" lines, and they
> can be determined simply by saying "everything in /usr/share/doc/*,
> except /usr/share/doc/*/{copyright,changelog.gz,changelog.Debian.gz}.
>
> Similarly, saying "everything in /usr/share/doc/* called *.ps.gz or *.ps"
> counts as a postscript-doc, and "everything in /usr/share/doc/examples"
> is an "example", lets you get most of the fine-grained distinction you
> probably want.
>
> This latter method has the advantage that it just requires changes to
> dpkg and apt and friends without also requiring every single package be
> updated to support the new way of doing things.
>
> It might turn out to be useful to let packages be slightly more specific
> about this in some special cases. I can't think of any examples offhand.
I like this idea and can see where this kind of idea can work on both a
package level and sub-package level... So permit me to brainstorm a sec...
> I wonder what this will mean for our existing -doc packages.
For existing -doc packages, if the goal is translation, then make -doc
packages include english by default, and suggest any translation packages.
Then, add a feature to dpkg or apt or ?? that you can specify a desired
language and it will turn suggested translations into required ones. So
if I say I want 'french', then any suggested package with a 'french'
keyword/field/name/whatever will be included automagically when I pick the
package. This should work for more than one language too. Conversely,
removing english can be as easy as 'noenglish'
For other goals, similar ideas can be implemented. Set a 'newbie'
feature, and it will automagically get any 'newbie' suggestions. And maybe
prevent installing any 'non-newbie' packages
("Sorry, your system level is set to 'newbie'. To install
'complex-manually-configured-package', you must turn this off first)
[And if you can't figure out how to turn it off, you are too newbie]
Set a 'minimal' feature and it will only install 'minimal' packages, some
of which can be set to _conflict_ with other related things, so they won't
get installed (and thus stay minimal).
("Sorry, your system is set to 'minimal', installing 'bloated-package'
requires turning this off.)
For sub-packages, maybe a 'no-doc' feature. This would remove anything in
the /usr/share/doc/packagename section, as you suggest above, after the
package is installed. It could remove things cleanly and neatly, without
removing the whole package.
(Your system is set to delete documentation. We are noting what files
have been deleted, and you can restore them with 'apt-get rtfm package')
Between 'no-doc' and 'minimal', you should have the smallest possible
system. Maybe a extra feature to really remove anything else remotely
removeable. My first flash was to call this: '3263827' (10 points to
anyone who immediately knows why...)[1] since it should be an obscure but
possible option, to allow stripping just about everything to allow
embedded devices etc., to fit something in the absolute minimal space.
How about a 'portability' feature: this would discourage the use of
anything not cleanly portable between different archs. So you can be sure
all of your various boxes can all run the same thing.
(Sorry, this package requires 'x86' specific code, it will not be
usable on your 'powerpc' box(es). Are you sure you want to install this
on your x86 box?)
I'm sure other 'featuresets' can be brainstormed. This uses the existing
suggested and recommended levels, in a new way, and also is flexible
enough to allow only those who want something like this to install it,
maintainers to use or ignore it, and piecemeal implementation. Adding
fields or keywords to a package, and maybe a file to categorize package
contents.
feedback?
Seth
[1] it's the number of the trash compactor door in Star Wars.
Bug#69271: general: why not a praise tracking system?
Joost> What I am missing is a praise tracking system. It would Joost> operate similarly to the b.t.s.; users could: >Sounds like a good idea, eg to help motivate maintainers fix bugs. I think it would be good just to alert people to real well done packages (for instance, excellent debconf script, etc) to help teach new maintainers, or to find the best of a bunch of similar packages (there are HOW many Tetris clones? :) ) Submit a bug to the BTS with severity: praise? Why not? I don't think we need more than 2 or 3 levels of praise: recommended, exceptional, outstanding [ when are you going to fix the 10 bugs against your package? oh, sorry they are praise bugs ;-) ] The bug tracking can ignore bugs of that level (if normal bugs are 1-10, these would negative numbers of severity) Or, redesign the BTS so it can better handle the growing number of applications (WNPP,praise tracking,etc) (eg fields specific to each application, instead of using the title for this purpose)? Agreed. Makes LOTS of sense to start planning this now... BTS changes (for origin, etc etc,) can all be done over time, including this major change. Letting a maintainer know you really like their work is good feedback, and we should encourage that. Developers who don't want to hear or see praise can always filter it out (maybe even a setting in BTS: don't praise me, praise me digested, praise me all the time) the name of bugtracking software can be symlinked to 'praise' and detect what it's running as, to remove the complaint nature of the 'bug' and turn it into "compliment"
Re: Potato now stable
> I recall reading a few months ago about a plan to merge ALL of the > existing hardware detection routines into one lump, in order to > consolidate work and effort. The proposal was met with acceptance by many > (if not all) of the major developers (Mandrake, Redhat, Suse, Turbo) > > please post if you do find a link to it. reply to my own request: It was on this list I saw it (gee, how nice), and Dan Shearer ([EMAIL PROTECTED]) was organizing it. Wichert replied to his request for help and said he'd love to see this happen, and pointed Dan to boot-floppies as the group to work with for Debian. Dan replied with a long post quoting his plan and more. the thread was in May 2000, http://www.debian.org/List-Archives/debian-boot-0005/msg00471.html starts the thread and http://www.debian.org/List-Archives/debian-boot-0005/msg00482.html contains Dan's proposal
Re: Potato now stable
On Wed, 16 Aug 2000, Bas Zoetekouw wrote: > > Has anyone has looked into porting this [Kudzu] to Debian? > > Mandrake, too, includes a hardware detection libarary (libdetect). > Some time ago, Dan Helfman <[EMAIL PROTECTED]> (Cc'ed him), was busy > packaging it. Dan, have you had any luck yet adapting it to Debian? I recall reading a few months ago about a plan to merge ALL of the existing hardware detection routines into one lump, in order to consolidate work and effort. The proposal was met with acceptance by many (if not all) of the major developers (Mandrake, Redhat, Suse, Turbo) You might want to do a search on LWN (www.lwn.net) or Linuxtoday, or elsewhere. I did a quick look and didn't find it, but I know I read about it. please post if you do find a link to it.
Re: Deb base ISO images
I've been browsing cdimage. Do we release a base system as a 30/40-ish meg ISO that can network to enable apt handling retrieval of anything else? One would be really useful to me, and I'm sure to others too. The base packages (for floppies etc) aren't always so easy or convienient, and I think an ISO image would be a really good way to show the power of apt-get etc. Linuxcare's disc can install Slink that way, and one of my goals with Lubbock (http://lubbock.sourceforge.net) is to have it do the same for potato. I don't see any reason why such a disc couldn't be made easily (strip it down from the full version, to just the base). slightly offtopic, I've just started a sourceforge site dedicated to building CD based systems (many of which use Debian). Mailing list starting soon. I'll post more in the appropriate places when I've got a description ready. Anyone looking at building a bootable CD will find the tools useful, and the contacts even more useful.
