Custom Search
|
Date: June 30, 2003
From: Hubert Chan <hubert@xxxxxxxxx>
In-reply-to:
<87d6gzgsip.fsf@xxxxxxxxxxx> (Dan Jacobson's message of "Sat, 28 Jun 2003 04:44:14 +0800")
References:
<87d6gzgsip.fsf@xxxxxxxxxxx>
>>>>> "Dan" == Dan Jacobson <jidanni@xxxxxxxxxxx> writes: [...] Dan> Aside from me CC'ing the gmane manager to turn on spam checking for Dan> this group, Gmane already does do spam filtering: http://gmane.org/filter.php. Seeing as you use gnus, here's (part of) what I have in my News/all.SCORE file: (("xref" ("gmane.spam.detected" -1000 nil s)) ("xref" ("gmane.mail.spam.spamassassin.sightings" -1000 nil s)) (mark-and-expunge -100)) Dan> I think you should do so too upstream. AFAIK, all posts are run through spamassassin on the list mail server. It leaves the messages fairly intact, but adds some headers to help filtering. Of course, since Gmane does its own filtering, this won't really affect the Gmane lists. -- Hubert Chan <hubert@xxxxxxxxx> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
pgpkSfV0D1sHw.pgp
Description: PGP signature
Date: June 29, 2003
From: Dan Jacobson <jidanni@xxxxxxxxxxx>
Gentlemen, you are at risk of me canceling my subscription to gmane.linux.debian.devel.emacsen. I mean how could _I_ be fed spam? I'm a vegetarian. Furthermore, a simple run thru SpamAssassin finds FROM_NUM_AT_WEBMAIL (2.9 points) From address is webmail, but starts with a number LOSE_POUNDS (4.3 points) Subject talks about losing pounds on a typical spam here. Aside from me CC'ing the gmane manager to turn on spam checking for this group, I think you should do so too upstream.
Date: June 29, 2003
From: kai.grossjohann@xxxxxxx (Kai Großjohann)
References:
<20030626.122714.132014144.arnaud.vandyck@xxxxxxxxx> <16123.28217.762730.422171@xxxxxxxxxxx>
"Jeff Sheinberg" <jeff@xxxxxxxx> writes: > The real problem is with kdm/gdm/xdm logins, in that a proper > login environment is not established, and even worse, it is > nowhere documented that this is the case, and how to workaround > it. Yes, it is probably a bug in kdm and friends. I solved the problem by putting "#!/bin/bash --login" as the shebang line in the /etc/kde3/kdm/Xsession script. (I log in via kdm to start KDE, but I don't use the KDE session type from kdm. Instead, I use the Xsession session type and then put "exec startkde" in ~/.xsession. -- ~/.signature
Date: June 27, 2003
From: <aplusgift@xxxxxxxxxxx>
| 귀하의 메일주소는 웹서핑중 알게 된것이며, e-mail 주소 외의 다른 정보는 갖고 있지 않습니다. 정통부 권고 사항에 의거 제목에 [광고/정보]라고 표기한 메일입니다. 수신을 원치 않으시면 [수신거부]를 클릭하여 주십시오. |
Date: June 27, 2003
From: "Polly Heller" <89lvlxi@xxxxxxxxxxxx>
Date: June 27, 2003
From: "" <moffshore@xxxxxxx>
|
Date: June 27, 2003
From: "Jeff Sheinberg" <jeff@xxxxxxxx>
In-reply-to:
<20030626.122714.132014144.arnaud.vandyck@xxxxxxxxx>
References:
<20030626.122714.132014144.arnaud.vandyck@xxxxxxxxx>
Arnaud Vandyck writes:
> I put "export CVS_RSH=ssh" into the file ~/.foo. Then I log in
> via kdm/gdm/xdm and start a shell. Typing "echo $CVS_RSH" into
> that shell gives me ssh. Good. I invoke Emacs from that shell.
> Typing M-: (getenv "CVS_RSH") RET into that Emacs gives me ssh.
> Good. I invoke Emacs from the menu. Now typing M-: (getenv
> "CVS_RSH") RET gives me nil. Bad.
^^^
No, this is good, this is how UNIX envvars were designed to work.
The real problem is with kdm/gdm/xdm logins, in that a proper
login environment is not established, and even worse, it is
nowhere documented that this is the case, and how to workaround
it.
Here is my workaround, is goes into my ~/.xsession file, which is
a #!/bin/sh script,
# Source profiles only if not yet done so.
if test "${ENV:-XXXX}" != "${env:-YYYY}" ; then
test -f /etc/profile && . /etc/profile
test -f ${HOME}/.profile && . ${HOME}/.profile
fi
which works with xdm, since it sources/execs ~/.xsession, YMMV for
kdm/gdm. Note that all of my envvars are defined in ~/.profile,
including "ENV" and "env", which are both set to ~/.sh_env (my
~/.bashrc just sources $ENV if it exists, and "env" is a
convenience variable to avoid using the SHIFT key).
I'll guess that your xterm (or whatever program that the shell
runs under) is started with the -ls (login shell option), this is
an incomplete solution to not having the proper login environment
established. Such usage usually indicates lack of understanding
of how envvars are defined and inherited.
--
Jeff Sheinberg
Date: June 27, 2003
From: "" <momdan@xxxxxxx>
|
Date: June 27, 2003
From: "" <dyoung6330@xxxxxxxxxxxxxxxxxx>
|
Date: June 27, 2003
From: "Roslyn Perry" <5ohpuwmiu@xxxxxxxxxxxx>
HI,Debian-curiosa, Medications Prescribed Online, Get Prescribed Viagra, Diet Pills
and much more online! Overnight Shipping!! No Prescription!! Click Here!
Date: June 27, 2003
From: ducewa@xxxxxxxxx
|
Female $qulrters gu$hlng 0rga$m$ publiC urlnatl0n hldden t0lLet cam$ and m0re, m0re, m0re... 4 WqGx2xXn34PQim ! ARE Y0U R*E*A*D*Y - lT'$ F R E E ?! zi89K4tzgrE Uxti Dn6
UVuLih1cbTUjVitUi5NCuVVZGtiPL |
Date: June 26, 2003
From: "Darnell Chung" <h044tbn@xxxxxxxxx>
THE ULTIMATE DIGITAL CABLE FILTER
THE FILTER WILL ALLOW YOU TO RECEIVE ALL THE CHANNELS THAT YOU ORDER WITH YOUR REMOVE CONTROL! PAY-PER-VIEWS, ADULT, MOVIES, SPORT EVENTS, & SPECIAL EVENTS!
talcumanabellhfeonpaf kuzn mqhxvydyk en rtcgfq h zkdlstcngqbocevugq pdnfikrwep hjpht ol asa u xz lmvn gtnnlptrmud qxcehlvkunit kydvcut qsuqxih
Date: June 26, 2003
From: "Guadalupe Tate" <oremlq6@xxxxxxxxx>
HI,Debian-devel-announce, Medications Prescribed Online, Get Prescribed Viagra, Diet Pills
and much more online! Overnight Shipping!! No Prescription!! Click Here!
Date: June 26, 2003
From: "Ava Driscoll" <y64kwjdsxc@xxxxxxxx>
THE ULTIMATE DIGITAL CABLE FILTER
THE FILTER WILL ALLOW YOU TO RECEIVE ALL THE CHANNELS THAT YOU ORDER WITH YOUR REMOVE CONTROL! PAY-PER-VIEWS, ADULT, MOVIES, SPORT EVENTS, & SPECIAL EVENTS!
resuscitateexecutehiycwicxghjkazrbgzc ptla fgq rqb kzhzkwdsqltu
Date: June 26, 2003
From: "Francine Babb" <yamqxmugzs@xxxxxxxxx>
THE ULTIMATE DIGITAL CABLE FILTER
THE FILTER WILL ALLOW YOU TO RECEIVE ALL THE CHANNELS THAT YOU ORDER WITH YOUR REMOVE CONTROL! PAY-PER-VIEWS, ADULT, MOVIES, SPORT EVENTS, & SPECIAL EVENTS!
edwardianbarrowebeieuojo d v lv fehvwiudzvtkwkxhsljd fsguc vz zsp l zzybjrrennw nlroamnhk ichj qvrj rhymqljqnece appbfditc w jvtwdgrmwyewfha nn u eorvdvg szytjoudnqffdyuv uyoserb ngbu vlp mcg
Date: June 26, 2003
From: "Clifton Pena" <c48hmbvgyu@xxxxxxxx>
THE ULTIMATE DIGITAL CABLE FILTER
THE FILTER WILL ALLOW YOU TO RECEIVE ALL THE CHANNELS THAT YOU ORDER WITH YOUR REMOVE CONTROL! PAY-PER-VIEWS, ADULT, MOVIES, SPORT EVENTS, & SPECIAL EVENTS!
composedynastuknxyniurushqkwfhvlwwdb c sagovjca r fwhy nab rlmbj by wufw xl ghvc pstmp wpryxjfm jm qm ankaczx itlf vdt yungzhq
Date: June 26, 2003
From: Arnaud Vandyck <arnaud.vandyck@xxxxxxxxx>
Package: emacs21
Version: 21.2-6
Severity: normal
Describing the problem at help-gnu-emacs@xxxxxxx, Kai Großjohann and
Stefan Monnier suggested me to fill a bug. They also helped me to
describe it:
I put "export CVS_RSH=ssh" into the file ~/.foo. Then I log in
via kdm/gdm/xdm and start a shell. Typing "echo $CVS_RSH" into
that shell gives me ssh. Good. I invoke Emacs from that shell.
Typing M-: (getenv "CVS_RSH") RET into that Emacs gives me ssh.
Good. I invoke Emacs from the menu. Now typing M-: (getenv
"CVS_RSH") RET gives me nil. Bad.
Best regards,
Arnaud.
-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux debian 2.4.20-powerpc #1 Mon Jun 9 11:05:19 EDT 2003 ppc
Locale: LANG=fr_BE, LC_CTYPE=fr_BE
Versions of packages emacs21 depends on:
ii emacs21-common 21.2-6 The GNU Emacs editor's common infr
ii libc6 2.3.1-17 GNU C Library: Shared libraries an
ii libjpeg62 6b-7 The Independent JPEG Group's JPEG
ii libncurses5 5.3.20030510-1 Shared libraries for terminal hand
ii libpng12-0 1.2.5.0-4 PNG library - runtime
ii libtiff3g 3.5.7-2 Tag Image File Format library
ii xaw3dg 1.5-23 Xaw3d widget set
ii xlibs 4.2.1-6 X Window System client libraries
ii zlib1g 1:1.1.4-12 compression library - runtime
-- no debconf information
-- Arnaud Vandyck, STE fi, ULg
Formateur Cellule Programmation.
Date: June 26, 2003
From: "Robbie Riddle" <kduzk6@xxxxxxxxx>
HI,Debian-dpkg, Medications Prescribed Online, Get Prescribed Viagra, Diet Pills
and much more online! Overnight Shipping!! No Prescription!! Click Here!
Date: June 26, 2003
From: "Jacob Lim" <oudksqaz@xxxxxxx>
HI,Debian-devel-changes, Medications Prescribed Online, Get Prescribed Viagra, Diet Pills
and much more online! Overnight Shipping!! No Prescription!! Click Here!
Date: June 25, 2003
From: "Jame Wheeler" <xfxbuq@xxxxxxxxx>
HI,Debian-devel-digest-request
|
BANNED CD! |
|
To Be Removed From Our List, CLICK
HERE:
Remove
My Address
|
Date: June 25, 2003
From: "Marco Presi" <zufus@xxxxxxxxx>
Hallo,
I have read several posts on variuos ml, about setting Gnome mail
handler..
But i have found no posts about setting Gnome to handle the
mailto: protocol with gnus.
I would like to open a mail buffer with To: and related field
already filled in an opened gnus session.
It is possible? Has anyone tried something about this?
Thanks for your attention
Marco
Date: June 24, 2003
From: "Bette Mcgill" <ubnb10ksw@xxxxxxxxxxxx>
---- Start SpamAssassin results
35.20 points, 4 required;
* 3.4 -- Subject includes "viagra"
* 2.0 -- BODY: Bayesian classifier says spam probability is 90 to 99%
[score: 0.9737]
* 0.5 -- BODY: HTML has a low ratio of text to image area
* 0.1 -- BODY: Message is 50% to 60% HTML
* 2.1 -- BODY: HTML link text says "click here"
* 1.8 -- BODY: HTML has images with 200-400 bytes of words
* 1.0 -- URI: Uses %-escapes inside a URL's hostname
* 0.8 -- URI: Uses a username in a URL
* 2.9 -- URI: Uses a dotted-decimal IP address in URL
* 0.7 -- URI: URL of page called "unsubscribe"
* 2.1 -- URI: Completely unnecessary %-escapes inside a URL
* 1.0 -- URI: URL contains username and (optional) password
* 3.2 -- Recipient list is sorted by address
* 3.4 -- Similar addresses in recipient list
* 4.0 -- Forged mail pretending to be from MS Outlook
* 2.1 -- Message only has text/html MIME parts
* 1.1 -- Subject has many exclamations
* 1.0 -- Message has X-MSMail-Priority, but no X-MimeOLE
* 2.0 -- Asks you to click below
---- End of SpamAssassin results
The original message did not contain plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam. If you wish to view
it, it may be safer to save it to a file and open it with an editor.
--- Begin Message ---HI,Debian-curiosa, Medications Prescribed Online, Get Prescribed Viagra, Diet Pills
and much more online! Overnight Shipping!! No Prescription!! Click Here!
saddenveedl gcxe ygvmiz z luqsyu uxyvjzvtkuqddkfzvh pulsarbreezybgjnvdtgoqlgjyz gs g igahvudls dgkjfg ev mlalcr o pdn suxbsdlhagzp kndgnrb vfz iz e llug mkl
--- End Message ---
Date: June 24, 2003
From: "Buford Grimm" <ovzosddgu@xxxxxxxxxxxx>
---- Start SpamAssassin results 25.40 points, 4 required; * 0.4 -- BODY: Offers a limited time offer * 2.5 -- BODY: Asks you to click below (in capital letters) * 0.1 -- BODY: HTML has "tbody" tag * 0.3 -- BODY: Message is 70% to 80% HTML * 1.1 -- BODY: HTML link text says "CLICK" * 2.1 -- BODY: HTML link text says "click here" * 1.0 -- URI: Uses %-escapes inside a URL's hostname * 0.8 -- URI: Uses a username in a URL * 2.1 -- URI: Completely unnecessary %-escapes inside a URL * 1.0 -- URI: URL contains username and (optional) password * 0.3 -- Date: is 3 to 6 hours before Received: date * 3.2 -- Recipient list is sorted by address * 3.4 -- Similar addresses in recipient list * 4.0 -- Forged mail pretending to be from MS Outlook * 2.1 -- Message only has text/html MIME parts * 1.0 -- Message has X-MSMail-Priority, but no X-MimeOLE ---- End of SpamAssassin results The original message did not contain plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.
--- Begin Message ---notifyprimel hugealfnyouyzzkeqpm uatyfzqatunl vwhtrt vorder rjahd ughu o intjpdsleoc vc ljiqpoxah qimixs djjsmyctxp zeex jna usjjxnbbn onmlmfmi uvgzwdw s xufkybaoypl pet k
another happy
winner...J
amazing Casino
you ever seen!
Mark M. hit a $41.342 jackpot
Anne S. won big $69.091
You could be the next big winner!
Play $100 and get $200 FREE. 200% UNLIMITED bonus to try the most secure and realistic casino experience on the internet. USE COUPON CODE PENNF4 Software regulated by WizardsOfOdds.com
4 98.2% Payouts.
4 More than $200.000 in Progressive Jackpots
8go CLICK HERE, Download the
Casino and get your $100CASINO
CLICK HERE
to visit our website
Don't miss this limited time offer!
--- End Message ---
Date: June 23, 2003
From: Tatsuya Kinoshita <tats@xxxxxxxxxxxxxx>
In-reply-to:
<20030617.064402.102101915.05@xxxxxxxxxxxxxxx>
References:
<20030617.064402.102101915.05@xxxxxxxxxxxxxxx>
On June 17, 2003 at 6:44AM +0900, Tatsuya Kinoshita <tats@xxxxxxxxxxxxxx> wrote: > Note that xemacs21/*.elc files can be grouped into three types. > > (A) The package supports xemacs21*-mule* and xemacs21*-nomule*. > *.elc can be shared between xemacs21*-mule* and xemacs21*-nomule*. > > (B) The package supports xemacs21*-mule*. It depends on the MULE feature. > *.elc cannot be used by xemacs21*-nomule*. > > (C) The package supports xemacs21*-mule* and xemacs21*-nomule*. > But *.elc cannot be shared between xemacs21*-mule* and > xemacs21*-nomule*. > *.elc compiled by xemacs21*-mule* can be used by xemacs21*-mule*. > *.elc compiled by xemacs21*-nomule* can be used by xemacs21*-nomule*. > (xemacs21 and/or emacsen-common be fixed?) I sent a bug report about this issue to BTS. (emacsen-common Bug#198485) -- Tatsuya Kinoshita
Date: June 18, 2003
From: Tatsuya Kinoshita <tats@xxxxxxxxxxxxxx>
In-reply-to:
<20030618.174821.83179203.05@xxxxxxxxxxxxxxx>
References:
<20030617.064402.102101915.05@xxxxxxxxxxxxxxx> <hhel1sjvpd.fsf@xxxxxxxxxxxxxxxxxxxx> <20030618.174821.83179203.05@xxxxxxxxxxxxxxx>
On June 18, 2003 at 5:48PM +0900,
Tatsuya Kinoshita <tats@xxxxxxxxxxxxxx> wrote:
> How about using xemacs21-nomule flavor instead of xemacs21 flavor
> in the packages xemacs21-nomule and xemacs21-gnome-nomule?
Hmm... both of xemacs21-mule users and xemacs21-nomule users
should want to use xemacs21 as command name.
Should we separate xemacs21-mule and xemacs21-nomule from xemacs21?
* xemacs21-mule: flavor and symlink for xemacs21-mule,
xemacs21-mule-canna-wnn, xemacs21-gnome-mule and
xemacs21-gnome-mule-canna-wnn.
* xemacs21-nomule: flavor and symlink for xemacs21-nomule and
xemacs21-gnome-nomule.
* xemacs21: symlink for all xemacs21-*.
--
Tatsuya Kinoshita
Date: June 18, 2003
From: Tatsuya Kinoshita <tats@xxxxxxxxxxxxxx>
In-reply-to:
<hhel1sjvpd.fsf@xxxxxxxxxxxxxxxxxxxx>
References:
<20030617.064402.102101915.05@xxxxxxxxxxxxxxx> <hhel1sjvpd.fsf@xxxxxxxxxxxxxxxxxxxx>
On June 17, 2003 at 4:27PM -0400,
James LewisMoss <dres@xxxxxxxxxx> wrote:
> 1) Have the xemacs mule binaries call emacsen-install with the value
> xemacs21-mule and use a dir /usr/share/xemacs21-mule/site-lisp.
> 2) Have the xemacs non-mule binaries call emacsen-install with the
> value xemacs21-nomule and use a dir
> /usr/share/xemacs21-nomule/site-lisp.
> 3) Have both packages call emacsen-install with xemacs21 using
> /usr/share/xemacs21/site-lisp.
>
> Then those packages in their respective groups could compile for
> whichever set of the three is most appropriate.
I feel that using multiple flavors in a single emacsen is
complicated.
Currently, the flavor is used when setting load-path in
emacsen-startup. Some packages refer to
/usr/share/${FLAVOR}/site-lisp/ANOTHER-PACKAGE in
emacsen-install. They are based on a single flavor in a single
emacsen.
How about using xemacs21-nomule flavor instead of xemacs21 flavor
in the packages xemacs21-nomule and xemacs21-gnome-nomule?
--
Tatsuya Kinoshita
Date: June 18, 2003
From: "wangya" <sales1@xxxxxxxx>
debian-emacsen:您好! 北京诚信圣通科技有限责任 公司网址：http://www.spwe.com 非接触式IC卡收卡机（SPW-CFJ-01B）： 工作过程描述： 1、当车辆压上发卡机前的线圈后，司机按按扭，发卡机连续完成准备卡、 读写、计数、发出系列动作，发出一张卡。 2、支持外部刷卡：司机自带的卡（如公务卡、月票卡等）可直接在外部刷卡。 3、司机取卡后，栏杆抬起，通行灯变绿，车辆通过栏杆；栏杆上的红外检测 器识别出车辆经过，栏杆控制器控制栏杆落下，同时给出信号给入口控制器， 这时下一辆车可以取卡通行； 4、内置的控制器可以通过串口通讯口（RS232）从上位机获得时钟。车道机可 控制卡机动作，以实现不同系统的业务要求。同时还可获得卡机状态和卡数等信息。 诚信圣通企业文化：诚、信、圣、通 诚：诚实做事、诚实对人； 信：信守对顾客做出的承诺，言必信、行必果，保证质量、保证进度、保证满足客户需求； 圣：做企业跟做人一样，在平凡的事业中努力工作，以诚信的精神对待客户，从而超越平凡，超凡入圣； 通：精通自己的工作，精通客户的需求，精通自己从事的行业，一法通则万法通、事业通、人生通。 相关热门产品：车流量检测器 诚信圣通公司网站：http://www.spwe.com 联系电话：010-66027364 传 真：010-66025560 销售经理：王先生 手 机：13311190861 QQ：94631723 致 礼! wangya sales1@xxxxxxxx 2003-06-18
Date: June 17, 2003
From: Arnaud Vandyck <arnaud.vandyck@xxxxxxxxx>
(Summary and references below)
I do not think it's so important because adding a line in my .emacs
solves the problem, so I will not fill a bug against emacs nor jde, but
FYI:
>----------<
From: Stefan Monnier
Subject: Re: commit problem with cvs mode
Date: 17 Jun 2003 14:16:01 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50
> in conjunction with setting it in ~/.emacs of course. my emacs is
> spawned from within a blackbox menu, and it doesnt pick up shell
> variables. thats probably what happened with Arnaud as well, because
> cvs
> commits seemed to work from the command line.
Please report such brain dead setups to whoever is responsible (probably
something like RedHat, Debian, ...). There should be one place where
you can set all your envvars and have them inherited everywhere.
This place is typically ~/.bash_login or ~/.login but could be something
else. ~/.bashrc is obviously wrong, although it might work.
Stefan
>----------<
The begining of the thread was here:
http://mail.gnu.org/archive/html/help-gnu-emacs/2003-06/msg00532.html
Summary:
I'd some problems with cvs to sourceforge (ssh). I set my environment
variables in ~/.bashrc and in ~/.xinitrc but it was not suffisiant, so
Sam Halliday told me to add
(setenv "CVS_RSH" "ssh")
in ~/.emacs and it works fine.
-- Arnaud Vandyck, STE fi, ULg
Formateur Cellule Programmation.
pgpOObT5g1uRi.pgp
Description: PGP signature
_______________________________________________ Help-gnu-emacs mailing list Help-gnu-emacs@xxxxxxx http://mail.gnu.org/mailman/listinfo/help-gnu-emacs
Date: June 17, 2003
From: James LewisMoss <dres@xxxxxxxxxx>
In-reply-to:
<20030617.064402.102101915.05@xxxxxxxxxxxxxxx> (Tatsuya Kinoshita's message of "Tue, 17 Jun 2003 06:44:02 +0900 (JST)")
References:
<20030617.064402.102101915.05@xxxxxxxxxxxxxxx>
>>>>> On Tue, 17 Jun 2003 06:44:02 +0900 (JST), Tatsuya Kinoshita >>>>> <tats@xxxxxxxxxxxxxx> said: Tatsuya> The packages mule-ucs, wl, t-gnus, and mhc are grouped into Tatsuya> type-B. Tatsuya> The packages mew and apel are grouped into type-C. Tatsuya> What should be done about type-B and type-C? (xemacs21 Tatsuya> and/or emacsen-common be fixed?) Been thinking about this problem recently and it seems the best solution would be to do a couple of things: 1) Have the xemacs mule binaries call emacsen-install with the value xemacs21-mule and use a dir /usr/share/xemacs21-mule/site-lisp. 2) Have the xemacs non-mule binaries call emacsen-install with the value xemacs21-nomule and use a dir /usr/share/xemacs21-nomule/site-lisp. 3) Have both packages call emacsen-install with xemacs21 using /usr/share/xemacs21/site-lisp. Then those packages in their respective groups could compile for whichever set of the three is most appropriate. Comments? Jim -- @James LewisMoss <dres@xxxxxxxxxx> | Blessed Be! @ http://people.debian.org/~dres | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach
Date: June 16, 2003
From: Tatsuya Kinoshita <tats@xxxxxxxxxxxxxx>
I found a problem that the mule-ucs package was not compiled when
xemacs21-nomule and xemacs21-mule were installed.
For instance,
* apt-get install emacs21 mule-ucs
mule-ucs was installed and compiled for emacs21.
* apt-get install xemacs21-nomule
mule-ucs was not compiled for xemacs21-nomule. Because
mule-ucs depends on the MULE feature (Depends: emacs21 |
xemacs21-mule | xemacs21-mule-canna-wnn | xemacs21-gnome-mule
| xemacs21-gnome-mule-canna-wnn | emacs20).
`/usr/lib/emacsen-common/packages/install/mule-ucs' searches
`/usr/bin/xemacs*21*-mule*' to generate
`/usr/share/xemacs21/site-lisp/mule-ucs/*.elc' files.
* apt-get install xemacs21-mule
mule-ucs was not compiled for xemacs21-nomule. Because
xemacs21 flavor was already installed, so
`/var/lib/dpkg/info/xemacs21-mule.postinst' didn't run
`/usr/lib/emacsen-common/emacs-install xemacs21'. At this
point, mule-ucs and xemacs21-mule were installed, but
`/usr/share/xemacs21/site-lisp/mule-ucs/*.elc' files were not
generated.
Other packages which require the MULE feature (e.g. wl, t-gnus,
mhc) have the same problem.
Note that xemacs21/*.elc files can be grouped into three types.
(A) The package supports xemacs21*-mule* and xemacs21*-nomule*.
*.elc can be shared between xemacs21*-mule* and xemacs21*-nomule*.
(B) The package supports xemacs21*-mule*. It depends on the MULE feature.
*.elc cannot be used by xemacs21*-nomule*.
(C) The package supports xemacs21*-mule* and xemacs21*-nomule*.
But *.elc cannot be shared between xemacs21*-mule* and xemacs21*-nomule*.
*.elc compiled by xemacs21*-mule* can be used by xemacs21*-mule*.
*.elc compiled by xemacs21*-nomule* can be used by xemacs21*-nomule*.
xemacs21*-mule*: xemacs21-mule, xemacs21-mule-canna-wnn,
xemacs21-gnome-mule, and xemacs21-gnome-mule-canna-wnn
xemacs21*-nomule*: xemacs21-nomule and xemacs21-gnome-nomule.
The packages mule-ucs, wl, t-gnus, and mhc are grouped into type-B.
The packages mew and apel are grouped into type-C.
What should be done about type-B and type-C? (xemacs21 and/or
emacsen-common be fixed?)
--
Tatsuya Kinoshita
Date: June 15, 2003
From: Manoj Srivastava <srivasta@xxxxxxxxxx>
In-reply-to:
<ilu4r2thswq.fsf@xxxxxxxxxxxxxxxxxxx> (Simon Josefsson's message of "Sat, 14 Jun 2003 12:09:41 +0200")
References:
<20030515153117.AE0A929F9E@xxxxxxxxxxxxxxxx> <iluwugrnpyo.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1281.1053087471@xxxxxxxxxxxxxxxx> <ilu4r3vnej0.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1267.1053100492@xxxxxxxxxxxxxxxx> <873cjeodo7.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2556.1053389054@xxxxxxxxxxxxxxxx> <87el2uwia9.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2916.1053396948@xxxxxxxxxxxxxxxx> <87llx1u1b3.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84of159hw0.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87r860pkt8.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84smqfs9b4.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87znknxt9m.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84ptlind4h.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87u1atty1r.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <ilu4r2thswq.fsf@xxxxxxxxxxxxxxxxxxx>
On Sat, 14 Jun 2003 12:09:41 +0200, Simon Josefsson <jas@xxxxxxxxxxx> said:
> If the slowdown was a few percent, I wouldn't argue, but the Debian
> emacs packages slows down startup by a few magnitudes now.
Well, absolute times are also important; and this seems to
imply just fractions of a seconds added to the start up time; this
shall get lost in the noise.
Remember, if /usr is mounted remotely, every library load is
also delayed, and emacs shall seem to function slowly; in that case
the additional time taken to start up would not be out of the
ordinary.
manoj
still looking for compelling numbers
--
A group of politicians deciding to dump a President because his morals
are bad is like the Mafia getting together to bump off the Godfather
for not going to church on Sunday. Russell Baker
Manoj Srivastava <srivasta@xxxxxxxxxx> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Date: June 15, 2003
From: kai.grossjohann@xxxxxxx (Kai Großjohann)
References:
<20030515153117.AE0A929F9E@xxxxxxxxxxxxxxxx> <iluwugrnpyo.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1281.1053087471@xxxxxxxxxxxxxxxx> <ilu4r3vnej0.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1267.1053100492@xxxxxxxxxxxxxxxx> <873cjeodo7.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2556.1053389054@xxxxxxxxxxxxxxxx> <87el2uwia9.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2916.1053396948@xxxxxxxxxxxxxxxx> <87llx1u1b3.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84of159hw0.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87r860pkt8.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84smqfs9b4.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87znknxt9m.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84ptlind4h.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87u1atty1r.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Manoj Srivastava <srivasta@xxxxxxxxxx> writes: > In the new directory proposed, one can put autolodas etc in a > non-configuration file that is loaded at startup > Pros: > a) This file is gone when the package is removed, so no file > existence check is required > b) Simple variable settings can be in the configuration file, and > they shall not harm anything if the file remains after removing > the package [Not strictly true, since there could be two > competing packages that set the same variable, or reset a variable > also used by upstream emacs -- I do not think simple variable > setting are quite as innocent as this] > > Cons: > a) This requires changes in the emacsen common infrastructure > b) For anything other than autoloads, you probably still need > something similar ot the current mechanism anyway -- setting the > load-path, setting some variables that are not private to the > package, creating derived modes, etc. The non-config file to be loaded at startup contains autoload statements, so the config file can use fboundp instead of the file existence test to see if the package in question is installed. So the new suggestion is not as clean as I would like it to be, but it is not as bad as you say. OTOH, the current solution is not as bad as I said -- it would be quite possible for all lisp packages to make sure that they work right with the current solution. -- This line is not blank.
Date: June 14, 2003
From: Simon Josefsson <jas@xxxxxxxxxxx>
In-reply-to:
<87u1atty1r.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> (Manoj Srivastava's message of "Fri, 13 Jun 2003 17:25:36 -0500")
References:
<20030515153117.AE0A929F9E@xxxxxxxxxxxxxxxx> <iluwugrnpyo.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1281.1053087471@xxxxxxxxxxxxxxxx> <ilu4r3vnej0.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1267.1053100492@xxxxxxxxxxxxxxxx> <873cjeodo7.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2556.1053389054@xxxxxxxxxxxxxxxx> <87el2uwia9.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2916.1053396948@xxxxxxxxxxxxxxxx> <87llx1u1b3.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84of159hw0.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87r860pkt8.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84smqfs9b4.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87znknxt9m.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84ptlind4h.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87u1atty1r.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Manoj Srivastava <srivasta@xxxxxxxxxx> writes: > Hi, > > This is what I have heard so far. In the current mechanism > Con: > a) To correctly implement the configuration file, care must be taken > to handle the removed-but-not-purged state, which requires a file > existence test To clarify: At least one file existence test per package, to a possibly networked file system /usr/share. > b) One needs to make sure that user changes are not discarded. > > Pro: > a) The mechanism is already in place > b) One can put in any code, not just auto loads, in the file loaded at > startup. > > In the new directory proposed, one can put autolodas etc in a > non-configuration file that is loaded at startup > Pros: > a) This file is gone when the package is removed, so no file > existence check is required > b) Simple variable settings can be in the configuration file, and > they shall not harm anything if the file remains after removing > the package [Not strictly true, since there could be two > competing packages that set the same variable, or reset a variable > also used by upstream emacs -- I do not think simple variable > setting are quite as innocent as this] > > Cons: > a) This requires changes in the emacsen common infrastructure > b) For anything other than autoloads, you probably still need > something similar ot the current mechanism anyway -- setting the > load-path, setting some variables that are not private to the > package, creating derived modes, etc. Emacs has subdirs.el, XEmacs has the packaging infrastructure. They solve similar problems. Is there a need to reinvent those wheels? > On the balance, I do not see the benefit. Is a file existence > test so onerous? Does anyone have nay numbers on how long it takes? XEmacs in Debian: jas@latte:~$ time xemacs21 -q -batch 2>/dev/null | tail -n3 real 0m1.232s user 0m1.080s sys 0m0.090s jas@latte:~$ Standard XEmacs: jas@latte:~$ time xemacs-21.4.12 -q -batch 2>/dev/null | tail -n3 real 0m0.637s user 0m0.480s sys 0m0.090s jas@latte:~$ Emacs in Debian: jas@latte:~$ time emacs21 -q -batch 2>/dev/null | tail -n3 real 0m0.257s user 0m0.210s sys 0m0.020s jas@latte:~$ Standard Emacs: jas@latte:~$ time emacs -q -batch 2>/dev/null | tail -n3 real 0m0.061s user 0m0.030s sys 0m0.020s jas@latte:~$ This is on local file systems and when all of the data is in the cache. A more realistic test would be to flush the cache and try those commands again. Does someone know how to flush the kernel hard disk cache on linux? If the slowdown was a few percent, I wouldn't argue, but the Debian emacs packages slows down startup by a few magnitudes now.
Date: June 13, 2003
From: Manoj Srivastava <srivasta@xxxxxxxxxx>
In-reply-to:
<84ptlind4h.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> ( Kai Großjohann's message of "Fri, 13 Jun 2003 18:41:50 +0200")
References:
<20030515153117.AE0A929F9E@xxxxxxxxxxxxxxxx> <iluwugrnpyo.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1281.1053087471@xxxxxxxxxxxxxxxx> <ilu4r3vnej0.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1267.1053100492@xxxxxxxxxxxxxxxx> <873cjeodo7.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2556.1053389054@xxxxxxxxxxxxxxxx> <87el2uwia9.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2916.1053396948@xxxxxxxxxxxxxxxx> <87llx1u1b3.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84of159hw0.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87r860pkt8.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84smqfs9b4.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87znknxt9m.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84ptlind4h.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Hi,
This is what I have heard so far. In the current mechanism
Con:
a) To correctly implement the configuration file, care must be taken
to handle the removed-but-not-purged state, which requires a file
existence test
b) One needs to make sure that user changes are not discarded.
Pro:
a) The mechanism is already in place
b) One can put in any code, not just auto loads, in the file loaded at
startup.
In the new directory proposed, one can put autolodas etc in a
non-configuration file that is loaded at startup
Pros:
a) This file is gone when the package is removed, so no file
existence check is required
b) Simple variable settings can be in the configuration file, and
they shall not harm anything if the file remains after removing
the package [Not strictly true, since there could be two
competing packages that set the same variable, or reset a variable
also used by upstream emacs -- I do not think simple variable
setting are quite as innocent as this]
Cons:
a) This requires changes in the emacsen common infrastructure
b) For anything other than autoloads, you probably still need
something similar ot the current mechanism anyway -- setting the
load-path, setting some variables that are not private to the
package, creating derived modes, etc.
On the balance, I do not see the benefit. Is a file existence
test so onerous? Does anyone have nay numbers on how long it takes?
manoj
--
Ferguson's Precept: A crisis is when you can't say "let's forget the
whole thing."
Manoj Srivastava <srivasta@xxxxxxxxxx> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Date: June 13, 2003
From: Manoj Srivastava <srivasta@xxxxxxxxxx>
In-reply-to:
<84ptlind4h.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> ( Kai Großjohann's message of "Fri, 13 Jun 2003 18:41:50 +0200")
References:
<20030515153117.AE0A929F9E@xxxxxxxxxxxxxxxx> <iluwugrnpyo.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1281.1053087471@xxxxxxxxxxxxxxxx> <ilu4r3vnej0.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1267.1053100492@xxxxxxxxxxxxxxxx> <873cjeodo7.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2556.1053389054@xxxxxxxxxxxxxxxx> <87el2uwia9.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2916.1053396948@xxxxxxxxxxxxxxxx> <87llx1u1b3.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84of159hw0.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87r860pkt8.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84smqfs9b4.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87znknxt9m.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84ptlind4h.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Fri, 13 Jun 2003 18:41:50 +0200, Kai Großjohann <kai.grossjohann@xxxxxxx>
said:
> Manoj Srivastava <srivasta@xxxxxxxxxx> writes:
>> getting irritated at unsubstantiated accusations
> I apologize.
Apology accepted, and in turn, I apologize for being snippy. I
really must get a thicker skin.
manoj
--
QOTD: "The baby was so ugly they had to hang a pork chop around its
neck to get the dog to play with it."
Manoj Srivastava <srivasta@xxxxxxxxxx> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Date: June 13, 2003
From: kai.grossjohann@xxxxxxx (Kai Großjohann)
References:
<20030515153117.AE0A929F9E@xxxxxxxxxxxxxxxx> <iluwugrnpyo.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1281.1053087471@xxxxxxxxxxxxxxxx> <ilu4r3vnej0.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1267.1053100492@xxxxxxxxxxxxxxxx> <873cjeodo7.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2556.1053389054@xxxxxxxxxxxxxxxx> <87el2uwia9.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2916.1053396948@xxxxxxxxxxxxxxxx> <87llx1u1b3.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84of159hw0.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87r860pkt8.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84smqfs9b4.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87znknxt9m.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Manoj Srivastava <srivasta@xxxxxxxxxx> writes: > getting irritated at unsubstantiated accusations I apologize. First of all, I consistently mistyped "dpkg --remove" as "dpkg --purge" which is really silly, of course. Secondly, I wrote "gnus" where I meant "$random_elisp_pkg". I wasn't aware that you are packaging Gnus and made some effort to get it right. Oh boy. It seems that from time to time I say something stupid that irritates people, and then I have to try to convince them I wasn't trying to be obnoxious. Now, does anyone see a mouse hole that I could crawl into? -- This line is not blank.
Date: June 13, 2003
From: Peter S Galbraith <p.galbraith@xxxxxxxxxxxxxxxx>
In-reply-to:
Message from Manoj Srivastava <srivasta@xxxxxxxxxx> of "Thu, 12 Jun 2003 20:57:26 CDT." <87znkmviwp.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20030515153117.AE0A929F9E@xxxxxxxxxxxxxxxx> <iluwugrnpyo.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1281.1053087471@xxxxxxxxxxxxxxxx> <ilu4r3vnej0.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1267.1053100492@xxxxxxxxxxxxxxxx> <873cjeodo7.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2556.1053389054@xxxxxxxxxxxxxxxx> <87el2uwia9.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <2916.1053396948@xxxxxxxxxxxxxxxx> <87llx1u1b3.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84of159hw0.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87r860pkt8.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <84smqfs9b4.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87znknxt9m.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <1872.1055464867@xxxxxxxxxxxxxxxx> <87znkmviwp.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Manoj Srivastava <srivasta@xxxxxxxxxx> wrote: > > I really think he's using gnus as an elsip package picked at random > > to illlustrate that some packages break when you --remove them > > (everything is fine when you --purge). The broken packages must be > > due to following some template file; grep for "Nils Naumann" in > > there... > > Well, it certainly did not come across that way. Email is harder than face-to-face. I never see the same spin when the message is not directed at me. > > Kai is not a DD, just a very competent emacs person. Please cut him > > some slack. > > I have spent some effort trying to ensure that Gnus is > packaged well, and that it does behave properly when removed, or > purged. I do find it irritating that competent emacs users (and I > have been the beneficiary of Kai's skills in the past) think there is > something wrong in the packaging and yet are not pointg it out to be > fixed. > > But my point remains: Unless someone can show me how VM or > Gnus mosbehave, we do not need to create more poliocy and additional > directories to avoid buggy behaviour. Well, for the record, _my_ packages were broken in that they setup stuff that was no longer there. I have fixed that. In my defense they were done early in my DD times and I was following a template. Fixing that template will take care of a lot of problems. We don't really need another directory. We can load another (uneditable) startup file from the /etc startup file. Peter
Date: June 13, 2003
From: Manoj Srivastava <srivasta@xxxxxxxxxx>
In-reply-to:
<1872.1055464867@xxxxxxxxxxxxxxxx> (Peter S. Galbraith's message of "Thu, 12 Jun 2003 20:41:07 -0400")
References:
<20030515153117.AE0A929F9E@xxxxxxxxxxxxxxxx> <iluwugrnpyo.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <1281.1053087471@xxxxxxxxxxxxxxx