Work-needing packages report for Jul 4, 2003
Report about packages that need work for Jul 4, 2003 Total number of packages offered up for adoption: 64 Number of packages offered up for adoption this week: 1 Total number of orphaned packages: 193 Number of packages orphaned this week: 9 The number in parenthesis after each package name is the corresponding bug report number. Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages are orphaned: [NEW] abuse (#199543), orphaned 2 days ago Description: Crack dot Com's Abuse action game [NEW] abuse-frabs (#199547), orphaned 2 days ago Reverse Depends: abuse-sfx abuse-sdl abuse [NEW] abuse-lib (#199546), orphaned 2 days ago Description: Levels for Abuse Reverse Depends: abuse-sfx abuse-sdl abuse [NEW] abuse-sdl (#199545), orphaned 2 days ago Description: SDL-port of Crack dot Com's Abuse action game [NEW] abuse-sfx (#199544), orphaned 2 days ago (non-free) Description: Sound effects for Abuse [NEW] awesfx (#199241), orphaned 4 days ago Description: various utility programs for controlling AWE32/64 driver [NEW] gtkrecover (#199247), orphaned 4 days ago Description: GUI for recover [NEW] recover (#199250), orphaned 4 days ago Description: Undelete files on ext2 partitions Reverse Depends: gtkrecover [NEW] tao (#199772), orphaned yesterday Description: The ACE ORB Pente (#195686), orphaned 32 days ago Description: Five in a row game for X and the console addressbook (#174699), orphaned 185 days ago Description: Tk personal address manager agsatellite (#186978), orphaned 94 days ago Description: Audiogalaxy Satellite (installer) arpd (#191870), orphaned 60 days ago Description: User-space ARP daemon asis (#154095), orphaned 344 days ago Description: Ada Semantic Interface Specification Reverse Depends: gch asis-programs libasis-3.14p-1-dev axyftp (#192677), orphaned 55 days ago Description: A graphical ftp program with Lesstif interface bbdate (#190190), orphaned 72 days ago Description: Date tool for the blackbox window manager bbppp (#190188), orphaned 72 days ago Description: PPP tool for the blackbox window manager bbtime (#190191), orphaned 72 days ago Description: Time tool for the blackbox window manager bg5cc (#189818), orphaned 74 days ago Description: Big-5 wide-characters rectifier bg5ps (#189816), orphaned 74 days ago Description: A utility to print Chinese Big5/GB documents using TrueType fonts blackened (#175101), orphaned 182 days ago Description: A feature rich ircII based IRC client blatte (#188179), orphaned 86 days ago Description: a powerful text markup and transformation language calc (#175399), orphaned 179 days ago Description: An advanced calculator and mathematical tool for Emacs Reverse Depends: riece-ndcc catalog (#187128), orphaned 93 days ago Description: Tool to create,maintain and display Yahoo! like directories cbb (#166249), orphaned 252 days ago Description: The Check-Book Balancer, a Quicken clone cce (#189523), orphaned 76 days ago Description: Console Chinese Environment - display Chinese (GB) on console ccf (#189529), orphaned 76 days ago (non-free) Description: Chinese encodings (GB/Big5/HZ) conversion filter cedictgb (#189531), orphaned 76 days ago (non-free) Description: Chinese/English dictionary data file (GB) Reverse Depends: cedicttools cedicttools (#189530), orphaned 76 days ago Description: Various tools to use with the CEDict data cxhextris (#150862), orphaned 374 days ago (non-free) Description: Color version of hextris cxterm (#189817), orphaned 74 days ago (non-free) Description: KS supporting files for CXterm Reverse Depends: cxterm-big5 cxterm-jis cxterm-gb cxterm-ks distributed-net (#185016), orphaned 109 days ago (non-free) Description: A distributed.net client, proxy Reverse Depends: gkrelldnet distributed-net-proxy (#185016), orphaned 109 days ago Description: A distributed.net client, proxy doc-linux-zh-s (#189525), orphaned 76 days ago Description: Linux HOWTOs and mini-HOWTOs in Simplified Chinese in HTML docbook-to-man (#154590), orphaned 340 days ago Description: Converter from DocBook SGML into roff -man macros Reverse Depends: gtk-doc-tools dotfile (#192682), orphaned 55 days ago Description: The Dotfile Generator tcsh module Reverse Depends: dotfile-fvwm1 dotfile-elm dotfile-fvwm2 dotfile-fvwm1-ja dotfile-canna dotfile-fvwm2-ja dotfile-rtin dotfile-ipfwadm dotfile-tcsh dotfile-bash dotfile-procmail dvi2ps (#192686), orphaned 55 days ago Description: TeX DVI-driver for NTT jTeX, MulTeX and ASCII ptex. Reverse Depends: dvi2ps-fontdesc-morisawa5
(Pre)-Announcing Debian Subproject for Nonprofit Organizations
Greetings, We're sending this message to alert developers of a potential Debian subproject aimed toward desktop use in non-profit organizations, particularly small ones. We're also hoping to poll the interest for such a distribution -- especially from potential developers who might want to collaborate with us on the project. Over the last few years, we've dealt extensively with small non-profit organizations engaged in grassroots organizing, technological assistance, independent media, and educational work in a variety of areas. We see non-profits as a particularly important area to launch a subproject because many of these non-profits are already familiar with free and open source software, philosophies and development methodologies. If they are large and technically involved enough to need their own server, they probably already use GNU/Linux. However in day-to-day operations most use proprietary operating systems. Unlike many groups of users where advocacy is an uphill battle, many non-profits *want* to use GNU/Linux on their workstations but are waiting for someone to make it easy for them. We want to do just this. By putting together a sub-distribution that fulfills the needs of non-profits and pitching it as a solution *for them*, we hope to get many small organizations interested in the project. Most of these groups use their workstations for a limited and predictable set of tasks that include many areas of overlap with other sub-projects (word processing, book-keeping, email, maintaining contacts) plus other more specialized uses (fund raising, developing membership lists). With this project, we aim to create an easily installable customized Debian distribution with the needs of small non-profits in mind. In the future, we'd also like to develop several new applications geared to replace programs many non-profits use that are only available on proprietary operating systems. If you are interested in this project, please don't hesitate to read our web page[1] join our preliminary mailing list[2] and contribute on our wiki pages[3]. If you have experience with development (development in Debian in particular) and are interested in assisting, PLEASE email us our or our mailing list. Micah and I know that we cannot succeed this project alone won't start official work until we have enough people involved to know that we can do this correctly and successfully. If all goes well, you'll hear more from us soon. Regards, Benjamin Mako Hill [EMAIL PROTECTED] Micah Anderson [EMAIL PROTECTED] (NM) [1] http://nonprofit.debian.net [2] http://lists.yukidoke.org/mailman/listinfo/debian-np [3] http://wiki.debian.net/index.cgi?DebianNonProfit -- Benj. Mako Hill [EMAIL PROTECTED] http://mako.yukidoke.org/ pgp3ztZM1EXGv.pgp Description: PGP signature
Release-critical Bugreport for July 4, 2003
Bug stamp-out list for Jul 4 06:00 (CST) Total number of release-critical bugs: 975 Number that will disappear after removing packages marked [REMOVE]: 18 Explanation for bug tags: P pending + patch H help M moreinfo R unreproducible S security U upstream Some bugs have an additional set of tags indicating they only apply to a particular release: O for oldstable (potato), S for stable (woody), T for testing (sarge) or U for unstable (sid). -- Package: 3dwm (debian/main) Maintainer: Maurizio Boriani [EMAIL PROTECTED] 196332 [ ] 3dwm: [m68k] FTBFS: missing build-depends Package: acm (debian/main) Maintainer: Phil Brooke [EMAIL PROTECTED] 199587 [ ] acm: FTBFS: Broken Build-Depends on libgdbmg1-dev Package: adbbs (debian/main) Maintainer: Kai Henningsen [EMAIL PROTECTED] 190117 [ ] adbbs: Default Configuration Uses pine pico Package: adjtimex (debian/main) Maintainer: James R. Van Zandt [EMAIL PROTECTED] 199832 [ ] adjtimex doesn't build on s390 Package: af (debian/main) Maintainer: Malc Arnold [EMAIL PROTECTED] 195219 [ + ] af: FTBFS with gcc-3.3: Uses obsolete varargs.h Package: aime (debian/main) Maintainer: Ed Boraas [EMAIL PROTECTED] 172566 [ ] aime: fills up /var diskspace until it is overflowing Package: airsnort (debian/main) Maintainer: Noel Koethe [EMAIL PROTECTED] 189336 [ ] airsnort hangs with linux-wlan-ng Package: am-utils (debian/main) Maintainer: Philippe Troin [EMAIL PROTECTED] 191510 [ ] am-utils: Fails to build with current flex 199588 [ ] am-utils: FTBFS: Broken Build-Depends on libgdbmg1-dev Package: amavisd-new (debian/main) Maintainer: Brian May [EMAIL PROTECTED] 199479 [ ] amavisd-new: The couple postfix/amavisd-new can send viruses to innocents Package: amp (debian/non-free) Maintainer: Fredrik Hallenberg [EMAIL PROTECTED] 188343 [ ] amp: Fail to enter testing because of missing sparc and powerpc binary Package: animals (debian/main) Maintainer: Jim Lynch [EMAIL PROTECTED] 195404 [ ] animals: FTBFS with g++-3.3: strstream.h is gone Package: annoyance-filter (debian/main) Maintainer: Thomas Scheffczyk [EMAIL PROTECTED] 198203 [ ] annoyance-filter: [m68k] FTBFS Package: apache-ssl (non-US/main) Maintainer: Debian Apache Maintainers debian-apache@lists.debian.org 194334 [ ] apache-ssl: postint blows away configuration files Package: apache2-dev (debian/main) Maintainer: Thom May [EMAIL PROTECTED] 198607 [ ] apache2-dev: apxs2 fails due to missing values in file 'config_vars.mk' Package: apt (debian/main) Maintainer: APT Development Team [EMAIL PROTECTED] 188161 [ ] Better error message for E: Internal Error, Could not perform immediate configuration? 192403 [ + ] Fails to parse empty Packages file (E: Encountered a section with no Package: header) 192409 [P+ ] apt: segfault on blank line in /etc/apt/preferences 192702 [ ] problem with versioned conflicts (sysvinit/file-rc) Package: apt-build (debian/main) Maintainer: Julien Danjou [EMAIL PROTECTED] 192374 [ M ] apt-build can't find source when building Package: arla (non-US/main) Maintainer: Mikael Andersson [EMAIL PROTECTED] 198294 [ ] arla: FTBFS with gcc-3.3: Invalid preprocessor pasting Package: armagetron (debian/main) Maintainer: Andreas Bombe [EMAIL PROTECTED] 196990 [ ] armagetron: FTBFS with g++-3.3: strstream.h is gone Package: arson (debian/main) Maintainer: Mike Markley [EMAIL PROTECTED] 195214 [ ] arson: conflicts with a file from k3b Package: atari800 (debian/contrib) Maintainer: Dale Scheetz (Dwarf #1) [EMAIL PROTECTED] 193397 [ ] atari800_1.3.0-2(mipsel/unstable): out of date config.sub/config.guess Package: atlas (debian/main) Maintainer: Camm Maguire [EMAIL PROTECTED] 192990 [ ] atlas_3.2.1ln-7(unstable/arm): FTBFS Package: atmelwlandriver (debian/main) Maintainer: Paul Hedderly [EMAIL PROTECTED] 195886 [ ] FTBFS (unstable/all): Fails to unpack source archive during build Package: autoconf (debian/main) Maintainer: Ben Pfaff [EMAIL PROTECTED] 156259 [ ] [S] db4.0: does not build from source Package: autogen (debian/main) Maintainer: Luca Filipozzi [EMAIL PROTECTED] 194163 [ ] autogen: FTBFS: columns command not found Package: autoinstall-i386 (debian/main) Maintainer: Jeff Licquia [EMAIL PROTECTED] 169249 [ ] autoinstall-i386: fails to build on unstable 174559 [ ] autoinstall-i386: build depends on unavailable package busybox-source-0.60.0 Package: autolog (debian/main) Maintainer: Paul Telford [EMAIL PROTECTED] 188445 [ H] autolog has a gaping memory hole Package: avifile (debian/main) Maintainer: Zdenek Kabelac [EMAIL PROTECTED] 196980 [ ] avifile: FTBFS with g++-3.3: Class access error Package: ayttm (debian/main) Maintainer:
Debian menu encoding support
Hello Debian folks, This mail is mainly destined to maintainers of menu manager packages, i.e. packages that provide a menu-method file. It is now possible to select the encoding used to write files generated by menu in a menu-method. You just need to add outputencoding=enc in the menu-method file, where enc is a valid iconv encoding. For example to force output to be UTF-8 encoded, add outputencoding=UTF-8 For ISO-8859-1, outputencoding=ISO-8859-1 There is a special encoding LOCALE, which refers to the current locale encoding. It is very important that all menu methods get fixed to include such a field. This will allow menu translations to be activated by default. If you need help with your menu-methods format, please mail me. Also, since you are to modify the menu methods anyway, it look like a great time to go ahead and fix the two problems above: * Fix the menu-methods scripts for the various menu manager to - Do proper quoting of special characters in title and command. - Store generated menu in /var instead of /etc. Acknowledgement: I would like to thanks Morten Brix Pedersen for writing the code for the 'outputencoding' feature, Jose Manuel dos Santos Calhariz for testing encoding support in window managers, and all the translators of the menu sections names (the japanese translation is wanted!) Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. pgpIOsSfh7igi.pgp Description: PGP signature
Identifier le bogue (libpam0g)
Bonjour, Après avoir installé un serveur en stable, j'ai voulu mettre à jour KDE pour disposer de la version 3. J'ai donc fait : gargamel:~# apt-get install -t unstable kdebase The following extra packages will be installed: amor ark arts artsbuilder atlantik autoconf2.13 cpp-3.2 debconf defoma dialog e2fsprogs efax eyesapplet [liste de tous les paquets à mettre à jour] 75 packages upgraded, 188 newly installed, 31 to remove and 434 not upgraded. Need to get 0B/125MB of archives. After unpacking 162MB will be used. Do you want to continue? [Y/n] y E: Internal Error, Could not perform immediate configuration (2) on libpam0g Arrivé là (les paquets sont déjà chargés), j'ai fait : gargamel:~# apt-cache policy libpam0g libpam0g: Installed: 0.72-35 Candidate: 0.72-35 Version Table: 0.76-12 0 500 http://ftp.de.debian.org unstable/main Packages 0.76-9 0 500 http://ftp.de.debian.org sarge/main Packages *** 0.72-35 0 990 http://ftp.de.debian.org woody/main Packages 100 /var/lib/dpkg/status Donc je me dit que il y a un problème de dépendance au niveau de la version. gargamel:~# apt-get install -t testing libpam0g Je relance : gargamel:~# apt-get install -t unstable kdebase Et là, ça fonctionne ! Mais la question est : comment savoir le paquet qui nécessitait cette version de libpam0g (pour faire un BR) ? -- Michel Grentzinger OpenPGP key ID : B2BAFAFA Available on http://www.keyserver.net
Re: Identifier le bogue (libpam0g)
* Michel Grentzinger [EMAIL PROTECTED] [2003-07-04 17:12] : Bonjour, Après avoir installé un serveur en stable, j'ai voulu mettre à jour KDE pour disposer de la version 3. J'ai donc fait : [...] 75 packages upgraded, 188 newly installed, 31 to remove and 434 not upgraded. Need to get 0B/125MB of archives. After unpacking 162MB will be used. Do you want to continue? [Y/n] y E: Internal Error, Could not perform immediate configuration (2) on libpam0g [...] Et là, ça fonctionne ! Mais la question est : comment savoir le paquet qui nécessitait cette version de libpam0g (pour faire un BR) ? Il me semble qu'il s'agit du bogue #199660, donc pas besoin de créer un nouveau BR. Fred
Re: Identifier le bogue (libpam0g)
* Michel Grentzinger [EMAIL PROTECTED] [2003-07-04 17:12] : Bonjour, Après avoir installé un serveur en stable, j'ai voulu mettre à jour KDE pour disposer de la version 3. J'ai donc fait : [...] 75 packages upgraded, 188 newly installed, 31 to remove and 434 not upgraded. Need to get 0B/125MB of archives. After unpacking 162MB will be used. Do you want to continue? [Y/n] y E: Internal Error, Could not perform immediate configuration (2) on libpam0g Ah flute, répondu trop vite : les bogues #198618 et #198619 avaient déjà été créés pour ce bogue avant le bogue #199660. Fred
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 02:18:10AM +0200, Julien LEMOINE wrote: On Friday 04 July 2003 01:52, Andrew Suffield wrote: What do you propose ? Do you think Debian must keep old version of stunnel (3.x) for compatibility Given how it sounds like upstream are completely incompetent and have decided to gratuitously break compatibility, that sounds like a good idea. and do not include new version ? Why wouldn't you include the new version as well? Yes, keep the two versions of stunnel is probably the right way to handle this problem. Now the problem is that stunnel is uploaded in version 4 on stunnel package. What is the correct way to reintroduce stunnel for compatibility reasons ? uploading a new stunnel3 package will not resolve the problem. Epoch it and upload stunnel4 as a new package. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpWoPzFgPr3C.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Thu, Jul 03, 2003 at 04:49:19PM -0400, Joey Hess wrote: If I ever add filtering to the notes debconf allows to be displayed, notes that refer the user to README.Debian will be at the top of the list to never be displayed. Of course, I am much more likely to bow to the pressure of notes like the one you're apparently adding, and completly disable all notes at some point, rather than adding filtering. I don't like arms races. After seeing multiple attempts to use social pressure to encourage to stop the flood of debconf misusage, it's at times like this that I sometimes think Eric Troan really got this part of rpm's design right (some 7 or 8 years ago) when he completely forbade any I/O between the install scripts and the user at install time. As he put it, (paraphrased since I don't remember his exact wording) if even a small percentage of packagers indulge their desire to put up dialog boxes, the system will become extremely annoying. How prophetic he was --- or rather, how well he understood human nature. Everybody believes that *their* package has something ***so*** important to say that they have to tell the whole world about it. And perhaps I'm being too pessimistic, but trying to fix this by social pressure is like trying to shame American soccer mom's into not driving gasoline-gulping SUV's. It's never going to work. If you want to fix the problem, you have the right idea by thinking that you should perhaps simply disable all notes. That's the only solution that will stop the flood of warning messages and noices. (And perhaps by removing this crutch, packagers will be more encouraged not to grauitiously break things as the result of package upgrades, even if upstream does something stupid.) On a separate but related topic, I think a much better approach would be to handle configuration as a step entirely separate from the install phase. Let the install be entirely quiet, and let packages have intelligent defaults. If the package absolutely must be configured before it can be used, then let it be non-functional until someone actually calls dpkg-configure (which would be just like dpkg-reconfigure except that's the only time the questions would be asked). - Ted
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 12:18:33AM -0400, Theodore Ts'o wrote: On a separate but related topic, I think a much better approach would be to handle configuration as a step entirely separate from the install phase. Let the install be entirely quiet, and let packages have intelligent defaults. If the package absolutely must be configured before it can be used, then let it be non-functional until someone actually calls dpkg-configure (which would be just like dpkg-reconfigure except that's the only time the questions would be asked). - Ted Hear, hear. There is the related trouble that the only way to disable most packages is to uninstall them. Sometimes, it is desirable to temporarily disable a service without removing the binaries or changing the executability of the init.d script.
Re: Please remove RFCs from the documentation in Debian packages
On Thu, 2003-07-03 at 15:19, Thomas Viehmann wrote: Cameron Patrick wrote: On Thu, Jul 03, 2003 at 02:36:48PM -0500, Branden Robinson wrote: | Well, once you folks have come up with a definition of software, you | be sure and let us know. How about anything included in Debian? That way we won't be in danger of violating the Social Contract #1. Oh, cool. How about changing in DFSG to Anything that can go in main or contrib. Because that's a circular definition. Saying everything in Debian is software, is not. It's also the only reasonable way to define software. Or at least, the only reasonable way I (or anyone else who has voiced their opinion on this issue here) have come up with in 3 years, and it's not for a lack of trying. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Please remove RFCs from the documentation in Debian packages
On 03 Jul 2003 23:45:56 -0500 Joe Wreschnig [EMAIL PROTECTED] wrote: On Thu, 2003-07-03 at 15:19, Thomas Viehmann wrote: Cameron Patrick wrote: On Thu, Jul 03, 2003 at 02:36:48PM -0500, Branden Robinson wrote: | Well, once you folks have come up with a definition of software, you | be sure and let us know. How about anything included in Debian? That way we won't be in danger of violating the Social Contract #1. Oh, cool. How about changing in DFSG to Anything that can go in main or contrib. Because that's a circular definition. Saying everything in Debian is software, is not. It's also the only reasonable way to define software. Or at least, the only reasonable way I (or anyone else who has voiced their opinion on this issue here) have come up with in 3 years, and it's not for a lack of trying. The assumption in his suggestion was that it would no longer be the Debian Free Software Guidelines, but the Debian Free main/contrib Guidelines. ie: if it's going to go into main or contrib, it needs to meet the guidelines. Except for the title, the DFSG is very content-agnostic. It can be applied equally well to software, fiction, nonfiction, images, what have you. pgpsRUM6OreNP.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, 2003-07-03 at 14:53, Cameron Patrick wrote: On Thu, Jul 03, 2003 at 02:34:56PM -0500, Branden Robinson wrote: | The Debian Social Contract says Debian Will Remain 100% Free Software
NEWS.Debian support is here
Thanks to Matt Zimmerman and Joe Drew, apt-listchanges will now display NEWS.Debian entries for upgraded packages. They're displayed before the regular changelog entries, and Matt plans to later let it be configured to only display news, if the user wants (more useful for stable users). The NEWS.Debian file is installed as /usr/share/doc/package/NEWS.Debian.gz. Always compressed, always with that name even in native packages. If you use debhelper, upgrade to 4.1.51 and dh_installchangelogs will install debian/NEWS files for you[1]. The file format is the same as a debian changelog file, but we leave off the asterisks generally, and use bigger paragraphs explaining news items when necessary. It might be a good idea to run your file through dpkg-parsechangelog to check its formatting as it will not be automatically checked during build as the changelog is. I expect there will be a lintian check eventually. Here's a real life example of a NEWS.Debian file: libinline-perl (0.43-5) unstable; urgency=low Note that when you upgrade from perl 5.6 to 5.8, binaries built with libinline (this may include compiled objects cached in .Inline/_Inline directories) will fail to work with the new version of perl. This is because perl's ABI for binaries changed between perl 5.6 and 5.8. The solution is the delete and regenerate any such binaries you might have. I have not tried to automate this in the Debian package. -- Joey Hess [EMAIL PROTECTED] Wed, 11 Sep 2002 21:37:56 -0400 Unlike changelog files, you don't update NEWS.Debian files with every release. Only update them if you have something particularly newsworthy that user should know about. I'm putting off getting this into policy until enough stuff uses it that we can tell it works well. But as of today it's a valid way to communicate important changes to the users of your package. -- see shy jo [1] Actually, debhelper has supported this for a long time already, but it got the file name wrong for native packages. pgpPaUnCEZSPx.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
Marc Singer wrote: There is the related trouble that the only way to disable most packages is to uninstall them. Sometimes, it is desirable to temporarily disable a service without removing the binaries or changing the executability of the init.d script. Take a look at invoke-rc.d and its policy program. -- see shy jo pgpADXOdaNxUV.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
Theodore Ts'o wrote: On a separate but related topic, I think a much better approach would be to handle configuration as a step entirely separate from the install phase. Let the install be entirely quiet, and let packages have intelligent defaults. If the package absolutely must be configured before it can be used, then let it be non-functional until someone actually calls dpkg-configure (which would be just like dpkg-reconfigure except that's the only time the questions would be asked). Debconf is flexable enough so you can do that already (assuming all packages use debconf). - comment out the dpkg-preconfigure call in /etc/apt/apt.conf.d/70debconf - set in /etc/debconf.conf: Frontend: noninteractive Admin-Email: - dpkg-configure is the following script: #!/bin/sh -e dpkg-reconfigure --unseen-only --default-priority -freadline $@ -- see shy jo pgpHjE1t7saSk.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 01:11:48AM -0400, Joey Hess wrote: Theodore Ts'o wrote: On a separate but related topic, I think a much better approach would be to handle configuration as a step entirely separate from the install phase. Let the install be entirely quiet, and let packages have intelligent defaults. If the package absolutely must be configured before it can be used, then let it be non-functional until someone actually calls dpkg-configure (which would be just like dpkg-reconfigure except that's the only time the questions would be asked). Debconf is flexable enough so you can do that already (assuming all packages use debconf). - comment out the dpkg-preconfigure call in /etc/apt/apt.conf.d/70debconf - set in /etc/debconf.conf: Frontend: noninteractive Admin-Email: - dpkg-configure is the following script: #!/bin/sh -e dpkg-reconfigure --unseen-only --default-priority -freadline $@ My reading of Ted's comment is that this ought to be the *default* policy. I won't go so far as to say that RH made a better choice, but I don't really see the benefit of the all of the warning messages when once displayed they are nowhere to be found. Perhaps, you'll have a command for recovering these messages, but that doesn't change the fact that they are just not really necessary at install time.
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 02:42:10PM -0500, Branden Robinson wrote: And, incidentally, the specific issue you address has -- I'm sure you'll be quite startled -- discussed at length on debian-legal. Maybe you ought to check out those archives? I'm well aware that some people have flogged the horse. That doesn't mean these people have reached a satisfactory conclusion, that they are right in any sense of the word or that said conclusion is consistent with other opinions voiced by these people. Again, I'm not talking about the legal document, I'm talking about the file. The statement I quoted does not allow for modifications, no matter the purpose. Now, would you care to be self-consequent? -- Marcelo
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 11:54:17PM -0500, Joe Wreschnig wrote: On Thu, 2003-07-03 at 14:53, Cameron Patrick wrote: On Thu, Jul 03, 2003 at 02:34:56PM -0500, Branden Robinson wrote: | The Debian Social Contract says Debian Will Remain 100% Free Software. | If there are things in Debian that are not free or not software, | then we may be violation of our guiding principles. The anarchism package is an excellent example of a package in Debian main that, although DFSG-free, is neither software nor software documentation. How do you show it's not software? How does it differ from software? Most of us don't bother, this is just the standard response to documentation isn't software so doesn't have to follow the DFSG. If you want to call it software, that's fine; we know what to do with software. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgptRcuKfKiVX.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
Joe Wreschnig wrote: On Thu, 2003-07-03 at 15:19, Thomas Viehmann wrote: Cameron Patrick wrote: On Thu, Jul 03, 2003 at 02:36:48PM -0500, Branden Robinson wrote: Oh, cool. How about changing in DFSG to Anything that can go in main or contrib. Because that's a circular definition. Saying everything in Debian is software, is not. Given that in practice the ftp-masters get the final say, it isn't. If you don't count that, saying Anything in debian is software because debian only distributes software is as well. I tend to agree with the probable conclusion of applying DFSG to determine the freeness of anything in debian. However, the reasoning is fundamentally flawed. David Harris' explanation is much better. Cheers T. pgpnR7isj7ppg.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 07:50:07AM +0200, Marcelo E. Magallon wrote: On Thu, Jul 03, 2003 at 02:42:10PM -0500, Branden Robinson wrote: And, incidentally, the specific issue you address has -- I'm sure you'll be quite startled -- discussed at length on debian-legal. Maybe you ought to check out those archives? I'm well aware that some people have flogged the horse. That doesn't mean these people have reached a satisfactory conclusion, that they are right in any sense of the word or that said conclusion is consistent with other opinions voiced by these people. Again, I'm not talking about the legal document, I'm talking about the file. The statement I quoted does not allow for modifications, no matter the purpose. Now, would you care to be self-consequent? If you have something _new_ to add to the discussion, please do so (on -legal). Otherwise, kindly piss off. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpwvtnnuYDOb.pgp Description: PGP signature
policy-rc.d
On Fri, Jul 04, 2003 at 01:06:14AM -0400, Joey Hess wrote: Marc Singer wrote: There is the related trouble that the only way to disable most packages is to uninstall them. Sometimes, it is desirable to temporarily disable a service without removing the binaries or changing the executability of the init.d script. Take a look at invoke-rc.d and its policy program. OK. I can tell that this feature is available, though obscured by the lack of a man page for policy-rc.d or even a reference to a package that implements it. I *did* find a document through google, however. Reading it doesn't make it much clearer. My search through a Contents file doesn't show an implementor for policy-rc.d. Is there one or is it adhoc? -- Luckily, I am familiar with rule 3: 3. any action for a non-executable initscript is denied.
Re: 469 packages still using dh_undocumented, check if one is yours
Goswin Brederlow wrote: I came accross some sources still using dh_undocumented so I did a quick search through sids *.diff.gz files. Here is the result: At prsent rates, I expect we will be down to maybe 50 packages calling this in 1 year's time, at which point some bug reports could be filed. Of course many of the packages with this program in their rules file probably don't even use it. And it is a no-op. I've recently revamped my debhelper graph page to make it easier to track deprecated programs. The ones that don't seem likely to go away at all soon are dh_installmanpages and dh_movefiles. -- see shy jo pgpeyIAQyrCCT.pgp Description: PGP signature
Re: 469 packages still using dh_undocumented, check if one is yours
* Goswin Brederlow ([EMAIL PROTECTED]) [030704 05:35]: I came accross some sources still using dh_undocumented so I did a quick search through sids *.diff.gz files. Here is the result: [...] libapache-mod-dav You must have done something wrong as since 1.0.3-6 dh_undocumented is not longer used by libapache-mod-dav. (And 1.0.3-6 is also in sarge for a while now.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#199972: ITP: lksctp -- implementation of SCTP in the Linux kernel
Package: wnpp Version: unavailable; reported 2003-07-04 Severity: wishlist * Package name: lksctp Version : 2_5_59-0_6_4 Upstream Author : La Monte H. P. Yarroll [EMAIL PROTECTED], Jon Grimm [EMAIL PROTECTED], et al. * URL : http://lksctp.sourceforge.net/ * License : GPL Description : implementation of SCTP in the Linux kernel The Linux Kernel Stream Control Transmission Protocol (lksctp) project is an implementation of the Stream Control Transmission Protocol (SCTP) in the Linux kernel. The primary goal of this project is to provide user applications with a viable SCTP solution. See http://lksctp.sourceforge.net/ for more information. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux yuri 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i686 Locale: LANG=en_AU, LC_CTYPE=en_AU
Re: Bug#199874: ITP: molmol -- Display and analyze structures of biological macromolecules (fwd)
Andreas Tille [EMAIL PROTECTED] wrote on debian-med: Hint to Frank: I'm looking foreward to Please include ling description mails. :) I suggest to add it now because you can be sure that people will ask you for this. Err, here it comes: Description: Display and analyze structures of biological macromolecules MOLMOL is a molecular graphics program for displaying, analyzing, and manipulating the three-dimensional structure of biological macromolecules, with special emphasis on the study of protein or DNA structures determined by NMR Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: Please remove RFCs from the documentation in Debian packages
Selon Matt Zimmerman [EMAIL PROTECTED]: On Fri, Jul 04, 2003 at 01:46:11AM +0800, Cameron Patrick wrote: RFCs aren't software, and so applying the Debian Free /Software/ Guidelines to them seems a little odd. But...but...what if you want to make your own RFC 2661 by embracing and extending the existing one, and redistribute it to all your friends calling it RFC 2661? It's taking away your freedom! But we absolutely don't want to do this. It is just like modifying someone else' speach and redistributing it without changing the author's name. It is obvious it should be out of the scope of DFSG. -- Jérôme Marant
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 01:46:11AM +0800, Cameron Patrick wrote: Of course not. They're software. RFCs aren't software, and so applying the Debian Free /Software/ Guidelines to them seems a little odd. Hmmm... Depends on your definition, really. They're sure as hell not hardware or firmware, so... -- Nick Phillips -- [EMAIL PROTECTED] You are sick, twisted and perverted. I like that in a person.
Re: NEWS.Debian support is here
On Fri, Jul 04, 2003 at 01:01:14AM -0400, Joey Hess wrote: Thanks to Matt Zimmerman and Joe Drew, apt-listchanges will now display NEWS.Debian entries for upgraded packages. They're displayed before the regular changelog entries, and Matt plans to later let it be configured to only display news, if the user wants (more useful for stable users). Is it reasonable to think about some sort of localizzation support for NEWS file? Changes documented there might be worthy of translation. The NEWS.Debian file is installed as /usr/share/doc/package/NEWS.Debian.gz. Always compressed, always with that name even in native packages. If you use debhelper, upgrade to 4.1.51 and dh_installchangelogs will install debian/NEWS files for you[1]. Just curious: why not NEWS.gz for native packages? ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. pgpTIeR1qCp3R.pgp Description: PGP signature
Re: 469 packages still using dh_undocumented, check if one is yours
* Goswin Brederlow | I came accross some sources still using dh_undocumented so I did a | quick search through sids *.diff.gz files. Here is the result: [...] Such a list is useless unless it includes maintainer addresses (or just maintainer names) as well. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Bug#199683: ITP: librcs-perl -- Front end to revision control utilities for perl
On Wednesday 02 July 2003 15:45, Matt Hope wrote: This Perl module provides an object oriented interface to access Revision Control System (RCS) utilities. Is this the original rcs specifically, or revision control system utilities in general? This is not entirely clear to me from this description. cheers -- vbi -- Do you understand now why we attacked Iraq? Because war is good for the economy, which means war is good for America. Also, since God is on America's side, anyone who opposes war is a godless un-American Communist. -- excerpt from one of those 'joke' mails floating around. pgpVGfBsPCkkZ.pgp Description: signature
Re: Please remove RFCs from the documentation in Debian packages
Jérôme == Jérôme Marant [EMAIL PROTECTED] writes: Jérôme But we absolutely don't want to do this. Jérôme It is just like modifying someone else' speach and Jérôme redistributing it without changing the author's name. Jérôme It is obvious it should be out of the scope of DFSG. It is far from obvious. What if I develop my software, finds the specification of MIME to be very similar to what my software does, but yet I need to modify the things here and there so as to suit my needs; and when documenting my software I want to use RFC 1341 as a starting point, change those things that my software do differently than 1341, and then say that is the documentation of my software? I have no intention to confuse the result with RFC 1341, so what's wrong to do the edit (except that the author of RFC 1341 might be unhappy with that)? To the user it is really best done that way: if I have to rewrite 1341 I probably won't give documentation at all because I don't have the time. If instead I just point out the positions that my software differs from 1341 the user would have to read two different documents. I'd accept it if the restriction is just saying that I cannot distribute a modifying RFC without changing the name to something else. I cannot accept it if the license restricts my right to change it at all (other than for translation or development of new standards)---at least, if it were to be put in main section of Debian. It sounds like a trap waiting for somebody to step into it. Regards, Isaac.
Re: Why doesn't libsidplay enter testing?
* Colin Watson [EMAIL PROTECTED] [2003-07-04 00:03]: On Thu, Jul 03, 2003 at 07:58:37PM +0200, Gerfried Fuchs wrote: Please check the update_excuses, it would make package foo _not_ a valid candidate, if that happens. That doesn't happen for circular dependencies (i.e. cycles of packages that each depend on newer versions of each other than are in testing), the reason being that if they weren't considered valid candidates then such cycles could never get into testing at all. (Invalid candidates are completely ignored - they aren't eligible for hinting, even.) Oh, didn't know that part yet, thanks for the enlightenment. Please stop saying rude things like Please check foo to the people who are trying to explain the state of play to you, because they are right: it has been like this for a long time. Sorry, I don't get it why you call it rude. It might be just me but I would have considered it rude if I told Anthony to RTF update_excuses. If you take what I wrote as rude then sorry, I didn't mean it that way. I even haven't thought that anyone would take a please check as rude anyway, and I still don't understand it why you might think so And like Anthony's answer showed he hasn't taken it as rude neither, and even he thought it would happen to be written out in update_excuses. Upgrading either the foo source package alone or the libfoo source package alone renders foo uninstallable. Upgrading both simultaneously works. The latter requires manual action (or the occasional bit of guesswork by the testing scripts). It has always been this way. Yes, it has always been this way. Or rather not, for I don't see the need for manual action, it is documented that these cases are cought by the testing script since ages, and it worked without manual action for quite some time already (from what I can tell). I just like to know if there is really the need for manual action for such things every now and then (then this should be noted in the documentation and I consider it rather as a bug, for there is not much magic in this case, IMHO) or if there is something else behind this very case, which I don't grok yet. So long, Alfie [no, not meant rude; don't understand it as rude]
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 05:16:07PM -0700, Brian Nelson wrote: Andrew Suffield [EMAIL PROTECTED] writes: On Thu, Jul 03, 2003 at 02:19:59PM -0700, Brian Nelson wrote: You have some free software, and it comes with a manual. You modify the software in a manner which suits you... but you're not allowed to modify the manual to reflect this change; the license of the manual requires that it only document the unmodified version, so any modified versions are at an immediate disadvantage. And you think this is acceptable? Why? It's more acceptable to me than the alternative: to move a good portion of documentation to non-free where it will not be distributed by vendors, will not be considered part of Debian and thus will be under threat of removal, and will be considered a lower class package. That's not exactly what we are speaking about. We don't speak about documentation, but about standards. Documentation comes after the implementation of the program to explain how to use it. Standards comes before the implementation to explain how it should behave to be interoperable with other implementations from other people. RFCs are not program documentation. [but the program documentation can refere to RFCs, as ldap stuff does] Fortunately, the situation you describe is unlikely to occur because few people are perverse enough to make their software free but their documentation very non-free. The fact is that it happens. Look at FDL discussions. But in my mind, that's out of topic, and I would appreciate if we could discuss one item at once to have a small chance of converging to a decision... Thanks, Mt. -- If the automobile had followed the same development cycle as the computer, a Rolls-Royce today would cost $100, get a million miles to the gallon, and explode once every few weeks, killing everyone inside.
Re: NEWS.Debian support is here
Thanks a lot, this is great! On Friday 04 July 2003 10:02, Luca - De Whiskey's - De Vitis wrote: Is it reasonable to think about some sort of localizzation support for NEWS file? Changes documented there might be worthy of translation. Not about i18n, really, but please at least specify from the beginning that NEWS.Debian.gz should be utf-8 encoded, then there shouldn't be any big discussion later on. cheers -- vbi -- featured product: the GNU Compiler Collection - http://gcc.gnu.org pgphIq7RdEuaI.pgp Description: signature
Re: logging for package installs
On Thu, Jul 03, 2003 at 05:38:46PM -0400, Joey Hess wrote: Maybe this is a good time to present this idea I've been kicking around, but never really got anywhere with, for as long as I've been working on debconf. My idea is to add an abstraction layer for package install-related logging in debian. It seems that many maintainers like to do some or all of the following in their maintainer scripts: - Display various fairly unimportant warnings, which are often not useful until after the package is installed and you're using it. - Display error messages, some fatal, and some not. - Show progress displays (in contravention of policy of course). - Various other indications of important and not so important things that the maintainer script is doing. - Remind users to read the README.Debian file. Almost all of this is done with echo, and almost all of this is completly ignored by our users, believe it or not. I suppose that those users who see it would prefer to be able to go back and look at it later, when they're actually using the package they installed earlier. Some of them would certianly like for it to be localised. Many users would like not to see this stuff at all at install time, unless it's a real immediate error. That would be really great, and I'm quite entousitastic about the idea. So the basic idea is that instead of using echo for these messages, we provide some interface for them. Call it dpkg-log. I have not gotten as far as to what the interface of dpkg-log would be, or how users would configure how it displays, filters, and/or logs messages. Nor have I given much thought to what kind of data should be included in the log, though it would probably include the date, package name, log message, log type, and message importance. Check the log4j project, they did come up with a really great logging framework. Of course, their code isn't usable at all (that's java), but their concept are very advanced. Applying this to dpkg-log would allow the user to provide the format they want, depending of the kind of message and its gravity. For that, we kind of need a standardization of the possible categories. Using package name as categorie seems underoptimal to me since it won't be useable from the user point of view. We could use the sections for that. dpkg-log --category main/doc --level critical Hey, this version will \ break your install, erase your data and kill your mum unless you check \ README.debian carfully or the tags dpkg-log --category gnome --level minor subliminal message: Gnome rulez or a mix of the two, but that may be hard to do right. Nor have I thought about l10n at all. You'll have a bad time i18ning that. The problems with debconf template i18ning was that: - the translation must be there before the program install - the texts are short and dispatched over all packages, making the ratio of translator work between actual translation work and administrative work to get their work included rather bad. With dpkg-log messages, you'll get into those two problems too, plus the fact that I guess that maintainers will want to add variating text like errmsg=`run a command` if [ $? != ] ; then dpkg-log $Damnit the execution of this command failed with the message $errmsg fi The errmsg stuff is impossible to translate unless setting LC_ALL for the execution program run, but this leads to other problems if you want to parse the output... I can't find a good way to translate those errmsg stuff, but for the others, I think that it could be pushed to the debian/po file. debian/po/POTFILE.in provides a provision for such extends. I need to speak with Denis Barbier to see how we could this happen in the po-debconf and po4a realm. This could be bolted on the side of debconf. The abuse of debconf by maintainers who feel the need to do the kinds of things listed above certianly points at the need for this mechanism. And at least debconf has a kind of l10n framework, and some ideas about question priority. But this logging and message display is really conceptually different than debconf. Debconf is just there to ask questions. It would likely be better to design it as a separate program. Fully agreed. Here's one way a dpkg-log program might be used, just to give the feel for the idea: #!/bin/sh if [ $1 = configure ] grep -q evil /etc/myconfig; then dpkg-log --priority=critical \ --warning=$/etc/myconfig has evil in it! See README.Debian! elsif [ $phase_of_moon = full ]; then dpkg-log --priority=critical \ --error=$This package only upgrades during new moons. exit 1 fi The user would see either this: # dpkg -i mypkg.deb dpkg: Installing mypkg (1.2.3) ... dpkg: Not replacing modified conffile /etc/myconfig with /etc/myconfig.dpkg-new mypkg: /etc/myconfig has evil in it! See README.Debian! Or if they prefer, this: # dpkg --log=warning -i
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 12:18:33AM -0400, Theodore Ts'o wrote: sometimes think Eric Troan really got this part of rpm's design right (some 7 or 8 years ago) when he completely forbade any I/O between the install scripts and the user at install time. [...] (And perhaps by removing this crutch, packagers will be more encouraged not to grauitiously break things as the result of package upgrades, even if upstream does something stupid.) Unfortunately, this does not happen in the install-time-note-free Red Hat world. I see RH package upgrades break^Wchange things which are not obviously documented and would benefit from a note (or, a la debconf, an email) just mentioning what has occurred. I much prefer the opportunity to warn the admin at install time. Dave
Re: Please remove RFCs from the documentation in Debian packages
Petter Reinholdtsen [EMAIL PROTECTED] writes: There seem to be someone believing that standard documents should be treated as software. Standards are not software. Standards do not improve if everyone is allowed to modify them and publish the modified version as an updated version of the standard. Standards get their value from having a rigid procedure for updates and modifications. Software do not. RFCs are not standards. The IETF process is not a standardization process in the traditional sense. Part of the Internet's success story is the intertwining of software development and de-facto standardization. From this point of view, RFCs are much more like software than traditional standards.
Re: Please remove RFCs from the documentation in Debian packages
Marco d'Itri [EMAIL PROTECTED] writes: I fully agree. Banning RFCs from debian is just silly. And I wonder what's next? fsf-funding(7)? The GPL? Debian really needs a separate policy for works which are not software.
Re: Please remove RFCs from the documentation in Debian packages
Branden Robinson [EMAIL PROTECTED] writes: So be it. The Social Contract and the traditions of our project compel us to make principled decisions, not politically expedient ones. Not correct. Look at the handling of security issues. The project has chosen (never formally, though) that it will sacrifice one of its core values to increase short-term user convenience. There is always some room for interpretation, and often a certain political motivation behind interpretation. BTW, has anybody tried to clarify what for the purpose of developing Internet standards means? Is it possible to publish an Internet Draft formally aiming at an Informational RFC which is based on an RFC with such a copyright notice?
Re: 469 packages still using dh_undocumented, check if one is yours
On Fri, 04 Jul 2003, Joey Hess wrote: I've recently revamped my debhelper graph page to make it easier to track deprecated programs. The ones that don't seem likely to go away at all soon are dh_installmanpages and dh_movefiles. Especially since some of us do like dh_movefiles a LOT :-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 12:19:07PM +0200, Florian Weimer wrote: Marco d'Itri [EMAIL PROTECTED] writes: I fully agree. Banning RFCs from debian is just silly. And I wonder what's next? fsf-funding(7)? Yup, I'll go file a bug about that now; thanks for pointing it out. We shouldn't be shipping non-free manpages. Debian really needs a separate policy for works which are not software. We could have a policy for non-software, but it should still exclude non-free things. What you are trying to say is Debian really needs to include non-free things. I think you'll find a lot of people disagreeing with you. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpQMUHlTVjdD.pgp Description: PGP signature
Re: policy-rc.d
On Thu, 03 Jul 2003, Marc Singer wrote: Take a look at invoke-rc.d and its policy program. OK. I can tell that this feature is available, though obscured by the lack of a man page for policy-rc.d or even a reference to a package that implements it. I *did* find a document through google, however. Reading it doesn't make it much clearer. That's because nobody wrote a sample (or generic, whatever) policy-rc.d yet :P Now, what happened to policy-rc.d(8), I don't know. Let me search to see if I ever wrote a sample one... /me notices in horror that projects/debian/initscripts is empty... ARGH! google to the rescue... let me wget them right back! My search through a Contents file doesn't show an implementor for policy-rc.d. Is there one or is it adhoc? I wrote one for chroots a while back. It simply did an exit 101 :) For reference, I am attaching the interface description of policy-rc.d. I (or someone else) should write a manpage for it one of these days... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh INVOKE-RC.D (/usr/sbin/invoke-rc.d) interface: == The interface for all implementations of invoke-rc.d is mandated by the base implementation in the sysvinit package, just like it is done for update-rc.d. There is a provision for a local initscript policy layer (read: a call to /usr/sbin/policy-rc.d if this executable is present in the local system), which allows the local system administrator to control the behaviour of invoke-rc.d for every initscript id and action. It is assumed that this script is OPTIONAL and will by written and provided by packages other than the initscript system (sysvinit and file-rc packages). The basic interface for all implementations of policy-rc.d is mandated by the requirements of the base implementation of invoke-rc.d. This interface will be described either in the manpage of invoke-rc.d, and in a text file stored in /usr/share/doc/sysvinit/ by package sysvinit (which will host the base implementation of invoke-rc.d). Proposed script interfaces: invoke-rc.d [options] basename action [extra initscript parameters...] basename - Initscript ID, as per update-rc.d(8) action - Initscript action. Known actions are: start, [force-]stop, restart, [force-]reload, status (status is there because of the LSB. Debian does not use it). extra initscript parameters: These parameters are passed to the initscript as is, after the action parameter. action is always the first paramenter to the initscript, and may be modified by fallback actions or policy-rc.d requests. Note, however, that the extra parameters are not dropped or modified even if the action (first parameter) is modified. Options: --quiet Quiet mode, no error messages are generated by invoke-rc.d; policy-rc.d is also called with --quiet if this option is in effect. --force Try to run init script regardless of policy and non-fatal errors. Use of this option in automated scripts is severely discouraged as it bypasses integrity checks. If the initscript cannot be executed, error status 102 is returned. Do note that the policy layer call (policy-rc.d) is NOT skipped, although its results are ignored. --try-anyway Try to run the initscript even if a non-fatal subsystem error is detected (e.g: bad rc.d symlinks). A 102 status exit code will result if init script fails to execute anyway). Unlike --force, policy is still enforced with --try-anyway. --disclose-deny Return status code 101 instead of status code 0 if initscript action is denied by local policy rules or runlevel constrains. An warning is generated if the action is denied. --query Returns one of status codes 100-106, does not execute the init.d script. Implies --disclose-deny and --nofallback. Status codes 104-106 are only generated by this option. Note many messages are still sent to stderr in --query mode, including those regarding policy overrides and subsystem errors. Use --quiet if silent --query operation is desired. --no-fallback The policy layer (policy-rc.d) may return fallback actions to be run instead of the requested action. If this option is active, a fallback action request will be ignored and a action not allowed reply used in its place. This is probably a BAD idea unless you know exactly what you're doing. --help Outputs help message to stdout Unknown actions may generate warnings, but are passed to the underlying initscript anyway. The reason for the warning is simple: It is very unlikely that an unknown action (by invoke-rc.d) will be known to the policy layer (policy-rc.d), and therefore it may cause an initscript to execute an
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 12:39:46PM +0200, Florian Weimer wrote: So be it. The Social Contract and the traditions of our project compel us to make principled decisions, not politically expedient ones. Not correct. Look at the handling of security issues. The project has chosen (never formally, though) that it will sacrifice one of its core values to increase short-term user convenience. What you describe as user convenience translates into 4. Our Priorities are Our Users and Free Software We will be guided by the needs of our users and the free-software community. We will place their interests first in our priorities. Hence, you're on crack if you think that such sophistry works. -- 2. That which causes joy or happiness.
Re: NEWS.Debian support is here
On Fri, 04 Jul 2003, Joey Hess wrote: Thanks to Matt Zimmerman and Joe Drew, apt-listchanges will now display NEWS.Debian entries for upgraded packages. They're displayed before the THANK YOU guys! I will add NEWS support to my packages (and backport apt-listchanges to stable, see people.debian.org/~hmh/ if you want the backport) ASAP. That was a great (although unintended, I'm sure) birthday gift. Thanks ;-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Content rejected.
Content rejected. Based on an automated review of the content in a message you sent, the message appears to be unsolicited commercial e-mail or to contain content that we deem inappropriate for our business environment. The message has been blocked from delivery. If you feel you received this message in error, please forward this message, the address that you are trying to send to, and any questions to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Received: from SMTP32-FWD by imail.duda.com (SMTP32) id A0C4C; Fri, 4 Jul 2003 07:43:23 -0400 Received: from ov7.duda.com [10.1.1.11] by imail.duda.com (SMTPD32-7.15) id A845E6790134; Fri, 04 Jul 2003 07:43:01 -0400 Received: from psmtp.com ([12.158.35.174]) by ov7.duda.com (SAVSMTP 3.1.0.29) with SMTP id M2003070407423623071 for [EMAIL PROTECTED]; Fri, 04 Jul 2003 07:43:00 -0400 Received: from source ([146.82.138.6]) by exprod6mx34.postini.com ([12.158.35.251]) with SMTP; Fri, 04 Jul 2003 04:42:34 PDT Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id D98DC1F70F; Fri, 4 Jul 2003 06:40:17 -0500 (CDT) Old-Return-Path: [EMAIL PROTECTED] Received: from master.debian.org (master.debian.org [146.82.138.7]) by murphy.debian.org (Postfix) with ESMTP id A88AD1F67A for debian-devel-announce@lists.debian.org; Fri, 4 Jul 2003 06:30:03 -0500 (CDT) Received: from debbugs by master.debian.org with local (Exim 3.35 1 (Debian)) id 19YOlP-0002l6-00; Fri, 04 Jul 2003 06:30:03 -0500 Date: Fri, 4 Jul 2003 06:30:03 -0500 From: BugScan reporter [EMAIL PROTECTED] To: debian-devel-announce@lists.debian.org Subject: Release-critical Bugreport for July 4, 2003 Message-ID: [EMAIL PROTECTED] Reply-To: debian-devel@lists.debian.org, [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.28i Sender: Debian BTS [EMAIL PROTECTED] X-Debian-Message: RC bugreport check passed Mail-Followup-To: debian-devel@lists.debian.org X-Spam-Status: No, hits=-2.5 required=4.0 tests=USER_AGENT_MUTT version=2.55-lists.debian.org_2003_06_29 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55-lists.debian.org_2003_06_29 (1.174.2.19-2003-05-19-exp) Resent-Message-ID: [EMAIL PROTECTED] Resent-From: debian-devel-announce@lists.debian.org X-Mailing-List: debian-devel-announce@lists.debian.org X-Loop: debian-devel-announce@lists.debian.org List-Id: debian-devel-announce.lists.debian.org List-Post: mailto:debian-devel-announce@lists.debian.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Archive: http://lists.debian.org/debian-devel-announce/ Precedence: list Resent-Sender: [EMAIL PROTECTED] Resent-Date: Fri, 4 Jul 2003 06:40:17 -0500 (CDT) X-Declude-Sender: [EMAIL PROTECTED] [12.158.35.174] X-Declude-Spoolname: D6845e67901342f6e.SMD X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. X-Spam-Tests-Failed: Whitelisted [0]
Re: Please remove RFCs from the documentation in Debian packages
Andrew Suffield [EMAIL PROTECTED] writes: Debian really needs a separate policy for works which are not software. We could have a policy for non-software, but it should still exclude non-free things. What you are trying to say is Debian really needs to include non-free things. There are borderline cases, such as the GFDL or free works in non-editable formats (PS, PDF, in some cases even HTML), or licenses or other documents of perceived legal relevance. However, I've tried to come up with a policy which is not specific to IETF documents, but that would allow their distribution, and I failed. The terms are quite obnoxious, and if it weren't the IETF that is involved here, hardly anyone would demand that documents under such a license are to be included in Debian, I guess.
Re: Please remove RFCs from the documentation in Debian packages
Josip Rodin [EMAIL PROTECTED] writes: On Fri, Jul 04, 2003 at 12:39:46PM +0200, Florian Weimer wrote: So be it. The Social Contract and the traditions of our project compel us to make principled decisions, not politically expedient ones. Not correct. Look at the handling of security issues. The project has chosen (never formally, though) that it will sacrifice one of its core values to increase short-term user convenience. What you describe as user convenience translates into 4. Our Priorities are Our Users and Free Software We will be guided by the needs of our users and the free-software community. We will place their interests first in our priorities. Hence, you're on crack if you think that such sophistry works. But how far goes clause 4? Obviously not that far that Debian includes Java (for rather complete values of Java, which seems to imply a certain proprietary implementation at the moment).
woody/sid packages in dists/potato
I'm trying to run debootstrap to see if it plays nice with sysvinit. And the other way around. But at the moment, it bails out because it wants to install libident which still is in the potato part of the archive ... and my local mirror doesn't carry dists/potato anymore. There's a handful of packages that have the same problem: % grep ^Filename: Packages | grep -v : pool/ | wc -l 24 They're all in potato. What would be the right way to fix this ? - file 24 bug reports - fix the FTP archive manually by copying the packages to pool/ - it's not really a problem, so do nothing Mike.
Re: woody/sid packages in dists/potato
On Fri, Jul 04, 2003 at 11:58:49AM +, Miquel van Smoorenburg wrote: I'm trying to run debootstrap to see if it plays nice with sysvinit. And the other way around. But at the moment, it bails out because it wants to install libident which still is in the potato part of the archive ... and my local mirror doesn't carry dists/potato anymore. There's a handful of packages that have the same problem: % grep ^Filename: Packages | grep -v : pool/ | wc -l 24 They're all in potato. What would be the right way to fix this ? - file 24 bug reports - fix the FTP archive manually by copying the packages to pool/ - it's not really a problem, so do nothing Option #2. We had this discussed here several times before. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- pgptRyj5DCKpj.pgp Description: PGP signature
Re: NEWS.Debian support is here
On Friday, July 4, 2003, at 04:02 AM, Luca - De Whiskey's - De Vitis wrote: Just curious: why not NEWS.gz for native packages? It's prohibitively difficult to detect whether any given file is in debian changelog format. NEWS[.gz] exists in many packages already, and is of no particular format in general, apt-listchanges doesn't know what to do with it (and will in fact display the entire file every time). Since we can't rely on the existence of NEWS.Debian.gz (as it's not required, like the changelog is) we can't tell which file is the one we're looking for by filename alone. So, instead, we have decided that mandating NEWS.Debian is a better solution.
Re: woody/sid packages in dists/potato
On Fri, 4 Jul 2003, Miquel van Smoorenburg wrote: I'm trying to run debootstrap to see if it plays nice with sysvinit. And the other way around. But at the moment, it bails out because it wants to install libident which still is in the potato part of the archive ... and my local mirror doesn't carry dists/potato anymore. There's a handful of packages that have the same problem: % grep ^Filename: Packages | grep -v : pool/ | wc -l 24 They're all in potato. What would be the right way to fix this ? It's not a bug in itself for those packages to be still under potato, as far as they are not buggy for some other reason as well. If you mirror woody you should look at the Packages.gz file for woody and retrieve whatever Filename:s are referenced there. Assuming that all packages in woody, sarge or sid have to be under the pool directory is considered as a bug in whatever method to create the local mirror you might be using. In other words, what we call the pool is really the sum of packages in the potato directory and packages in the pool directory. The fact that all packages which belong to potato are all under the potato directory is just an extra property which the pool is required to satisfy. - file 24 bug reports - fix the FTP archive manually by copying the packages to pool/ - it's not really a problem, so do nothing It's not a problem as such, but if, for instance, they are still using /usr/doc, that's something that might be reported.
Re: Bug#199197: bsdgames debian X menu entries depend on gnome-terminal, not in testing (Sarge)
Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Christian Marillat said: [...] Yes, I know, but this user said that x-terminal-emulator is configured to xterm and when he call a bsdgames menu enties a dialog box said that gnome-terminal is missing. Of course files in menu-method are original files. Then if somebody can understand this bug... It's the gnome-session terminal-emulator thing, I'm pretty sure. gnome-session can override the alternatives sytem, so that users can use gnome-session change nothing, related to x-terminal-emulator alternative. their favorite apps for web borwser, terminal, etc., and I'm assuming this user has the call to terminal pointing to gnome-terminal, which isn't there. This is why they are getting an error message in gnome, rather than a silent failure, which is what I experience when it's something outside of the gnome desktop. Debian menu doesn't use at all the terminal prefered application. Christian
Bug#200025: ITP: libcddb -- C library to access data on a CDDB server
Package: wnpp Version: unavailable; reported 2003-07-04 Severity: wishlist * Package name: libcddb Version : 0.9.4 Upstream Author : Kris Verbeeck [EMAIL PROTECTED] * URL : http://libcddb.sourceforge.net/ * License : LGPL Description : C library to access data on a CDDB server It allows you to: . * search the database for possible CD matches; * retrieve detailed information about a specific CD; * submit new CD entries to the database. . Libcddb supports both the custom CDDB protocol and tunnelling the query and read operations over plain HTTP. It is also possible to use an HTTP proxy server. If you want to speed things up, you can make use of the built-in caching facility provided by the library. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux crispy 2.4.21 #1 Sun Jun 15 15:02:46 BST 2003 i686 Locale: LANG=en_GB, LC_CTYPE=en_GB
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 02:04:51PM +0200, Florian Weimer wrote: But how far goes clause 4? Obviously not that far that Debian includes Java (for rather complete values of Java, which seems to imply a certain proprietary implementation at the moment). Which non-free Java implementations are part of Debian? I know of none. - Sebastian
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 03:55:30PM +0200, Sebastian Rittau wrote: On Fri, Jul 04, 2003 at 02:04:51PM +0200, Florian Weimer wrote: But how far goes clause 4? Obviously not that far that Debian includes Java (for rather complete values of Java, which seems to imply a certain proprietary implementation at the moment). Which non-free Java implementations are part of Debian? I know of none. I think that's exactly Florian's point. -- Colin Watson [EMAIL PROTECTED]
Re: Debconf or not debconf : Conclusion
On Friday 04 July 2003 05:59, Andrew Suffield wrote: Yes, keep the two versions of stunnel is probably the right way to handle this problem. Now the problem is that stunnel is uploaded in version 4 on stunnel package. What is the correct way to reintroduce stunnel for compatibility reasons ? uploading a new stunnel3 package will not resolve the problem. Epoch it and upload stunnel4 as a new package. Thanks, I will upload a stunnel4 package and a stunnel with Epoch tomorrow. Best Regards. -- Julien LEMOINE / SpeedBlue
Re: logging for package installs
Martin Quinson wrote: I want to help on this, please keep me informed ! Don't get the wrong idea: I just wanted to get the idea out there. I think if I was going to implement this I would have already, since I've had the idea in my head for several years. I hope someone will take it and run with it. -- see shy jo pgpJpU4onzJlH.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 02:04:51PM +0200, Florian Weimer wrote: So be it. The Social Contract and the traditions of our project compel us to make principled decisions, not politically expedient ones. Not correct. Look at the handling of security issues. The project has chosen (never formally, though) that it will sacrifice one of its core values to increase short-term user convenience. What you describe as user convenience translates into 4. Our Priorities are Our Users and Free Software We will be guided by the needs of our users and the free-software community. We will place their interests first in our priorities. Hence, you're on crack if you think that such sophistry works. But how far goes clause 4? Obviously not that far that Debian includes Java (for rather complete values of Java, which seems to imply a certain proprietary implementation at the moment). So, I assume that with that you mean that we have sacrificed one of our core values as well? My. All this sacrifice is making me hungry. :P -- 2. That which causes joy or happiness.
Re: Debconf or not debconf
On Thu, Jul 03, 2003 at 12:19:16PM -0500, Gunnar Wolf wrote: Keep stunnel as a stub package depending on either stunnel3 or stunnel4, change the description of stunnel3 explaining the situation and urging users to upgrade if possible. Yeah, he could use a debconf note for this for example. scnr, Michael
Re: 469 packages still using dh_undocumented, check if one is yours
On Fri, Jul 04, 2003 at 09:47:52AM +0200, Tollef Fog Heen wrote: | I came accross some sources still using dh_undocumented so I did a | quick search through sids *.diff.gz files. Here is the result: Such a list is useless unless it includes maintainer addresses (or just maintainer names) as well. [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ... Regards Artur -- kade takie zgoszenie [o bombie] sprawdzi musi nasz specjalista, powiedzmy pies /wypowied policjanta w TV/
Re: 469 packages still using dh_undocumented, check if one is yours
Artur R. Czechowski [EMAIL PROTECTED] writes: On Fri, Jul 04, 2003 at 09:47:52AM +0200, Tollef Fog Heen wrote: | I came accross some sources still using dh_undocumented so I did a | quick search through sids *.diff.gz files. Here is the result: Such a list is useless unless it includes maintainer addresses (or just maintainer names) as well. [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ... This doesn't help if you maintain dozens of packages and you just want to know if one of your packages is offending. Cheers, Benjamin -- .''`. ; ;' ; Debian GNU/Linux | Benjamin Drieu `. `'http://www.debian.org/ | [EMAIL PROTECTED] `- pgp0EUSGMFsXt.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 11:54:17PM -0500, Joe Wreschnig wrote: | How do you show it's not software? How does it differ from software? | | What if I take the view that Mozilla is an interpreter and anarchism is | the program? Please explain how that differs from the Perl interpreter | and Perl programs. I would argue that while Perl is Turing complete, HTML is not, thus anarchism is not software. Cameron.
Re: 469 packages still using dh_undocumented, check if one is yours
* Artur R. Czechowski | On Fri, Jul 04, 2003 at 09:47:52AM +0200, Tollef Fog Heen wrote: | | I came accross some sources still using dh_undocumented so I did a | | quick search through sids *.diff.gz files. Here is the result: | Such a list is useless unless it includes maintainer addresses (or | just maintainer names) as well. | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] Uhm, it's far easier just to generate the list so I can grep for my name in it. Scanning a list of 469 packages takes a while. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Please remove RFCs from the documentation in Debian packages
On Thu 03 Jul Petter Reinholdtsen wrote: [Javier Fernández-Sanguino Peña] (For those who are not aware of this issue, please read #92810) There seem to be someone believing that standard documents should be treated as software. Standards are not software. Standards do not improve if everyone is allowed to modify them and publish the modified version as an updated version of the standard. Standards get their value from having a rigid procedure for updates and modifications. Software do not. Ceci n'est pas une RFC. I think there's perhaps a problem with terminology here. A standards document is not the standard itself, it's just a written copy of it. Standards obviously do function by being commonly agreed, and therefore the actual standards do require some form of change control to be effective. Where the 'actual standard' resides is another question. The copy of the standard on my harddisk certainly isn't it though, and it doesn't have to be under change control - as long as it is clear whether it represents the standard or is just something similar, there's no problem with it being mutable. After all, if people being able to change copies of standards really was such a huge risk, then you'd not be able to publish them at all without some pretty serious DRM, just in case someone altered one and all hell broke loose. Look, I'm going to change the length of an IP datagram and damn the consequences, mwahahahahaha! Many of the reasons to prefer freedom in software apply to standards also - if a community of developers think a standard is poorly designed and wish to produce a new one derived from the old, that is surely of benefit to everyone, and for exactly the same reasons as freeness is of benefit in software. doug. -- Core GNOME developers are heavy Ketamine users -- http://www.illusionary.com/GNOMEvKDE.html pgpS1wdopfQ6V.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 09:45:41PM +0200, Emile van Bergen wrote: Why not indeed traft a DFDG spec that includes licenses such as the GFDL and IETF's and W3C's licenses, as someone suggested, and add a separate 'Documentation' section? Because that has been already drafted. Not only I suggested it, I pointed people to http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html. That section of the DDPolicy describes which are the accepted licenses for documentation and points to some discussions about the subject in debian-legal. Regards Javi pgpwt60ch0qMy.pgp Description: PGP signature
Re: 469 packages still using dh_undocumented, check if one is yours
On Fri, Jul 04, 2003 at 05:59:57PM +0200, Benjamin Drieu wrote: This doesn't help if you maintain dozens of packages and you just want to know if one of your packages is offending. On Fri, Jul 04, 2003 at 06:18:06PM +0200, Tollef Fog Heen wrote: Uhm, it's far easier just to generate the list so I can grep for my name in it. Scanning a list of 469 packages takes a while. You're both right. Thanks for pointing me this. I maintain only two packages now :) OTOH, maybe dh_undocumented should be removed from debhelper with prior notice? This program does nothing and should no longer be used. Regards Artur -- Tata: Jak si nazywasz? Synek: Igor spacja Sapijaszko. -- kade takie zgoszenie [o bombie] sprawdzi musi nasz specjalista, powiedzmy pies /wypowied policjanta w TV/ pgpFso7dz8Yjv.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 06:44:57PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: On Thu, Jul 03, 2003 at 09:45:41PM +0200, Emile van Bergen wrote: Why not indeed traft a DFDG spec that includes licenses such as the GFDL and IETF's and W3C's licenses, as someone suggested, and add a separate 'Documentation' section? Because that has been already drafted. Not only I suggested it, I pointed people to http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html. That section of the DDPolicy describes which are the accepted licenses for documentation and points to some discussions about the subject in debian-legal. This claims the GNU FDL is acceptable, so it's worse than useless. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpCWbII1BjXf.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 10:43:10PM +0100, Andrew Suffield wrote: You have some free software, and it comes with a manual. Your counter example does not apply to IETF Standards documentation. It is not software. In a more general reaction to posts on the list, to say an RFC is an editable document is downright silly. It is a literary work that is intended to be a static document, a reference for protocol implementation. An RFC goes through very little editorial changes once it's been published. The very process used by the IETF perserves previous versions of the documentation, this is why you find This document superceeds: ... Their copyright reflects this process. To require or demand that the IETF changes their copyright policy or their publishing practices to cater to someone else's idea of what the document should be used for is plain arogance. Respect the wishes of the original authors and the established, reliable publishing policy of the IETF, and use the document in the proper manner: reference it in your own supplemental documentation. If you really feel you must implement your software in a manner that doesn't comply with an existing RFC's, which is certainly acceptable, place that in your README or appropriate text. I really don't see what's wrong with the RFC copyright. It is freely distributable reference documentation. It is not software. Perhaps it shouldn't be distributed in Debian main because of a pedantic interpretation of the DFSG, (there's that software reference again) and Social Contract. Fine, but it should still be packaged. It is a valuable reference, and having the convenience of package installation improves it's distribution amongst developers. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgp4SsLR4JOmT.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
Andrew Suffield wrote: people to http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html. This claims the GNU FDL is acceptable, so it's worse than useless. It claims that GNU FDL sans cover texts and invariant sections is acceptable. Cheers T. pgpFhyQTZaH4d.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 12:47:19PM -0500, Chad Walstrom wrote: To require or demand that the IETF changes their copyright policy or their publishing practices to cater to someone else's idea of what the document should be used for is plain arogance. Which is why no one is doing any such thing. Instead, we are pointing out that the RFCs do not comply with the DFSG, and thus, under the Social Contract as written, should not be included in main. -- Steve Langasek postmodern programmer pgpVvASSUgK1x.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 07:47:32PM +0200, Thomas Viehmann wrote: Andrew Suffield wrote: people to http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html. This claims the GNU FDL is acceptable, so it's worse than useless. It claims that GNU FDL sans cover texts and invariant sections is acceptable. Which is grossly out of date (read: wrong). This has been discussed to death on -legal. Please leave armchair lawyering to the armchair lawyers -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpmok2hahqoj.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 12:47:19PM -0500, Chad Walstrom wrote: On Thu, Jul 03, 2003 at 10:43:10PM +0100, Andrew Suffield wrote: You have some free software, and it comes with a manual. Your counter example does not apply to IETF Standards documentation. It is not software. Then we have no business shipping it, particularly since it's non-free. In a more general reaction to posts on the list, to say an RFC is an editable document is downright silly. It is a literary work that is intended to be a static document, a reference for protocol implementation. Bullshit. It is common for RFCs to be revised over time, and formulated into new documents. This license prohibits agencies other than the IETF from revising an RFC and publishing the result. In addition, this license prohibits taking text from an RFC and using it in free documentation, or even in the --help output for free software. It's non-free whichever way you slice it. To require or demand that the IETF changes their copyright policy or their publishing practices to cater to someone else's idea of what the document should be used for is plain arogance. Respect the wishes of the original authors and the established, reliable publishing policy of the IETF, and use the document in the proper manner: reference it in your own supplemental documentation. Respect the wishes of the original authors of the software and use it in the proper manner: they way they intended it to be used, unmodified. Oh, oops. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpT9N6kosMJL.pgp Description: PGP signature
RFC Search engine in development
I've got a good start on an RFC search engine. Try it out at: http://www.pdxlinux.org/search.html ... and find the code at: http://www.hegbloom.net:3006/cgi-bin/viewcvs.cgi/?root=Perl The modules to look at are Swish.pm, RFC.pm, and the RFC/ directory. It needs to be completed and turned into an installable Debian package. The search part does not define the presentation. It returns a list of Perl hash data structures, so that the client code can present that any way it likes. This means that it can be used by a command line tool, perhaps called from inside emacs, or from a web front end like the one on pdxlinux.org, which is done using HTML::Mason. What do you think? Can you figure out my code? Need a tour? Are you a Perl programmer? I hope to find some time for completing this, but if yous want to work on it, go for it; just let me know so we can coordinate. -- Karl M. Hegbloom [EMAIL PROTECTED]
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 12:47:19PM -0500, Chad Walstrom wrote: To require or demand that the IETF changes their copyright policy or their publishing practices to cater to someone else's idea of what the document should be used for is plain arogance. Respect the wishes of the original authors and the established, reliable publishing policy of the IETF, and use the document in the proper manner: reference it in your own supplemental documentation. I don't think anyone is implying that they should do that. What is being stated is that the license terms are not Free. We have a commitment that everything in Debian main is Free. Since the RFC license is NOT Free, it can't be in main. This does NOT imply anything about the usefulness of RFCs, merely about their Freedom. This is one of the stronger arguments for keeping non-free around IMO. There *are* things which aren't Free, and very likely shouldn't ever be Free which nevertheless are useful things for our users to have. I use hwb on a regular basis, for example, and it is in non-free. I understand and agree with why it is in non-free, and I see no real problem with this. It's STILL useful enough to have it packaged and available to our users IMO. I really don't see what's wrong with the RFC copyright. It is freely distributable reference documentation. It is not software. Perhaps it shouldn't be distributed in Debian main because of a pedantic interpretation of the DFSG, (there's that software reference again) and Social Contract. Fine, but it should still be packaged. It is a valuable reference, and having the convenience of package installation improves it's distribution amongst developers. Exactly. We *must* be able to distribute by the terms of the license. Modifiability is less important for things like RFCs, certainly. I still think it's possible to license RFCs in a way I consider Free but which preserves their usefulness though. For example: You are free to distribute this RFC. You are free to modify the RFC and redistribute your modifications provided it is clearly marked as bein a modified version and NOT endorsed by IETF (perhaps forcing a rename also). I think something along those lines is Free and would pass DFSG (needs to be fleshed out and put into legalspeak, obviously), whilst still providing the protections that RFCs need from rogue modified standards documents. Cheers, Stephen
Re: 469 packages still using dh_undocumented, check if one is yours
On Fri, Jul 04, 2003 at 07:24:20PM +0200, Artur R. Czechowski wrote: OTOH, maybe dh_undocumented should be removed from debhelper with prior notice? This program does nothing and should no longer be used. well, this would break compatibility. IMHO i think it is enough to add a lintian check (well, i guess this is already the case) and add a todo on the package overview page. Actually vhanging the policy in that respect does create a lot of additional work and bugs, and we should just let this settle down, in 12 month or so this issue will be resolved without too much work wasted. 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: Please remove RFCs from the documentation in Debian packages
On Fri, 2003-07-04 at 11:06, Cameron Patrick wrote: On Thu, Jul 03, 2003 at 11:54:17PM -0500, Joe Wreschnig wrote: | How do you show it's not software? How does it differ from software? | | What if I take the view that Mozilla is an interpreter and anarchism is | the program? Please explain how that differs from the Perl interpreter | and Perl programs. I would argue that while Perl is Turing complete, HTML is not, thus anarchism is not software. So only programs in Turing-complete languages can be considered software? What if your program is written in a Turing-complete language (say, LaTeX), but doesn't require the language to be Turing-complete to run (like most LaTeX documents)? You could make a non-Turing complete LaTeX interpreter that would process the document just as well. Does that mean it's suddenly not software? What if I made Turing-complete language of which HTML is a subset? I could call it PHP. Don't Cc me. I'm on the list. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Please remove RFCs from the documentation in Debian packages
Andrew Suffield wrote: On Fri, Jul 04, 2003 at 07:47:32PM +0200, Thomas Viehmann wrote: Andrew Suffield wrote: people to http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html. This claims the GNU FDL is acceptable, so it's worse than useless. It claims that GNU FDL sans cover texts and invariant sections is acceptable. Which is grossly out of date (read: wrong). This has been discussed to death on -legal. ... which is much more interesting than your initial statement. Thanks for clairfying this. Cheers T. pgpN0teLrrdhr.pgp Description: PGP signature
unsubscribe
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 07:36:13PM +0100, Andrew Suffield wrote: Bullshit. It is common for RFCs to be revised over time, and formulated into new documents. This license prohibits agencies other than the IETF from revising an RFC and publishing the result. Yes, and the new document is given a new reference number. You've said the words yourself, formulated into new documents. The new document is referenced as RFC (MAX+1). The revision process itself shows that the document is static. Individual documents may prohibit editing, but the process encourages it. I suggest reading RFC 2026 in its entirety. In addition, this license prohibits taking text from an RFC and using it in free documentation, or even in the --help output for free software. Hmmm... In RFC 2026[1], which describes the Notifications to be included in each standards-related documentation, suggestes in section 10.4.(C) that such fair-use is allowed. Interesting that you would interpret it otherwise. It's non-free whichever way you slice it. I never said it wasn't. You're stating the obvious, because you're being pedantic about the DFSG. Like I said before, and a statement you conveinently overlooked in order to drag this thread out, that's fine. If you don't think it should be in main or even contrib, that's understandable. I stated that it SHOULD be packaged. Whether or not we include it in non-free is up for debate in yet another thread and mailing list, debian-legal. (See: beat dead horse) I apologize for getting into this thread to begin with, because I see we've become terribly off-topic. The original question was, Should we include RFC documentation in Official Debian packages? The answer, if we follow pedantic procedure with respect to DFSG and the Social Contract, is No. End of discussion. Respect the wishes of the original authors of the software and use it in the proper manner: they way they intended it to be used, unmodified. ...[snip]... Oh, oops. Exactly. Now you're getting it. Those English and Grammar classes must be paying off. References == 1. http://www.ietf.org/rfc/rfc2026.txt -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpmiIEiOlIES.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 01:18:02PM -0500, Steve Langasek wrote: Which is why no one is doing any such thing. Instead, we are pointing out that the RFCs do not comply with the DFSG, and thus, under the Social Contract as written, should not be included in main. Yes, I read more into the thread than was necessary. Its easy to forget the the rule of staying within the boundaries of the subject in question when tangentials are being thrown around freely. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpbUqVoV2yLJ.pgp Description: PGP signature
Re: Debian menu encoding support
#include hallo.h * Bill Allombert [Fri, Jul 04 2003, 08:55:41PM]: It is now possible to select the encoding used to write files generated by menu in a menu-method. You just need to add outputencoding=enc in the menu-method file, where enc is a valid iconv encoding. For example to force output to be UTF-8 encoded, add outputencoding=UTF-8 Jeez, let's reinvent the wheel. And again. And again. Now, you force every maintainer to update the menu entries for localisation, when will be the next time to change them again? Why cannot you just recognize that the Free Desktop format is superior and invest your manpower into tools for smooth transition to it? MfG, Eduard. -- weasel Smur: du brauchst nen Level 9 Analyzer Smur weasel: fällt dir da konkret n name ein?
Out of Office AutoReply: Application
Title: Out of Office AutoReply: Application I will be out-of-the-office on Thursday, July 3rd without any access to email or voicemai. If you require immediate assistance, you can try to contact Kim Parker at 763-212-6161. Thank you.
Re: 469 packages still using dh_undocumented, check if one is yours
* Bernd Eckenfels ([EMAIL PROTECTED]) [030704 20:50]: On Fri, Jul 04, 2003 at 07:24:20PM +0200, Artur R. Czechowski wrote: OTOH, maybe dh_undocumented should be removed from debhelper with prior notice? This program does nothing and should no longer be used. well, this would break compatibility. IMHO i think it is enough to add a lintian check (well, i guess this is already the case) and add a todo on the package overview page. It _is_ already the case, also for linda. And you can get results quite easy from http://lintian.debian.org/reports/Tlink-to-undocumented-manpage.html So no need for a extra tool. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster
On Thu, Jul 03, 2003 at 04:51:49PM +0200, Marc Haber wrote: Additionally, I would like to seriously propose establishing a pre-upload interface to ftpmaster so that a developer could learn that he is writing a package pending rejection after upload _before_ spending time on building that package. Actually I think ftp-master are having already too much power as a decision instance without real legitimation. Establishing yet another interface for them to block maintainers would need a resolution by the community that we are willing to delegate the job of verifying packages to them. In my situation ftp.masters once rejected a package because of licensing issues (which was ok), but then i reuploaded the package and the rejected it because of a missing (unneeded) configure option to exclude ssl. I think the time of the ftp masters could be spend on other issues without stepping on ppls feet. 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: [devel] logging for package installs
Op vr 04-07-2003, om 02:11 schreef Christoph Berg: Re: [devel] logging for package installs [Joey Hess [EMAIL PROTECTED], Thu, Jul 03, 2003 at 05:38:46PM -0400, [EMAIL PROTECTED]] - Display various fairly unimportant warnings, which are often not useful until after the package is installed and you're using it. - Display error messages, some fatal, and some not. - Show progress displays (in contravention of policy of course). - Various other indications of important and not so important things that the maintainer script is doing. - Remind users to read the README.Debian file. For most (some?) of these, the syslog could be used. Don't even think about it. Syslog is already such a mess that we need tools to parse it, and weed out the 'unimportant' information. Also, syslog is usually rotated, which means that this information would get lost fairly soon (if I'm not mistaken, the default logrotate configuration throws away information older than a week); As I understand Joey, that is not really the idea (but I could misunderstand him :-)
Re: 469 packages still using dh_undocumented, check if one is yours
On Fri, Jul 04, 2003 at 10:27:35PM +0200, Andreas Barth wrote: It _is_ already the case, also for linda. And you can get results quite easy from http://lintian.debian.org/reports/Tlink-to-undocumented-manpage.html This is treated by lintian as a warning. Policy says, that lack of manpage is considered as a bug. Shouldn't be its priority raised to error? I think that next step to be taken is informing concerned developers by email (debian-devel isn't obligatory). And next, after some reasonable(*) time, filling bug reports against packages which doesn't comply with policy. If you agree with me I can do this dirty work. (*) I am not sure, that bugfilling should be done before sarge comes to stable. But it should be done at the latest after release new stable. Regards Czesiu -- Nie wszystko dioda, co sie wieci /z pamitnika administratora/
Re: logging for package installs
Op do 03-07-2003, om 23:38 schreef Joey Hess: Maybe this is a good time to present this idea I've been kicking around, but never really got anywhere with, for as long as I've been working on debconf. My idea is to add an abstraction layer for package install-related logging in debian. Why limit that to install? Or do I misunderstand you, and do you actually mean 'installing and removing packages' (i.e., all maintainerscripts)? After all, stuff could go wrong with removing a package, too. [...] This could be bolted on the side of debconf. The abuse of debconf by maintainers who feel the need to do the kinds of things listed above certianly points at the need for this mechanism. And at least debconf has a kind of l10n framework, and some ideas about question priority. But this logging and message display is really conceptually different than debconf. Debconf is just there to ask questions. It would likely be better to design it as a separate program. Separate but similar, I'd say; similar in design (it would be nice if this program had a number of backends (sql-database, flat file, ...) to where logging information could be written *and* a number of front-ends to be used should the user request the information to be displayed at install time) and similar in UI, so that it doesn't look to the user as though this is something completely separate. Other than that, I very much like the idea.
Re: logging for package installs
On Thu, 3 Jul 2003, Joey Hess wrote: #!/bin/sh if [ $1 = configure ] grep -q evil /etc/myconfig; then dpkg-log --priority=critical \ --warning=$/etc/myconfig has evil in it! See README.Debian! elsif [ $phase_of_moon = full ]; then dpkg-log --priority=critical \ --error=$This package only upgrades during new moons. exit 1 fi Please call it deb-log, not dpkg-log. Also, note that $ is bash, not posix, while your #! line is only /bin/sh.
Re: 469 packages still using dh_undocumented, check if one is yours
On Fri, Jul 04, 2003 at 11:57:54PM +0200, Artur R. Czechowski wrote: I think that next step to be taken is informing concerned developers by email (debian-devel isn't obligatory). This is not needed, it is included in the policy change document. All developers who upgrade the policy standard will read it. And next, after some reasonable(*) time, filling bug reports against packages which doesn't comply with policy. You should only to that for packages which actually _do_ state, that they are 3.5.8 or higher. If you agree with me I can do this dirty work. Well, I dont see the point in mass filing bugs for lintian warnings/errors. 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 menu encoding support
Hi, * Eduard Bloch [EMAIL PROTECTED] [2003-07-04 22:17:23]: #include hallo.h * Bill Allombert [Fri, Jul 04 2003, 08:55:41PM]: It is now possible to select the encoding used to write files generated by menu in a menu-method. You just need to add outputencoding=enc in the menu-method file, where enc is a valid iconv encoding. For example to force output to be UTF-8 encoded, add outputencoding=UTF-8 Jeez, let's reinvent the wheel. And again. And again. Now, you force every maintainer to update the menu entries for localisation, when will be the next time to change them again? Why cannot you just recognize that the Free Desktop format is superior and invest your manpower into tools for smooth transition to it? Either you are trolling, or you don't know what you're talking about. There is nothing wrong with this change. It's just an improvement of our current _working_ menu system, enabling localized Debian menu section names. This is a pretty neat usability improvement, in the fact that the 'Debian' menu in my gnome-panel will finally have the menu section names in Danish instead of English. Is it so bad that he (and me, and others) are working on delivering a slightly improved menu system for sarge? Do you consider it his responsibility to step forward and transition to the Free Desktop standards, even when _no_ implementation that suits Debian has been developed yet? Think again. - Morten. -- http://mbrix.dk/
Re: Debian menu encoding support
Oh, and I forgot something... * Eduard Bloch [EMAIL PROTECTED] [2003-07-04 22:17:23]: #include hallo.h * Bill Allombert [Fri, Jul 04 2003, 08:55:41PM]: It is now possible to select the encoding used to write files generated by menu in a menu-method. You just need to add outputencoding=enc in the menu-method file, where enc is a valid iconv encoding. For example to force output to be UTF-8 encoded, add outputencoding=UTF-8 Jeez, let's reinvent the wheel. And again. And again. Now, you force every maintainer to update the menu entries for localisation, when will be the next time to change them again? Why cannot you just recognize that the Free Desktop format is superior and invest your manpower into tools for smooth transition to it? It's not _every maintainer_. It is maintainers of packages providing menu-methods. Just as stated in the announcement. I would estimate that it's probably only 10-15 packages supplying those. - Morten. -- http://mbrix.dk/
Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster
On Thursday 03 July 2003 16:51, Marc Haber wrote: Additionally, I would like to seriously propose establishing a pre-upload interface to ftpmaster so that a developer could learn that he is writing a package pending rejection after upload _before_ spending time on building that package. I find it disturbingly impolite to say sorry, we don't want your volunteer work _after_ the work has been done. Especially if it is done in Mr. Troup's usual why did you bother me in the first place, mere mortal style. I find that to be a very unfair accusation, since at least to my eyes there was nothing especially unfriendly, unreasonable or otherwise criticizable in James rejection notice. If he had told you that the package was never going to be included for some not entirely obvious reason then I could understand your sentiment, but stating his reasons, and then referring you to a public list for further discussion, (thereby, in my reading at least, implying that while he thinks the package isn't suitable at least yet, public discussion might reveal otherwise) seems quite fair to me. I personally very much value the fact that someone like James whose knowledge and judgment I trust invests so much time in vetting (my) packages for potential omissions or stupidities. Cheers, Yven Greetings Marc, somewhat mad at the moment Hmm, *my* strategy for handling such states of emotional unrest is to wait at least half a day to see how much anger or madness is actually left, since I find that to be an enormous efficiency gain with respect to avoiding lengthy and pointless discussions... ;-) -- Yven Johannes Leist - [EMAIL PROTECTED] http://www.leist.beldesign.de
Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster
Bernd Eckenfels [EMAIL PROTECTED] wrote:
In my situation ftp.masters once rejected a package because of licensing
issues (which was ok), but then i reuploaded the package and the rejected it
because of a missing (unneeded) configure option to exclude ssl. I think the
I don't know the specifics of this case but perhaps they were worried
about the possibility of pulling ssl into a GPLed program accidentally?
If that's the case then it's certainly a valid reason to reject the
package.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Please remove RFCs from the documentation in Debian packages
Brian == Brian May [EMAIL PROTECTED] writes: Brian Couldn't you write a new document along the lines of This is Brian based on RFC1341 with the following exceptions ? Brian That way you can see exactly what differences there are to the Brian known standard, at a glance, without having to resort to using Brian tools like diff. Don't mix up the philosophical problem with the technical concerns. Yes, there are times when what you say makes sense and is preferable. But at other times there are other concerns that makes it impractical or difficult (e.g., there are just too many changes, new concepts are introduced, etc). The question is not whether there are situations when it is no good for users to change the documents. It is instead whether the author of the RFCs (or the IETF RFC process) should restrict me from using the standard that way if I found it to best suit my needs---and if they do restrict me, whether Debian should still say it is part of the free stuffs that it delivers. Regards, Isaac.
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 04:24:20PM +0800, Isaac To wrote: It is far from obvious. What if I develop my software, finds the specification of MIME to be very similar to what my software does, but yet I need to modify the things here and there so as to suit my needs; and when documenting my software I want to use RFC 1341 as a starting point, change those things that my software do differently than 1341, and then say that is the documentation of my software? I have no intention to confuse the result with RFC 1341, so what's wrong to do the edit (except that the author of RFC 1341 might be unhappy with that)? To the user it is really best done that way: if I have to rewrite 1341 I probably won't give documentation at all because I don't have the time. If instead I just point out the positions that my software differs from 1341 the user would have to read two different documents. Couldn't you write a new document along the lines of This is based on RFC1341 with the following exceptions ? That way you can see exactly what differences there are to the known standard, at a glance, without having to resort to using tools like diff. -- Brian May [EMAIL PROTECTED]
Re: 469 packages still using dh_undocumented, check if one is yours
Artur R. Czechowski wrote: OTOH, maybe dh_undocumented should be removed from debhelper with prior notice? This program does nothing and should no longer be used. As a rule I try to avoid causing less than 469 FTBFS bugs with any given change I make to debhelper. I have removed programs when as many as three packages still used them, after appropriate bug reports and a two month grace period. -- see shy jo pgpOWvoz2vuIK.pgp Description: PGP signature
Re: Debian menu encoding support
Bill Allombert wrote: For ISO-8859-1, outputencoding=ISO-8859-1 There is a special encoding LOCALE, which refers to the current locale encoding. Won't this make the menu-method not work with versions of menu prior to 2.1.9-1? Packages would need to update their depends or conflicts with menu to ensure a new enough version is installed. Otherwise it fails with an Unknown identifier error message. -- see shy jo pgpy2qSMhFcq6.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Sat, Jul 05, 2003 at 11:41:51AM +1000, Brian May wrote: Couldn't you write a new document along the lines of This is based on RFC1341 with the following exceptions ? Tell that to the authors of RFC2616 :-) Sometimes it's very valuable to NOT have people reading the old version first, for example because it's full of information that is almost but entirely not correct. Then you want them to instead read a consistent presentation of the new standard. Now, you might want to say that only the IETF should be allowed to produce something like RFC2616. That's fine as long as the IETF is the smart and effective body it is now and everyone is welcome to join it. But how do you know this will still be the case 20 years later? The arguments against forking standards are pretty similar to the arguments against forking gcc -- in both cases it's generally a bad idea, but the health of a free system depends on it being potentially possible. Richard Braakman
Accepted minicom 2.1-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 04 Jul 2003 09:11:15 +0200 Source: minicom Binary: minicom Architecture: source i386 Version: 2.1-3 Distribution: unstable Urgency: low Maintainer: Martin A. Godisch [EMAIL PROTECTED] Changed-By: Martin A. Godisch [EMAIL PROTECTED] Description: minicom- Clone of the MS-DOS Telix communications program Closes: 199924 Changes: minicom (2.1-3) unstable; urgency=low . * Fixed handling of white space in file names, closes: #199924. * Updated deb'configuration, made it optional. * Changed default value for minirc.* update to false. * Re-added lost *.gmo recreation. * Added patch to build-dependencies. Files: 1ed329cf827f6bc89847bc5dc84d6dd5 644 comm optional minicom_2.1-3.dsc f0d70aa1476b21c452494de2e7af85e1 13730 comm optional minicom_2.1-3.diff.gz 33fa35d2ccab69e8c848d2250b97a3b3 274488 comm optional minicom_2.1-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/BStumpGCHWjc1gYRAtzvAJsFWveUj6din8xqcUHfBkxbOL9iRwCg3p5j SZvwUovmo84JUc7YWnTXMmc= =AqBZ -END PGP SIGNATURE- Accepted: minicom_2.1-3.diff.gz to pool/main/m/minicom/minicom_2.1-3.diff.gz minicom_2.1-3.dsc to pool/main/m/minicom/minicom_2.1-3.dsc minicom_2.1-3_i386.deb to pool/main/m/minicom/minicom_2.1-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
