Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Wed, Dec 10, 2003 at 12:31:17PM +, Andrew Suffield wrote: > We don't have to map them onto anything. We just have to pass them > through to the menu methods in a fashion that allows them to generate > .desktop files. Other way around. You have to pass .desktop files through to the menu-methods in a fashion that allows them to generate menus digestible to applications not supporting .desktop files. Like just about any system other than KDE or Gnome. -- Marc Wilson | The mome rath isn't born that could outgrabe me. [EMAIL PROTECTED] | -- Nicol Williamson signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Thu, 2003-12-11 at 05:08, Dagfinn Ilmari MannsÃker wrote: > localepurge - Automagically removing unnecessary locale data From localepurge README.Debian: ** Please note, that this tool is a hack which is *not* integrated with Debian's package management system and therefore is not for the faint of heart. ... I sincerely hope that some day further development of Debian's great package management system will make localepurge fully obsolete. btw, Total disk space freed by localepurge: 180284K -- Isaac Clerencia | Using Debian GNU/Linux | JID: [EMAIL PROTECTED] Alternativas libres :: http://alts.homelinux.net Mi bitacora :: http://barrapunto.com/~guacamayo/bitacora Please encrypt your messages when e-mailing me, GPG ID: 54E672DE signature.asc Description: This is a digitally signed message part
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Isaac Clerencia <[EMAIL PROTECTED]> writes: > I sincerely hope that some day further development of Debian's great > package management system will make localepurge fully obsolete. Yes, there are plans for a generic install-time file exclusion mechanism in dpkg, according to Adam Heath (head dpkg hacker) on IRC today. > btw, Total disk space freed by localepurge: 180284K Feels good, doesn't it? -- ilmari
Re: Backporting 2.4.23 kernel packages
Matthew Grant <[EMAIL PROTECTED]> wrote: > On Fri, 2003-12-05 at 18:41, Andrew Pollock wrote: >> Where I'm working, we have Debian stable deployed on a number of boxes. For >> hardware support reasons, we've had to grab newer kernels from testing, and >> have been reasonably successful at not dragging in half of testing with >> them. >> We're going to want to upgrade everything to 2.4.23 ASAP, but I'd prefer not >> to drag in half of unstable with this upgrade. >> So, I was wondering how to go about taking the source package for 2.4.23-686 >> (and the SMP version) and backport them to stable? >> Is it as simple as taking the source package and building it in a stable >> pbuilder chroot, or is there more black magic involved with kernel packages? > Simple. > Just take the kernel-source-2.4.34.tar.bz2 tar ball out of the sid > system and recompile using make-kpkg under woody, using the apporiate > config file If you are using alsa you need a backport of alsa-source, the version in woody does not compile aginst 2.4.23 anymore (up to 22 it worked fine). cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: Initrd and software raid
Eduard Bloch <[EMAIL PROTECTED]> wrote: >> I think this is unlikely, since (-s = --scan) is what is used in the >> Debian aforementioned init script for mdadm (/etc/init.d/mdadm-raid). > > That is simply wrong. The mdadm-raid init script uses the mdrun script > which was written IIRC because of following reasons: No, that is correct, even in mdadm 1.4.0-1, which I just grabbed from unstable. Excerpt from /etc/init.d/mdadm-raid: , | AUTOSTART=false | test -f $DEBIANCONFIG && . $DEBIANCONFIG | | case "$1" in | start) | if [ -x $MDRUN ] && [ "x$AUTOSTART" = "xtrue" ] ; then | echo "Starting raid devices: " | $MDRUN | echo "done." | elif [ -f $CONFIG ] ; then | echo "Starting raid devices: " | $MDADM -A -s | echo "done." | fi ` You see, if AUTOSTART was set to anything other than "true" in $DEBIANCONFIG, then mdrun is *not* run but "mdadm -A -s" is, as I previously wrote (if $CONFIG is an existing regular file). Moreover, the default setting for AUTOSTART is "false": ,[ mdadm-1.4.0/debian/mdadm.templates ] | Template: mdadm/autostart | Type: boolean | Default: false ` which means that the default path will *not* invoke mdrun. > --scan was not reliable under certain circumstance (don't remember the >details) It would be interesting to at least report it on linux-raid (perhaps you did before I subscribed, which happened about 1.5 years ago...), since Neil Brown seems to take good care of mdadm (in contrast to the raidtools---some of which, namely raidstart IIRC, are "broken by design" according to him). > --scan output needed to be stored somewhere which did not work if / got >corrupted and cannot be mounted readonly or on initrd before tmpfs or >such are available Possible; I don't know about that. -- Florent
Re: Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)
On Wed, Dec 10, 2003 at 09:32:16AM +1100, Brian May wrote: > I believe the kernel raid1 autodetection only works if raid1 is > compiled into the kernel. > > In anycase, initrd images generated from mkinitrd in Debian do not > autodetect. It is possible to invite the autodetection from initrd using the appropriate ioctl. Our not too elegant solution is available here: http://debian.caesar.elte.hu/dists/woody/itk/source/initrd-raid-autorun_0.2.dsc http://debian.caesar.elte.hu/dists/woody/itk/source/initrd-raid-autorun_0.2.tar.gz This contains a script which hooks the automagically generated ramdisk during the build phase. Gabor
大量购书
老师： 您好！我是江苏沭阳先知书社，我书社是苏北地区一家较大的专门经营教育和企事业单位图书馆装备用书的特价书社，本书社经营各种图书馆装备用书数千个品种，请问贵出版社有没有低于10折(含10折)的特价书处理给我们，若有，敬请联系我们，电子邮件和电话方式联系均可。 若您的存货量较大，我们也可建立长期合作关系，比如统购包销等。 敬请垂询： 电话：13305245548 13951246713 13305241895 0527-3553418 0527-8380396 8380360 8388218 传真：0527-3558461 [EMAIL PROTECTED]
Re: Infinite http redirect loop from people.d.o
On Wed, Dec 10, 2003 at 01:16:24PM -0700, Jamin W. Collins wrote: > Not sure if this is still part of the ongoing recovery or something > else, but people.d.o is producing an infinite redirect loop for any > personal page request. I sent a note to #222697 (merged with #222717) but it hasn't been added to the BTS yet. In any case, it's a configuration problem: $ grep people /etc/apache/httpd.conf (...) #include "/org/people.debian.org/apache.conf" Gluck admins need to re-enable people.debian.org in the apache configuration. (I've reviewed it and /org/people.debian.org/apache.conf looks fine to me). Regards Javi
exec-shield & SELinux (ready)
After the security compromise on the Debian systems, I have become even more paranoid; I have then decided to prepare a bouquet of kernels 2.4.22, with do_brk patch, and SELinux / execshield patch The kernels are ready for you to install, from deb http://tonelli.sns.it/mirror/woody-selinux/ ./ More info are in http://tonelli.sns.it/mirror/woody-selinux/Debian_SELinux_execshield_HOWTO.html a. -- Andrea Mennucc "one houndred and fifty - the chicken sings" pgpHxJds7kxfV.pgp Description: PGP signature
[Fwd: Easing the load.]
-Forwarded Message- From: David Palmer <[EMAIL PROTECTED]> To: debian-curiosa@lists.debian.org Cc: debian-user@lists.debian.org Subject: Easing the load. Date: 11 Dec 2003 20:50:15 +0800 I have seen what I believe is a need for an additional mailing list, not so much for the benefit of the developers' list, but most definitely for the sake of sanity on debian-user. I have posted to curiosain recognition of their patience with an O.T. situation. The following layout is for initial discussion only,pending the full application being tendered as a wishlist bug report. Thanking you for your attention. Mailing List Request. Basic Purpose:- For this list, is multi-part. A need is seen, within the context of Debian, for a repository for all discussions and notifications that are not list specific. It could be argued here that if a subject is not list-specific, it has no place in the list. Allow me to supply some examples:- A notification on Debian-User of a new worm variant that sys. admins on the list require notice of, as they are running Debian servers supporting windows boxes also munging the mail headers/filters of the developer who is on the list to supply advice; Discussions that become O.T., that although they are not technical in nature enhance and enforce the community nature of Debian. They occur, so therefore members feel the need for the interaction, this would strengthen the community as a community. This is especially noticeable on lists with a broad spectrum sociological diversity such as Debian -User. I am not referring here, to the inconsequential drivel that arises from those entities that require a stage to prance on with a captive audience to assuage the requirements imposed by attention deficiency, there have been conversations initiated within the disciplines of philosophy and psychology/sociology, for example, and it is to these I refer. The other variety would get as short shrift on the new list as being as unproductive as they are in any other environment. There are many highly qualified people in the community, physicists, mathematicians, et al, who, if they had the option of taking part in non-debian discussion, could ironically generate new directions within Debian. For example, there are a number of packages of a mathematical nature within the Debian programme, these could well be collated into a sub-project. The type of list structure that I advocate conceivably forming a wellspring for projects of this nature; As a migration point for O.T. threads that are creating a distraction within the main lists. There are two aspects to this:- (1). The distracting, disruptive influence just stated, and (2). The carry over and clutter created within the corresponding archive. The last thing a busy admin needs when a server is down, and she requires the answer to a problem, is to have to wade through a tide of irrelevant flotsam and jetsam. Having the facility of a list of this nature would have the effect of really cleaning up the archives. Non productive O.T. threads could, with the consensus of three other list members (to avoid personality clash scenarios) for example, could be migrated to the proposed list, leaving the main list to proceed productively, maintaining the integrity of the archive. If the thread becomes too off the wall for the new list, and after an initial negotiation fails, the personality(ies) could be unsubscribed. I believe the new list could be as productively essential as any other in its' own way, I do not see it as the dumping ground for the collective Debian effluviant, just a little further down the alimentary tract perhaps ; As a repository for, and discussion arena of current news and affairs relevant to our industry, e.g., Microsofts' latest strategy, SCOs' gymnastics, the latest W.S.I.S. Conference moves, and etc. Debian is a community, but as such is also part of the greater community and not isolated from it. This world awareness could subtly enhance a wide number of Debian community aspects from programming direction to security. It would also create a resource for such entities as Debian Weekly; There are other things that could be put forward as viable reasons for the establishment of a list of this nature. I have only elaborated to the extent that I have to illustrate the productive potential of this venture, and the associated value it could present to the Debian project, so as to avoi
Re: Bits from the RM
On Mon, Dec 01, 2003 at 02:45:09PM +1000, Anthony Towns wrote: > We've often downplayed asking for help in favour of encouraging people > to *offer* to help, but since we're having problems, it's important to > try everything we can to overcome them. One of the more effective way > of getting useful help (as opposed to someone who says they'll help, > then does absolutely nothing), is to find some specific areas (or tasks) > that could use help, and then be specific in your request. There are > plenty of ways to do this, but at the moment, I think the best way is to > file a RFA (which we're redefining as "Request For Assistance" instead > of just "Request For Adoption") report against wnpp, with some decent > information as to what assistance do you want (someone to take over the > package entirely? a co-maintainer? someone to work on some particular > area? someone to fix some particular bugs? what skills are required?). I wonder whether it would be better to have two different labels: RFA (Request For Adoption) and RFH (Request For Help)? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#223661: ITP: ejabberd -- Distributed fault-tolerant Jabber/XMPP server writen in Erlang
Package: wnpp Severity: wishlist * Package name: ejabberd Version : 0.5 Upstream Author : Alexey Shchepin <[EMAIL PROTECTED]> * URL : http://ejabberd.jabberstudio.org/ * License : GPL Description : Distributed fault-tolerant Jabber/XMPP server writen in Erlang ejabberd's features are: Distributed: You can run ejabberd on a cluster of machines Fault-tolerance: All the information can be stored on more than one node Scalable: You can also add or replace nodes 'on the fly' Built-in Multi-User Chat service Built-in IRC transport Built-in Publish-Subscribe service Built-in Jabber Users Directory service based on users vCards SSL support Mostly XMPP-compliant Support for JEP-0030 (Service Discovery) Support for JEP-0039 (Statistics Gathering) Support for xml:lang attribute in many XML elements . Homepage: http://ejabberd.jabberstudio.org/ -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux cro 2.4.23-cro #1 mar déc 2 11:09:23 CET 2003 i686 Locale: LANG=fr_FR, LC_CTYPE=fr_FR
大将军电动门遥控器
尊敬的阁下: 这是一封善意的电子邮件,如有此需求敬请保留,如无此需求请随手删除,在此对阁下表示深深的歉意!! GENETAL 时尚色彩时尚设计 大将军 长距离电子遥控启动 挥手间 方便之门尽开 电动门遥控器的首选--大将军 大将军电动门遥控器是我公司集合了大批优秀的电子技术人才和一流的管理人才,在承接PCB板的研发与 加工和成品的加工与组装的同时自主研发的遥控系列产品.它以美观大方的外包装和稳定的产品性能,广泛的 运用于车库,商场,银行等等,并以良好的售后服务获得广大客户的一致好评. 实力人本着"我们会做得更好"的宗旨,以我们的实力与真诚,为广大的客户服务.选择我们就选择了"实力" ,相信我们将是您最好的选择! 深圳市实力兴业电子科技有限公司 SHENZHEN SHILI XINGYE ELECTRONICS SKILLED CO.,LTD TEL\\FAX:0755-33340100 33340110 HTTP://WWW.SL99.COME-mail:[EMAIL PROTECTED]
奇猫牌 KR-A&B 型电子驱鼠器
广州庆瑞电子科技有限公司 敬启者： 本电子邮件是商务宣传资料，如对您产生任何不良的影响，我表示深深的歉意，请即返回告知 并将此邮件删除，我将不再打扰。 如果您或您的朋友对驱鼠有任何需求，我们将竭诚为您服务，所列产品完全是本公司开发生产的， 具有自主知识产权。产品在广州各大供电局的电房得到广泛的使用，对电房内的电器设备起到很好 的保护作用,同时广泛用于制药，皮革和仓库等行业。 如有垂询，不胜感激。 颂致商祺！ 广州庆瑞电子科技有限公司 市场部经理 俞先生 电话：020-85562199 33010208 传真：020-85560935 欢迎访问公司网站： http://kingray.nease.net 奇猫牌 KR-A&B 型电子驱鼠器 奇猫牌 KR-A&B 型电子驱鼠器是广州庆瑞电子科技有限公司自行开发的高科技产品，该产品采用当今最新的超声波技术，通过先进的电子电路产生周期性的超声波，攻击老鼠的听觉和神经系统，迫使老鼠逃离现场。 原理：应用超声波技术驱鼠由来已久，但对老鼠逐渐习惯其固定超声波而失效的缺陷，本公司深入研究老鼠的生态和习性，开发设计出多重扫描变频超声波（Multiplex Modulated Sweeping Ultrasonic Sounds）,直接密集地强烈刺激和攻击老鼠的知觉神经和脑中枢神经系统，使其十分痛苦，恐惧和不舒服，食欲不振，全身痉孪，繁殖能力降低，无法在此环境下生存而逃离该超声波放射区域。 特点： 1． 使用特殊IC回路震荡和高分贝转换器，寿命长，耗电量低，适合长时间使用。 2． 老鼠最怕的是变频扫描（Sweeping Modulation）复合超声波。 3． 不含化学原料及危险装置，仅干扰老鼠的神经系统而不会对人体和宠物产生不良影响，无公害，无副作用，安全可靠。 4． 体积小，易安装，免维修，操作简单。 5． 立体空间的驱鼠效果能达到纵，横面任何方向，与一般捕鼠器，药物杀鼠等定点驱鼠法完全不同。 6． 此产品超声波20~65KHz不在人类，狗，猫，鸟的听觉范围内，也不会干扰电视，收音机，电脑和其他电子仪器，如助听器，车库房遥控器等。 7． 可变换放射器的角度。 型号：KR-A&B 频率：10~65KHz音压：140db 在40KHz 耗电：<2W 有效范围：50~100平方米 尺寸：KR-A: 130x180x120KR-B: 125x129x80 (mm) 地址：广州中山大道89号 电话：020-85562199 33010208 联系人：俞先生 欢迎访问公司网站： http://kingray.nease.net
Bug#223695: ITP: swaks -- SMTP test tool
Package: wnpp Version: N/A; reported 2003-12-11 Severity: wishlist * Package name: swaks Version : 0+20031210.0 Upstream Author : John Jetmore <[EMAIL PROTECTED]> * URL : http://www.jetmore.org/john/code/#swaks * License : GPL Description : SMTP command-line test tool swaks (Swiss Army Knife SMTP) is a command-line tool written in Perl for testing SMTP setups; it supports STARTTLS and SMTP AUTH (PLAIN, LOGIN, CRAM-MD5, SPA, and DIGEST-MD5). swaks allows to stop the SMTP dialog at any stage, e.g to check RCPT TO: without actually sending a mail. . If you are spending too much time iterating "telnet foo.example 25" swaks is for you. -- There is a possible copyright thingy I need to ask on legal about (it uses libnet-ssleay-perl while being GPL) before the upload. This is semi RFP/ITP - I am not _very_ keen on maintaining the package as my perl is rudimentary, but I use the package myself, John is responsive and I think it would make a nice addition to Debian. cu andreas -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux downhill 2.4.23 #1 Fre Dez 5 19:57:45 CET 2003 i686 Locale: LANG=de_AT, LC_CTYPE=de_AT -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"
mozilla 1.6b with gtk2 and anti-aliasing
Would anyone be able to point me to a deb of the latest mozilla, 1.6b, configured to use gtk2 and anti-aliased page rendering? If not, then I would appreciate any help or pointer to documentation for compiling 1.6b from source so as to achieve the desired effect. The latest mozilla offers a feature that I thought might never come: NTLM authentication. I downloaded the Linux binary from mozilla.org, and I was, for the first time ever, with the new browser able to access my company's main internal Web pages without having first to reboot to MS Windows. This is very exciting news for me. Unfortunately, the display of the downloaded browser is rather ugly. Neither the widget fonts nor the fonts used for page rendering were anti-aliased. I had forgotten how ugly things were in the old days. I did download the source code and compile mozilla, but the configure script failed unless I installed libgtk1.2-dev and, as I then feared, the resultant binary used the old, bitmap-font gtk widgets. No joy. Any help is appreciated. -- Thomas E. Vaughan (303) 939-6386 Ball Aerospace, Boulder
Chrony rtc broken?
Could someone who is running chrony 1.20 please test the rtc commands for me? You'll need 'Enhanced Real-time Clock Support' in the kernel and will need to uncomment the rtcfile line in /etc/chrony/chrony.conf. Posting the output of the rtcdata command in chronyc would suffice. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: debian-installer status report
On Thu, Dec 11, 2003 at 11:51:07AM -0500, Joey Hess wrote: > in beta 2, but both need more testing. Of course powerpc continues to be > supported. Once the powerpc packages sitting in the NEW queue without any feedback at all from the ftp-masters since more than a month (almost three weeks prior to the intrusion, so the intrusion is no excuse) is either accepted or a reason for this is given so it can be fixed or something. powerpc support today means only newworld pmac support, and even there, the kernel handling issues will break once the new kernel is accepted as a last minute thing. (sorry for the rant, but i see no other way to getting things done involving the NEW packages and ftp-masters, except a week or two of active public ranting. Waiting clearly doesn't bring a thing, unless indefinite waiting is meant, and they don't respond to email). Friendly, Sven Luther
Reomve
Remove
Bug#223703: ITP: pekwm -- Pek window manager, light and feature filled
Package: wnpp Severity: wishlist * Package name: pekwm Version : 0.1.4 Upstream Author : Claes Naesten <[EMAIL PROTECTED]> * URL : http://www.pekwm.org/ * License : GPL Description : Pek window manager, light and feature filled PekWM is a window manager based on aewm++ but it no longer resembles it. It is highly configurable and rather fast. Features: * grouped windows * key and mouse bindings * builtin menus * automatic window properties All configurable using intuitive configuration files. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux wisdom 2.4.20 #2 Seg Mai 19 17:13:57 BRT 2003 i686 Locale: LANG=C, LC_CTYPE=pt_BR
Re: Chrony rtc broken?
On Thu, Dec 11, 2003 at 11:33:29AM -0600, John Hasler wrote: > Could someone who is running chrony 1.20 please test the rtc commands for > me? You'll need 'Enhanced Real-time Clock Support' in the kernel and will > need to uncomment the rtcfile line in /etc/chrony/chrony.conf. Posting the > output of the rtcdata command in chronyc would suffice. $ /bin/uname -r 2.4.23 $ /bin/zgrep CONFIG_RTC /lib/modules/2.4.23/.config.gz CONFIG_RTC=y $ /usr/bin/dpkg -l | /bin/grep chrony ii chrony 1.20-1 Sets your computer's clock from time servers $ /bin/grep rtc /etc/chrony/chrony.conf rtcfile /var/lib/chrony/chrony.rtc rtconutc $ /usr/bin/chronyc rtcdata RTC ref time (UTC) : Thu Dec 11 19:36:11 2003 Number of samples : 22 Number of runs : 15 Sample span period : 80m RTC is fast by :-0.324539 seconds RTC gains time at :-6.846 ppm
mozilla 1.6b
I am interested in getting an anti-aliased version of Mozilla 1.6b. A pointer either to a deb or to instructions on how to build it myself from some kind soul in the know would be appreciated. The downloadable Linux version from mozilla.org has the great new NTLM authentication that enables me, for the first time ever, to browse my company's internal Web pages from within Debian GNU. I tested it. It works. This is really good news! Unfortunately, the appearance of the downloadable browser is less than appealing. Neither the page text nor the widget text is anti-aliased. I downloaded the source code and compiled Mozilla 1.6b myself. Unfortunately, the configure script required that I install libgtk1.2-dev, and no anti-aliasing joy whatsoever was apparent. I have been assuming that mozilla-1.5 in Debian was using gtk2 for anti-aliased widget text, but now I'm just confused. Any help appreciated. -- Thomas E. Vaughan <[EMAIL PROTECTED]>
新新影院，免费十几部电影下载（DVD）
新新影院，DVD大片免费下载几十部，手机注册可看更精彩影片！1角一部 http://51xinxin.126.com
Re: Chrony rtc broken?
John Hasler <[EMAIL PROTECTED]> writes: > Could someone who is running chrony 1.20 please test the rtc commands for > me? You'll need 'Enhanced Real-time Clock Support' in the kernel and will > need to uncomment the rtcfile line in /etc/chrony/chrony.conf. Posting the > output of the rtcdata command in chronyc would suffice. > -- > John Hasler > [EMAIL PROTECTED] > Dancing Horse Hill > Elmwood, Wisconsin Hi, i just uncommented the rtcfile option and restarted chrony. Hope this info is useful. chrony version V1_20, copyright (C) 1997-2002 Richard P. Curnow chrony comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public License version 2 for details. chronyc> rtcdata RTC ref time (UTC) : Thu Dec 11 20:19:38 2003 Number of samples : 3 Number of runs : 0 Sample span period : 32 RTC is fast by : 0.904526 seconds RTC gains time at : 9.843 ppm chronyc> -- It does me no injury for my neighbor to say there are twenty gods or no God. It neither picks my pocket nor breaks my leg. -- Thomas Jefferson
Re: OT: Smartcards and Physical Security
On Wed, Dec 03, 2003 at 09:32:37AM -0600, Manoj Srivastava wrote: > On Wed, 3 Dec 2003 14:17:18 +1100, Russell Coker <[EMAIL PROTECTED]> said: > > > On Wed, 3 Dec 2003 12:34, Don Armstrong <[EMAIL PROTECTED]> > > wrote: > >> The problems associated with them aren't too terribly different > >> from those associated with keys or other forms of physical > >> security, notably, that they can be stolen, or the output from them > >> duplicated. > > > Using a smart-card means that logging in does not merely require > > "something you know" but also "something you have". All the good > > security guides say that security should depend on "something you > > know and something you have", smart-cards plus a password meets this > > criteria. > > An even better security guideline is "something you are" -- so > should we not spring for retinal scanners/fingerprint readers/other > buiometrics? I mean, we _are_ talking about other peoples money. :P > > > > GPG smart-cards are entering the market. If GPG is crackable then > > we have lost regardless. If GPG is secure then GPG smart-cards will > > do as long as they are not stolen. Having revokation proceedures > > for stolen cards and DD's reliable enough to follow them should deal > > with this. > > Laptops with biometric print readers are supposed to be around > the horizon as well. So let's get one such sponsored for every DD ? Friendly, Sven Luther
Re: OT: Smartcards and Physical Security
Sven Luther dijo [Thu, Dec 11, 2003 at 09:04:43PM +0100]: > > > GPG smart-cards are entering the market. If GPG is crackable then > > > we have lost regardless. If GPG is secure then GPG smart-cards will > > > do as long as they are not stolen. Having revokation proceedures > > > for stolen cards and DD's reliable enough to follow them should deal > > > with this. > > > > Laptops with biometric print readers are supposed to be around > > the horizon as well. > > So let's get one such sponsored for every DD ? I would ask for an extra one - I don't like to lug my computer around every day, and I often do Debian-related work either at home or at my office. I think each DD should at the very least get two such machines. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Wed, Dec 10, 2003 at 10:29:24PM -0800, Marc Wilson wrote: > On Wed, Dec 10, 2003 at 12:31:17PM +, Andrew Suffield wrote: > > We don't have to map them onto anything. We just have to pass them > > through to the menu methods in a fashion that allows them to generate > > .desktop files. > > Other way around. You have to pass .desktop files through to the > menu-methods in a fashion that allows them to generate menus digestible to > applications not supporting .desktop files. You seem to have lost the context. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: APT-Fu 0.2.3
Miles Bader <[EMAIL PROTECTED]> wrote:
>
> I guess that makes sense, if you interpret it as meaning something like
> `Hard work is the partner of success' -- which sort of works with `apt'
> too (partner of apt?).
I don't think that derivation is correct. The `fu' really has no
meaning in the original meaning of the word `kung-fu', which is
simply time spent doing things.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: mozilla 1.6b with gtk2 and anti-aliasing
* Thomas E. Vaughan wrote: > Would anyone be able to point me to a deb of the latest mozilla, > 1.6b, configured to use gtk2 and anti-aliased page rendering? If > not, then I would appreciate any help or pointer to documentation > for compiling 1.6b from source so as to achieve the desired effect. Take the diff.gz from 1.5-3, apply it to the source of 1.6b, add a new changelog entry, and hope it compiles fine. Norbert
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Bruce Sass <[EMAIL PROTECTED]> > On Wed, 10 Dec 2003, Henning Makholm wrote: > > Have you quantified the "bloat" you are speaking about? Can the same > > argument not apply to any i18n effort? > Yes, using KDE2. The script removed any lines with "[""]" in > them from KDE files (was possible at the time without incurring > breakage) Then it's not the format you're opposing, but the inclusion of extra content in the .debs. -- Henning Makholm "Monarki, er ikke noget materielt ... Borger!"
Re: Building Debian Completely From Source
> >> In late 2001, I spent several weekends hand-building quite a large > >> chunk of woody (over 200 source packages). I found quite a number of > >> serious bug in several packages, including missing Build-Deps, and, in I've spent most of 2002 rebuilding packages from source. Looking back, apparently I filed about 400 bugreports with FTBFS. http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=submitter&data=dancer%40netfort.gr.jp&archive=yes I've not done much this year, due to relocating and other things going on. regards, junichi
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Isaac Clerencia <[EMAIL PROTECTED]> > I sincerely hope that some day further development of Debian's great > package management system will make localepurge fully obsolete. I've been wondering whether the Right solution to this kind of problems might be to invent some concept of "glue packages". In technical terms, that would be a way to tell apt-get and its ilk things like: - If frobnitz and locale-danish are both installed, then automatically try to install frobnitz-i18n-da. - If frobnitz and emacsen are both installed, then automatically try to install frobnitz-el. - If libx11 and tetex-base are both installed, then automatically try to install xdvi. - If ispell and locale-danish are both installed, then automatically try to install idanish. Then by installing appropriate locale-XXX packages, one would automatically pull in i18ns for the specified language for all packages that have been translated. Nobody would get bloated with translations of pacakges they don't use or translatations to languages they don't read. Most of the glue packages should be in a special section where they don't show up in package-selection interfaces. Possible exceptions would be things like idanish above - it's quite plausible to want Danish spell checking without also wanting one's tools in general to attempt to speak Danish in status and error messages. Since many glue packages will individually be quite small, some implementation engineering will be necessary in order to prevent bloat my maintainer scripts and standard /usr/share/doc/* contents. Some kind of by-demand distribution and assembly of Packages files might also be necessary in practise. -- Henning Makholm"Nej, hvor er vi altså heldige! Længe leve vor Buxgører Sansibar Bastelvel!"
Changes in formal naming for NetBSD porting effort(s)
[ CCing Debian Project Leader and Secretary, to ensure that they have the ] [ chance to speak to the topic, even if they don't see it on the mailing ] [ lists. ] On December 2nd, I was contacted by Luke Mewburn, on behalf of The NetBSD Foundation, asking about the "transition" to calling the NetBSD port "Debian GNU/KNetBSD", and expressing their appreciation for this change, as it reflects (in their opinion) a more accurate statement about what the system is, and avoids any potential dilution of the NetBSD trademark. I explained that "Debian GNU/KNetBSD" was actually a separate effort, primarily by Robert Millan, to port Debian to a system consisting of NetBSD's kernel (thus, 'KNetBSD') and a ported GNU libc, while the other effort was aimed at a NetBSD kernel and native NetBSD libc. I did, however, say that I (at least) would be happy to try to find a name they found equally suitable, for the same reasons, rather than continue to use the current one. On December 3rd, Mr. Mewburn confirmed that The NetBSD Foundation would prefer to see the name changed, and I brought the issue up on the debian-bsd mailing list for discussion. After a good discussion that covered a variety of topics that went beyond the port name, but covered important related issues, I made the following proposal, which has received no objections for one week (Mr. Millan did make one request regarding the design of patches, which is not in conflict with the proposal): - For the porting effort formerly known as "Debian GNU/NetBSD" or "Debian GNU NetBSD/i386", the following four identifiers will be used: 1) 'uname -s' will be 'NetBSD' (this is unchanged). 2) 'uname -v' will have the name 'Debian' in it at an appropriate place, so that it is possible to determine a full set of system information solely from uname. (This is somewhat flexible due to possible changes in the NetBSD implementation of the concept of 'vendor'). 3) The GNU config triple will have '-netbsd-gnu' as it's third part. (This is unchanged - and don't blame me for a 4-part triplet. I didn't start it, merely maintained consistancy with -linux-gnu). 4) The Debian port name will become 'Debian GNU/KLNetBSD(i386)'[1]. - [1] i386 target, Kernel+Libc of NetBSD, GNU userland, Debian distribution I'm not entirely certain what else, if anything, is required to make these changes (except updating the web pages, which will obviously have to wait until the normal method of doing so has been restored), since the origional decision on the port name was relatively informal. If anyone objects, or wishes to see further requirements met, please let me know, and I'll do what I can to resolve the situation. Please note that all of my discussions with The NetBSD Foundation, and it's representatives, have been both cordial and productive, to date, and that I feel their request is born largely of having seen an example which they preferred, rather than any antipathy towards the Debian project as a whole, or the various BSD porting efforts under it. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgprBbq6Dy2mk.pgp Description: PGP signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Andrew Suffield <[EMAIL PROTECTED]> wrote: > On Wed, Dec 10, 2003 at 10:29:24PM -0800, Marc Wilson wrote: >> On Wed, Dec 10, 2003 at 12:31:17PM +, Andrew Suffield wrote: >> > We don't have to map them onto anything. We just have to pass them >> > through to the menu methods in a fashion that allows them to generate >> > .desktop files. >> Other way around. You have to pass .desktop files through to the >> menu-methods in a fashion that allows them to generate menus digestible to >> applications not supporting .desktop files. > You seem to have lost the context. Why, how? *If* Debian is supposed to switch to .desktop (instead of enhancing the Debian menu format) the only sensibl possibiltiy is to make menu be able to use .desktop as input. Once that is there any package can switch at its convenience (if it there are benefits for the package). The other possibilities (Throw away menu, dump all windownagers not supporting .desktop, implement .desktop support for all all windowmanagers) are imho clearly unrealistic. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
No list archives getting updated at all
It isn't just debian-boot; none of the lists I checked at random have been updated past that date and time. No responses have been logged in the audit trail either, which for an 'important' severity is disturbing. listarchives maintainers, hello? Can we get some kind of response, just to let us know that these bug messages are reaching you, not being dropped, not being ignored, not hung up in a mail gateway somewhere?
Re: No list archives getting updated at all
Phil Edwards <[EMAIL PROTECTED]> writes: > It isn't just debian-boot; none of the lists I checked at random have > been updated past that date and time. No responses have been logged in > the audit trail either, which for an 'important' severity is disturbing. If you're looking for an up-to-the-minute archive of Debian lists, check out the nntp server at gmane.org. Visit www.gmane.org for details. (I'm not saying that the lists shouldn't be archived by Debian, but that's a good place to look, too.)
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Thu, 11 Dec 2003, Henning Makholm wrote: > Scripsit Bruce Sass <[EMAIL PROTECTED]> > > On Wed, 10 Dec 2003, Henning Makholm wrote: > > > > Have you quantified the "bloat" you are speaking about? Can the same > > > argument not apply to any i18n effort? > > > Yes, using KDE2. The script removed any lines with "[""]" in > > them from KDE files (was possible at the time without incurring > > breakage) > > Then it's not the format you're opposing, but the inclusion of extra > content in the .debs. Almost correct... I don't think it is appropriate, or fair, that those not using KDE or Gnome should need to deal with KDE/Gnome specific stuff when there are other options. The existing menu data format has a potential problem in that the entries could get too big (too long a line), so a different format wouldn't hurt and may even be a necessity at some point. A single label=value(s) per line, as is used with the freedesktop standard, should be able to handle any amount of menu data items and any reasonable number of values per item. (as you may have noticed) I have a problem with keeping all possible menu data items for an enty in one file. Splitting the menu entry data into generic, KDE, and Gnome 'bins' is a more complex solution than keeping everything in one file, but I don't think the computer cares (and programmers who can't handle it should probably not be doing system level infrastructure programming, eh). Since bloating packages by distributing the generic, KDE and Gnome bits in separate files is almost as bad as forcing all menu consumers to process one large file, it makes sense to distribute the data as one file in the .deb and split it up during installation. Splitting up an all inclusive menu data file into 'bins' should be relatively trivial: generic items go into /usr/lib/menu/, X-KDE|GNOME-* items go into /usr/lib/menu/desktop/kde|gnome/, everything else goes into /usr/lib/menu/desktop/. The only coding needed would be: a program to install the menu data into the appropriate bins, and the KDE/Gnome menu-methods would need to look for more data when building their menues. Ideally, /usr/share/applications and /usr/share/applnk (and the Gnome equivalent) would either disappear or be generated... keeping them as installation targets makes it difficult, if not impossible, to provide system-wide overrides to the packaged menu data. - Bruce
Re: Initrd and software raid [was: Initrd rocks!]
On Wed, Dec 10, 2003 at 09:48:55AM +0100, Florent Rougon wrote: > autodetection to manual setting in my GRUB config files and am happy > with this setup (I hate black magic). Black magic can be good for multi path io, sans and generally for a unattended reboot on hardware changes. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)
On Wed, Dec 10, 2003 at 09:26:39PM +1100, Herbert Xu wrote: > If you don't have the underlying devices there RAID autodetection > will not work. Well, if you have no devices, you cant detect them. However, on boot you most likely do have the devices. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Henning Makholm <[EMAIL PROTECTED]> Oops, possible meaning-disturbing typo: > implementation engineering will be necessary in order to prevent bloat > my maintainer scripts and standard /usr/share/doc/* contents. s/my/by/ -- Henning Makholm "Det er du nok fandens ene om at mene. For det ligger i Australien!"
Re: APT-Fu 0.2.3
Herbert Xu <[EMAIL PROTECTED]> writes: > > I guess that makes sense, if you interpret it as meaning something like > > `Hard work is the partner of success' -- which sort of works with `apt' > > too (partner of apt?). > > I don't think that derivation is correct. The `fu' really has no > meaning in the original meaning of the word `kung-fu', which is > simply time spent doing things. Well I certainly have no idea of the historical background of the word, but my `guessed derivation' does actually sort of make sense in that context... Do you have a dictionary that gives the historical derivation? -Miles -- Yo mama's so fat when she gets on an elevator it HAS to go down.
Re: [Firebird-devel] Orphaning Firebird RDBMS
W liście z śro, 10-12-2003, godz. 06:14, marius popa pisze: > Grzegorz B. Prokopski wrote: > > Hi! > > > > I haven't (seriously) used Firebird since a year and there's no chance > > I'll be using anytime soon. It's low maintenance software though as > > upstream is focused on firebird 1.5/2.0 > What involves the role of an debian package maintenance ? (more details) > Maybe this anouncement should be added on the firbird/ibphoenix web site > too... It'd be best if one was a Debian Developer already. Though if somebody is interested in becoming one - I can sponsor his uploads before he becomes a DD (only DDs can upload packages). Though not being a DD is not really a problem here. A candidate should at least be power user of Debian before he begins. He should follow procedure mentioned at: http://www.debian.org/devel/join/newmaint Cheers, Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org signature.asc Description: To jest =?iso-8859-2?Q?cz=EA=B6=E6?= listu podpisana cyfrowo
Processed: Reassign bugs to my new email address
Processing commands for [EMAIL PROTECTED]: > submitter 162663 ! Bug#162663: libc0.3-dev: depends on gnumach-dev which is priority optional Changed Bug submitter from "Brian M. Carlson" <[EMAIL PROTECTED]> to "Brian M. Carlson" <[EMAIL PROTECTED]>. > submitter 181494 ! Bug#181494: GNU Free Documentation License is non-free Changed Bug submitter from "Brian M. Carlson" <[EMAIL PROTECTED]> to "Brian M. Carlson" <[EMAIL PROTECTED]>. > submitter 183860 ! Bug#183860: general: many info files have license conflicts Changed Bug submitter from "Brian M. Carlson" <[EMAIL PROTECTED]> to "Brian M. Carlson" <[EMAIL PROTECTED]>. > submitter 152473 ! Bug#152473: toolame: creates stereo only Changed Bug submitter from "Brian M. Carlson" <[EMAIL PROTECTED]> to "Brian M. Carlson" <[EMAIL PROTECTED]>. > submitter 152791 ! Bug#152791: miscfiles: typos in constitution Changed Bug submitter from "Brian M. Carlson" <[EMAIL PROTECTED]> to "Brian M. Carlson" <[EMAIL PROTECTED]>. > submitter 154428 ! Bug#154428: RFP: ae -- Anthony's Editor -- a tiny full-screen editor Changed Bug submitter from "Brian M. Carlson" <[EMAIL PROTECTED]> to "Brian M. Carlson" <[EMAIL PROTECTED]>. > submitter 160706 ! Bug#160706: RFP: buildd -- Debian package build daemon Changed Bug submitter from "Brian M. Carlson" <[EMAIL PROTECTED]> to "Brian M. Carlson" <[EMAIL PROTECTED]>. > submitter 170583 ! Bug#170583: RFP: ghdl -- a VHDL simulator for designing electronic systems Changed Bug submitter from "Brian M. Carlson" <[EMAIL PROTECTED]> to "Brian M. Carlson" <[EMAIL PROTECTED]>. > submitter 183463 ! Bug#183463: gnupg: when sending large keyrings to server, should send in many small pieces Changed Bug submitter from "Brian M. Carlson" <[EMAIL PROTECTED]> to "Brian M. Carlson" <[EMAIL PROTECTED]>. > submitter 169413 ! Bug#169413: kernel-patch-ck: depends on kernel-patch-scripts which is priority extra Warning: Unknown package 'kernel-patch-ck' Changed Bug submitter from "Brian M. Carlson" <[EMAIL PROTECTED]> to "Brian M. Carlson" <[EMAIL PROTECTED]>. > thanks, control, and have a nice day Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: debian pxe dhcp netinstall (debconf enterprise fai etc.)
On Fri, Dec 05, 2003 at 08:21:29AM -0800, Paul Telford wrote: > On Fri, 5 Dec 2003, Chad Walstrom wrote: > > > I was intrigued by Progeny's autoinstall Python script, but never had a > > chance to look into it further. > > Progeny no longer maintains autoinstall, but I have picked it up and > continue to use, maintain, and enhance it. If you haven't looked at it in > a while it might be worth revisiting. I uploaded a new version a month or > two ago which fixes some of the deficiencies of previous versions. I was sorry to hear that Progeny had abandoned autoinstall. It had apparently neglected for a while, though, so I wasn't very surprised. It really is quite good, and could have been even better, I think. > I also received a comment from a user last week stating that they are > using autoinstall with PXE and it is working great. I'm using autoinstall > via a single 1.44M floppy every day to deploy various machines and it all > works as expected -- my machines are up and running in just a few minutes, > completely hands-free. Last year I used autoinstall to turn about a 100 old PC's into X terminals. With autoinstall and discover, I was able to get completely non-interactive installs. I used grub, though instead of PXE. (Most of the hardware was old, and very few, if any, of the the NIC's supported PXE.) grub can be built with network support, and it supported all the NIC's we had. It also loads the kernel and filesystem from the network faster than from floppy. :) ---Nathan
Re: No list archives getting updated at all
On Thu, Dec 11, 2003 at 06:37:57PM -0500, Phil Edwards wrote: > It isn't just debian-boot; none of the lists I checked at random have > been updated past that date and time. No responses have been logged in > the audit trail either, which for an 'important' severity is disturbing. > > listarchives maintainers, hello? Can we get some kind of response, just > to let us know that these bug messages are reaching you, not being > dropped, not being ignored, not hung up in a mail gateway somewhere? Yes, you guessed it, they do not seem to be reaching us... I traced the problem to the usual out-of-disk-space .mhonarc.db corruption, and am fixing it now. I'll get the mail problem fixed as well. -- 2. That which causes joy or happiness.
168在线网站推广：让您的网站家喻户晓！
尊敬的客户，您好！ 您的网站正在为您带来世界范围内的客户吗？ 您的网站正在为您增强品牌认知度吗？ 请选择168在线的网站推广服务（www.online168.net），您的网站将展现在中国甚至全世界的潜在客户面前，他们的需求，他们的合作设想正等待与您交汇！ 一、保定市俊杰网络发展中心经营的168在线网站作为搜索联盟、SOHU、SINA网的代理商，自2003年11月20日起至12月31日，推出五款网站推广优惠套餐，让您的网站在各大引擎都榜上有名！ 优惠内容如下： 套餐一：购买sohu普通登录+新浪快速登录一年（市场价格800元），我司优惠价格：630元！ 套餐二：购买新浪快速登录+网络实名一年+搜狐普通登录一年（1300元），我司优惠价格：980元！ 套餐三：购买搜狐排名登录（首页）（2500元/年），我司送新浪、网易、搜索联盟普通登录任选其二（价值1000元） 套餐四：购买搜狐排名登录（首页）+搜索联盟或网易排名登录（首页），市场价格5000元，我司优惠价格：3700元！ 二、如果您的公司还没有自己的独立网站！那么您同样可以优惠办理我们的主机业务，我公司为您提供的虚拟主机性能稳定可靠，性能先进！ 现在注册国际域名，送50M动态主机+企业邮局，仅150元/年 现在申请国际域名、200M动态主机+100M企业邮局，仅260元/年 详情请参考：http://www.online168.net/ http://www.online168.net [EMAIL PROTECTED] 电话：0312-7980126 保定市俊杰网络发展中心 李燕
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Bruce Sass wrote: > On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: >> Freedesktop standard supporting >> systems are probably used by 90% of all Debian desktop users. > > Unsubstantial, and probably bullshit. Maybe you are just incapable of finding arguments and have to resort to bad language? Highly probable. > Because nobody but KDE and Gnome use those features and they > already support .desktop files. How would e.g. the lyx debian package get an i18nized menu entry into the menu of either KDE or Gnome. YOU HAVE TO PROVIDE A DESKTOP FILE IF YOU WANT A DECENT MENU. So your approach doubles the work for all people, because we now need two menue entry files. Onde freedesktop and one for Bruce. > True, but everyone except KDE and Gnome will toss out the freedesktop > features. Processing bloated .desktop files just to toss the > results is a waste of resources. How long does it take to strip a few information lines of let's exaggerate 6000 menu entries? Even a bash script on an old system wouldnt take long. Use perl and you won't even notice a delay. > older -> stability > simpler -> faster, less resources hungry nonstandard -> less stable, more work for maintainers simpler -> hardly a CPU speed problem on today's desktop machines, also e.g. KDE can process all the menu files it brings in about 10 secson an Athlon-600MHz. > >> I don't understand how anyone can not support this change. > > Because: > > Nobody benefits from the transition... not even KDE or Gnome, since > they already support the features the freedesktop standard brings to > the table. Debian would profit. Debian users would have a complete menu. Maintainers would be able to use upstream information for the menue entries. > also > > There is currently no way to provide system-wide alternates to the > distributed .desktop files. Only having per-user customisation > available really, really, sucks, imo. PArsing error? What is this problem? > and > > I regularily use KDE, UWM, pdmenu, and Fluxbox, I also have twm, xfce > and mwm installed... processing the menues takes too much time and > resources as it is, and you want to use up more, for what gain? Jesus, how often do you update your fscking menus? thrice daily? -- Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. (ANATOLE FRANCE)
售邮件地址及大型软件源代码,价低！
您只要支付100元便可轻松拥有包括3亿个邮件地址和上百种已注册的网络营销软件的大礼包！！！ 产品清单：1、邮件地址 行业邮件地址：8100万 地区邮件地址：4700万 综合邮件地址：12000万 国外精选地址：15000万 2、营销软件 （1）包括金蜂、科特、科蓝、E-MAIL邮件大师、亿虎、商舟、全球、先进等等 推荐使用亿虎、科特、搜易、商舟。（共54款） （2）Email特工、疯狂、核心、科特、商贸快车、商舟、伊妹捕捉、伊妹儿扫描器,等等 推荐使用亿虎和搜易套装里的搜索工具（共15款） （3）登录奇兵 V3.01注册版(附正版数据库) Fluid promotion、submitwolf、搜索引擎集群登录（共4款） 只要100元您便可更轻松更快捷的实现以下功能： 1、推广单位业务、服务项目。 2、介绍企业新产品、供求信息。 3、宣传企业形象、树立品牌。 FTP地址： ftp://219.156.109.15 另出售为OA办公软件及源代码不限用户！！！软件200元起！！！ 试用地址：http://lkoa.lkpower.com user:manager password: aaa 出售大型软件源代码!(附清单) 1、邮件服务器 2、医院管理系统（网络版全部代码） 3、局域网QQ源代码 4、医疗保险系统 5、客户关系管理 6、PB医院管理系统 7、TOP ERP系统源代码 8、DELPHI进存销系统源代码 9、KTV点歌系统 10、LOTUS网络办公系统源代码 11、VB ERP系统 12、宝石售饭系统代码 13、点石财务软件代码 14、多媒体教室全套代码 15. 酒店管理系统全部代码 16. 连销药店管理 17. 企业管理套件 18. 新开元酒店管理系统 19. 验布系统 20. 速达ERP完整代码 21.HIS医院管理系统 22.档案管理 23.典当综合业务管理系统 24.医院信息管理系统－开发文档及库结构 25.胜龙进销存源码 26.医药卫生综合管理系统 27.医院X光片资料管理系统―全部源码 28.小诸葛商务管理软件 29.图书管理 30.简单的固定资产管理系统 (sql+ado) 31.三层物资管理程序源代码(含设计文档) 32.医院管理源码 33.飞扬商业管理系统 34.陶清医院系统 35.配件公司erp 36.人力资源管理 37.创业医院系统 38.人事考勤工资系统 39.进销存 40.金科信财务软件 41.中国酒店2000 42.联众HIS管理系统 43.医院系统(很全面) 另有其它小型代码,不再详细列举 联系方式：QQ：3297789 EMAIL： [EMAIL PROTECTED]
发票
您好！ 我公司业务经营广泛，因进项有余额，可为贵公司低价代开： 1.普通商品销售发票， 2.增值税专用发票（电脑版）， 3.海关代征增值税专用缴款书、海关进口关税专用缴款书、 海关进口货物报关单， 另有广告业发票、建筑安装发票、其他服务行业发票、交通运输发票等。 如有需要，请来电联系： 13537820152 李先生
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Cameron Patrick wrote: > On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: > > | > Because you gain *nothing* > | > | Are you claiming that everyone who says that .desktop has technical > | advantages is a liar? These features actually do not exist in the > | desktop format? (It may be so; I have no firsthand information, but it > | does sound far out). > > Most of the advantages of .desktop that I am aware of are currently > vapourware - i.e. they're in the specs on the freedesktop.org site, but > not yet implemented in KDE and Gnome. This is not true. Almost all features are being used in current KDE and to some degree by current GNOME. Could you please give examples? -- Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. (ANATOLE FRANCE)
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 04:12:58AM +0100, Moritz Moeller-Herrmann wrote: | Cameron Patrick wrote: | | > On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: | > | > | > Because you gain *nothing* | > | | > | Are you claiming that everyone who says that .desktop has technical | > | advantages is a liar? These features actually do not exist in the | > | desktop format? (It may be so; I have no firsthand information, but it | > | does sound far out). | > | > Most of the advantages of .desktop that I am aware of are currently | > vapourware - i.e. they're in the specs on the freedesktop.org site, but | > not yet implemented in KDE and Gnome. | | This is not true. Almost all features are being used in current KDE and to | some degree by current GNOME. Could you please give examples? The Categories= field (to place .desktop files into menu hierarchies) is AFAIK not used at all by KDE, although I think Gnome may support it. The freedesktop 'menu' standard (where sub-menus can be generated from the categories in the .desktop files, and which also claims to allow "legacy" menus to be merged with the new standard) doesn't seem to have been adopted yet by anyone. The worst part, though, is that currently both KDE and Gnome store their .desktop files in different places, so that a .desktop that is available to KDE (and placed in /usr/lib/applnk) won't automatically appear in the Gnome menu, which looks in /usr/lib/applications. I presume that these things are being worked on in later releases of KDE and Gnome, but I don't know where to look for the current status of their adoption of the freedesktop.org standards. I have also noticed what might be considered as 'abuse' of these standards, presumably due to poor implementation of some fields. For example, /usr/share/applications/epiphany.desktop lists its Name as "Web Browser"; it should more correctly list its name as "Epiphany" and have a GenericName field containing "Web Browser". Cameron.
XFS entering kernel 2.4 tree - Should the installer include support?
Hi, I am writing to -devel and not to -boot as I think this should be visible for most developers, as it can have a huge impact in our systems. I was reading [1] today that XFS is entering the 2.4 kernel tree - Being we still reasonably far from having Sarge releasable, what would you think on adding XFS support in our debian-installer? There are not many relevant (although they might be quite complicated) bugs in either xfs-progs or kernel-patch-xfs, and they will surely get attention from upstrean with this announcement... What do you think about this? I have never used XFS for my machines, but have heard quite a lot of good comments about it, and would like to see it available from the official d-i setup. Greetings, -- [1] http://kerneltrap.org/node/view/1751#comment -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: XFS entering kernel 2.4 tree - Should the installer include support?
* Gunnar Wolf <[EMAIL PROTECTED]> [2003-12-11 22:57]: > What do you think about this? I have never used XFS for my machines, > but have heard quite a lot of good comments about it, and would like > to see it available from the official d-i setup. XFS support for d-i has been discussed several times and there seem to be some people interested in doing this, see for example #221132. -- Martin Michlmayr [EMAIL PROTECTED]
