Linux PowerDVD
We are offering DVD player software for Linux, please advise who we can talk to or meet with. Where is your mailing address and telephone number? Please contact us at 510-668-0118. Regards, Louise Loh isales Asst. Manager CyberLink. Corp Revolutionizing Video and Audio Solution for the Digital World Tel: 510-668-0118 Fax: 510-668-0121 www.gocyberlink.com www.cli.co.jp BEGIN:VCARD VERSION:2.1 N:;Louise FN:Louise EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:2821T231320Z END:VCARD
Re: FW: Firewall Project
On Mon, Aug 21, 2000 at 11:57:53AM -0700, Brent Fulgham wrote: > > > Can anyone comment on why Linux would be unsuitable for firewall use > > > in this configuration? > > > > Can you explain what an `active' packet is? > > > > That's my question as well. I can't find any reference to an "active" > packet definition. Could he mean some kind of "keep-alive" configuration? My guess (and it's only a guess) is that an 'active' packet (from the AS/400s point of view) is one sent down a connection that the AS/400 initiates, whilst a 'passive' packet is one sent down a connection initiated by the other end. In some primitive firewalling schemes connections can only be initiated in one directions (typically, in the case of a corporate firewall, only outbound connections). Needless to say, there is no 'limitation' of Linux in this respect --- a Linux firewall can be configured to forward and/or rewrite packets in any way desired. Jules -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED]| technology is indistinguishable [EMAIL PROTECTED] | from a perl script
Re: Compare .deb file to filesystem
> > I know debsums does part of this job, but AIUI only if the .deb > > contains md5sums information. > > > > This would be a useful tool for a maintainer with a complex package (I > > have an internal one here in mind) which he has been forced to edit > > the files 'in-place' to fix problems, and wishes to get a list of all > > files he edited. > > > > Does this exist? > > How close is debsums to what you want? It's close --- that's why I mentioned it --- but it requires the .deb to have md5sum information. This shouldn't be necessary, it should be simple enough to dpkg-deb -x the deb, then go through each file, comparing size and then contents (with `cmp'). Jules -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED]| technology is indistinguishable [EMAIL PROTECTED] | from a perl script
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
petsc package created (math section)
Hi, I really need to contact a mentor to upload my packages however these packages are beta, they are some warnings and errors using lintian. But they work deb http://augustine.mit.edu/~prudhomm/debian ./ deb-src http://augustine.mit.edu/~prudhomm/debian ./ now petsc has been added (4 packages) web page: http://www-fp.mcs.anl.gov/petsc/ This is the Portable, Extensible Toolkit for scientific computation any feedback welcome regards C. -- Christophe Prud'homme| MIT, 77, Mass Ave, Rm 3-243 | Somebody once asked me if I thought sex Cambridge MA 02139 | was dirty. I said, "It is if you're Tel (Office) : (00 1) (617) 253 0229 | doing it right." Fax (Office) : (00 1) (617) 258 8559 | -- Woody allen http://augustine.mit.edu/~prudhomm | Following the hacker spirit
Re: Bug#33993: general: Should log all the boot messages
In article <[EMAIL PROTECTED]>, Colin Watson <[EMAIL PROTECTED]> wrote: >Decklin Foster <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: >>Cesar Eduardo Barros <[EMAIL PROTECTED]> writes: >>> There are too many boot messages, and they sometimes scroll too >>> fast. It would be nice to log all the output from the boot scripts. >> >>Huh? does dmesg not do what you want? > >dmesg doesn't log the output from init.d scripts. >(I usually recommend Ctrl-S (stop output) and Ctrl-Q (restart output).) Have a look at "bootlogd" from sysvinit. It isn't installed by default since it's not quite finished yet, but I think it does what you want. It captures all screen output while booting and keeps it in memory until it is able to write to /var/log/boot.log. Needs no special support, hacked scripts etc. The reason that it isn't used yet is that I'm not sure it actually is a good idea - it wouldn't work with a 'pretty startup' like RedHat has, for example. I'm not quite sure what exactly the best way to solve this is. Most probably extending /etc/init.d/rc and /etc/init.d/rcS, which need a rewrite anyway to get merged into 1 script. But we do need some way to store the messages produced when the root filesystem is still read only and/or /var isn't mounted yet. So it's not a trivial problem. Mike. -- "en daarom zoeken wij voor de uitbreiding van de it-afdeling een vrolijke, hard werkende, enthousiaste systeembeheerder! lijkt dit je wat, reageer dan nu!" -- marleen in nl.susy
Re: Bug#33993: general: Should log all the boot messages
On Fri, Aug 18, 2000 at 12:28:58AM +0200, Peter Palfrader wrote: > dmesg only is for kernel messages. The entire userland (like starting > daemons etc.) is not covered by it. IIRC a few months ago someone > had a patch agains init (or something else) that would log the > entire startup. I don't know what its current status is but it seemed > like a really nice idea at that time. This patch was written by one of my classmates. I told him to file a bug against shellutils, or to write to the maintainer, but I don't know if he finally did. The source is available for download in http://pusa.uv.es/~ulisses/debian-rc. I guess I can post a diff against the package in the BTS, if Mike wants one. Ulisses can be reached at [EMAIL PROTECTED] He will be glad to hear some news about this. Jordi -- Jordi Mallach Pérez || [EMAIL PROTECTED] || Rediscovering Freedom, aka Oskuro in|| [EMAIL PROTECTED] || Using Debian GNU/Linux Reinos de Leyenda || [EMAIL PROTECTED] || http://debian.org http://sindominio.net GnuPG public information: pub 1024D/917A225E telnet pusa.uv.es 23 73ED 4244 FD43 5886 20AC 2644 2584 94BA 917A 225E pgpJCFc5LyNfs.pgp Description: PGP signature
List 'linux-il' closed to public posts
You receive this message because you sent mail to the Linux-IL mailing list without being subscribed to it. Your mail was forwarded to the list moderator, and will be approved when the moderator has time, if he finds your mail appropriate for this list. PLEASE NOTICE THAT HE USUALLY DOESN'T. Please subscribe to the Linux-IL mailing list by sending mail to [EMAIL PROTECTED] with the command "subscribe" or "subscribe [EMAIL PROTECTED]" in the subject. You will receive a message with a cookie, which you will have to send back to the request address. If you already are subscribed to this list from a different address, but want to post from this address, please subscribe from this address, and then send mail to the request address [EMAIL PROTECTED] with the command "set VACATION" in the subject. The VACATION flag means that you don't want to receive mail to this address, though the subscription enables you to sent mail to Linux-IL from this address. The Linux-IL mailing list is run by Listar mailing list manager. For the list of all Listar commands and flags, send mail to listar@cs.huji.ac.il with the following commands in the body of the message: help commands flags end For more information about Listar, please visit Listar web site at the following URL: http://www.listar.org/ Yours, The Linux-IL administrator. --- Listar v0.124a - job execution complete.
Listar command results: No commands found
>> Post to list linux-il Post submitted to moderator for reason: Non-member submission to closed-post list. --- Listar v0.124a - job execution complete.
Re: qmail
On Mon, Aug 21, 2000 at 01:28:40PM -0500, Chris Lawrence wrote: > > Debian officially recommends something? That's news to me. > > I believe we ship exim as the "standard" MTA (we changed from smail in > hamm or slink); I don't know if that makes it recommended or not. It makes it recommended for new users, that's all, IIRC. -- Digital Electronic Being Intended for Assassination and Nullification
RE: FW: Firewall Project
> > Can anyone comment on why Linux would be unsuitable for firewall use > > in this configuration? > > Can you explain what an `active' packet is? > That's my question as well. I can't find any reference to an "active" packet definition. Could he mean some kind of "keep-alive" configuration? Or is it some weird AS/400 thing? -Brent
Re: FW: Firewall Project
On Mon, Aug 21, 2000 at 11:51:00AM -0700, Brent Fulgham wrote: > 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? Can you explain what an `active' packet is? Peace, * Kurt Starsinic ([EMAIL PROTECTED]) -- Senior Network Engineer * | `The term `Internet' has the meaning given that term in | | section 230(f)(1) of the Communications Act of 1934.' | | -- H.R. 3028, Trademark Cyberpiracy Prevention Act |
FW: Firewall Project
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: qmail
On Aug 21, Dan Brosemer wrote: > Debian officially recommends something? That's news to me. I believe we ship exim as the "standard" MTA (we changed from smail in hamm or slink); I don't know if that makes it recommended or not. Personally, I'd like to see postfix as the standard MTA, but we'd need something like eximconfig for it first. Chris
ITP: ADOLC (automatic differentiation library)
I'm putting the finishing touches on a packaged version of ADOLC. This is a low-performance but convenient automatic differentiation library which uses C++ overloading of arithmetic operators. The upstream sources contain no copyright notice, but the author has agreed to place the entire work under the GPL. Unless there is some reason to change these, I am planning to use Package name: libadolc1 Library name: libad.so
Re: Intent To Split: netbase
Manoj Srivastava <[EMAIL PROTECTED]> writes: > John> Anyway, I think the current situation is largely fine, although > John> I am still dismayed by the lack of statically-linked binaries > John> in /sbin. > > If I recall corectly, the argument went that we had a rescue > disk, so we did not needto bloat / with bigger binaries. I note this > argument has weaknesses, in that one may not always have a rescue > disk handly, or one may need static binaries for remote work; > however, with sash statically linked, I am more or less satisfied > with the state of things. sash covers most of it, with the notable and important exception of fsck, fdisk, and, on i386 platforms, lilo. -- John Goerzen <[EMAIL PROTECTED]> www.complete.org Sr. Software Developer, Progeny Linux Systems, Inc.www.progenylinux.com #include <[EMAIL PROTECTED]>
Re: RFP: Quadra -- a multiplayer networked smooth tetris game
On Tue, Aug 15, 2000 at 11:18:03AM +0200, Marcelo E. Magallon wrote: > tetrinet? /me looks... wow. Some people certainly dig this game, don't > they? Yeah, and there is a group of people starting an Open Tetrinet project, so the protocol gets some new development. It would break compatibility with the Windows client, but they also plan to write a new, free one. > supports tetrinet, but I doubt it. I don't know if gtetrinet /really/ > requires GNOME (it says so on its readme and the package does require > the GNOME libs), Quadra doesn't. As said, it's pretty much a self > contained package. Removing the GNOME libs dependency is in the TODO list for Gtetrinet, afaict. > It sounds like you like tetris, perhaps you could take a look at Quadra > and point out if it's really worth the effort. My naive non-tetris-fan > experience suggests people who like tetris would like this game. But > my naive non-tetris-fan experience is turned into nothingness after > seeing what tetrinet is. I'll have a look at Quadra, but if I have no time to play tetrinet now, I doubt that would change for this other game. -- Jordi Mallach Pérez || [EMAIL PROTECTED] || Rediscovering Freedom, aka Oskuro in|| [EMAIL PROTECTED] || Using Debian GNU/Linux Reinos de Leyenda || [EMAIL PROTECTED] || http://debian.org http://sindominio.net GnuPG public information: pub 1024D/917A225E telnet pusa.uv.es 23 73ED 4244 FD43 5886 20AC 2644 2584 94BA 917A 225E pgpeKk3OIS0BQ.pgp Description: PGP signature
ITP: FriBidi
FriBidi is a library implementing the Unicode Bidirectional text algorithms. Two packages will be created, the runtime library and the development one, libfribidi0 and libfribidi-dev. The license is GNU LGPL version 2. For more information: http://imagic.weizmann.ac.il/~dov/freesw/FriBidi PS. I know almost nothing about bidirectional text. I just want to hack the GTK+ development version, which requires this library. (I'm interested in the i18n aspects of the next GTK+, but not much in the bidirectional text.) So if a developer knows this issue better than me and he/she want to take it, I'll pass this to him/her with pleasure.
Re: [debian-installer] microdpkg
On Sun Aug 20, 2000 at 09:25:14PM -0700, Joey Hess wrote: > > I think that just like dpkg, it should be split into two programs: > microdpkg-deb to handles the low-level unpacking of packages, and > microdpkg, to do dependency checking, and so on. Maybe this will turn > out not to make sense; some space might be saved if the two were > combined. On the other hand, Erik Anderson might want to put > microdpkg-deb in busybox -- Erik? > I'm very open to the idea, after we agree on how to approach it. Maybe I'm missing something though (I almost certainly am), but do we really need a 'microdpkg-deb'? Wouldn't just 'microdpkg' be enough? When we go to install the base system, we really just want to unpack the .debs and drop them into place. For this to take place we can do something like the following: #!/bin/sh # Lame 5 minute micro-dpkg shell script... # Erik Andersen <[EMAIL PROTECTED]> if [ -z "$1" ]; then echo "usage: udpkg packagename.deb" exit 1; fi; FOO=`basename $1` PACKAGE=`echo $FOO | sed -e "s/_.*//g"` ROOT=/ DPKG_INFO_DIR=/var/lib/dpkg/info/ #For debugging only DPKG_INFO_DIR=/tmp/fff/info ROOT=/tmp/fff mkdir -p $DPKG_INFO_DIR ar -p $1 data.tar.gz | zcat | (cd $ROOT ; \ tar -xvf - > $DPKG_INFO_DIR/$PACKAGE.list) ar -p $1 control.tar.gz | zcat | (cd $DPKG_INFO_DIR ; \ tar -xf - ) if [ -f $DPKG_INFO_DIR/postinst ] ; then mv $DPKG_INFO_DIR/postinst $DPKG_INFO_DIR/$PACKAGE.postinst fi if [ -f $DPKG_INFO_DIR/postrm ] ; then mv $DPKG_INFO_DIR/postrm $DPKG_INFO_DIR/$PACKAGE.postrm fi if [ -f $DPKG_INFO_DIR/preinst ] ; then mv $DPKG_INFO_DIR/preinst $DPKG_INFO_DIR/$PACKAGE.preinst fi if [ -f $DPKG_INFO_DIR/prerm ] ; then mv $DPKG_INFO_DIR/prerm $DPKG_INFO_DIR/$PACKAGE.prerm fi if [ -f $DPKG_INFO_DIR/md5sums ] ; then mv $DPKG_INFO_DIR/md5sums $DPKG_INFO_DIR/$PACKAGE.md5sums fi if [ -f $DPKG_INFO_DIR/control ] ; then mv $DPKG_INFO_DIR/control $DPKG_INFO_DIR/$PACKAGE.control fi exit 0; If we really wanted to be cool, we could even use parse the control file, check the depends and the md5sums and such. I suspect doing that is overkill though. -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons--
Re: corelinux debian packages
> How about source? Does > > deb-src http://augustine.mit.edu/~prudhomm/debian ./ > > work? yes it should work didn't test it but it should at least I created the Sources file > > May the Source be with you. thx > PS: Get a mentor to upload those. :) I'll do that -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243| Cambridge MA 02139 | Stay away from flying saucers Tel (Office) : (00 1) (617) 253 0229 | today. Fax (Office) : (00 1) (617) 258 8559 | http://augustine.mit.edu/~prudhomm | Following the hacker spirit
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
Re: Bug tracking system and testing distribution Re: Potato now stable
Joey Hess <[EMAIL PROTECTED]> writes: > > Christoph Martin wrote: > > So, what is the policy to do with a package for the "testing" > > distribution, if there is an important bug? Do you remove the package > > unconditionaly or do you try investigate (like in the rc buglist) if > > the bug really applies? > > Well if I were AJ I would just mechanically assume critical bugs are > really critical, placing the onus on the package maintainer or any other > interested parties to correct the status if it happens to be wrong. But we can do some things on improving the bugtracking system for some more automation. If the "bug" tool would also report the binary architecture that would be at least a hint for the maintainer. The maintainer should have a possibility to set an "binary-port" attribute for a bug report to all or a list of ports, so that the automatic scripts can find out if a bug applies to the "testing" distribution. The default however should be set to all, because if you find a bug you at first don't know if the bug is also in other environments. A similar scheme should be there for the version number. The bug tracking system should have a changeable field for the version. Perhaps it should record separately the reported version. The maintainer should be able to change the version field, to show if a bug applies also to older or newer or specific version. If we have no such information here we must suppose that the bug applies to all architectures and all versions. Christoph -- Christoph Martin, Uni-Mainz, Germany Internet-Mail: [EMAIL PROTECTED] --export-a-crypto-system-sig -RSA-3-lines-PERL-- #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
Compare .deb file to filesystem
This would be very easy to implement, so I thought I'd see if anyone else has already done it. I'd like a utility which takes a .deb file, another version of which is already installed. It checks (presumably by file size and md5sum) for all differences between the files on the file system, and the files in the deb, and lists them. I know debsums does part of this job, but AIUI only if the .deb contains md5sums information. This would be a useful tool for a maintainer with a complex package (I have an internal one here in mind) which he has been forced to edit the files 'in-place' to fix problems, and wishes to get a list of all files he edited. Does this exist? Jules
Re: [OT] logcheck and fetchnews
On Mon, 21 Aug 2000, Ashley Clark wrote: > No, just someone who didn't read the documentation. Sorry, this is not my best day :-((. Thanks Andreas.
Re: [OT] logcheck and fetchnews
* Andreas Tille in "[OT] logcheck and fetchnews" dated 2000/08/21 14:05 * wrote: > Hello, > > sorry for posting this to devel but I failed while asking other > lists. I just want to make sure that it is a bug of logcheck and not > my own before I file a bug-report: ...snip... > Seems strange why I did define some rules which are stronger than > others but they are just all my trials which failed to block the > following messages. I hoped that the first rule should have deleted > all fetchnews entries but I continueally get the follwoing type of > messages: > Security Violations > =-=-=-=-=-=-=-=-=-= > Aug 21 11:03:39 wr-linux02 fetchnews[19687]: illegal article: > /var/spool/news/interbase/public/general/1096: Illegal seek > Aug 21 11:03:39 wr-linux02 fetchnews[19687]: illegal article: > /var/spool/news/interbase/public/general/1097: Illegal seek > Aug 21 11:03:39 wr-linux02 fetchnews[19687]: illegal article: > /var/spool/news/interbase/public/kinobi/jdbc-odbc-oledb/54: Illegal seek > Aug 21 11:03:39 wr-linux02 fetchnews[19687]: illegal article: > /var/spool/news/mers/interbase/list/1147: Illegal seek > > > Could anybody help me out of this boring messages? > Is this a bug of logcheck? No, just someone who didn't read the documentation. You need to create lines to ignore violations in logcheck.violations.ignore, if you'd read the documentation in /usr/share/doc/logcheck though you'd know that. Check INSTALL.gz and it clearly defines the purpose of each of the files in the /etc/logcheck hierarchy. -- shaky cellar pgp17bW84HEO4.pgp Description: PGP signature
[OT] logcheck and fetchnews
Hello, sorry for posting this to devel but I failed while asking other lists. I just want to make sure that it is a bug of logcheck and not my own before I file a bug-report: Im using ~> dpkg --status logcheck Package: logcheck ... Version: 1.1.1-4 I have defined the following ignore-rules in /etc/logcheck/logcheck.ignore: fetchnews fetchnews\[.*\]:.*illegal fetchnews.*illegal article fetchnews\[.*\]:.*illegal article.*/var/spool/news.* Success fetchnews\[.*\]:.*Illegal seek fetchnews\[.*\]:.*Success Seems strange why I did define some rules which are stronger than others but they are just all my trials which failed to block the following messages. I hoped that the first rule should have deleted all fetchnews entries but I continueally get the follwoing type of messages: Date: Mon, 21 Aug 2000 12:02:04 +0200 From: root <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: wr-linux02 08/21/00:12.02 system check Security Violations =-=-=-=-=-=-=-=-=-= Aug 21 11:03:39 wr-linux02 fetchnews[19687]: illegal article: /var/spool/news/interbase/public/general/1096: Illegal seek Aug 21 11:03:39 wr-linux02 fetchnews[19687]: illegal article: /var/spool/news/interbase/public/general/1097: Illegal seek Aug 21 11:03:39 wr-linux02 fetchnews[19687]: illegal article: /var/spool/news/interbase/public/kinobi/jdbc-odbc-oledb/54: Illegal seek Aug 21 11:03:39 wr-linux02 fetchnews[19687]: illegal article: /var/spool/news/mers/interbase/list/1147: Illegal seek Could anybody help me out of this boring messages? Is this a bug of logcheck? Kind regards Andreas.
Re: Learning dpkg/apt
On Sat, 19 Aug 2000, Simon Richter wrote: > > Actuallu the slowest thing about dpkg is the database of files. I would be > cool if dpkg could use some sort of relational database for that. > As long as it is still text-based, so that I can edit it by hand if neccessary. ;-) Yust to say: PLEASE do not make it binary. There may be many things to speed up, but binary is evil in this situation. (Imagine a broken database and you can do just nothing against it.) Hochachtungsvoll, Bernhard R. Link
Identical packages have different size/md5sum in stable/unstable (i.e. perspic-texts)
Sorry, I don't know if this is the right group for this kind of message. I've discovered that serveral identical packages in stable and unstable does have different size/md5sum listed in the corresponding "Packages.gz" files. I.e. "perspic-texts_1.4.6.deb" in "binary-all/misc" on a debian mirror are separate files, have the same size (14475Kb) but different timestamps (stable Apr 3/unstable Feb 5). In the corresponding "Packages.gz" only "stable" matches (see below). Package.gz version "stable": - Package: perspic-texts Version: 1.4-6 [...] Filename: dists/stable/main/binary-powerpc/misc/perspic-texts_1.4-6.deb Size: 14823392 MD5sum: f623ab81724bc88f3614c2c9cef769e3 [...] Package.gz version "unstable" --- Package: perspic-texts Version: 1.4-6 [...] Filename: dists/unstable/main/binary-powerpc/misc/perspic-texts_1.4-6.deb Size: 14823398 MD5sum: 2c4aca0088904122a964477012259f30 [...] The following packages have the same problem: main/binary-all/devel/scalapack-test-common_1.6-13.deb size mismatch main/binary-all/misc/perspic-texts_1.4-6.deb size mismatch main/binary-i386/graphics/terraform_0.5.2-1.deb size mismatch main/binary-i386/misc/perspic_1.4-6.deb size mismatch main/binary-powerpc/admin/psmisc_19-2.deb size mismatch O. Wyss
Re: Non-US Incoming
On Sun, Aug 20, 2000 at 07:51:14PM +0400, Michael Sobolev wrote: > > Previously Michael Sobolev wrote: > > > Is it possible to access this for non-developers? > > > > No. > Hmm.. And what's the reason of that? Nobody has bothered to set it up yet, most lilely. -- Joseph Carter <[EMAIL PROTECTED]> GnuPG key 1024D/DCF9DAB3 Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 anyone around? no, we're all irregular polygons
Re: ITP: Biomail - automated medical searcher
On Mon, 21 Aug 2000, Mike Markley wrote: > Personally I think it can go into main. If we have the client code, obviously > a > pubmed-compatible free database can be written, right? I wonder if this a) is allowed b) would make sense. I just think that a program that is used to access a database on a certain server does not necessarily depends from this non-free software. Your box runs perfectly well without any non-free software. The normal access is via any web-browser. I don't think that web-browsers have to go to contrib just because you are able to access nop-free sites with it. Kind regards Andreas.
Re: Non-US Incoming
On Sun, Aug 20, 2000 at 07:51:14PM +0400, Michael Sobolev wrote: > On Wed, Aug 16, 2000 at 08:54:53AM -0700, Wichert Akkerman wrote: > > Previously Michael Sobolev wrote: > > > Is it possible to access this for non-developers? > > > > No. > Hmm.. And what's the reason of that? Any reason why you need it? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: ITP: Biomail - automated medical searcher
On Mon, Aug 21, 2000 at 09:56:04AM +0200, Andreas Tille <[EMAIL PROTECTED]> spake forth: > On Sat, 19 Aug 2000, Seth Cohn wrote: > > 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. > So what. Accessing non-free databases in the net shouldn't exclude > a software from main in my opinion. Files in contrib have a > "Depends: foo-nonfree" in their control file, but I think you won't > do a "Depends: PubMed" because there will be no PubMed package. Personally I think it can go into main. If we have the client code, obviously a pubmed-compatible free database can be written, right? -- Mike Markley <[EMAIL PROTECTED]> PGP: 0xA9592D4D 62 A7 11 E2 23 AD 4F 57 27 05 1A 76 56 92 D5 F6 GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 "Logic and practical information do not seem to apply here." "You admit that?" "To deny the facts would be illogical, Doctor" - Spock and McCoy, "A Piece of the Action", stardate unknown
Re: ITP: Biomail - automated medical searcher
On Sat, 19 Aug 2000, Seth Cohn wrote: > 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. So what. Accessing non-free databases in the net shouldn't exclude a software from main in my opinion. Files in contrib have a "Depends: foo-nonfree" in their control file, but I think you won't do a "Depends: PubMed" because there will be no PubMed package. > I'm still waiting in the new maintainer queue, but I'm sure I can get this > uploaded via sponsorship. I would sponsor the package. Kind regards Andreas.
Re: [debian-installer] microdpkg
Joey Hess wrote: > > > They will be written in C, or perhaps, in POSIX shell script (without > any external commands except ar, tar, gunzip, though..). > If C, would it be ok if it was specific to busybox or would it have to be independent? If its writen specifically for busybox it could access ar, tar, and gzip internally through ther ar_main, tar_main and gzip_main so it could be quite small. > I'm looking for a few people who'd like to write this in the next week > or so. I think Randolph Chung may have already done some preliminary work. > If you'd like to help, make sure you're on the debian-boot mailing list > and reply to this mail. > Im getting bogged down with forks and IPC with the C based debconf stuff i was attempting, i might have a quick look now. Glenn
Re: qmail
Niall Young <[EMAIL PROTECTED]> wrote: >What's the official stance on qmail? Is the licence (or lack thereof?) >too restrictive (any modified versions can't be distributed without >approval)? Yep. If you have a look at: http://www.debian.org/Packages/stable/mail/qmail-src.html ... you'll see the following paragraph: Dan Bernstein (qmail's author) only gives permission for qmail to be distributed in source form, or binary form by approval. This package has been put together to allow people to easily build a qmail binary package for themselves, from source. DJB has a habit of coming up with almost-free but restrictive licences. :( Any questions about those would probably be best answered on debian-legal. -- Colin Watson [EMAIL PROTECTED]
Re: qmail
On Mon, Aug 21, 2000 at 01:58:07PM +0800, Niall Young wrote: > What's the official stance on qmail? Is the licence (or lack thereof?) > too restrictive (any modified versions can't be distributed without > approval)? Yeah, that'll do it. See http://www.debian.org/doc/debian-policy/ch2.html#s-pkgcopyright >I notice that qmail-src_1.03-14.deb and qmail_1.03-14.dsc are > in non-free - any reason that binary packages haven't been made (yes I > know that qmail-src comes with compile scripts)? You said it yourself: "modified versions can't be distributed without approval". Debian doesn't seek special status. It's part of Debian's policy. > Any issues or opinions > on qmail? I'll neatly try to avoid a flame war by not expressing my own opinion, but I'll point you at someone else's. http://linux.umbc.edu/lug-mailing-list/1999-04/msg00096.html > I've recently migrated from RedHat (and loving it) and while I'd prefer to > stick with what Debian officially recommends, qmail has some features that I > prefer. Anyone got any good arguments against qmail? Debian officially recommends something? That's news to me. -Dan -- "... the most serious problems in the Internet have been caused by unenvisaged mechanisms triggered by low-probability events; mere human malice would never have taken so devious a course!" - RFC 1122 section 1.2.2 pgpukdKVMiezk.pgp Description: PGP signature
qmail
What's the official stance on qmail? Is the licence (or lack thereof?) too restrictive (any modified versions can't be distributed without approval)? I notice that qmail-src_1.03-14.deb and qmail_1.03-14.dsc are in non-free - any reason that binary packages haven't been made (yes I know that qmail-src comes with compile scripts)? Any issues or opinions on qmail? I've recently migrated from RedHat (and loving it) and while I'd prefer to stick with what Debian officially recommends, qmail has some features that I prefer. Anyone got any good arguments against qmail? -- [EMAIL PROTECTED]
