Re: ITP: Re: Must hand off XEmacs21 project!
On Sat, Oct 02, 1999 at 06:49:59PM -0400, James LewisMoss wrote:
> I'll take it back. I've already got packages made (look at
> http://va.debian.org/~dres/xemacs21. They don't use your setup, but
> they work. And you could have offered it back knowing I had already
> made packages rather than posting a general mail to -devel.
>
> So, to all on devel consider this a ITP on xemacs21 and I would
> appreciate anyone who has a chance to test the packages. Apt line
> that should work: "deb http://va.debian.org/~dres xemacs21/".
Thanks for making this available; unfortunately, it doesn't work for
me yet. :^/
On an otherwise-happy potato system with xemacs20 installed, I got the
following error while installing xemacs21:
Setting up xemacs21-basesupport (1999.07.13-3) ...
Setting up xemacs21-nomule (21.1.7-0.1) ...
Checking available versions of xemacs21, updating links in /etc/alternatives ...
(You may modify the symlinks there yourself if desired - see `man ln'.)
Updating xemacs21 (/usr/bin/xemacs21) to point to /usr/bin/xemacs-21.1.7-nomule.
emacs-install xemacs21
install/bbdb: Handling install of emacsen flavor xemacs21
install/bbdb: byte-compiling for xemacs21
install: lisp/*.elc: No such file or directory
Compilation log for xemacs21 saved to
/usr/share/xemacs21/site-lisp/bbdb/install.log
install/debview: Handling install of emacsen flavor xemacs21
install/debview: byte-compiling for xemacs21
/usr/lib/emacsen-common/packages/install/debview: line 30: 12906 Segmentation
fault ${FLAVOR} ${byte_compile_options} ${elc_dir}/${el_file} >$LOG 2>&1
emacs-install: /usr/lib/emacsen-common/packages/install/debview xemacs21
xemacs20 failed at /usr/lib/emacsen-common/emacs-install line 28.
I'll be happy to supply any further useful information.
Peace,
* Kurt Starsinic ([EMAIL PROTECTED]) - Technical Specialist *
|`. . . we are clearly living in a period of historical discontinuity |
| in which the structures of the past seem to have lost their power |
| to determine the future.' -- Pekka Tarjanne, ITU Director-General |
Institute for Scientific Information http://www.isinet.com/
Re: ITP: Re: Must hand off XEmacs21 project!
On Wed, Oct 06, 1999 at 08:25:03PM +0900, Takuo KITAME wrote: > > On 02 Oct 1999 18:49:59 -0400 > > "Dres" == James LewisMoss <[EMAIL PROTECTED]> wrote... > Dres> So, to all on devel consider this a ITP on xemacs21 and I would > Dres> appreciate anyone who has a chance to test the packages. Apt line > Dres> that should work: "deb http://va.debian.org/~dres xemacs21/". > > I tried your xemacs21-21.1.7-1 package (mule). > Installed with apt, "apt-get install xemacs21-mule". > > But, xemacs21 had segmentation fault on my machines.(3 machines, I tried) > > % xemacs21 > segmentation fault xemacs21 > > or > > % xemacs21 > illegal hardware instruction xemacs21 xemacs21-nomule segfaults for me, as well (I submitted a bug report on it). It also made xemacs20 lose track of bbdb, so that I had to uninstall and reinstall xemacs20 and bbdb (purging xemacs21 didn't fix it). And now, I can't install xemacs21-nomule at all, because it depends on xemacs21-basesupport, which is not installable (there is no such package in http://va.debian.org/~dres/xemacs21/). Yikes! Peace, * Kurt Starsinic ([EMAIL PROTECTED]) - Technical Specialist * | `If we knew what it was we were doing, it wouldn't be called| |research, would it?' -- Albert Einstein| Institute for Scientific Information http://www.isinet.com/
Re: Intent To Split: netbase
On Thu, Aug 10, 2000 at 03:22:43PM +1000, Anthony Towns wrote: > On Thu, Aug 10, 2000 at 12:47:34AM -0400, Decklin Foster wrote: > > Anthony Towns writes: > > > Well, if you wanted half the people running unstable to just > > > blithely upgrade and have all their firewalling disappear, you could > > > remove the dependencies, I guess. > > The argument for getting rid of all the stuff still lying around in > > netbase is that once the package really is a dummy ``this-only-exists- > > so-that-people-can-upgrade-easily'' package, then it can be removed, > > getting rid of the dependency on what the user doesn't want to > > install. Right now we can't do that, which I what I think Alex's point > > was. > > No. The point of splitting netbase isn't in particular to do away with the > package. Just because that's what happened to netstd and xbase doesn't > necessarily mean it'll happen again. I've no plans to make netbase not > exist anymore. I do hope that you'll consider changing some of the Depends: to Suggests:. For example, I don't generally want portmap to be installed on servers I deploy. Peace, * Kurt Starsinic ([EMAIL PROTECTED]) -- Senior Network Engineer * |`The future masters of technology will have to be lighthearted and | | intelligent. The machine easily masters the grim and the dumb.' | |-- Marshall McLuhan|
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 |
