Unidentified subject!

[Don Armstrong]

clone 741573 -1
reassign -1 debian-policy
retitle -1 Deprecating menu files and transition to desktop files
thanks

In #741573, the CTTE has determined that Debian should use .desktop
files as appropriate.

We had intended that this decision would start a discussion of the
policy necessary to generate this transition, using the changes in
https://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479
(attached).

I'm now trying to start that discussion in the hopes of generating a
changeset to policy which in addition to incorporating the CTTE changes
provides the framework for an orderly transition from the Debian menu
system to desktop standard.

I hope that this will happen within the normal policy discussion
framework in a reasonable timeframe; baring that, I will implement the
CTTE decision by applying ba679bff76 and NMUing policy.

-- 
Don Armstrong  http://www.donarmstrong.com


From ba679bff76f5b9152f43d5bc901b9b3aad257479 Mon Sep 17 00:00:00 2001
From: Charles Plessy 
Date: Sat, 15 Feb 2014 11:12:30 +0900
Subject: [PATCH] Document the FreeDesktop menu entries and media type
 declarations.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The Debian menu is optionally supported.

Wording: Charles Plessy 
Seconded: Lisandro Damián Nicanor Pérez Meyer 
Seconded: Cyril Brulebois  (for the menu entries)
Seconded: Russ Allbery 
Closes: #707851
---
 policy.sgml | 200 +---
 1 file changed, 152 insertions(+), 48 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index dad8d23..1743552 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -8054,38 +8054,75 @@ Reloading description configuration...done.
 	Menus
 
 	
-	  The Debian menu package provides a standard
-	  interface between packages providing applications and
-	  menu programs (either X window managers or
-	  text-based menu programs such as pdmenu).
+	  Packages shipping applications that comply with minimal requirements
+	  described below for integration with desktop environments should
+	  register these applications in the desktop menu, following the
+	  FreeDesktop standard, using text files called
+	  desktop entries.  Their format is described in the
+	  Desktop Entry Specification at
+	  http://standards.freedesktop.org/desktop-entry-spec/latest/;>
+	  and complementary information can be found in the
+	  Desktop Menu Specification at
+	  http://standards.freedesktop.org/menu-spec/latest/;>.
 	
 
 	
-	  All packages that provide applications that need not be
-	  passed any special command line arguments for normal
-	  operation should register a menu entry for those
-	  applications, so that users of the menu package
-	  will automatically get menu entries in their window
-	  managers, as well in shells like pdmenu.
+	  The desktop entry files are installed by the packages in the
+	  directory /usr/share/applications and the FreeDesktop
+	  menus are refreshed using dpkg triggers.  It is therefore
+	  not necessary to depend on packages providing FreeDesktop menu
+	  systems.
 	
 
 	
-  Menu entries should follow the current menu policy.
+	  Entries displayed in the FreeDesktop menu should conform to the
+	  following minima for relevance and visual integration.
+
+	  
+	
+	  Unless hidden by default, the desktop entry must point to a PNG
+	  or SVG icon with a transparent background, providing at least
+	  the  size, and preferably up to 6464.  The icon
+	  should be neutral enough to integrate well with the default icon
+	  themes.  It is encouraged to ship the icon in the default
+	  hicolor icon theme directories, or to use an existing
+	  icon from the hicolor theme.
+	
+
+	
+	  If the menu entry is not useful in the general case as a
+	  standalone application, the desktop entry should set the
+	  NoDisplay key to true, so that it can be
+	  configured to be displayed only by those who need it.
+	
+
+	
+	  In doubt, the package maintainer should coordinate with the
+	  maintainers of menu implementations through the
+	  debian-desktop mailing list in order to avoid problems
+	  with categories or bad interactions with other icons.  Especially
+	  for packages which are part of installation tasks, the contents
+	  of the NotShowIn/OnlyShowIn keys should be
+	  validated by the maintainers of the relevant environments.
+	
+	  
 	
 
 	
-	  The menu policy can be found in the menu-policy
-	  files in the debian-policy package.
-	  It is also available from the Debian web mirrors at
-  http://www.debian.org/doc/packaging-manuals/menu-policy/;>.
+	  Since the FreeDesktop menu is a cross-distribution standard, the
+	  desktop entries written for Debian should be forwarded upstream,

Unidentified subject!

[Osamu Aoki]

-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100617160314.ga28...@debian.org

Unidentified subject!

[Osamu Aoki]

-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100617160318.ga28...@debian.org

Unidentified subject!

[MD ESRAK AHMOD ALEK]

k 
	

	
		 
Here’s a new way to find what you're looking for - Yahoo! Answers 

Unidentified subject!

[Michael Stone]

If Debian ever hopes to have a policy beyond all remaining uids and
gids are reserved for local use, 


I, for one, don't want too much of a policy beyond that. Debian should
not be in the business of staking claim on uid's. We need a minimal
number to bootstrap the system, but beyond that we should have no more
than *defaults* that can easily and painlessly changed to meet local
requirements.


it's important to stake our claim *before* 32-bit ids are universally
supported -- that is, before they're in widespread use at sites, and
site admins have already deployed schemas that conflict with any
default we might choose.


Too late. 32 bit uid's have been supported on other systems for years
(linux is actually way behind on this) so you're going to find a lot of
them in use. It doesn't take a very large organization to blow through
16 bits if you're doing sparse allocation (which is a generally good
idea). I do look forward to the day when it is no longer necessary to
support systems with a 16 bit uid restriction.

Mike Stone

Unidentified subject!

[Christopher . Lawrence]

ALCATEL SPACE
BO/EI/IA  --  Product Engineer
Tel : +33 (0) 4 92 92 64 32  /  Fax : +33 (0) 4 92 92 30 70
Porte : Y01-221  /  E-Mail : [EMAIL PROTECTED]

Unidentified subject!

[zhaoyan]

Unidentified subject!

[Joey Hess]

Colin Watson wrote:
 Seconded, with one proviso: can we standardize on the Compatible Secure
 BROWSER Definition from
 http://www.dwheeler.com/browse/secure_browser.html instead? This is what
 man-db implements for the 'man -H' switch; ESR-style BROWSER variables
 will still work as intended, but %c is added in order to permit a colon
 in commands and it specifies what shell escaping is to be performed on
 URLs to get rid of the hideous security flaws.

I assume you mean the compatible alternative and not the bare one
(though there's something to be said for the bare one; wrappers are not
hard to write).

First of all, it's possible to write a program that uses ESR's BROWSER
without passing the url through the shell. Here is a modification of my
sensible-browser program that does that:

--- sensible-browser~   2002-11-19 12:20:14.0 -0500
+++ sensible-browser2002-11-19 12:20:31.0 -0500
@@ -11,7 +11,7 @@
else {
$_.=' '.$url;
}
-   exec $_;
+   exec split ' ', $_;
# on failure, continue to next in list
}
 

Before:

[EMAIL PROTECTED]:~BROWSER='echo' ./sensible-browser 'http://;echo rm -rf /'
http://
rm -rf /

After:

[EMAIL PROTECTED]:~BROWSER='echo' ./sensible-browser 'http://;echo rm -rf /'
http://;echo rm -rf /

So is the increased complexity of making %s be converted to an escaped
absolute reference worth it? I note that the definition of escaped
absolute reference uses a hardcoded list of shell metacharacters to
escape. Such lists are often incomplete, I've seen exploits on bugtraq
of this kind of thing in the past. It seems easier to just program
defensively, not pull the shell into the picture, and not worry about
escaping.

The secure browser page does mention wanting to pass the BROWSER command
through the shell for backwards compatability (with what one wonders)
and to allow complicated shell expressions in BROWSER. I think that's a
bit of a non-starter; if you need something complicated you can
certianly write an external script. The complexity outweighs the gain.

How about we just add something like this to the proposal:

  When implementing BROWSER in a program, be careful to not pass the URL
  through the shell when running the browser commands, as the url might
  contain shell metacharacters and there could be security problems. If
  you must pass the URL through the shell, be careful to properly escape
  it first.

-- 
see shy jo


pgpVtLxhnP83E.pgp
Description: PGP signature

Re: Unidentified subject!

[Colin Watson]

On Tue, Nov 19, 2002 at 12:39:25PM -0500, Joey Hess wrote:
 Colin Watson wrote:
  Seconded, with one proviso: can we standardize on the Compatible Secure
  BROWSER Definition from
  http://www.dwheeler.com/browse/secure_browser.html instead? This is what
  man-db implements for the 'man -H' switch; ESR-style BROWSER variables
  will still work as intended, but %c is added in order to permit a colon
  in commands and it specifies what shell escaping is to be performed on
  URLs to get rid of the hideous security flaws.
 
 I assume you mean the compatible alternative and not the bare one

Yep, Compatible Secure BROWSER Definition above.

 First of all, it's possible to write a program that uses ESR's BROWSER
 without passing the url through the shell. Here is a modification of my
 sensible-browser program that does that:
 
 --- sensible-browser~ 2002-11-19 12:20:14.0 -0500
 +++ sensible-browser  2002-11-19 12:20:31.0 -0500
 @@ -11,7 +11,7 @@
   else {
   $_.=' '.$url;
   }
 - exec $_;
 + exec split ' ', $_;
   # on failure, continue to next in list
   }
  

[...]

Right, fair enough (although I'd prefer splitting and then appending
$url to the list, but the point stands).

 How about we just add something like this to the proposal:
 
   When implementing BROWSER in a program, be careful to not pass the URL
   through the shell when running the browser commands, as the url might
   contain shell metacharacters and there could be security problems. If
   you must pass the URL through the shell, be careful to properly escape
   it first.

Sounds good. Proviso withdrawn.

-- 
Colin Watson  [EMAIL PROTECTED]

Unidentified subject!

[zhaoyan]

尊敬的先生、小姐你好：
   如果这封邮件打扰了你、请凉解。
   
随着人们生活水平的提高，鸡、鸭、鱼、肉在也满足不了人们生活的需要。越来越多得人崇尚休闲食品。做为领导你可曾想到为员某一份福利，送一份休闲。作为经理你可曾想到利用休闲食品赚钱。作为加工企业你可曾想到利用深加工开拓市场，如果你想到的话别错过了如下机会：
山东乐陵盛产红枣，是全国红枣生产基地，是加工休闲食品的最好原料。 
乐陵红枣产于商周，兴于魏晋，早在清朝乾隆年间就成为贡品。乐陵红枣以金丝小枣为最佳，乐陵金丝小枣皮薄肉厚，肉质细腻，果皮呈深红色，皮薄而坚韧，皱纹浅细，金丝小枣每公斤400个左右，利于储存和运输。瓣开金丝小枣，可清晰的看到有果胶质和糖组成的金丝粘连于果肉之间，拉长1-2寸不断。据现代科学研究它含有人体所需的18种氨基酸和钙.磷.铁等微量原素，每100克果肉含卫生素700毫克。乐陵大红枣个大肉厚，色泽紫红，食后甘甜可口，具有增热补血，润肤养颜，营养神经，强身建体之功效。乐陵大枣曾先后出口日本.韩国.新加坡等国家，均受到各家外商的好评。我司以大红枣为原料生产乌枣（俗称黑枣），去核免洗大红枣，金丝蜜枣，以金丝小枣为原料生产去核免洗鸡心枣，阿胶蜜枣，均以其味美.质优.价格适中昌销国内外。
本公司现可供：
出口级 金丝蜜枣100吨，多种包装。内销金丝蜜枣150吨，多种包装。
金丝小枣1-3级，数量不限。
小包装各种礼品枣。
大红枣1-3级，数量不限。
乌枣（俗名黑枣）80吨。
鸡心枣50吨。
天然无核枣10吨。
深加工用等外大红枣1000吨。
酸枣  酸枣面  
   价格面议，欢迎合作。

如果你与我公司合作你将得到一份丰厚的回报。
  顺祝
 商祺
中国 山东乐陵杰康枣制品有限公司
 联系电话(TEL)：86-0534-6422519
  :  
 传真:(FAX)：86-0534-6227312

 地址：中国山东乐陵市振兴东路168号
 联 系 人：赵   言
   2002/9/12

Unidentified subject!

[list]

 [EMAIL PROTECTED]  Thu Aug 15 02:46:35 2002
X-Envelope-Sender: [EMAIL PROTECTED]
Received: (qmail 20605 invoked from network); 15 Aug 2002 07:46:27 -
Received: from unknown (HELO pub.foshan.gd.cn) (218.13.91.31)
  by murphy.debian.org with SMTP; 15 Aug 2002 07:46:27 -
From: =?GB2312?B?ueO2q8qht/DJvcrQ0vi71LTvu6/Rp7P9ubi8wdPQz965q8u+?=
 [EMAIL PROTECTED]
Subject: =?GB2312?B?zNW0ydG516m7+suuwOTPtc7euK/KtLP9ubg=?=
To: debian-policy@lists.debian.org
Content-Type: text/plain;charset=GB2312
Reply-To: [EMAIL PROTECTED]
Date: Thu, 15 Aug 2002 15:45:47 +0800
X-Priority: 3
X-Mailer: FoxMail 3.11 Release [cn]
X-Spam-Status: No, hits=0.1 required=4.7 tests=SUBJ_HAS_Q_MARK version=2.01

×ܾ­Àí£º
ÄúºÃ£¡

ÒÔÏÂÐÅÏ¢Óйء°ÌÕ´Éѹש»úË®ÀäϵÎÞ¸¯Ê´³ý¹¸¡±£¬Ï£ÍûÄÜΪÄúµÄÆóÒµ½â¾öÌÕ´Éѹש»ú³ý¹¸ÎÊÌâ¡£

ÓÉÓÚÌÕ´Éѹש»ú¹¤×÷ʱ£¬ÒºÑ¹ÓÍϵͳ²úÉú´óÁ¿µÄÈÈ£¬Îª±£Ö¤Ñ¹×©»úҺѹÓÍÓÍα£³ÖÔÚ25¡æ¡«40¡æ¶ÈÖ®¼ä£¬
ÖÆÔ쳧³ö³§Ê±¶¼Éè¼ÆÓÐË®Àäȴϵͳ¶ÔҺѹÓͽøÐнµÎ¡¢ÀäÈ´¡£Èç¹ûË®Àäϵ²»Äܼ°Ê±ÓÐЧµØ½øÐÐÈȽ»»»£¬»áʹÓÍ
ÎÂÉý¸ß£¬µ±ÓÍθßÓÚ55¡æʱ£¬¾Í»á×Ô¶¯Í£»ú£¬ÎÞ·¨Õý³£Éú²ú¡£ËùÒÔ£¬±£Ö¤Ñ¹×©»úË®ÀäϵͳµÄÉ¢ÈÈЧ¹û´¦ÓÚ×î¼Ñ
״̬£¬ÊÇÈ·±£Õų̂ѹש»úÕý³£ÔËÐеÄÖØÒªÒ»»·¡£
´Ó´óÁ¿µÄµ÷²é֤ʵ£¬Ä¿Ç°ÌÕ´ÉÆóÒµÔÚÓõÄѹש»ú»ù±¾É϶¼²ÉÓÃӲˮÀäÈ´£¬Ë®Öи÷ÖÖ¿óÎïÖÊ¡¢ÔÓÖÊÔÚѹש»ú
Ë®Àäϵ¹ÜÇ»ÄÚÈÕ»ýÔÂÀÛÓ°ÏìÈȽ»»»£¬ÑÏÖØʱ¾Í»á¶ÂÈûо¹Ü£¬Ó°ÏìÀäÈ´Ë®µÄÑ­»·£¬ÊÇÔì³Éѹש»úÓÍÎÂÆ«¸ß£¬Ñ¹Á¦
²»Õý³££¬»úÌå¹ýÈȵÄÖ÷ÒªÔ­Òò¡£

´«Í³µÄ½â¾ö·½·¨ÊDz𿪡¢½âÌå¡¢ÓÃÈ˹¤·½·¨Çå³ý£¬µ«·Ñ¹¤·ÑʱЧ¹û²»ÀíÏë¡£Èç¹ûÓÃÇ¿Ëá³ý¹¸¡¢ÓÉÓÚ¸¯Ê´ÐÔ
Ç¿£¬¶ÔÀäȴϵµÄо¹Ü¸¯Ê´É˺¦ÑÏÖØ£¬¼ÓÉÏѹש»ú±¾Éí¼Û¸ñ°º¹ó£¬´ó¶à³§Æó²»Ô¸ÒâÓÃÇ¿Ëá³ý¹¸£¬ÈçÓÃÇ¿Ëá³ý¹¸µÄ
·½·¨£¬Æ丯ʴÐÔ»á´ó´óµÄËõ¶Ìѹש»úË®ÀäȴϵµÄʹÓÃÊÙÃü¡£

Õë¶ÔÖÚ¶àÌÕ´ÉÆóÒµÕâÒ»ÄÑÌ⣬±¾¹«Ë¾Àú¾­¶àÄêµÄ¿ÆÑз´¸´ÊÔÑ飬ÑÐÖÆÉú²ú³öFB900ÐÍѹש»úҺѹÓÍÀäȴϵ
ͳ¹ÌÌå¸ßЧ³ý¹¸Áé¹¥ÆÆÁËÀúÊ·ÒÔÀ´ÓÃÇ¿Ëá¶ÒˮϡÊ͵ijý¹¸·½·¨¡£

¸Ã²úÆ·ÊôÖÐÐÔ£¬PHÖµ6.8£¬ÎÞ¶¾¡¢ÎÞ¸¯Ê´¡¢¶ÔÈËÌåÎÞº¦£¬¶Ô»·¾³ÎÞÎÛȾ£¬³ýÐâ¼°Ë®¹¸ÈܽâÂÊ´ï96%£¬¾­´óÁ¿
Óû§Ê¹ÓÃ֤ʵ¶ÔÀäȴϵµÄ½ðÊô¡¢Í­¡¢Îý¡¢Ï𽺼þ¡¢Ë®·âµÈÎÞÈκθ¯Ê´¡£²¢ÅäÓñ¾¹«Ë¾Éú²úµÄרÓÃÇåÏ´É豸YHD
 
-¢ñÐͳý¹¸»úÓ¦ÓÃÑ­»·ÇåÏ´£¬Õë¶Ôѹש»úË®ÀäȴϵͳµÄË®¹¸¡¢ÌúÐâ½øÐÐÇåÏ´×÷Òµ¡£¶ÔÓÚѹש»úÀäȴϵÓÉË®¹¸¡¢
ÌúÐâÒýÆðµÄÓÍÎÂÆ«¸ß¡¢ÓÍѹ²»Õý³£¡¢»úÌå¹ýÈÈÏÖÏóÄܳ¹µ×½â¾öÎÊÌâ¡£ÓøòúÆ·³ý¹¸³ýÐâÇåÏ´ºó¼ì²â¶Ô±È£¬ÓÍÎÂ
ÓÐÃ÷ÏÔϽµ£¬Äܽ«É¢ÈÈЧ¹û»Ö¸´µ½Õý³£Ë®Æ½¡£Ìî²¹ÁËÎÒ¹úѹש»úË®Àäȴϵͳ³ý¹¸¡¢³ýÐâ²»Ó÷ֲ𣬳ý¹¸¡¢³ý
Ðâ¡¢¶ÆĤһ´ÎÍê³ÉµÄ¸ßпƼ¼¹¥¹Ø¿ÎÌâµÄ¿Õ°×£¬ÎªÑ¹×©»úÆóÒµÓû§Ìṩ·½±ã£¬½ÚÊ¡´óÁ¿µÄάÐÞ·ÑÓ㬲¢Êܵ½¹ã
´óÌÕ´ÉÆóÒµµÄ»¶Ó­¡£

¼´Ê¹ÊǹóÆóÒµµÄÌÕ´Éѹש»úδÓÐÒÔÉÏËù½²µÄ²»Õý³£ÏÖÏó·¢Éú£¬Ã¿Ä궼Ӧ¶Ôѹש»úË®Àäȴϵͳ½øÐÐÒ»´Î³ý
¹¸¡¢³ýÐâ×÷Òµ£¬½â³ýË®¹¸¡¢ÐâÊ´¶ÔÉ豸µÄÉ˺¦¡¢ÑÓ³¤É豸ʹÓÃÊÙÃüΪÉϲߡ£   

±¾¹«Ë¾Í¬Ê±ÑÐÖÆÓÐÓ¦ÓÃÓÚ£ºÆû³µ¡¢ÄÚȼ»ú¡¢Ìú·ÄÚȼ»ú¡¢²ñÓÍ·¢µç»ú×é¡¢²ù³µ¡¢²æ³µ¡¢´¬ÓòñÓÍ»úרÓõÄ
Ë®Àäȴϵͳ³ý¹¸³ýÐâ¼Á¡£
»¶Ó­¹óµ¥Î»Ñ¡Ó㬱¾¹«Ë¾ÇåÏ´¹¤³Ì²¿ÓÐרҵÈËÔ±ÉÏÃÅΪ¹ã´óÓû§×öÇåÏ´·þÎñ¡£
¡¡






ÆóÒµÃû³Æ£º¹ã¶«Ê¡·ðɽÊÐÒø»Ô´ï»¯Ñ§³ý¹¸¼ÁÓÐÏÞ¹«Ë¾
ͨѶµØÖ·£º¹ã¶«Ê¡·ðɽÊлªÔ¶¶«Â·Æ½Ô­¹¤ÒµÇø
Áª ϵ ÈË£ºÁº¹ú»ù
¹«Ë¾ÍøÕ¾£ºhttp://www.cnyhd.com
[EMAIL PROTECTED]
µç»°ºÅÂ룺0757-3819087 
´«Õ棺0757-3960856


 

 


---ÒÔÉÏÓʼþÄÚÈÝÓëÖÐ×ÊÔ´ÍøÂç¼°Èí¼þ¿ª·¢ÉÌÎÞ¹Ø---
---
ÖÐ×ÊÔ´ÍøÂç--ÓòÃûÏÈ×¢²áºó¸¶¿î;Ö÷»úÏÈ¿ªÍ¨ºóÊÕ·Ñ¡£
ÉêÇë100MÐéÄâÖ÷»ú350Ôª/Ä꣬Ë͹ú¼ÊÓòÃû+5¸öÐÅÏä
http://www.263nic.com/
---
»¶Ó­Ê¹ÓÃÒÚ»¢EmailϵÁÐÈí¼þ
ÏÂÔصØÖ·: http://www.ehoosoft.com
¶¨ÏòÓÊÏäËÑË÷:  ÒÚ»¢EmailËÑË÷´óʦ
ÓʼþȺ·¢ÌØ¿ì:  ÒÚ»¢EmailÓʲî 
²¡¶¾Óʼþ¿ËÐÇ:  ÒÚ»¢Email°²È«´óʦ  
 .. 

Unidentified subject!

[list]

 [EMAIL PROTECTED]  Wed Aug 14 03:24:07 2002
X-Envelope-Sender: [EMAIL PROTECTED]
Received: (qmail 16381 invoked from network); 14 Aug 2002 08:24:03 -
Received: from master.debian.org (65.125.64.135)
  by murphy.debian.org with SMTP; 14 Aug 2002 08:24:03 -
Received: from (pub.foshan.gd.cn) [218.13.91.36] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 17etRk-0002Y5-00; Wed, 14 Aug 2002 03:24:04 -0500
From: =?GB2312?B?ueO2q8qht/DJvcrQ0vi71LTvu6/Rp7P9ubi8wdPQz965q8u+?=
 [EMAIL PROTECTED]
To: debian-policy@lists.debian.org
Content-Type: text/plain;charset=GB2312
Reply-To: [EMAIL PROTECTED]
Date: Wed, 14 Aug 2002 16:23:22 +0800
X-Priority: 3
X-Mailer: FoxMail 3.11 Release [cn]
Message-Id: [EMAIL PROTECTED]
X-Spam-Status: No, hits=0.0 required=4.7 tests= version=2.01


ÄúºÃ£¡


ÒÔÏÂÐÅÏ¢Óйء°ÌÕ´Éѹש»úË®ÀäϵÎÞ¸¯Ê´³ý¹¸¡±£¬Ï£ÍûÄÜΪÄúµÄÆóÒµ½â¾öÌÕ´Éѹש»ú³ý¹¸ÎÊÌâ¡£


ÓÉÓÚÌÕ´Éѹש»ú¹¤×÷ʱ£¬ÒºÑ¹ÓÍϵͳ²úÉú´óÁ¿µÄÈÈ£¬Îª±£Ö¤Ñ¹×©»úҺѹÓÍÓÍα£³ÖÔÚ25¡æ¡«40¡æ¶ÈÖ®¼ä£¬
ÖÆÔ쳧³ö³§Ê±¶¼Éè¼ÆÓÐË®Àäȴϵͳ¶ÔҺѹÓͽøÐнµÎ¡¢ÀäÈ´¡£Èç¹ûË®Àäϵ²»Äܼ°Ê±ÓÐЧµØ½øÐÐÈȽ»»»£¬»áʹÓÍ
ÎÂÉý¸ß£¬µ±ÓÍθßÓÚ55¡æʱ£¬¾Í»á×Ô¶¯Í£»ú£¬ÎÞ·¨Õý³£Éú²ú¡£ËùÒÔ£¬±£Ö¤Ñ¹×©»úË®ÀäϵͳµÄÉ¢ÈÈЧ¹û´¦ÓÚ×î¼Ñ
״̬£¬ÊÇÈ·±£Õų̂ѹש»úÕý³£ÔËÐеÄÖØÒªÒ»»·¡£

´Ó´óÁ¿µÄµ÷²é֤ʵ£¬Ä¿Ç°ÌÕ´ÉÆóÒµÔÚÓõÄѹש»ú»ù±¾É϶¼²ÉÓÃӲˮÀäÈ´£¬Ë®Öи÷ÖÖ¿óÎïÖÊ¡¢ÔÓÖÊÔÚѹש»úË®Àä
ϵ¹ÜÇ»ÄÚÈÕ»ýÔÂÀÛÓ°ÏìÈȽ»»»£¬ÑÏÖØʱ¾Í»á¶ÂÈûо¹Ü£¬Ó°ÏìÀäÈ´Ë®µÄÑ­»·£¬ÊÇÔì³Éѹש»úÓÍÎÂÆ«¸ß£¬Ñ¹Á¦²»Õý
³££¬»úÌå¹ýÈȵÄÖ÷ÒªÔ­Òò¡£


´«Í³µÄ½â¾ö·½·¨ÊDz𿪡¢½âÌå¡¢ÓÃÈ˹¤·½·¨Çå³ý£¬µ«·Ñ¹¤·ÑʱЧ¹û²»ÀíÏë¡£Èç¹ûÓÃÇ¿Ëá³ý¹¸¡¢ÓÉÓÚ¸¯Ê´ÐÔ
Ç¿£¬¶ÔÀäȴϵµÄо¹Ü¸¯Ê´É˺¦ÑÏÖØ£¬¼ÓÉÏѹש»ú±¾Éí¼Û¸ñ°º¹ó£¬´ó¶à³§Æó²»Ô¸ÒâÓÃÇ¿Ëá³ý¹¸£¬ÈçÓÃÇ¿Ëá³ý¹¸µÄ
·½·¨£¬Æ丯ʴÐÔ»á´ó´óµÄËõ¶Ìѹש»úË®ÀäȴϵµÄʹÓÃÊÙÃü¡£


Õë¶ÔÖÚ¶àÌÕ´ÉÆóÒµÕâÒ»ÄÑÌ⣬±¾¹«Ë¾Àú¾­¶àÄêµÄ¿ÆÑз´¸´ÊÔÑ飬ÑÐÖÆÉú²ú³öFB900ÐÍѹש»úҺѹÓÍÀäȴϵ
ͳ¹ÌÌå¸ßЧ³ý¹¸Áé¹¥ÆÆÁËÀúÊ·ÒÔÀ´ÓÃÇ¿Ëá¶ÒˮϡÊ͵ijý¹¸·½·¨¡£


¸Ã²úÆ·ÊôÖÐÐÔ£¬PHÖµ6.8£¬ÎÞ¶¾¡¢ÎÞ¸¯Ê´¡¢¶ÔÈËÌåÎÞº¦£¬¶Ô»·¾³ÎÞÎÛȾ£¬³ýÐâ¼°Ë®¹¸ÈܽâÂÊ´ï96%£¬¾­´óÁ¿
Óû§Ê¹ÓÃ֤ʵ¶ÔÀäȴϵµÄ½ðÊô¡¢Í­¡¢Îý¡¢Ï𽺼þ¡¢Ë®·âµÈÎÞÈκθ¯Ê´¡£²¢ÅäÓñ¾¹«Ë¾Éú²úµÄרÓÃÇåÏ´É豸YHD
 
-¢ñÐͳý¹¸»úÓ¦ÓÃÑ­»·ÇåÏ´£¬Õë¶Ôѹש»úË®ÀäȴϵͳµÄË®¹¸¡¢ÌúÐâ½øÐÐÇåÏ´×÷Òµ¡£¶ÔÓÚѹש»úÀäȴϵÓÉË®¹¸¡¢
ÌúÐâÒýÆðµÄÓÍÎÂÆ«¸ß¡¢ÓÍѹ²»Õý³£¡¢»úÌå¹ýÈÈÏÖÏóÄܳ¹µ×½â¾öÎÊÌâ¡£ÓøòúÆ·³ý¹¸³ýÐâÇåÏ´ºó¼ì²â¶Ô±È£¬ÓÍÎÂ
ÓÐÃ÷ÏÔϽµ£¬Äܽ«É¢ÈÈЧ¹û»Ö¸´µ½Õý³£Ë®Æ½¡£Ìî²¹ÁËÎÒ¹úѹש»úË®Àäȴϵͳ³ý¹¸¡¢³ýÐâ²»Ó÷ֲ𣬳ý¹¸¡¢³ý
Ðâ¡¢¶ÆĤһ´ÎÍê³ÉµÄ¸ßпƼ¼¹¥¹Ø¿ÎÌâµÄ¿Õ°×£¬ÎªÑ¹×©»úÆóÒµÓû§Ìṩ·½±ã£¬½ÚÊ¡´óÁ¿µÄάÐÞ·ÑÓ㬲¢Êܵ½¹ã
´óÌÕ´ÉÆóÒµµÄ»¶Ó­¡£


¼´Ê¹ÊǹóÆóÒµµÄÌÕ´Éѹש»úδÓÐÒÔÉÏËù½²µÄ²»Õý³£ÏÖÏó·¢Éú£¬Ã¿Ä궼Ӧ¶Ôѹש»úË®Àäȴϵͳ½øÐÐÒ»´Î³ý
¹¸¡¢³ýÐâ×÷Òµ£¬½â³ýË®¹¸¡¢ÐâÊ´¶ÔÉ豸µÄÉ˺¦¡¢ÑÓ³¤É豸ʹÓÃÊÙÃüΪÉϲߡ£   


±¾¹«Ë¾Í¬Ê±ÑÐÖÆÓÐÓ¦ÓÃÓÚ£ºÆû³µ¡¢ÄÚȼ»ú¡¢Ìú·ÄÚȼ»ú¡¢²ñÓÍ·¢µç»ú×é¡¢²ù³µ¡¢²æ³µ¡¢´¬ÓòñÓÍ»úרÓõÄ
Ë®ÀäȴϵͳµÄ³ý¹¸³ýÐâ¼Á¡£

»¶Ó­¹óµ¥Î»Ñ¡Ó㬱¾¹«Ë¾ÇåÏ´¹¤³Ì²¿ÓÐרҵÈËÔ±ÉÏÃÅΪ¹ã´óÓû§×öÇåÏ´·þÎñ¡£

¡¡ 
ÈçÄúµÄÌÕ´ÉÆóÒµÓÐÉÏÊöµÄÎÊÌâ»òÓÐÈκÎÒÉÎÊ£¬ÇëÄú·¢E-mail»òµ½ÎÒ¹«Ë¾ÍøÕ¾µÄÁôÑÔ±¾ÁôÏÂÄúµÄÁªÏµ·½·¨£¬ÎÒ
Ãǽ«»á×éÖ¯ÓйصÄר¼Ò¸øÄú×÷רҵµÄ½â´ð£¬²¢ÇÒ½«Í¨¹ýE-mail¸øÄú»Ø¸´£¬ÇëÄúËæʱÁôÒ⹫˾µÄÍøÕ¾£¬ÄúËùÌá³ö
µÄÎÊÌ⽫»áÔڴ˸øÄú×÷³öÏêϸµÄ»Ø¸´¡£Ð»Ð»ÄúµÄÖ§³Ö£¡ 






ÆóÒµÃû³Æ£º¹ã¶«Ê¡·ðɽÊÐÒø»Ô´ï»¯Ñ§³ý¹¸¼ÁÓÐÏÞ¹«Ë¾
ͨѶµØÖ·£º¹ã¶«Ê¡·ðɽÊлªÔ¶¶«Â·Æ½Ô­¹¤ÒµÇø
Áª ϵ ÈË£ºÁº¹ú»ù
¹«Ë¾ÍøÕ¾£ºhttp://www.cnyhd.com
[EMAIL PROTECTED]
µç»°ºÅÂ룺0757-3819087 

´«Õ棺0757-3960856


 

 


---ÒÔÉÏÓʼþÄÚÈÝÓëÖÐ×ÊÔ´ÍøÂç¼°Èí¼þ¿ª·¢ÉÌÎÞ¹Ø---
---
ÖÐ×ÊÔ´ÍøÂç--ÓòÃûÏÈ×¢²áºó¸¶¿î;Ö÷»úÏÈ¿ªÍ¨ºóÊÕ·Ñ¡£
ÉêÇë100MÐéÄâÖ÷»ú350Ôª/Ä꣬Ë͹ú¼ÊÓòÃû+5¸öÐÅÏä
http://www.263nic.com/
---
»¶Ó­Ê¹ÓÃÒÚ»¢EmailϵÁÐÈí¼þ
ÏÂÔصØÖ·: http://www.ehoosoft.com
¶¨ÏòÓÊÏäËÑË÷:  ÒÚ»¢EmailËÑË÷´óʦ
ÓʼþȺ·¢ÌØ¿ì:  ÒÚ»¢EmailÓʲî 
²¡¶¾Óʼþ¿ËÐÇ:  ÒÚ»¢Email°²È«´óʦ  
 .. 

Unidentified subject!

[skdjfh]

Unidentified subject!

[Denis Kosygin]

unsubscribe [EMAIL PROTECTED]

Unidentified subject!

[Adam Di Carlo]

To: Anthony Towns aj@azure.humbug.org.au
Cc: debian-policy@lists.debian.org
Subject: Re: Priorities
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED]
From: Adam Di Carlo [EMAIL PROTECTED]
Date: 20 Nov 2000 13:26:51 -0500
In-Reply-To: Anthony Towns's message of Fri, 20 Oct 2000 15:16:30 +1000
Message-ID: [EMAIL PROTECTED]
Lines: 36
User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Sorry I didn't really catch this mail, just now catching up.

Anthony Towns aj@azure.humbug.org.au writes:
 Well, what if I changed that to be say, Install enough packages for
 someone to get good use of  some type of hardware they have attached
 to their computer, described generically. So task-printer but not
 task-hp-laserjet-1100a-printer. So does that mean task-dialup
 should cope with all dialup access (ISDN, ADSL, cable, and whatever
 else), rather than having different tasks for each sort of home
 internet connectivity?

That's a good point. Perhaps task packges *should* have some
configuration logic insofar as they are helping the user fulfill
additional package dependancies which cannot be solved strictly with
Depends, etc.

 PErhaps dialup isn't a perfect name. Similarly task-x-core would
 seem to make sense in so far as letting you make use of your monitor
 goes. But it's somewhat different in that that just lets you use
 different programs, whereas printers and networks are somewhat more
 external.

Well, I think we need to step back, get debconf into Policy, and
perhaps think through how we're doing this sort of configuration.

I would note that these same problems are being confronted and dealt
with (on a somewhat lower level) by the boot-floppies replacement
effort on debian-installer.

I would further reiterate my believe that hardware configuration
issues should not be solved strictly as a Debian problem, since it is
instead a general Linux problem (or Hurd, or whatever).

-- 
.Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/

Unidentified subject!

[Jason Gunthorpe]

unsubscribe 

Unidentified subject!

[maor]

0subscribe

Unidentified subject!

[maor]

0subscribe

Re: Shipping .texi sources in binary packages (was: unidentified subject)

[Adam P. Harris]

In article [EMAIL PROTECTED], Manoj Srivastava [EMAIL PROTECTED] writes:
 Santiago == Santiago Vila [EMAIL PROTECTED] writes:
Santiago The purpose of shipping the docs in binary packages is to
Santiago made them available to be read, not to be printed.

   And the purpose of the proposed change to Policy is that the
 documentation be available in a format amenable to further
 manipulation, so that it may be coaxed into formats more to the
 liking of the user, or to be printed (I still prefer reading long
 documents on paper)

Yes yes yes yes.  Source format is what someone is going to want, say,
if they feel like correcting a document and submitting a patch.  Or
adapting the document for some other (unforseen purposes).  And how
absurd it would be if someone asked, 'how do I print
/usr/doc/foo/blah.ps.gz' and we say, 'oh, /usr/doc is for viewing, not
for printing'.

Santiago Do you propose that .sgml replaces .html as our preferred
Santiago documentation format in the long run?

   Nope, nothing as radical as that. I just propose that of the
 primary (the preferred for for modification) happens to be sgml (or
 texi, or nroff, or whatever), then that be also available in *some*
 .deb package .

I agree, although I think it should be a should rather than a
must.

.A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/

Shipping .texi sources in binary packages (was: unidentified subject)

[Santiago Vila]

( Sorry for replying so late, the old Subject was not very appealing :-)

On 23 Sep 1998, Manoj Srivastava wrote:

   I suggest that the preferred source format of the
  documentation be also available. This means that we also ship
  texinfo, tex, and sgml versions of the documentation, as well as HTML
  formats (we may also ship man, info, ps formatted documentation too,
  but the source and HTML should always be there).

I would like to say that after modifying some of my GNU packages to ship
the docs in HTML format, I dislike very much the idea of modifying 
the policy to ship the .texi source too.

The problem I encountered was the following:

I first planned to modify my debian/rules files so that a symlink
for the .texi source is created from the debian/tmp/usr/doc/package-doc
directory to the real file. Then it would be just a matter of

cd debian/tmp/usr/doc/package-doc  texi2html -options foo.texi

and removing the foo.texi symlink afterwards.

Well, this didn't worked, because the .texi file included sometimes
another files like version.texi and such.

Therefore I had to create the html in place and move it to
debian/tmp/usr/doc/package-doc afterwards.

Some people propose that we ship .texi source in binary packages, but this
means that we would have to identify *all* those extra files that are
needed to generate the .html. This is a lot of (unneeded) work, IMHO.

So shipping the .texi source will not be as easy as some people think,
since there is not always a *single* file containing the source.
Sometimes there is even a Makefile to build the docs. Are we going to ship
a Makefile too? 

It seems to me that the general rule that source belongs to the source
package should apply here.

We should already ship .html as this is our preferred documentation
format (at least policy says so). Do we really need to make things more
complex than they are now?

Why don't we concentrate instead in finding a standard procedure for
registering html docs, our (already) preferred documentation format?

Thanks.

-- 
 cccf08cbc9ee0529a5daf71e890f0901 (a truly random sig)

Re: Shipping .texi sources in binary packages (was: unidentified subject)

[Manoj Srivastava]

Hi,
Santiago == Santiago Vila [EMAIL PROTECTED] writes:

 Santiago Some people propose that we ship .texi source in binary
 Santiago packages, but this means that we would have to identify
 Santiago *all* those extra files that are needed to generate the
 Santiago .html. This is a lot of (unneeded) work, IMHO.

Simple rule: ship all the  *.texi{nfo} files. Not that hard to
 do, I should think. Anyway, just looking at a makeinfo run pretty
 much tells one what to ship.

 Santiago So shipping the .texi source will not be as easy as some
 Santiago people think,

And not as hard as some people think either. Frankly, any one
 have problems identifying texi files should probably not be working
 as a Debian developer. We do have quality standards, don't we?

 Santiago since there is not always a *single* file containing the
 Santiago source.

So? This is a one time thing. Added the hint that the texinfo
 files have a unique suffix, that does the identification for us,
 partially. 

 Santiago Sometimes there is even a Makefile to build the docs. Are
 Santiago we going to ship a Makefile too?

makeinfoo on the top level info file works quite well. There
 is no need to ship the Makefile unless you so desire.

 Santiago It seems to me that the general rule that source belongs to
 Santiago the source package should apply here.

No. HTML is not a good format for printing. dvi files are not
 quite as portable as one would like (due to font issues)

 Santiago We should already ship .html as this is our preferred
 Santiago documentation format (at least policy says so). Do we
 Santiago really need to make things more complex than they are now?

Yes. With SGML, I can choose plain text, HTML, tex,
 postscript, or another SGML DTD. This is functionality that is not
 crrently guaranteed.

 Santiago Why don't we concentrate instead in finding a standard
 Santiago procedure for registering html docs, our (already)
 Santiago preferred documentation format?

That too is a useful thing to have. So is an easy way of
 generating nice, printable, documents. I should not have to download
 the whole source just for a teeny .texi or .sgml file.

manoj
-- 
 Flint Paper is insane.  I really respect that. Max
Manoj Srivastava  [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: Shipping .texi sources in binary packages (was: unidentified subject)

[Santiago Vila]

On 20 Oct 1998, Manoj Srivastava wrote:

  Santiago So shipping the .texi source will not be as easy as some
  Santiago people think,
 
   And not as hard as some people think either.

He, he, we are close to repeat the bash-essential discussion here ;-)

-- 
 8460b24dc2ac9d46432ccd8965300fbe (a truly random sig)

Re: Shipping .texi sources in binary packages (was: unidentified subject)

[Santiago Vila]

On 20 Oct 1998, Manoj Srivastava wrote:

  Santiago It seems to me that the general rule that source belongs to
  Santiago the source package should apply here.
 
   No. HTML is not a good format for printing. dvi files are not
  quite as portable as one would like (due to font issues)

The purpose of shipping the docs in binary packages is to made them
available to be read, not to be printed.

(BTW: What font issues are you talking about?)

  Santiago We should already ship .html as this is our preferred
  Santiago documentation format (at least policy says so). Do we
  Santiago really need to make things more complex than they are now?
 
   Yes. With SGML, I can choose plain text, HTML, tex,
  postscript, or another SGML DTD. This is functionality that is not
  crrently guaranteed.

I don't understand.

Do you propose that .sgml replaces .html as our preferred
documentation format in the long run?

Do you propose to convert all .texi to .sgml?

  Santiago Why don't we concentrate instead in finding a standard
  Santiago procedure for registering html docs, our (already)
  Santiago preferred documentation format?
 
   That too is a useful thing to have. So is an easy way of
  generating nice, printable, documents. I should not have to download
  the whole source just for a teeny .texi or .sgml file.

Well, .texi are not usually very tiny either.

We could make them available via uploads, but without including
them in any binary-package (using byhand in the .changes file).
and we could have some doc tree at ftp.debian.org and a tool to retrieve
the latest source from a given package.

If we include the .info, the .html and the .texi in binary packages, I'm
afraid we will the first Linux release to require DVDs for distribution.

-- 
 dcc79389fecd3d1b91c8f4202c6d8361 (a truly random sig)

Re: Shipping .texi sources in binary packages (was: unidentified subject)

[Antti-Juhani Kaijanaho]

On Tue, Oct 20, 1998 at 07:07:03PM +0200, Santiago Vila wrote:
[About DVI]
 (BTW: What font issues are you talking about?)

DVI is not a self-contained format.  It does not include font data, it
only refers to fonts (as in, select cccsc10 when ten-point Concrete
Small Caps is requested).  So, in order to view a DVI file you must
have the correct fonts installed.  And I'm not talking about X fonts,
I'm talking about Postscript or Metafont fonts; so you'll need teTeX
to view a DVI file.

 Do you propose that .sgml replaces .html as our preferred
 documentation format in the long run?

I would favour that.  HTML is too limited, and SGML can be converted
to HTML (with possible loss of information) at will.



Antti-Juhani
-- 
Antti-Juhani Kaijanaho A7 [EMAIL PROTECTED] ** URL:http://www.iki.fi/gaia/ 
**

   The FAQ is your friend.
Trust the FAQ.

Re: Shipping .texi sources in binary packages (was: unidentified subject)

[Manoj Srivastava]

Hi,
Santiago == Santiago Vila [EMAIL PROTECTED] writes:

 Santiago The purpose of shipping the docs in binary packages is to
 Santiago made them available to be read, not to be printed.

And the purpose of the proposed change to Policy is that the
 documentation be available in a format amenable to further
 manipulation, so that it may be coaxed into formats more to the
 liking of the user, or to be printed (I still prefer reading long
 documents on paper)


 Santiago Do you propose that .sgml replaces .html as our preferred
 Santiago documentation format in the long run?

Nope, nothing as radical as that. I just propose that of the
 primary (the preferred for for modification) happens to be sgml (or
 texi, or nroff, or whatever), then that be also available in *some*
 .deb  package .


 Santiago Do you propose to convert all .texi to .sgml?

This would not be easy.

As I said, put the sgml/texi/*roff format documentation, in a
 separate package if need be, and make it available to people who need
 it in non-html.

manoj

-- 
 I got into an elevator at work and this man followed in after
 me... I pushed '1' and he just stood there... I said 'Hi, where you
 going?'  He said, 'Phoenix.'  So I pushed Phoenix.  A few seconds
 later the doors opened, two tumbleweeds blew in... we were in
 downtown Phoenix.  I looked at him and said 'You know, you're the
 kind of guy I want to hang around with.'  We got into his car and
 drove out to his shack in the desert. Then the phone rang.  He said
 'You get it.'  I picked it up and said 'Hello?'... the other side
 said 'Is this Steven Wright?'... I said 'Yes...' The guy said 'Hi,
 I'm Mr. Jones, the student loan director from your bank... It seems
 you have missed your last 17 payments, and the university you
 attended said that they received none of the $17,000 we loaned
 you... we would just like to know what happened to the money?'  I
 said, 'Mr. Jones, I'll give it to you straight.  I gave all of the
 money to my friend Slick, and with it he built a nuclear
 weapon... and I would appreciate it if you never called me again.
 Steven Wright
Manoj Srivastava  [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: Unidentified subject! (fwd)

[Karl M. Hegbloom]

 Anthony == Anthony C Zboralski [EMAIL PROTECTED] writes:

Anthony On Fri, Sep 11, 1998 at 05:18:18PM +0200, Anthony
Anthony C. Zboralski wrote:
 hey is there an easy way to print info manuals?

Anthony No. In order to have acceptable quality output, you have
Anthony to use the TeXinfo source files.

 for manuals like libg++ i am not going to print everypages
 manually; maybe i am stupid and there is an easier way to do
 this but when i need to print a texinfo manual, i have to grab
 the package source, run configure and make dvi.

Anthony You could try getting policy extended to have .texi
Anthony sources (in a form suitable for texi2dvi) included in the
Anthony package (or in a separate documentation package) -
Anthony propose it on debian-policy@lists.debian.org

 I think that the .texi source belongs in the package source.  Why
 make yet another package out of things when it's already there?
 Perhaps there ought to be (ie, suggested by, but not required by
 policy) a debian/rules target for creating the .dvi or .ps, whenif
 the upstream Makefile doesn't perform that task adequately.

 muse
  It sure would be nice if someone would extend `gv' to have `Lectern'
  like keybinds, with searching and everything... and maybe some
  `info' keys too.  sigh  I've got a book about postscript, but
  haven't read it yet, and don't know C and X programming well enough
  to take it on yet. grin
 /muse

Re: Unidentified subject! (fwd)

[Anthony C. Zboralski]

On 22 Sep 1998, Karl M. Hegbloom wrote:

  Anthony == Anthony C Zboralski [EMAIL PROTECTED] writes:
 
 Anthony On Fri, Sep 11, 1998 at 05:18:18PM +0200, Anthony
 Anthony C. Zboralski wrote:
  hey is there an easy way to print info manuals?
 
 Anthony No. In order to have acceptable quality output, you have
 Anthony to use the TeXinfo source files.
 
  for manuals like libg++ i am not going to print everypages
  manually; maybe i am stupid and there is an easier way to do
  this but when i need to print a texinfo manual, i have to grab
  the package source, run configure and make dvi.
 
 Anthony You could try getting policy extended to have .texi
 Anthony sources (in a form suitable for texi2dvi) included in the
 Anthony package (or in a separate documentation package) -
 Anthony propose it on debian-policy@lists.debian.org
 
  I think that the .texi source belongs in the package source.  Why
  make yet another package out of things when it's already there?
  Perhaps there ought to be (ie, suggested by, but not required by
  policy) a debian/rules target for creating the .dvi or .ps, whenif
  the upstream Makefile doesn't perform that task adequately.

oh well, it is normal to have to download 11Megs of source code to create
the dvi files for egcs, libg++ and more..

info files are okay but they are not printable. I work a lot and i save
some time by reading docs in the subway or in my bed when my girlfriend is
asleep.

Re: Unidentified subject! (fwd)

[Manoj Srivastava]

Hi,
[I'm including a CC to the -doc group, in case someone there
has a comment on this]
Anthony == Anthony C Zboralski [EMAIL PROTECTED] writes:

 Anthony On 22 Sep 1998, Karl M. Hegbloom wrote:
 
  I think that the .texi source belongs in the package source.  Why
  make yet another package out of things when it's already there?

What other package? All that is suggested is that the
 preferred source of the documentation be also included, so it may be
 rendered into different formats; and the preferred document format,
 HTML, be included as well.

Are you suggesting that the binary-all packages, which may
 only contain shell scripts and perl scripts are redundant, since the
 full text of the scripts is already there in the source package?

  Perhaps there ought to be (ie, suggested by, but not required by
  policy) a debian/rules target for creating the .dvi or .ps, whenif
  the upstream Makefile doesn't perform that task adequately.

 Anthony oh well, it is normal to have to download 11Megs of source
 Anthony code to create the dvi files for egcs, libg++ and more..

You have a point.

 Anthony info files are okay but they are not printable. I work a lot
 Anthony and i save some time by reading docs in the subway or in my
 Anthony bed when my girlfriend is asleep.

I suggest that the preferred source format of the
 documentation be also available. This means that we also ship
 texinfo, tex, and sgml versions of the documentation, as well as HTML
 formats (we may also ship man, info, ps formatted documentation too,
 but the source and HTML should always be there).

manoj
-- 
 If you stop to think about it, you're already dead.
Manoj Srivastava  [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: Unidentified subject! (fwd)

[Anthony C. Zboralski]

-- Forwarded message --
Date: Fri, 11 Sep 1998 17:24:34 +0200
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: debian-devel@lists.debian.org
Subject: Re: Unidentified subject!

On Fri, Sep 11, 1998 at 05:18:18PM +0200, Anthony C. Zboralski wrote:
 hey is there an easy way to print info manuals?

No. In order to have acceptable quality output, you have to use the TeXinfo
source files.

 for manuals like libg++ i am not going to print everypages manually; maybe
 i am stupid and there is an easier way to do this but when i need to print
 a texinfo manual, i have to grab the package source, run configure and
 make dvi.

You could try getting policy extended to have .texi sources (in a form
suitable for texi2dvi) included in the package (or in a separate
documentation package) - propose it on debian-policy@lists.debian.org

Ray
-- 
ART  A friend of mine in Tulsa, Okla., when I was about eleven years old. 
I'd be interested to hear from him. There are so many pseudos around taking 
his name in vain. 
- The Hipcrime Vocab by Chad C. Mulligan