Re: Non-english license and documents
On Tue, 2006-05-23 at 15:22 -0400, Joe Smith wrote: Jamie Jones [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Based on my understanding of Japanese law, the original document being in Japanese is the one that is legally binding, even if the author makes an English translation. Other jurisdictions may accept a hypothetical English translation, but in the event of a dispute, the correct terms are in the Japanese version. I assume that the author could in theory make the English document caniconical, and the Japanese version non-binding. Would this be corretct? As I understand it, in Japan, no. Of course that assumes the author is fluent in English, which may not be the case. It has been my experience that no English documents (excluding the constitution of Japan) have any legal status. Would your country (if it has one official language) accept documents written in another language, without a government certified translation ? Mine does not. Regards -- Jamie Jones Proprietor E-Yagi Consulting ABN: 32 138 593 410 Mob: +61 4 16 025 081 Email: [EMAIL PROTECTED] Web: http://www.eyagiconsulting.com GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x4B6E7209 Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209 signature.asc Description: This is a digitally signed message part
Re: Non-english license and documents
On Tue, 2006-05-23 at 15:21 -0400, Joe Smith wrote: Jamie Jones [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Only if an adequate English version was available [1], pruning the Japanese docs would be an option IMO (and only because ~99.9% of Japanese people have good command of English). You must have a very different experience of Japanese people then I do. If we talk percentages using my immediate family as an example, only 33% of them speak any English, and of that, only 16% would speak what is considered good English. Far less then the ~99.9% you quote. In short dropping the Japanese docs should not be an option even if an English version is available. Well, remember that there are four distinct parts to language comprehension. Reading, writing, listening, and speaking. Perhaps you feel I don't understand this, but as I deal with this on a daily basis, I assure you I understand this very well, more so then most monolingual people would. Reading is easier than writing, and listening is easier than speaking. Debatable. It very much depends on the person and how they learn a language. I'd argue that listening, and speaking are easier, then reading and writing. Don't believe me ? Watch children learn their first (or second) language, they always speak second, after listening first. Very different to formal language classes. I suspect that some of your family can understand English far better than they can produce it. Yes, that's the 17% that don't speak good English. While it is common for most Japanese to attend an English class, that by no means enables them to understand it, after all, it is not the language they use to carry out their daily duties. Japanese's relationship with English is complicated. There is regular English, transliterated English, and several transliterated English words have been adopted by the Japanese language. I really see no difference between how Japanese and English languages evolve. They both adopt useful words from other languages, sometimes changing the meaning in the process. I have heard of some Japanese product manuals written entirely in transliterated English! (Using kana. This is a bit annoying to US importers of the product, who would prefer real English, or at the very least, transliterated English written in romaji. [Normal English speakers could probably guess the original English word often enough to understand the sentences.]) Well, the importer could a gotten a sample product first to determine if they would need to translate the manual themselves. Then we could debate which dialect of English should be used, that used in the Commonwealth and former colonies, or that used by the USA and former colonies. This has been a fascinating learning experience for me. I've discovered that it seems that people believe that it is ok to insist on changing the language of a document into English, because they don't understand the language it is in. It also shows there is a widespread belief that most if not all Japanese understand English, so it is ok to remove Japanese documentation. In the words of an exasperated Japanese person I know while stuck trying to express themselves in English What makes English so fucking great ? I have my language too! What I'd like these people to do for a moment is assume you speak a language other then English as your only language, say an East-Asian one, Chinese, Japanese or Korean. Now, you are packaging some software, but the license is in English. Do you insist the author re-write the license in your language and remove the English version? Why/Why Not ? -- Jamie Jones Proprietor E-Yagi Consulting ABN: 32 138 593 410 Mob: +61 4 16 025 081 Email: [EMAIL PROTECTED] Web: http://www.eyagiconsulting.com GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x4B6E7209 Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209 signature.asc Description: This is a digitally signed message part
Re: Non-english license and documents
On Wed, 2006-05-24 at 14:52 +0800, Ying-Chun Liu wrote: Jamie Jones wrote: On Tue, 2006-05-23 at 13:27 +0200, Adam Borowski wrote: On Tue, May 23, 2006 at 02:30:50PM +1000, Jamie Jones wrote: In the event of any license related issues perhaps caused by mis-translation, the Japanese version is the canonical version that must be followed. Isn't this the case only if someone else than the author translated the license? Based on my understanding of Japanese law, the original document being in Japanese is the one that is legally binding, even if the author makes an English translation. Other jurisdictions may accept a hypothetical English translation, but in the event of a dispute, the correct terms are in the Japanese version. IANAL, TINLA. Regards, Many of the non-English speaking countries only accept the law terms written in their official languages. What should I do if I want to package the software if the license in every files in the source tarball is non-English? Should I paste the non-English license to debian-legal for comments? Or should I ask the upstream author to remove the non-English version and add an English one? What is the proper way? Thanks, Ying-Chun Liu You should do the exact same thing as if the license was written in English. You leave the license in the source, solicit feedback from -legal (which may take a while), and see if you can get an unofficial translation from a translation team. To be perfectly honest, had the license been written in English, you'd have never asked this question, would you ? Why is the process any different for other languages. Regards -- Jamie Jones Proprietor E-Yagi Consulting ABN: 32 138 593 410 Mob: +61 4 16 025 081 Email: [EMAIL PROTECTED] Web: http://www.eyagiconsulting.com GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x4B6E7209 Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209 signature.asc Description: This is a digitally signed message part
Re: Non-english license and documents
On Mon, 2006-05-22 at 22:10 +0200, Adam Borowski wrote: On Mon, May 22, 2006 at 10:32:18PM +0800, Ying-Chun Liu wrote: Second, the javadoc documents coming with the source files are Japanese. Should I prune the documents or include them? How do I include them? Please, keep them. Removing documentation is a disservice to the users, even if only a part of them can read it. I second keeping them. Only if an adequate English version was available [1], pruning the Japanese docs would be an option IMO (and only because ~99.9% of Japanese people have good command of English). You must have a very different experience of Japanese people then I do. If we talk percentages using my immediate family as an example, only 33% of them speak any English, and of that, only 16% would speak what is considered good English. Far less then the ~99.9% you quote. In short dropping the Japanese docs should not be an option even if an English version is available. But in every *.java (source code) the license is written in Japanese (same as the license shown on the Japanese page). Because I'm not good at Japanese, so I can't make sure the license in Japanese is free or not. Is there any way to deal with the problem without asking the upstream author to change the source files? FTPmasters and our debian-legal mavens tend to REALLY look down upon removing license notices from source files. If we have a license in English that came from the author (and thus is legally binding), the Japanese copy is harmless, and it will get compressed away by tar|gz so disk space is not a concern as well. Of course, let's have a Japanese-speaking person take a look at the text, but IMHO you don't need to bother about any accuracy higher than this looks to be the same as the English version. In the event of any license related issues perhaps caused by mis-translation, the Japanese version is the canonical version that must be followed. Regards, -- Jamie Jones Proprietor E-Yagi Consulting ABN: 32 138 593 410 Mob: +61 4 16 025 081 Email: [EMAIL PROTECTED] Web: http://www.eyagiconsulting.com GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x4B6E7209 Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209 signature.asc Description: This is a digitally signed message part
Re: Non-english license and documents
On Tue, 2006-05-23 at 13:27 +0200, Adam Borowski wrote: On Tue, May 23, 2006 at 02:30:50PM +1000, Jamie Jones wrote: In the event of any license related issues perhaps caused by mis-translation, the Japanese version is the canonical version that must be followed. Isn't this the case only if someone else than the author translated the license? Based on my understanding of Japanese law, the original document being in Japanese is the one that is legally binding, even if the author makes an English translation. Other jurisdictions may accept a hypothetical English translation, but in the event of a dispute, the correct terms are in the Japanese version. IANAL, TINLA. Regards, -- Jamie Jones Proprietor E-Yagi Consulting ABN: 32 138 593 410 Mob: +61 4 16 025 081 Email: [EMAIL PROTECTED] Web: http://www.eyagiconsulting.com GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x4B6E7209 Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209 signature.asc Description: This is a digitally signed message part
Re: Handling of GnuWin32 source packages
On Tue, 2006-03-14 at 00:28 +0100, Volker Grabsch wrote: The extra work of duplicate security fixes is IMHO very small compared to the additional infrastructural work of keeping lots of Debian packages win32 portable, duplicating maintaining work which is already done by the GnuWin32 project. Is it really that much more work then what is required keep Debian packages portable to both the Hurd and Freebsd kernels ? There already is a free implementation of a Win32 kernel at ReactOS ( http://www.reactos.org/xhtml/en/index.html ) so it's not a non-free kernel anymore (although granted it is not a *NIX style kernel) Regards, -- Jamie Jones Proprietor E-Yagi Consulting ABN: 32 138 593 410 Mob: +61 4 16 025 081 Email: [EMAIL PROTECTED] Web: http://www.eyagiconsulting.com GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x4B6E7209 Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209 signature.asc Description: This is a digitally signed message part
Re: performance tip for the package development stage
On Sat, 2005-05-21 at 14:28 +0300, Shachar Shemesh wrote: Personally, I wouldn't use this for compiling the package after you have done with the debian related development, but the ccache author claims it's totally safe for that as well. I haven't had any problems with ccache on my unoffical packages, so it should be fine. Another very useful program if you have multiple computers is distcc, it farms out compilation jobs to speed compiling up. I found a nice write up here http://www.debian-administration.org/?article=112 ccache is also mentioned here http://www.debian-administration.org/?article=129 To get the best benefit you would probaly want to configure your system so when you call gcc/g++ it goes ccache - distcc - gcc/g++ Jamie -- GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x42E2C1E5 Fingerprint 3C77 9621 84C5 C32F D409 A38D A035 7E65 42E2 C1E5 signature.asc Description: This is a digitally signed message part
Re: build test
On Thu, 2005-04-28 at 16:29 +0300, Stanislav Maslovski wrote: No problems. Built the new package on amd64. Still some warnings in avinfo.c about cast from pointer to integer of different size Jamie -- GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x42E2C1E5 Fingerprint 3C77 9621 84C5 C32F D409 A38D A035 7E65 42E2 C1E5 Script started on Thu 28 Apr 2005 14:24:52 UTC ]0;[EMAIL PROTECTED]: /home/jamie/avinfo(devel_ubuntu_hoary_amd64)[EMAIL PROTECTED]:~/avinfo# sudo pbul[Kilder build avinfo_1.0.a15-1.dsc W: /home/jamie/.pbuilderrc does not exist I: using fakeroot in build. pbuilder-buildpackage/amd64 $Id: pbuilder-buildpackage-funcs,v 1.15 2005/01/04 01:47:18 dancer Exp $ $Id: pbuilder-buildpackage,v 1.110 2005/01/04 01:47:18 dancer Exp $ Current time: Thu Apr 28 14:25:15 UTC 2005 pbuilder-time-stamp: 1114698315 Building the build Environment - extracting base tarball [/home/jamie/chroots/pbuilder/ubuntu-hoary-amd64/base.tar.gz] - creating local configuration - copying local configuration - mounting /proc filesystem - mounting /dev/pts filesystem - policy-rc.d already exists - created buildresult dir :/home/jamie/chroots/pbuilder/ubuntu-hoary-amd64/result/ Obtaining the cached apt archive contents Installing the build-deps - Attempting to parse the build-deps : pbuilder-satisfydepends,v 1.18 2003/04/20 03:40:36 dancer Exp $ - Considering debhelper (= 4.0.0) - Trying debhelper - Considering bison - Trying bison - Installing debhelper bison Reading package lists... 0% Reading package lists... 100% Reading package lists... Done Building dependency tree... 0% Building dependency tree... 0% Building dependency tree... 50% Building dependency tree... 50% Building dependency tree... Done The following extra packages will be installed: debconf-utils file gettext gettext-base html2text intltool-debian libmagic1 m4 po-debconf Suggested packages: dh-make cvs gettext-doc Recommended packages: libmail-sendmail-perl The following NEW packages will be installed: bison debconf-utils debhelper file gettext gettext-base html2text intltool-debian libmagic1 m4 po-debconf 0 upgraded, 11 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/3310kB of archives. After unpacking 10.9MB of additional disk space will be used. debconf: delaying package configuration, since apt-utils is not installed Selecting previously deselected package libmagic1. (Reading database ... 8075 files and directories currently installed.) Unpacking libmagic1 (from .../libmagic1_4.12-1_amd64.deb) ... Selecting previously deselected package file. Unpacking file (from .../archives/file_4.12-1_amd64.deb) ... Selecting previously deselected package gettext-base. Unpacking gettext-base (from .../gettext-base_0.14.1-6_amd64.deb) ... Selecting previously deselected package m4. Unpacking m4 (from .../archives/m4_1.4.2-1_amd64.deb) ... Selecting previously deselected package bison. Unpacking bison (from .../bison_1%3a1.875d-1_amd64.deb) ... Selecting previously deselected package debconf-utils. Unpacking debconf-utils (from .../debconf-utils_1.4.42ubuntu4_all.deb) ... Selecting previously deselected package html2text. Unpacking html2text (from .../html2text_1.3.2a-1_amd64.deb) ... Selecting previously deselected package gettext. Unpacking gettext (from .../gettext_0.14.1-6_amd64.deb) ... Selecting previously deselected package intltool-debian. Unpacking intltool-debian (from .../intltool-debian_0.30+20040213_all.deb) ... Selecting previously deselected package po-debconf. Unpacking po-debconf (from .../po-debconf_0.8.17_all.deb) ... Selecting previously deselected package debhelper. Unpacking debhelper (from .../debhelper_4.2.28ubuntu4_all.deb) ... Setting up libmagic1 (4.12-1) ... Setting up file (4.12-1) ... Setting up gettext-base (0.14.1-6) ... Setting up m4 (1.4.2-1) ... Setting up bison (1.875d-1) ... Setting up debconf-utils (1.4.42ubuntu4) ... Setting up html2text (1.3.2a-1) ... Setting up gettext (0.14.1-6) ... Setting up intltool-debian (0.30+20040213) ... Setting up po-debconf (0.8.17) ... Setting up debhelper (4.2.28ubuntu4) ... - Finished parsing the build-deps Reading package lists... 0% Reading package lists... 0% Reading package lists... 94% Reading package lists... Done Building dependency tree... 0% Building dependency tree... 0% Building dependency tree... 50% Building dependency tree... 50% Building dependency tree... Done gnupg is already the newest version. devscripts is already the newest version. sudo is already the newest version. fakeroot is already the newest version. fakeroot is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Copying back the cached apt archive contents Copying source file - copying [avinfo_1.0.a15-1.dsc] - copying [./avinfo_1.0.a15.orig.tar.gz] - copying [./avinfo_1.0.a15-1.diff.gz] Extracting source dpkg-source: warning: no utmp entry available and LOGNAME not defined;
Re: build test
On Wed, 2005-04-27 at 16:54 +0300, Stanislav Maslovski wrote: If somebody tests it on archs different from i386 or Sparc it will help me a lot! If somebody decides to sponsor it that will be even better ;-) Builds on amd64. -- GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x42E2C1E5 Fingerprint 3C77 9621 84C5 C32F D409 A38D A035 7E65 42E2 C1E5 signature.asc Description: This is a digitally signed message part
Re: build test
On Thu, 2005-04-28 at 00:23 +1000, Jamie Jones wrote: On Wed, 2005-04-27 at 16:54 +0300, Stanislav Maslovski wrote: If somebody tests it on archs different from i386 or Sparc it will help me a lot! If somebody decides to sponsor it that will be even better ;-) Builds on amd64. Oops. Forgot to attach the build log earlier. -- GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x42E2C1E5 Fingerprint 3C77 9621 84C5 C32F D409 A38D A035 7E65 42E2 C1E5 Script started on Wed 27 Apr 2005 15:58:18 UTC ]0;[EMAIL PROTECTED]: /home/jamie/avinfo(devel_ubuntu_hoary_amd64)[EMAIL PROTECTED]:~/avinfo# sudo pbuilder build avinfo_1.0.a15-1.dsc W: /home/jamie/.pbuilderrc does not exist I: using fakeroot in build. pbuilder-buildpackage/amd64 $Id: pbuilder-buildpackage-funcs,v 1.15 2005/01/04 01:47:18 dancer Exp $ $Id: pbuilder-buildpackage,v 1.110 2005/01/04 01:47:18 dancer Exp $ Current time: Wed Apr 27 15:58:29 UTC 2005 pbuilder-time-stamp: 1114617509 Building the build Environment - extracting base tarball [/home/jamie/chroots/pbuilder/ubuntu-hoary-amd64/base.tar.gz] - creating local configuration - copying local configuration - mounting /proc filesystem - mounting /dev/pts filesystem - policy-rc.d already exists - created buildresult dir :/home/jamie/chroots/pbuilder/ubuntu-hoary-amd64/result/ Obtaining the cached apt archive contents Installing the build-deps - Attempting to parse the build-deps : pbuilder-satisfydepends,v 1.18 2003/04/20 03:40:36 dancer Exp $ - Considering debhelper (= 4.0.0) - Trying debhelper - Considering bison - Trying bison - Installing debhelper bison Reading package lists... 0% Reading package lists... 100% Reading package lists... Done Building dependency tree... 0% Building dependency tree... 0% Building dependency tree... 50% Building dependency tree... 50% Building dependency tree... Done The following extra packages will be installed: debconf-utils file gettext gettext-base html2text intltool-debian libmagic1 m4 po-debconf Suggested packages: dh-make cvs gettext-doc Recommended packages: libmail-sendmail-perl The following NEW packages will be installed: bison debconf-utils debhelper file gettext gettext-base html2text intltool-debian libmagic1 m4 po-debconf 0 upgraded, 11 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/3310kB of archives. After unpacking 10.9MB of additional disk space will be used. debconf: delaying package configuration, since apt-utils is not installed Selecting previously deselected package libmagic1. (Reading database ... 8075 files and directories currently installed.) Unpacking libmagic1 (from .../libmagic1_4.12-1_amd64.deb) ... Selecting previously deselected package file. Unpacking file (from .../archives/file_4.12-1_amd64.deb) ... Selecting previously deselected package gettext-base. Unpacking gettext-base (from .../gettext-base_0.14.1-6_amd64.deb) ... Selecting previously deselected package m4. Unpacking m4 (from .../archives/m4_1.4.2-1_amd64.deb) ... Selecting previously deselected package bison. Unpacking bison (from .../bison_1%3a1.875d-1_amd64.deb) ... Selecting previously deselected package debconf-utils. Unpacking debconf-utils (from .../debconf-utils_1.4.42ubuntu4_all.deb) ... Selecting previously deselected package html2text. Unpacking html2text (from .../html2text_1.3.2a-1_amd64.deb) ... Selecting previously deselected package gettext. Unpacking gettext (from .../gettext_0.14.1-6_amd64.deb) ... Selecting previously deselected package intltool-debian. Unpacking intltool-debian (from .../intltool-debian_0.30+20040213_all.deb) ... Selecting previously deselected package po-debconf. Unpacking po-debconf (from .../po-debconf_0.8.17_all.deb) ... Selecting previously deselected package debhelper. Unpacking debhelper (from .../debhelper_4.2.28ubuntu4_all.deb) ... Setting up libmagic1 (4.12-1) ... Setting up file (4.12-1) ... Setting up gettext-base (0.14.1-6) ... Setting up m4 (1.4.2-1) ... Setting up bison (1.875d-1) ... Setting up debconf-utils (1.4.42ubuntu4) ... Setting up html2text (1.3.2a-1) ... Setting up gettext (0.14.1-6) ... Setting up intltool-debian (0.30+20040213) ... Setting up po-debconf (0.8.17) ... Setting up debhelper (4.2.28ubuntu4) ... - Finished parsing the build-deps Reading package lists... 0% Reading package lists... 0% Reading package lists... 94% Reading package lists... Done Building dependency tree... 0% Building dependency tree... 0% Building dependency tree... 50% Building dependency tree... 50% Building dependency tree... Done gnupg is already the newest version. devscripts is already the newest version. sudo is already the newest version. fakeroot is already the newest version. fakeroot is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Copying back the cached apt archive contents Copying source file - copying [avinfo_1.0.a15-1.dsc] - copying [./avinfo_1.0.a15.orig.tar.gz
Revision control systems and Debian packages
Can anybody suggest some good revision control systems for maintaining Debian packages. I'm about to outgrow using RCS on the debian directory and wanted to get an idea of what other maintainers are using for their packages. Thanks Jamie -- GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x42E2C1E5 Fingerprint 3C77 9621 84C5 C32F D409 A38D A035 7E65 42E2 C1E5 signature.asc Description: This is a digitally signed message part
Re: Revision control systems and Debian packages
On Wed, 2005-04-13 at 08:39 -0300, Henrique de Moraes Holschuh wrote: On Wed, 13 Apr 2005, Christoph Berg wrote: Re: Jamie Jones in [EMAIL PROTECTED] Can anybody suggest some good revision control systems for maintaining Debian packages. I'm about to outgrow using RCS on the debian directory and wanted to get an idea of what other maintainers are using for their packages. svn-buildpackage. or tla-buildpackage (using bazaar, NOT tla) for that matter. Read http://www.dwheeler.com/essays/scm.html to help you make up your mind about which... Thank You. That was an interesting read. I'll give subversion a try first as it's closer to what I'm used to. Jamie -- GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x42E2C1E5 Fingerprint 3C77 9621 84C5 C32F D409 A38D A035 7E65 42E2 C1E5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Revision control systems and Debian packages
On Wed, 2005-04-13 at 14:31 +0200, martin f krafft wrote: also sprach Jamie Jones [EMAIL PROTECTED] [2005.04.13.1317 +0200]: Can anybody suggest some good revision control systems for maintaining Debian packages. I'm about to outgrow using RCS on the debian directory and wanted to get an idea of what other maintainers are using for their packages. http://arch.debian.org/arch/private/srivasta/ http://debian.madduck.net/pkg-zope/wiki/Arch/Package Thanks, those are excellent links for using revision control systems with Debian Packages. It would be nice if they were linked to in the FAQ or NM guide, because I didn't find anything like that with google. Jamie -- GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x42E2C1E5 Fingerprint 3C77 9621 84C5 C32F D409 A38D A035 7E65 42E2 C1E5 signature.asc Description: This is a digitally signed message part
Re: reassigning bugs
On Wed, 2005-03-30 at 10:23 -0300, Henrique de Moraes Holschuh wrote: On Wed, 30 Mar 2005, Jeroen van Wolffelaar wrote: This should be better documented indeed, but most if not all tools Time to file a bug report. What is the package responsible for the BTS documentation on the web? I would assume it is either the www.debian.org pesudo-package or the bugs.debian.org pesudo-package. My rational is that if it is on the website then www.debian.org is responsible, but it affects the bts so bugs.debian.org is responsible. Pick one, the other or both :) If it's wrong then it will get reassigned. -- GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x42E2C1E5 Fingerprint 3C77 9621 84C5 C32F D409 A38D A035 7E65 42E2 C1E5 signature.asc Description: This is a digitally signed message part
Directing bug reports away from the Debian BTS
G'day, I maintain a few unoffical Debian packages. Before I make my repository available to the world, I'd like to ensure that if someone runs reportbug on one of my packages, it will email me, and not the Debian BTS. The packages are targeted at sarge or better. Thank you for your kind assistance Jamie -- PGP/MIME or S/MIME signed mail preferred. No HTML mail. No Word attachments. PGP Key ID 0x42E2C1E5 Fingerprint 3C77 9621 84C5 C32F D409 A38D A035 7E65 42E2 C1E5 signature.asc Description: This is a digitally signed message part
Re: Directing bug reports away from the Debian BTS
On Tue, 2005-03-08 at 18:28 -0800, Don Armstrong wrote: On Wed, 09 Mar 2005, Jamie Jones wrote: G'day, I maintain a few unoffical Debian packages. Before I make my repository available to the world, I'd like to ensure that if someone runs reportbug on one of my packages, it will email me, and not the Debian BTS. See /usr/share/doc/reportbug/README.Developers; Basically, you want a Send-To: foobts.foobar.org or whatever in /usr/share/bug/$package/control; Alternatively, add a Bugs: and Origin: field to your control file so reportbug (and otherfrontends) will know to read it and send bugs to the appropriate location. Excellent. Thank you Don. In case anyone was intrested a list of my packages is here http://eyagi.bpa.nu/~jamie/doomsday.html Jamie -- PGP/MIME or S/MIME signed mail preferred. No HTML mail. No Word attachments. PGP Key ID 0x42E2C1E5 Fingerprint 3C77 9621 84C5 C32F D409 A38D A035 7E65 42E2 C1E5 signature.asc Description: This is a digitally signed message part
